Re: ssl-cert.nse

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 2 Apr 2010 14:40:03 -0500
"Norris Carden" <ncarden () ascendfcu org> wrote:

> I'm looking for a way to determine if a SSL proxy is in place between
> a system and the web server.
>
> I believe the Bluecoat proxy replaces the server SSL certificate with
> an internal corporate one, but there are man-in-the-middle techniques
> that forge a certificate practically identical to the one from the
> server.
>
> Can you think of a way this ssl-cert.nse could be used to determine if
> the certificate is coming from the same address as the web server?
> Might this also be able to determine if the host side is using a SSL
> proxy? Is there another script or method that will accomplish this?
>
> Thanks,
>
> Norris Carden, CISSP, CISA


Norris,

This is a hard question because there are lots of different types of
SSL "proxies" and there are lots of answers, none 100% complete.  That
said, I'll bite.

I think it mostly comes down to "does the certificate validate"?  For
example:

$ sudo nmap -p 443 -v -d -Pn -n -T5 --script=ssl-cert www.citibank.com
[...]
NSE: Loaded 1 scripts for scanning.
Initiating SYN Stealth Scan at 19:49
Scanning www.citibank.com (192.193.103.222) [1 port]
Packet capture filter (device eth0): dst host 132.239.181.229 and (icmp or ((tcp or udp or sctp) and (src host 
192.193.103.222)))
Discovered open port 443/tcp on 192.193.103.222
[...]
Nmap scan report for www.citibank.com (192.193.103.222)
Host is up, received user-set (0.046s latency).
Scanned at 2010-04-02 19:49:56 UTC for 0s
PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
| ssl-cert: Subject: commonName=www.citibank.com/organizationName=Citigroup Inc./stateOrProvinceName=New 
York/countryName=US/serialNumber=2154254/postalCode=10043/1.3.6.1.4.1.311.60.2.1.2=Delaware/streetAddress=399 Park 
Avenue/organizationalUnitName=gtcbweb1-www/localityName=New York/1.3.6.1.4.1.311.60.2.1.3=US/businessCategory=V1.0, 
Clause 5.(b)
| Issuer: commonName=VeriSign Class 3 Extended Validation SSL SGC CA/organizationName=VeriSign, 
Inc./countryName=US/organizationalUnitName=Terms of use at https://www.verisign.com/rpa (c)06
| Not valid before: 2009-06-16 00:00:00
| Not valid after:  2011-06-16 23:59:59
| MD5:   df03 2c3b 7536 4c97 73fd 134f f0e5 63dc
| SHA-1: 95db da4c 9f78 9fb4 7288 7a3d 18ae 796e 9a47 fa50
| -----BEGIN CERTIFICATE-----
| MIIGSDCCBTCgAwIBAgIQenDGtKyQqWYSLP5aicEQfjANBgkqhkiG9w0BAQUFADCB
| vjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
| ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
| YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNjE4MDYGA1UEAxMv
| VmVyaVNpZ24gQ2xhc3MgMyBFeHRlbmRlZCBWYWxpZGF0aW9uIFNTTCBTR0MgQ0Ew
| HhcNMDkwNjE2MDAwMDAwWhcNMTEwNjE2MjM1OTU5WjCCAQcxEzARBgsrBgEEAYI3
| PAIBAxMCVVMxGTAXBgsrBgEEAYI3PAIBAhMIRGVsYXdhcmUxGzAZBgNVBA8TElYx
| LjAsIENsYXVzZSA1LihiKTEQMA4GA1UEBRMHMjE1NDI1NDELMAkGA1UEBhMCVVMx
| DjAMBgNVBBEUBTEwMDQzMREwDwYDVQQIEwhOZXcgWW9yazERMA8GA1UEBxQITmV3
| IFlvcmsxGDAWBgNVBAkUDzM5OSBQYXJrIEF2ZW51ZTEXMBUGA1UEChQOQ2l0aWdy
| b3VwIEluYy4xFTATBgNVBAsUDGd0Y2J3ZWIxLXd3dzEZMBcGA1UEAxQQd3d3LmNp
| dGliYW5rLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANo9gH3C
| pqZrcE5zZhsiGvVwqF/tGMYwaCsfKcbofS7Flo3FGo22PCf4/34CpVR+S4YH8Xa3
| ThzpmrDizObHWnhG4rn4PGrZaJ3dSHgIQBaNbz63BH02APTSQu7o2/udc7Jcqq/0
| VSv8IFiFa7Ur3iRrkc9cIlwwSAgWlJYQR2w6Od+O5nwvT2q3zmbq7yZ8+suuEeHJ
| ahjuXWWhWM3DSt9JYdv9NYmuit07zgaJPT9LJ4vGVwRSG4rO4cp4EbL0nLkxOZTB
| g2i9MgOzlIeXrICiwXBdWtfEJSLbT2T2lUka24ZaLS0ol5IRTyMLxeRPWboCnsBp
| Svv0ihSIPOy3FGcCAwEAAaOCAfQwggHwMAkGA1UdEwQCMAAwHQYDVR0OBBYEFNby
| q9YbDWLLQR4n6Ewc76AGuOzOMAsGA1UdDwQEAwIFoDA+BgNVHR8ENzA1MDOgMaAv
| hi1odHRwOi8vRVZJbnRsLWNybC52ZXJpc2lnbi5jb20vRVZJbnRsMjAwNi5jcmww
| RAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXBjAqMCgGCCsGAQUFBwIBFhxodHRwczov
| L3d3dy52ZXJpc2lnbi5jb20vcnBhMCgGA1UdJQQhMB8GCCsGAQUFBwMBBggrBgEF
| BQcDAgYJYIZIAYb4QgQBMB8GA1UdIwQYMBaAFE5DyB127zdTek/yWG+U8zji1b3f
| MHYGCCsGAQUFBwEBBGowaDArBggrBgEFBQcwAYYfaHR0cDovL0VWSW50bC1vY3Nw
| LnZlcmlzaWduLmNvbTA5BggrBgEFBQcwAoYtaHR0cDovL0VWSW50bC1haWEudmVy
| aXNpZ24uY29tL0VWSW50bDIwMDYuY2VyMG4GCCsGAQUFBwEMBGIwYKFeoFwwWjBY
| MFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUY
| MCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjANBgkqhkiG
| 9w0BAQUFAAOCAQEAldbZSMLCJHsN8Z5+54VZEBPCKuGa0QK01hDkttzmji7E/+2W
| bLLqjU6zEPU3rIQ5dy3cfv57Ca7pANOoYCAy5q8zOMLUSBl7f9rO1i6E0Q8D2Jn4
| nsJ6wD2D4cUowxpH2lmoK9BexkF8t0bH+9AfAA+PTdlHrVrtXGi8km1n59QGiyEk
| B4v7YyKucQaBMZA6FH0R6GYBNxA4JXY1gSTaeZOlA3I0LrEA3zVWwsEEf+nhaiVo
| QWVPiKpeXVPUDWEYWjLQklAjBVubxlFqvwk/RLbXZSgWEtScjIln2Vjk6rKGio+7
| 7vL0HPT9gncwhjy/rwsyEek0zW29nwDq/9gDFQ==
|_-----END CERTIFICATE-----
Final times for host: srtt: 45828 rttvar: 45828  to: 229140

Read from /usr/share/nmap: nmap-services.
Nmap done: 1 IP address (1 host up) scanned in 0.80 seconds
           Raw packets sent: 1 (44B) | Rcvd: 1 (44B)


Will yield the certificate being used.  You can then copy the cert
output and paste into something like the following to get more info
about the certificate:

$ cat | sed -r 's/^\|[ _]//g' | openssl x509 -text

Or you can verify with:

$ cat | sed -r 's/^\|[ _]//g' | openssl verify


Of course, unless you have all the various certs in the chain, you'll
end up with something like:

stdin: /1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=V1.0,
Clause 5.(b)/serialNumber=2154254/C=US/postalCode=10043/ST=New
York/L=New York/street=399 Park Avenue/O=Citigroup
Inc./OU=gtcbweb1-www/CN=www.citibank.com
error 20 at 0 depth lookup:unable to get local issuer certificate


So with the above being said, I think you can do a lot to detect SSL
proxies without getting to actually trying to validate the
certificates.  Many SSL proxies are going to generate forged certs for
any site you visit and sign them all with the same key.  You should be
able to do a simple scan of several SSL servers and check to see if
the Issuer: field is the same.  You can do the same sanity check on the
subject structure as well as the dates the certificate is valid for.
Only when this all looks correct would you even need to bother
validating.


I think the only trouble you'll run into is when the persons running
the proxy are working with the persons running the SSL sites and they
have installed a copy of the certificate and private key ON THE PROXY.
In this case I don't believe there is any 100% sure way you can do to
detect that a proxy is serving up your SSL connection.  For external
sites this shouldn't be possible but for internal sites it may be.  You
could try using "ssl-enum-ciphers.nse" to check for anomalies in the
accepted algorithms.  You'd expect a IIS server to use the IIS+Windows
ciphers and Apache+OpenSSL to use a slightly different set.  If you get
the same support out of a server running IIS as you do Apache you might
be dealing with a proxy.

Regards,

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAku2T8gACgkQqaGPzAsl94KLjwCgnVhvio6Ycvev+esOomlL7Eoc
N6UAoIkK+tWNNB2osjGHIfaXTF0mz2NA
=IQz2
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/