Imagine a scenario where a malicious entity launches a Man-In-The-Middle (MITM) Attack with a Compromised Certificate Authority (CA). They do this by generating a Certificate Signing Request (CSR) with a stolen Private key. The attacker has compromised the root CA and stolen its private key, allowing it to generate any arbitrary certificate using this CA’s private key. As a result, what appears to be Instagram is actually a fake site!
Note:
"It's a secure blog; you can feel safe – I will not deceive you."
This blog will covers PKI using the SSL. PKI plays a crucial role in securing communication by addressing the challenge of verifying the ownership of public keys. Let’s delve into the keywords and key aspects covered in this blog:
Keywords and Key aspects:
MITM Attack: Man-In-The-Middle Attack, exploit insecure communication channels.
CA: Certificate Authority issues and manages these certificates.
CSR: Certificate Signing Request.
PKI: Public Key Infrastructure, PKI enhances secure communication by providing a framework for managing digital certificates and it helps prevent man-in-the-middle attacks and ensures secure connections.
Digital certificates: verify the ownership of a public key by associating it with a named subject.
X.509 certificates: play a widespread role in PKI as they hold crucial information about the certificate holder, including their public key. Unlike regular certificates signed by other CAs.
SSL: Secure Sockets Layer.
Apache2: is a popular web server software and I will configure it for HTTPS.
HTTPS: is a secure communication, where relies on PKI for certificate validation.
Before we dig into this trap, let's go backward and Become a CA.
I will generate a self-signed X.509 certificate using my root CA instead of relying on commercial CAs. As the root, I will create digital certificates and utilize PKI by using OpenSSL to generate the certificates.
The Basic Constraints extension in a certificate indicates whether it is a CA's certificate. If the extension value is "CA:TRUE," it means that the certificate belongs to a certificate authority. The Issuer DN (Distinguished Name) is a part of the certificate that indicates it as a self-signed certificate. When the Issuer DN matches the Subject DN (the certified entity), it shows that the certificate is self-signed.
Now, CA is trusted and its certificate will be the root certificate note that Root CA certificates are self-signed. Let's get it short ;
First, I generated arbitrary certificates using this compromised CA’s private key, using Instagram.com as the common name of the certificate request, I used the Instagram.html page to trick the victim and then I signed it.
Second, I deployed the Instagram Certificate in HTTPS Web Server, and deployed in Apache2 HTTPS Website. Deploying Instagram Certificate in an HTTPS Web Server:
Step 1: Configuring DNS Maps the hostname to the localhost.
Step 2: Configuring the web server Launching a simple web server with the secret key and the certificate.
Step 3: Getting the browser to accept our CA certificate .
Then jump to launching the MITM attack!
Launching a Man-In-The-Middle Attack with a Compromised CA Generate a CSR with the stolen private key:
Unfortunately, the attacker compromised the root CA and stole its private key. Therefore, the attacker now will generate any arbitrary certificate using this CA’s private key. First, I - "I" here refer to "Attacker" which is me ;) - generate an arbitrary certificates using this compromised CA’s private key, using Instagram.com as the common name of the certificate request, and then I signed it.
After the signing, I deployed the Instagram Certificate in HTTPS Web Server, And deployed in Apache2 HTTPS Website.
Execute the https://www.instagram.com. The victim will fall into my trap by landing on the fake website, and their browser will not raise any suspicion As shown below:
Figure 1: Instagram fake website.
We assume that the root CA has been compromised by an attacker, and its private key has been stolen. As a result, the attacker can generate arbitrary certificates using this compromised CA’s private key. This situation poses a significant security risk, allowing the attacker to perform MITM attacks, intercepting and altering communication between parties. The compromised CA undermines the trust in the PKI, highlighting the importance of secure CA management and protection against such attacks.
Delve into the exciting and surprising observations:
First, When a CA's private key is compromised, it jeopardizes the entire trust model of PKI. The CA is responsible for issuing certificates, and its compromised key allows attackers to create fraudulent certificates. These certificates can impersonate legitimate entities, leading to MITM attacks. The surprising aspect here is how a single compromised CA can undermine the security of an entire system. Secondly, with the compromised CA’s private key, an attacker can generate valid certificates for any domain. They can intercept communication between parties by presenting a fraudulent certificate during SSL handshakes. The disconcerting ease with which a malicious actor can take over encrypted communication channels poses a substantial risk to the security of confidential information.
References:
[1]“PKI Lab,” Seedsecuritylabs.org, 2024. https://seedsecuritylabs.org/Labs_16.04/Crypto/Crypto_PKI/ (accessed Aug. 19, 2024).
[2]Cryptography: A Hands-on Approach: Udemy – 2024.
[3] SEC6611:Networks Security : M.Sc. in Information Security, IMAMU -2024.
Comments