Certificates
From charlesreid1
This page contains information about SSL certificates for establishing secure lines of communication with public servers.
You can obtain your own certificates, and even forge new ones, and serve them up using SSLStrip and a man in the middle attack. See MITM Labs/Bettercap SSL Over Wifi
Alternatively, if you are unable to forge a private key for a certificate, you can always take the easier route of obtaining a private key for the sheep, and eavesdropping that way. See MITM_Labs/Decrypting_HTTPS_Traffic_with_Stolen_Private_Key.
Contents
Code Signing Certificates
Whoops, wrong page. Check Code Signing Certificates.
Background on HTTPS Protocol
Basic HTTPS
With HTTPS attacks having been in the wild for many years, and browser technology constantly evolving, protection against HTTPS attacks has definitely improved over time (Moxie Marlinspike originally presented sslstrip/sslsniff at Defcon 2009: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf). For this reason, stripping SSL and sniffing HTTPS is not easy to do if the sheep is using a modern browser like Firefox or Chrome. Many sites insist on HTTPS, making it impossible to strip SSL out. Modern browsers will also lock up when they detect invalid certificates:
Normal HTTPS Session
To understand why this happens, let's examine how a normal HTTPS session is supposed to go.
Client Request: First, the client sends an HTTPS request to the HTTPS web server.
Server Response: The server responds with its certificate. This is equivalent to a public key that the client uses to encrypt communications with the server.
Client Key: The client responds with its public key, which the server will use to encrypt communications with the client
Each party has a private key, which they combine with the other party's public key, to encrypt their communications. (How does it work? THE MATHS - SPECIFICALLY ZETA FUNCTION MATHS)
The end result: secure, encrypted communications established by exchanging only public information on a public channel.
MITMed HTTPS Session
When an HTTPS session is attacked with a man in the middle attack, the modified sequence looks like this:
Sheep Request (intercepted by attacker): First, the sheep sends an HTTPS request to the HTTPS web server, which is intercepted by the bettercap HTTPS proxy.
Fake Server Response: The attacker responds to the sheep with its (self-signed) certificate. This certificate, equivalent to a public key, is an identity mechanism - cryptographic fingerprint of the HTTPS proxy server.
(Aside: This public key corresponds to one and only one private key that is a cryptographic, identifying fingerprint - that's a symbol of everyone's trust in your identity. To create a public/private key pair that looks exactly like EvilCorp.com's, for example, and that would allow an attacker to completely and transparently pwn all https://evilcorp.com visitors by assuming the identity of the corporation and masquerading as them, one would need to obtain Evil Corp's private key - their cryptographic identity - no easy task.)
Attacker Request Forward: The attacker forwards the original HTTPS request to the HTTPS server, which is unaware of the MITM attack.
Server Response (intercepted by attacker): The server responds with its certificate. This is the public key that the attacker uses to encrypt communications with the server (which is still unaware of the MITM attack).
Client Key: The client responds to the attacker's (self-signed) certificate with its own public key, so that it can communicate securely with the attacker (which it thinks is the trusted HTTPS web server).
The end result: the attacker has established secure, encrypted communication channels with the sheep and the server.
Detecting the Attack
The naive may think this is enough to thwart encryption. But there's an alternate channel here for verifying identity: the public key. If the domain and the public key do not match, the sheep knows the traffic is being tampered with and that it is being presented with a fake certificate.
Responsibility to detect HTTPS MITM attacks falls on the sheep's browser. The browser should be checking the public keys of each certificate it receives with the domain of the certificate. If the two do not match, then the encryption channel that has been established is hazardous and links to an attacker, not to the trusted endpoint.
For the attacker to truly trick the sheep into trusting it, it would need to find a private key of Evil Corp - which, given that it is equivalent to Evil Corp's digital identity, is going to be a closely-guarded secret that is impossible for the armchair pentester to crack.
Alternatively, you hijack the trust mechanism of the sheep's browser (pop up from Level 3 to Level 7).
Attacks on Certificates
Stealing SSL session info
One way to decrypt HTTPS information is to steal SSL session information, either in the form of SSL keys extracted from memory, or by obtaining the private key .pem file utilized by the browser to encrypt private HTTPS connections.
These two approaches are covered here:
- MITM Labs/Decrypting HTTPS Traffic with Private Key File
- MITM Labs/Decrypting HTTPS Traffic by Obtaining Browser SSL Session Info
Exploiting/Forging certificates
Topics in this category include:
- Frankencert to create fake certificates
- Bundled certificates whose private keys are compromised, but still might be bundled...
- Fuzzing to generate certificates that will crash something like openssl or the ssl certificate checking software
Defeating HTTPS with sslsniff and fake certificates
To defeat HTTPS in a way that is transparent to the sheep, you must be able to issue a certificate that the sheep trusts, and obtain a private key for that certificate. sslsniff allows you to use various self-made certificates and serve them up for various domains. This makes it easy to automate dealing with large numbers of forged certificates.
More on forged certificates below.
Faking certificates
Check out the following resources for HTTPS certificates and known private keys for embedded devices:
- BenBE kompromat: https://github.com/BenBE/kompromat
Corrupting Firefox certificates
Here's a bit of background primer on how Firefox uses certificates: https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates
Firefox comes bundled with certificate authorities. Here's how those work.
When a sheep connects to a server that claims to be a website like linux.org, the sheep's browser receives a certificate. To verify the certificate is valid, the sheep needs a trusted, third-party authority whose principal role is to go around signing certificates of people who can prove they are who their certificate says they are. If a sheep receives a certificate that says "I'm Google.com" and it's drawn in crayon on the back of an old homework assignment, it seems suspicious. If a sheep receives a certificate that says "I'm Google.com" and it has a signed note from The Pope that says "I can verify this certificate is valid", you can assume it is the real deal (assuming the Pope knows anything about internet infrastructure).
To check third-party signatures, Firefox comes bundled with a set of certificate authorities, which it can use to independently check the signatures of the trusted third party.
They can also be corrupted.
Flags
attacking SSL with man in the middle attacks attacking secure socket layer, an encrypted wrapper for TCP/IP traffic, and the public-key encryption process.
Certificates (or, how HTTPS works)
MITM LabsARP PoisoningDsniff ARP Poisoning: Bettercap ARP Poisoning: MITM Labs/Bettercap Over Wifi DNS HijackingBettercap to Hijack DNS: Bettercap/Failed DNS Spoofing Attack · Bettercap/Failed DNS Spoofing Attack 2 Traffic InjectionBettercap to Replace Images: MITM Labs/Bettercap to Replace Images MITMf to Backdoor Browsers: MITM Labs/MITMf to Backdoor Browsers HTTPS MITMBrowser + Wireshark/SSLSniff to Decrypt HTTPS: MITM Labs/Decrypting HTTPS Traffic with Private Key File Browser + Wireshark to Decrypt HTTPS: MITM Labs/Decrypting HTTPS Traffic by Obtaining Browser SSL Session Info Device MITMBettercap to MITM Android Phone: MITM Labs/Bettercap Android Evo Bettercap to MITM iPhone: MITM Labs/Bettercap iPhone
Category:SSL · Category:Man in the Middle · Category:Attacks · Category:Kali Attack Layers Flags · Template:MITMSSLFlag · e |
monkey in the middle attacks in which an attacker tricks two parties into thinking they're communicating with each other, but both are communicating with the attacker.
Wireless Attacks: MITM/Wireless Wired Attacks: MITM/Wired
Layer 1 and 2 MITM Attacks: Network Tap: MITM/Wired/Network Tap Evil Twin Attack: Evil Twin · MITM/Evil Twin
Layer 3 and 4 MITM Attacks:
ARP Poisoning: MITM/ARP Poisoning Traffic Injection/Modification: MITM/Traffic Injection DNS Attacks: MITM/DNS · Bettercap/Failed DNS Spoofing Attack · Bettercap/Failed DNS Spoofing Attack 2 DHCP Attacks: MITM/DHCP WPAD MITM Attack: MITM/WPAD Port Stealing: MITM/Port Stealing Rushing Attack: MITM/Rushing Attack Attacking HTTPS: MITM/HTTPS
Session Hijacking: MITM/Session Hijacking
Toolz:
SSLSniff · SSLStrip · Frankencert
MITM Labs: {{MITMLabs}}
Category:MITM · Category:Attacks · Category:Kali Attack Layers Template:MITMLabs · Template:MITMFlag Flags · Template:MITMFlag · e |