Man in the Middle III / Notes

http://www.dest-unreach.org/socat/doc/socat.html
socat - SSL:server:4443,cafile=server.crt,cert=client.pem


MITM主要就是设置一个中间站，当Client端的安全设置不强的的时候，比如没有设置证书，或者没有检查证书的hostname是不是和站点的hostname匹配的时候，就可以通过设置中间站，让Client发来的信息误认为，这是一个有认证的站点，或者就是目标站点。从而暴露Client发过来的加密信息。

the application does not perform any validation to ensure that the hostname used by the TCP connection matches the hostname in the Subject of the certificate.

***********************

TLS verification

As part of a request sent over TLS, before sending the request, the client will make sure that:

• The certificate is valid.
• The certificate matches the hostname it's visiting.

For example, if you bind the same socat from the previous exercise (using the self-signed certificate):

$ sudo socat openssl-listen:443,reuseaddr,fork,cert=$FILENAME.pem,cafile=$FILENAME.crt,verify=0 -

The connection will fail if you connect using the following ruby code:

require 'socket'
require 'openssl'
socket = TCPSocket.new('localhost',  443)
ssl_context = OpenSSL::SSL::SSLContext.new
ssl_context.ca_file = '/usr/local/etc/openssl/cert.pem'
ssl_context.verify_mode =  OpenSSL::SSL::VERIFY_PEER
socket = OpenSSL::SSL::SSLSocket.new(socket, ssl_context)
socket.connect
socket.write("TEST")

Since the certificate is self-signed, Ruby will reject it:

% sudo socat openssl-listen:443,reuseaddr,fork,cert=$FILENAME.pem,cafile=$FILENAME.crt,verify=0 -
2016/01/19 21:02:19 socat[65904] E SSL_accept(): error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

However, if you use a valid certificate (as in issued by a CA that is trusted by the client):

% sudo socat openssl-listen:443,reuseaddr,fork,cert=hackingwithpentesterlab.link.cer,cafile=GandiStandardSSLCA2.pem,key=hackingwithpentesterlab.link.key,verify=0 -  

To complete this exercise, you can access a valid certificate and its' private key here.

The application will send the message to the server:

% sudo socat openssl-listen:443,reuseaddr,fork,cert=hackingwithpentesterlab.link.cer,cafile=GandiStandardSSLCA2.pem,key=hackingwithpentesterlab.link.key,verify=0 -
TEST

In this example, the application does not perform any validation to ensure that the hostname used by the TCP connection matches the hostname in the Subject of the certificate. Therefore, any certificate issues by a valid CA will allow you to bypass the TLS checks. The cost to get a certificate is insignificant nowadays as they are given for free with no domain.

Here the option cafile=GandiStandardSSLCA2.pem is given to `socat` to ensure that `socat` will present the full chain of certificates to the client as the client may not have Gandi's certificate in their trusted store.

Conclusion

This exercise showed you how you can intercept a TLS connection from a client that does not properly check the hostname against the certificate's subject. It's a pretty common issue when testing mobile applications and thick clients as not every developer will take the time to test this behaviour using a valid certificate (or by adding their own CA to the keystore and creating a certificate with a different hostname). I hope you enjoyed learning with PentesterLab.