MitM server-to-server HTTPS communication

SSL spoofing is one of the most potent MitM attacks between a client device and a server because it allows for exploitation of services that people assume to be secure.

  • A passive MitM attack (only sniffing), decrypting the traffic by using the servers private key is only possible when RSA key exchange is used. Diffie-Hellman key exchange causes forward secrecy, which means that previously sniffed connections can not be decrypted once an adversary has the private key of the certificate.
  • An active MitM attack consists of an encrypted session from client to MitM and from MitM to server. Two fully separate sessions which have different keys and can also use a different cipher, protocol version etc. If an adversary has the servers original private key he/she can impersonate the server by using the original certificate. Alternatively a fake certificate can be created and used, which succeeds only if the client already trusts the CA issuing the fake certificate or the client does not do proper certificate validation.
  • Client certificates are similar to server certificates: either the adversary has to have the private key of the original certificate or the server needs to somehow trust the attackers fake certificate or fails to properly validate the certificate.

Some server-side HTTP client libraries accept untrusted TLS communication by default. The most common attack vectors for MitM-ing a server-to-server HTTPS communication that accepts untrusted SSL certificates are:

  • DNS cache poisoning can be used to replace the real endpoint with an attacker's replacement using a self-signed certificate.
  • An adversary can rent a server in the same data center/from the same host, or compromise a vulnerable server on an intranet and attempt an ARP spoofing.
  • Border Gateway Protocol (BGP) hijacking: Once an adversary obtains access to a BGP peer, she can announce any prefix she wants to the other peers of the vulnerable ISP, causing denial of service or conducting a MitM attack for either the hijacked prefix or the upstream ISP itself in case the incoming traffic requires more bandwidth than that ISP can handle.

Suppose a target server and visitors are in France, and the prefix is hijacked local to the US (adversary has chosen to get a certificate from a CA in the US). In that case it is possible to impersonate the target (because no reliable identification method is used by the CA for X.509 certificates) or impersonate a WHOIS server of her registrar and obtain a perfectly valid TLS/SSL certificate for the target domain. The procedure takes 15 minutes at most, and immediately after, she may stop announcing the target's prefix. The target will have only those 15 minutes to detect the issue. The certificate will be valid globally, so it may be used in man-in-the-middle attacks anywhere in the world.

  • For a basic TLS certificate, the Certificate Authority (CA) asks that requestors prove that they own the associated domain. While many approaches can be used to provide this proof, one of the most common is having the requestor post specific content at a URL on that domain. When a domain has been temporarily hijacked, the adversary can post the content and then be issued a domain-validated (DV) certificate within minutes.
  • Let’s Encrypt makes the creation of SSL certificates free and easy.

GCHQ and the NSA appear to have already taken aggressive and controversial routes by performing SSL spoofing MitM attacks:

  • In 2013 the NSA likely snooped on SSL traffic by hacking into target's Internet routers and covertly redirecting targeted Google traffic using a fake security certificate.
  • GCHQ’s “network exploitation” unit operated a program called Flying Pig that (from the slides) appears to identify information related to use of the anonymity browser Tor and allows for the collection of information about specific SSL encryption certificates.

This isn't about a vulnerability in a software, it is about a flawed concept. The abstraction of trusted Internet routing is wrong. The below mitigations can help some, but are like mopping up the leaked water with the tap open, and only a few information security specialists and network engineers use them.

ARP spoofing

  • Use static, read-only entries for critical services in the ARP cache of a host (prevents only simple attacks and does not scale).
  • Switches do cross-checking of ARP responses (combined with certification).
  • OS of devices ignore unsolicited replies. The different OS's respond differently:
  • Packet filtering: a spoofed packet can contain packets from outside the network that shows source addresses from inside the network and vice-versa.
  • Authentication and encryption
  • The above mitigations can only prevent simple ARP attacks. Use anti-ARP tools to identify and stop the more sophisticated adversary.

DNS cache poisoning

  • Use Passive DNS databases for near-real-time detection of fraudulent delegation changes and cache poisoning. The databases can be queried frequently to know more about the addresses being mapped by the major domain names at the time. All the information will come directly from the passive Data sensors and in the case of any deviations from the regular mappings of data gathered from an authoritative source, it could mean a breach of web security. Passive DNS data is rich, and can also be used to help administrators block the resolution of suspicious new domain names, identify potential infringements and as source for threat intelligence.

BGP hijacking

  • Some proposed mitigations mention measuring the Time to Live (TTL) field of incoming IP packets and filtering on that, but TTL is also easy to forge by a MitM. Measuring Round-Trip Time (RTT) would not be so easy to forge.
  • A hijacked route is relatively easy to detect and mitigate. RPKI and BGPsec address this issue (to some extent). Global hijacking is rare, local hijacking possible under certain conditions, but also opens the possibility to hijack a prefix in such way that the hijack will not be seen by large ISPs, and RTT for most customers will not change either.
  • A route leak is much harder to understand and prevent without a complex network monitoring solution.
  • Using data aggregation from global route collection (DNS analytics) to filter prefix announcements coming from peers before passing them on to others (prefix de-aggregation, invalid originations, invalid AS (Autonomous System) adjacencies, and perhaps even improbable AS paths) may work, but none of that makes sense if ISP's do not even secure their networks properly.
  • In general, large ISPs often implement some measures to prevent hijacking and leaking, but probably for the same reasons small ISPs often leave their network equipment and even the border routers unpatched and vulnerable, small ISPs seem not to care about prefix filtering.

Certificate validation

  • There are proposals for being able to “pin” domains to a specific certificate authority (for a fee of course), in which a certificate authority is to do extra diligence before considering issuing a certificate for a “pinned” domains.
  • A new “pinning” header is being implemented by servers and browsers to protect against fraudulent certificates, but are not widely used yet.
  • Some certificate authorities use multiple clients around the world to do their domain control validation. That will not stop a local BGP hijacking of a target domain, but does stop hijacking of the certificate authority validation test traffic itself.
  • The Extended Validation (EV) process for certificates requires additional validation, including based on contact details provided in a qualified information source. An adversary would have to compromise that third-party source in addition to doing the BGP hijacking.
  • The Certificate Transparency (CT) project is working on a global repository of domains, certificates, and associated certificate authorities. CT encourages domain owners to register with a monitoring service that will notify them if another certificate is ever issued. At the moment, only EV certificates are required to be registered with CT Logs.