Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.

Transparent Proxy / Route
Proxy or route all traffic between a client to various destination IP(s) through an alternative proxy
server or tunneled gateway.
Assumption: Traffic should not be encrypted, it will only raise a red flag.
General Issues:
Authentication
The FT firmware already ships with a auth protocol that is encrypted and can be used as the
basis for authenticating with a proxy server.
Note: rather than re-use the same pre-shared key as with mm crypto, we should just deploy
another key for proxy authentication and encryption.
- CherryTree based auth and handoff
Pros: no additional crypto lib required to hide pre shared key or credentials.
CT protocol could determine the client proxy type and select an appropriate server
impl.
CB Server could host a local openvpn or socat server or 'pipe' the connection to another
server.
means of quickly adding support for proxy with minimal overhead to Frontend.
Cons: VPN client software on the FT must be customized to integrate with an initial
handshake prior to after establishing a TCP tunnel. i.e. Customization of socat or openvpn
client app. Susceptible to replay attack.
- ssl certificate auth
Pros: socat and openvpn already support ssl integration
Cons: requires a significant extra space on FT firmware
still requires a means of authentication as part of establishing the ssl connection
- pre deploy server or root certificate so that the client can avoid a MITM attack
- deploy proxy IP, certificate or credentials in the mission
DNS request handling
If a client's traffic is routed through a proxy server, then the client's nameserver(s) may not be
accessible.
Potential Solutions:

e-Highlighter

Click to send permalink to address bar, or right-click to copy permalink.

Un-highlight all Un-highlight selectionu Highlight selectionh