28.08.2007
A Case of SSL MITM attack - Protecting The Trust Relationship - Part 3: The Two-Way Trust Relationship

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

For any real authentication method we must forced mutual authentication: we will have the "magic" two-way trust relationship.  We authenticate the server and the server authenticates us.
Coming back to the OWA discussion it is very simple to force this kind of relationship with ISA. Just go to your OWA publishing rule, the “Listener” tab and on the “Listener” properties go to the “Authentication” tab and click “Advanced”:

Figure62: ISA OWA Publishing Rule/Listener Properties/Authentication 

Put a checkmark in the “Require SSL client certificate” checkbox. This means that now the “TLS authentication mode” is set to: “authentication of both parties”. It does not mean that you provide a user certificate to ISA and automatically you are logged on to your OWA account(it's not user authentication). 
By now, you must first present a valid certificate to ISA(after ISA has presented you a vaild one), then enter your credentials in the ISA OWA FBA page and if these credentials are good, eventually traffic will reach the Exchange server.
The “SSL client certificate timeout” specifies that the client certificate will be presented after 300 seconds. If it is located on a smart card, you retrieve the smart card and you let the session open, then ISA will end up the session because you will not present the certificate. If you store the certificate in your “Local User store” then you will not notice the ISA time out request.

 
Figure63: Listener Properties/Authentication/Advanced/Authentication Preferences 

Make sure you accept only certificates which were issued by your private corporate CA:

Figure64: Accept only certificates which were issued by your private corporate CA 

You can even further and restrict the Client certificates, for example, accept only certificates whose “Enhanced Key Usage field” contains the following “Smart Card Logon object ID: 1.3.6.1.4.1.311.20.2.2”(see ISA’s help for details) which identifies a smart card logon certificate. Be aware that your client certificate must also contain the “Client Authentication ID1.3.6.1.5.5.7.3.2” because your certificate must have signing capabilities for the TLS client authentication. Also there are other restriction options.

Figure65: Client Certificate Restriction 

Our user has the below certificate, see Figure66:

Figure66: JohnVPN’s user certificate

He wants to log on to the OWA site. After he types the address of the OWA site he is prompted for his certificate.

Figure67: IE prompts JohnVPN for hist certificate

Since his certificate does not contain the “Smart Card Logon object ID: 1.3.6.1.4.1.311.20.2.2” ISA denies his request.

Figure68: ISA blocks JohnVPN due to certificate restrictions 

If JohnVPN has a proper certificate then he will make it:

Figure69: JohnVPN’s proper certificate 

Figure70: JohnVPN reaches the OWA screen

So what’s happening on the wire ? 

Let’s take a look with Wireshark:

Figure71: Wireshark Trace, “Server Hello”

Now when the server sends its certificate to the client it will request a client certificate, the “Certificate Request” message.
In this “Certificate Request” the server will specify the types that client must provide. As seen in Figure72 the client has two options:

Figure72: Client certificates types 

What do “RSA Sign” and “DSS Sign“ mean?
They mean that the server is expected the “Certificate Verify” from the client, message which is sent to explicitely verify the certificate.
RFC2246(TLSv1.0) states that about “Certificate Verify”:
“This message is used to provide explicit verification of a client certificate. This message is only sent following a client certificate that has signing capability.
When RSA is used for key exchange, clients are authenticated using the certificate verify message. The client signs a value derived from the master_secret and all preceding handshake messages. These handshake messages include the server certificate, which binds the signature to the server, and ServerHello.random, which binds the signature to the current handshake process.”
So the client must use his/her private key to sign a message for the server(that’s why he needs signing capabilities on his certificate).With the public key from the client certificate received(which must be from a trusted CA), the server can be sure that the client is the one who is pretending to be.
Also there is a “Distinguished Names” list which includes some certificate authorities.

Figure73: “Distinguished Names”

And here it comes the client answer:

Figure74: Client Answer 

Figure75: Client Answer: “Certificate” and “Certificate Verify” included 

So JohnVPN will not have any chances to reach the OWA screen(no packets actually will reach the Exchange server before JohnVPN enters his user name and password and ISA validates them).
In this way we have set a high security trust relationship between the client and server and vice-versa.
We have seen the certificate restriction working, let’s take a look at the CA restriction. Remember that ISA accepts client certificates only from DCMain?
I have another CA, TESTSTDCA, a standalone one(Windows 2003) which is trusted by ISA, but ISA is not accepting connections from it:

Figure76: The TESTSTDCA 

And the valid client certificate which contains both the “Client Authentication” and “Smart Card Logon” IDs:

Figure77: The client valid certificate issued by TESTSTDCA 

And ISA is rejecting our connection:

Figure78: ISA does not accept a certificate issued by TESTSTDCA 

So our two-way trust relationship is working like a charm.
Let’s see what’s happening when someone tries to mount a MITM attack against JohnVPN. 
JohnVPN, a person with common sense, follows his company’s IT Security department directives. And he uses only his corporate laptop to access company resources.
Let’s assume that the attacker has crafted a client certificate “for” JohnVPN which will be presented to ISA. For this we will use the makecert.exe utility. This one is shiped with Fiddler, that’s why I am in the Fiddler2 directory.
First let’s issue a self-signed certificate which will play the role of the CA(root) certificate(for all purposes) for “DCMain”:

Figure79: Crafting a "CA" certificate 

It will be installed in “My Current User Store”:
Here it is:

Figure80: The “DCMain” CA certificate 

Is not trusted because I did not installed it in the “Trusted Root CAs Store”. We could forge other options, like the validity period, mark the private key exportable and so on but we are not interested in doing so right now.
After that we will issue another certificate which will be signed by “DCMain” and place it in “My Current User Store”:

Figure81: Crafting the “John VPN” certificate signed by “DCMain”

Figure82: The “John VPN” certificate signed by “DCMain” 

Figure83: The “John VPN” certificate signed by “DCMain”, the “Certification Path”

We are going to use one more time Fiddler to perform the attack so we need to place the client certificate where Fiddler can access it(just export the certificate without the private key, Fiddler will know how to use it as long your certificate remains, say, in the “Current User Store”):

Figure84: Fiddler’s client certificate

When JohnVPN tries to login and is being MITM-ed he will receive an IE error which informs him that hist certificate was not signed by a CA which is trusted by ISA.  The first error receive by him will be about the server certificate which is not trusted. If the Fiddler CA would be trusted he will not see it but since he is on his managed private PC is not the case.

Figure85: IE error if Fiddler CA is not trusted

Let’s continue and:

Figure86: IE ISA error reply message

Figure87: ISA blocks the MITM attack

Figure88: The “client” answer 

As you can see, Fiddler sent the reply with the required fields, this time with no luck.
OK. Want to see what’s happening when the client has only the certificate without the private key?
Let’s use on more time Fiddler2. This time we export the good client certificate like before without the private key. And we delete the good one from our store.
Obviuosly that IE error complaining about the CA not being trusted and then if we continue:

Figure89: IE error needing a client certificate

Figure90: ISA error

The “client” answer:

Figure91: The “client” answer 

As you can see the “client” sent only the “Certificate” message which is empty because it does not have the type of certificate ISA requested(it has, but it has “lost” its private key). Obviouly no “Certificate Verification” message(he cannot sign anything).
So by now since our JohnVPN uses his managed private laptop to access emails(his certificate can be stored on a proper smart card) it is very hard for an attacker to make JohnVPN to trust his CA and quite impossible to do that with ISA, remember ISA only accepts certificates issued  by our private CA which is supposed to be very well protected. And ISA 2006 as currently writing this article 28.08.2007(and counting) has zero advisories listed (no further comments needed):
http://secunia.com/product/12468/ 
Another thing you would like to do is to control the Cryptographic Algorithm and Protocols used by ISA: say you would want RSA with 3DES and SHA-1.
You can refer to this article from Microsoft site:
How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll 
As you have seen I use only IE7. IE7 will check for certificate address mismatch(CN on the certificate), if the certificate was issued by a trusted CA, if the certificate is not expired or revoked. You can take a look at some of this options accessing “Internet Option” and the “Advanced” tab.
I did not use other browsers like Firefox or Opera since it would require more pictures(printscreens). Maybe I will add Part4 and Part5 to explain the error messages the two browser will give. Keep in mind that Firefox and Opera have their own CA trusted lists, but I guess you know very well this fact if you are using them frequently.
If you have an ISA lab set like in our article ISA VMware Simple Lab and you would like to test the above described issues yourself it is very simple to do that: if 192.168.22.3 is holding the VMs in order to have a simple traffic flow we can modify ISA’s External Interface network settings from “Bridged” to “NAT”.

Figure92: ISA External Interface settings 

Make sure the “Services” are running:

Figure93: VMware services running

On ISA Wan NIC manually add two IP addresses(from VMnet8 range):

- say 192.168.146.31(my VMnet8 range 192.168.146.0/24) for publishing your CA certificate and CRL(optional, if you want to). The DG will be 192.168.146.2(probably your VMnet8 NIC from your PC uses 192.168.146.1, but you can disable it if you want)

  
Figure94: VMnet8 adapter 

Figure95: ISA’s External interface IP settings 1

- and 192.168.146.30 for publishing OWA

Figure96: ISA’s External interface IP settings 2

I have used multiple IP addresses since they are from a private range. And I can have a clear simple picture like so.

Next configure port forwarding from “Virtual Network Editor”(see our VMware Server Networking Options for more details)

Figure97: “Virtual Network Editor” NAT tab 

And add the following port forwarding mappings:

Figure98: Port Forwarding 

Now my LAN computers will access owa.cabonwind.net and dcmain.carbonwind.net by IP address 192.168.22.3. For that I have created some entries in my “Hosts” file:

Figure99: The “Hosts” file

And you have a simple traffic flow: JohnVPN at 192.168.22.2 connects to the OWA site through the “gateway” 192.168.22.3. The attacker using ARP Spoofing directs traffic from 192.168.22.2 to 192.168.22.3 through his PC 192.168.22.4.