From charlesreid1

No edit summary
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Notes==
Thinking more about how MITM attacks could be implemented against HTTPS, seeing if I can test any on the sandbox network at home.
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?
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.
* HTTP - ARP spoofing with [[Bettercap]] works only against HTTP sites; works like a charm in that case, and it's easy to watch a sheep's HTTP traffic stream.
* 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
* HTTP - 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
* [[SSLStrip]] is too old of an attack to work - many sites bypass it, browsers seem immune to 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.
* [[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:
Dead ends:
* [[Man in the Middle/ARP Poisoning]] - requires a way to crack https, otherwise modern browsers pick up on this attack
* [[MITM/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
* [[MITM/DNS]] and [[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.
* Stealing private keys: while this is the best attack, in theory, getting private keys was stupidly hard to actually do. Probably by design, but there's no way to learn that way.


Promising leads:
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.
* [[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
* CreatePEM - if you are able to downgrade the encryption, and if the version of RSA being used 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:
* Scapy-SSL_TLS - https://github.com/tintinweb/scapy-ssl_tls - a Scapy utility library that describes itself as follows: "An offensive stack for SSLv2, SSLv3 (TLS), TLS, DTLS testing, packet crafting, dissection, encryption, session tracking, handshakes, crypto containers, hooks, SSL sniffing, PCAP stream decryption, fuzzing, security vulnerability scanning
 
For practice:
* ssl pcap, with a crackable private key, here: http://blog.stalkr.net/2010/03/codegate-decrypting-https-ssl-rsa-768.html


"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, ...)."
==Attacks==


More attacks on HTTPS:
More attacks on HTTPS:
Line 34: Line 39:


Logjam attack
Logjam attack
* Exploits a weakness allowing a downgrade to a weaker form of cryptography
* 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.
* 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 [https://aws.amazon.com/ec2/pricing/]
* Can be scanned with Scapy SSL-TLS
* Can be scanned with Scapy SSL-TLS
* More info here: https://bettercrypto.org/blog/2015/05/20/tls-logjam/
* More info here: https://bettercrypto.org/blog/2015/05/20/tls-logjam/
Line 47: Line 54:
* See [[Frankencerts]]
* See [[Frankencerts]]


Targeted private HTTPS/SSL keys:
* Kompromat: https://github.com/BenBE/kompromat
* Little black box: https://github.com/devttys0/littleblackbox
* Rapid7 ssh-badkeys: https://github.com/rapid7/ssh-badkeys
==Links==


Nice explanation: https://www.grc.com/fingerprints.htm


=Flags=
==Flags==


{{MITMFlag}}
{{MITMFlag}}
[[Category:SSL]]

Latest revision as of 04:51, 25 March 2022

Notes

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?

  • HTTP - ARP spoofing with Bettercap works only against HTTP sites; works like a charm in that case, and it's easy to watch a sheep's HTTP traffic stream.
  • HTTP - 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, browsers seem immune to 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:

  • MITM/ARP Poisoning - requires a way to crack https, otherwise modern browsers pick up on this attack
  • MITM/DNS and Bettercap#DNS Spoofing - similarly ineffective against HTTPS requests
  • Stealing private keys: while this is the best attack, in theory, getting private keys was stupidly hard to actually do. Probably by design, but there's 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 you are able to downgrade the encryption, and if the version of RSA being used 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 - https://github.com/tintinweb/scapy-ssl_tls - a Scapy utility library that describes itself as follows: "An offensive stack for SSLv2, SSLv3 (TLS), TLS, DTLS testing, packet crafting, dissection, encryption, session tracking, handshakes, crypto containers, hooks, SSL sniffing, PCAP stream decryption, fuzzing, security vulnerability scanning

For practice:

Attacks

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

Fuzzing certificate checkers:

Targeted private HTTPS/SSL keys:

Links

Nice explanation: https://www.grc.com/fingerprints.htm

Flags