Vault 7: Projects

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

2. Application layer impl:
Pros
- Could be as simple as mission cmd exec support. e.g. exec netcat –args
-simple impl. leads to control of alternative tools that may be available on some FTs
Cons
- not as reliable and as good of performance as NAT translation (marginal considering use
cases)
may be easier to provide an application layer impl on some devices
even application layer impl. still requires firewall rule checking/override
Note: we must override existing firewall config specified by a user on the FT-- which means
that we'd have to either modify IP tables periodically or place our hooks in before iptables can
filter out/drop the packets.
E) Support to forward to FT LAN IP or localhost
1. Required
2. If it works for a FT without effort, great.
3. No support to forward to FT LAN IP or FT localhost
Assumptions:
no validation or security on pinhole
i.e. a packet from ANY IP would be forwarded through the firewall (option A-1)
or
the 'right' IP (option A-2)
must be able to configure a FT's firewall to open up the hole without interfering with the FT's
normal firewall configuration.
Reverse Pinhole
Note: We already have a form of reverse pinhole, but is for all outbound traffic for a specific IP. I
don't think that it will be difficult to perform a NAT translation from a outbound destination IP, that
corresponds to one of the following options, to a translated outside IP and port. Where the destination
IP is:
1. the FT's LAN IP
or
2. an arbitrary IP/network mask
or
3. a domain, (requires looking into DNS requests).

e-Highlighter

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

Un-highlight all Un-highlight selectionu Highlight selectionh