Vault 7: Projects

This publication series is about specific projects related to the Vault 7 main publication.
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).
Hole punching:
Technique of establishing and outbound TCP connection or UDP packet (or UDP handshake) in order
to open up a hole in Firewalls between a non public addressable FT and an outside destination IP. This
is useful in order to
Pinhole Estimate of Work
This estimate is for kernel/netfilter based impl (Option D-1) on FT's that already support HTTP