MITM/HTTPS

Thinking more about how MITM attacks could be implemented against HTTPS, seeing if I can test any on the sandbox network at home.

So far, what have I tried?

• ARP spoofing with Bettercap works only against HTTP sites - works like a charm and it's easy to watch a sheep's HTTP traffic stream, but there's no tampering with HTTPS streams.
• DNS spoofing with Bettercap or Dnsspoof works only against HTTP sites - can spoof DNS requests (although it is not working correctly); they cannot spoof HTTPS requests
• SSLStrip is too old of an attack to work - many sites bypass it
• SSLSniff still holds promise. It is a certificate server, so you can use it to server fake certificates. Using Moxie0's suggested null-byte and other certificate attacks did not work - against an up-to-date browser... did not check any older ones. Could load fake root certificates on sheep's machine, could find vulnerabilities in certificate-checking mechanism, could find way to legitimately self-sign certificates, could crack private key.

Dead ends:

• Man in the Middle/ARP Poisoning - requires a way to crack https, otherwise modern browsers pick up on this attack
• Man in the Middle/DNS/Bettercap#DNS Spoofing - similarly ineffective against HTTPS requests
• Stealing private keys: getting private keys was just ridiculously stupidly impossible to actually do. Probably by design, but absolutely no way to learn that way.

Promising leads:

• SSLSniff allows you to serve up fake certificates - there are potential attacks on how browsers check certificates. This is one where you have to try throwing everything at the wall, until something sticks, and now all your sheep are all people who use that browser.
• CreatePEM - if RSA is weak enough, you can brute-force crack it to obtain a private key from a public key: http://blog.stalkr.net/2010/03/codegate-decrypting-https-ssl-rsa-768.html
• Scapy-SSL_TLS - a Scapy utility library that describes itself as follows:

"An offensive stack for SSLv2, SSLv3 (TLS), TLS, DTLS penetration testing providing easy access to packet crafting, automatic dissection, encryption, decryption, session tracking, automated handshakes, TLSSocket abstraction, cryptography containers, predefined hooks, SSL sniffing including minimalistic PCAP stream decryption (RSA_WITH_*), fuzzing and security scanning (Renegotiation, Heartbleed, Poodle, Logjam/Freak, various Buffer overflows, ...)."

More attacks on HTTPS:

Heartbleed attack:

• the heartbleed attack is specifically intended to leak private keys from servers.
• once you obtain a server's private key, you can decrypt all communications with that server that have been recorded.

Poodle attack:

• October 2014
• MITM exploit forcing clients to fall back to SSL 3.0, allowing 1 byte of encrypted message revealed per 256 bytes
• Discovered by Google Security, not considered as serious as Heartbleed and Shellshock
• CVE 2014-3566 and CVE 2014 8730
• Second variant attacked TLS, Dec 2014; CVE 2014 8730
• Second attack is easier to execute, fewer steps

Logjam attack

• Exploit that forces a victim to downgrade to a weaker form of cryptography
• Specifically, logjam attacks a weakness in 512-bit key size DHE crypotgraphy. Normally you want to use DHE crypto with a key size of at least 1024 bits, at minimum the size of your RSA key, and for high security, 4096 bits.
• "Weak" means, attacker could crack it with 100,000 CPU hours
• For scale, a cloud server would cost you about $0.01 per CPU hour, and improves with scale, so you're looking at a cost of $5,000-$10,000 for the one-time computation (or, you could spend 3-4 times that on your own cluster), which then makes future cracking of DHE crypto easier [1]
• Can be scanned with Scapy SSL-TLS
• More info here: https://bettercrypto.org/blog/2015/05/20/tls-logjam/
• via https://bettercrypto.org/ and http://github.com/firefart

Drown attack

• Also forcing downgrade? https://github.com/nimia/public_drown_scanner

Fuzzing certificate checkers:

• frankencerts: https://github.com/sumanj/frankencert
• See Frankencerts