Certificates

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.

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

Main article: SSLSniff

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.