28.08.2007
A Case of SSL MITM attack - Protecting The Trust Relationship - Part 2: The SSL MITM Attacks

 Carbonwind.net and the author do not condone or approve the illegal use of this tutorial in any way.

For the first MITM test we are going to use Burp Proxy. We will configure IE to use it as an Web Proxy:

Figure27: Preparing IE for Burp Proxy 

We are going to start Burp Proxy and make sure that interceptation is on:

Figure28: Burp Proxy Interceptation is on 

And JohnVPN goes ahead for a poor MITM attack:

Figure29: IE error with Burp Proxy MITM 

As you can see from Figure29 now IE warns us that the CN from the certificate does not match owa.carbonwind.net(our destination) and that it does not trust the CA.
Click continue and “forward” on Burp Proxy:

Figure30: Click “forward”

A look at the certificate shows that the web server name is incorrect(the CA is not trusted either and it is not the one we expected to be, DCMain):

Figure31: Burp Proxy Certificate

As we can see from Figure31 this certificate looks like a self-sign certificate(like a root certificate).

Figure32: Burp Proxy Certificate details

From Figure32 we can also see that the other fields are different and the public key has only 1024 bits.
JohnVPN expected anyway the IE error(since he remembers something from the instructions that the IT Security department of his company gave to all of its employees) and did not bother to check the certificate(although IE warned him about the CN mismatch, too much for JohnVPN).

Figure33: JohnVPN logs in 

Next we see in Burp Proxy the username “JohnVPN” and the password “pa55w0RD”.

Figure34: JohnVPN’s credentials exposed

And click “forward” so that JohnVPN to be taken to his email account.
Now let’s go and install Burp Proxy’s CA certificate into the “Trusted CA store”(just click “Install Certificate” from the “General” tab when viewing the certificate in IE and follow the wizard).

 
Figure35: Now Burp Proxy’s CA certificate is trusted 

And JohnVPN will log one more time:

Figure36: New IE error 

Right now IE is complaining about the fact that the CN from the certificate did not match our request address. JohnVPN will not read it. An error like any others…
In Figure37 is the IE setting that checks the CN.

Figure37: IE Setting 

Figure38: The certificate is fine except… 

Figure39: …Except the CN(and of course the other detail fields do not match) 

JohnVPN continues and submit his credentials.

Figure40: Again JohnVPN’s credentials were exposed 

If the attacker disables that security check from IE and installs Burp Proxy’s CA certificate in the “Trusted Root CA Store” then no errors will show up in IE:

Figure41: No IE errors 

If actually JohnVPN’s company was using a commercial certificate he would not expect any errors and since there are no errors he will not notice anything(of course if he did not check the certificate).
So by now we have exemplified a poor SSL MITM. Even it is a poor one it can actually succeed if the attacker disables the browser’s security checks and make sure he/she includes its CA certificate in the “Trustes Root CAs”. A careless user will not even look at the certificate and since IE it does not give him/her any errors he/she will not have a clue about the MITM attack.
Let’s move forward and perform a more advanced SSL MITM.
For this we are going to use Cain&Abel.
Let’s assume once again that JohnVPN is using a public PC and the server certificate is from a private CA. For some reasons, knowing the risks, he will do so. He is aware about the IE errors about the certficate but he is confident that he can spot a fake one.
For our test the DG is 192.168.22.3, the attacker sits on 192.168.22.4 and JohnVPN is at 192.168.22.2.
Cain&Abel is very easy to configure. First scan for MAC addresses:

Figure42: Cain&Abel Scanning for MAC addresses

Figure43: Cain&Abel Preparing the ARP Spoofing 

We want to redirect to our PC 192.168.22.4 all the trafic from 192.168.22.2 to 192.168.22.3.

Figure44: Cain&Abel the ARP Spoofing was started 

I did not touch its configuration:

Figure45: Cain&Abel Filters and Ports

Figure46: Cain&Abel HTTP Fields 

Now JohnVPN proceeds.
The IE error, as expected the certificate was not issue by a trusted CA:

Figure47: Cain&Abel IE error

Looking at Cain&Abel we can see that it has create a custom fake certificate and has successfully intercepted the traffic:

Figure48: Cain&Abel fake certificate

JohnVPN continues and takes a look at the certificate:

Figure49: Cain&Abel IE certificate

It looks very good, even the CA name is OK. 

Figure50: Cain&Abel IE certificate details

Looking at the details the public key has a different length 1024 and the Signature algorithm is md5RSA and not sha1RSA. But if we can also forge the length. It is very unlikely that JohnVPN actually knows it by letter. And JohnVPN must must be well trained to check all those fields. The CN is good, the CA name also, as well as OU, O, L, S, C, the validation dates, the serial number. 

Figure51: Cain&Abel IE certification path 

The CA certificate is missing but JohnVPN might expect that as we have seen in the previously example.
JohnVPN is fooled and continues with his login.
So now we are moving into Cain&Abels’s “Sniffer/Passwords” section and there we can see JohnVPN’s credentials:

Figure52: Cain&Abel IE exposed credentials

As you can see it is easy to forge the certificate fields on the fly. Only the web server public key cannot be forged. But since it is quite long we cannot remember it.
So the attack might succeed if John VPN logs on from a public PC while the server certificate was issued by a private CA. He expects the error and the certificate he receives is well crafted.
Now let’s use Fiddler2 to perform a SSL MITM. We first must enable it to “Decrypt HTTPS traffic”

Figure53: Tell Fiddler to decrypt HTTPS

When we start Fiddler, it sets our browser to use its proxy, Fiddler listen on TCP port 8888. There is an option “Allow remote clients to connect” which enables other computer to use Fiddler as their Web proxy(just set their proxy with the IP address of the machine where Fiddler runs and TCP port 8888).

Figure54: IE settings after Fiddler starts

IE will give us the same error about not trusting the CA(we can see that the name of the CA is suggestive). However Fiddler forges on the fly the CN and so we won’t see the error about it in IE.

Figure55: Fiddler Certificate 

Figure56: Fiddler Certificate Details

Figure57: Fiddler Certificate Certification Path

Fiddler sent us the CA certificate along with the web server certificate so we can follow the Certification path.
If we go and install the Fiddler CA in our “Trusted CA Store” then no IE error will appear anymore.

Figure58: Fiddler no IE errors

And Fiddler2 shows JohnVPN's credentials:

 
Figure59: Fiddler shows credentials(Text View)

Figure60: Fiddler shows credentials(Raw View)

Figure61: Fiddler shows credentials(WebForms) 

Obviously the attacker can came up with the right CA name, maybe with the right public key length and other fields like OU, O…  
The CN was forged, the attacker’s CA can be made trusted. 
If the attacker actually expected JohnVPN then he would knew the CA name(+ all the details) and then JohnVPN would have no chance, he will be owned. Unless he remembers the server’s public key. As you can see the certificate can be forged and it is quite impossible to detect a fake one if the attack is properly done(all the fields are correct except the public key one, the CA is trusted). Since JohnVPN logged from a public share PC, the attacker’s job is made very easy. He/she can have direct access to the network and so he/she can own it. We are referring only to SSL MITM attacks and not to keyloggers or other tools that the attacker might use.  Remember the RFC2246(TLSv1.0) words:
“Because certificate validation requires that root keys be distributed independently”
If I present you my certificate along with the CA certificate that has signed it then you cannot tell if the certificate is not a fake if you do not “know” the CA. The CA must be a “person” not interested by me or you. It’s like when you and I sign a piece of paper in front of an witness. If this witness is an disinterested, honest person then he/she becomes the link that would certify that you and I actually signed that piece of paper. If this witness has hidden interests then the link is broken.
There are other tools that can perform SSL MITM attacks(some of the ones used here were developed for debugging). A skilfull atacker will probably have his own tools which for designed specifically for maliciuos activities.
As you can see it is quite easy to proper create a SSL MITM attack on a public shared PC.
If you want a real world, this time a good example, think at ClearTunnel, an ISA Server add-on which enables ISA to perform outbound SSL inspection. It achieves this by doing a MITM attack. But in this case it is a trusted MITM(its documentation specifies that you must use it only if you are compliant with the privacy laws in your country or locality regarding the interception of encrypted traffic even if you are on your own internal network). By preparing certificates on the fly, the CN will match your connection’s request and the CA obviuosly will be trusted. So no IE errors.
Now with all these on our mind you might thought, well I’m skilled enough not to be MITM-ed when I’m reading my emails from a public shared PC. Besides, I have bought a commercial certificate, so I’m not using any private CA(although you have seen that this does not help).
Well, I’m sorry to spoil your party but you are wrong. There are hardware keystroke loggers(if you can spot software ones) which can even built in your keyboard like Security Keyboard(which is addressed to). Imagine that an atacker crafts his/her own keyboard and then place it in the right place. You “are owned” no matter what.
Actually there are tutorials showing you how to make your own are hardware keystroke loggers. See it yourself: 
http://www.keelog.com/diy.html 
Maybe you can try to use a virtual keyboard(even an online one). But in the end, the risk is too high, it’s like someone has thrown you into the jungle. You cannot know “what’s” next.
 When you are accessing sensitive data from a public, shared PC you are breaking the relationship of trust. “Clientless access” from virtually anywhere is beautiful but how can you tell who’s who? 
When you are using your private, managed, laptop you have original software running on it along with proper antivirus, spyware and firewall programs. No one has forged your “Trusted Root CA Store” or installed malicious programs. Having your own PKI with your own CAs is very secure once you have properly deployed it. And you have a great flexibility regarding the certificates. 
All the above attacks were performed when only the one-way trust relationship exists. Only the the server was authenticated.