jpetter
asked on
How To Detect SSL Running on a Port
Hi,
I work in vulnerability assessment and recently we began to see a series of SSL vulnerabilities related to MS SQL on 1433. While Nessus does have more than its share of false positives, from my experience it is usually pretty accurate regarding SSL.
We have been using MS SQL for well over 15 years, and this is the first I'm starting to see of this, and I'm seeing quite a bit of it. I don't know if it's being set on by default, but I find it odd that only now we're beginning to see these.
Naturally the application teams are all screaming that these must be false positives. I thought it would be pretty trivial to see if SSL was running on 1433, but as is often the case my thinking was a bit off.
I thought I should be able to see this by SSH'ing into one of our Linux scanners, opening two terminals. With one, I set tcpdump up to listen to traffic from one of the impacted SQL Servers. With the other one, I ran the command openssl s_client -state -connect <host>:<port>. I was expecting to see the SSL handshake from openssl in one terminal, and I thought I would also see the SSL handshake in tcpdump/wireshark. This did not happen. Instead, the output from the openssl command didn't even look like it completed a handshake. I don't know, but suspect this is because I didn't go in using something like MS SQL Query Analyzer.
After that failed, I thought I could at least prove my method by setting up the same two terminals, except this time I would be targeting one of our other scanners on its secure port of 8834. The output from the openssl command clearly showed the handshake, but the tcpdump (and tshark) output showed nothing of the SSL handshake. So my thinking was not correct. How would I be able to see the SSL handshake in tcpdump/tshark?
Perhaps more importantly, how can I verify if SSL is even running on 1433 on those MS SQL hosts? The potential vulnerabilities were pointing to certificate errors, yet I was not able to even pull the cert. I tried both the openssl binary and Firefox.
If anyone has any idea on how I might be able to tell with certainty whether those SQL ports - 1433 - are truly running SSL I would be grateful. I would also lover to know where my reasoning went wrong on being able to sniff/capture the SSL handshake.
Here is the output from trying to check the handshake with openssl:
]# openssl s_client -state -connect <host>:1433
CONNECTED(00000003)
SSL_connect:before/connect
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 112 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Any and all help is really appreciated.
Thank you,
Jeff
I work in vulnerability assessment and recently we began to see a series of SSL vulnerabilities related to MS SQL on 1433. While Nessus does have more than its share of false positives, from my experience it is usually pretty accurate regarding SSL.
We have been using MS SQL for well over 15 years, and this is the first I'm starting to see of this, and I'm seeing quite a bit of it. I don't know if it's being set on by default, but I find it odd that only now we're beginning to see these.
Naturally the application teams are all screaming that these must be false positives. I thought it would be pretty trivial to see if SSL was running on 1433, but as is often the case my thinking was a bit off.
I thought I should be able to see this by SSH'ing into one of our Linux scanners, opening two terminals. With one, I set tcpdump up to listen to traffic from one of the impacted SQL Servers. With the other one, I ran the command openssl s_client -state -connect <host>:<port>. I was expecting to see the SSL handshake from openssl in one terminal, and I thought I would also see the SSL handshake in tcpdump/wireshark. This did not happen. Instead, the output from the openssl command didn't even look like it completed a handshake. I don't know, but suspect this is because I didn't go in using something like MS SQL Query Analyzer.
After that failed, I thought I could at least prove my method by setting up the same two terminals, except this time I would be targeting one of our other scanners on its secure port of 8834. The output from the openssl command clearly showed the handshake, but the tcpdump (and tshark) output showed nothing of the SSL handshake. So my thinking was not correct. How would I be able to see the SSL handshake in tcpdump/tshark?
Perhaps more importantly, how can I verify if SSL is even running on 1433 on those MS SQL hosts? The potential vulnerabilities were pointing to certificate errors, yet I was not able to even pull the cert. I tried both the openssl binary and Firefox.
If anyone has any idea on how I might be able to tell with certainty whether those SQL ports - 1433 - are truly running SSL I would be grateful. I would also lover to know where my reasoning went wrong on being able to sniff/capture the SSL handshake.
Here is the output from trying to check the handshake with openssl:
]# openssl s_client -state -connect <host>:1433
CONNECTED(00000003)
SSL_connect:before/connect
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 112 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Any and all help is really appreciated.
Thank you,
Jeff
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The ssl should be the same just that it is likely not the openssl. More straightforward is using sniffer either nw monitor or wireshark to detect ssl as the protocol. Even errors will ne surfaced during the sniff if any.
an ssl connection uses encryption hen the client requests it.
it function similar to smtp with TLS (STARTTLS).
openssl s_client -connect mail.somedomain.com:25 -starttls smtp
i.e the unencrypted connection is started, and then they negotiate a secure communication channel within the established connection.
I am unfamiliar with the ms sql trigger to start the tls session.
looked to see what/whether an example exist that could be used with openssl.
it function similar to smtp with TLS (STARTTLS).
openssl s_client -connect mail.somedomain.com:25 -starttls smtp
i.e the unencrypted connection is started, and then they negotiate a secure communication channel within the established connection.
I am unfamiliar with the ms sql trigger to start the tls session.
looked to see what/whether an example exist that could be used with openssl.
ASKER
Sorry for the long time delay. I appreciate your help.
Thanks
Thanks
I personally prefer SSLScan. It reports all supported ciphers, preferred cipher preference, and the SSL certificate details. Any port is supported.
sslscan --no-failed host.domain.local:1433Testing SSL server cia.gov on port 443
Supported Server Cipher(s):
Accepted SSLv3 256 bits AES256-SHA
Accepted SSLv3 128 bits AES128-SHA
Accepted SSLv3 168 bits DES-CBC3-SHA
Accepted SSLv3 128 bits RC4-SHA
Accepted SSLv3 128 bits RC4-MD5
Accepted TLSv1 256 bits AES256-SHA
Accepted TLSv1 128 bits AES128-SHA
Accepted TLSv1 168 bits DES-CBC3-SHA
Accepted TLSv1 128 bits RC4-SHA
Accepted TLSv1 128 bits RC4-MD5
Prefered Server Cipher(s):
SSLv3 256 bits AES256-SHA
TLSv1 256 bits AES256-SHA
SSL Certificate:
Version: 2
Serial Number: -4294967295
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
Not valid before: Apr 8 00:00:00 2013 GMT
Not valid after: Apr 8 23:59:59 2015 GMT
Subject: /1.3.6.1.4.1.311.60.2.1.3=US/busines sCategory= Government Entity/serialNumber=Govern ment Entity/C=US/ST=Virginia/L= McLean/O=C entral Intelligence Agency/OU=Operations 1/OU=Terms of use at www.verisign.com/rpa (c)05/CN=www.cia.gov
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:a5:b6:f2:36:e5:3c:c4:38:e8:c4:d5: 88:01:47:
65:78:01:aa:7b:f7:8b:96:ef:2c:af:d9: 76:23:38:
7d:34:cd:93:64:9e:a7:3a:d8:b4:70:a0: af:e7:fd:
88:d5:0b:be:c7:c0:63:a4:e2:6f:06:d9: e4:ee:9c:
11:19:2f:4d:18:01:5b:87:3d:fb:52:ee: be:2b:41:
f2:2a:d4:e0:66:7f:57:0c:bd:56:38:b8: 5b:f0:10:
43:0d:a1:82:43:0a:c7:3f:2a:8a:2e:d4: 63:43:4b:
30:72:09:ba:4e:f2:de:d2:8f:37:d3:3c: be:90:34:
2c:55:9d:cb:36:8b:63:4c:68:b2:9b:fb: 02:81:cb:
28:6b:be:3b:c8:c3:0d:f4:b1:3a:73:fb: 19:79:ac:
1d:30:cc:6f:52:7a:d7:bc:41:a4:4a:b7: 6b:b0:5e:
9e:5a:26:91:60:39:84:f2:e8:0c:dc:87: 66:f7:2e:
5e:2b:ec:2c:87:3b:2d:23:33:8f:de:4e: 1e:b6:10:
3f:f7:8f:30:cc:31:b2:f7:7b:56:36:27: d4:44:eb:
0b:76:df:f4:ba:25:a2:6d:b7:97:e1:1a: 1b:b8:31:
89:a4:61:f2:ad:7e:e0:49:c3:34:34:66: 70:95:24:
cf:7c:f9:4c:5e:40:d0:47:72:66:57:80: 7b:05:b0:
c5:87
Exponent: 65537 (0x10001)
X509v3 Extensions:
X509v3 Subject Alternative Name:
DNS:www.cia.gov
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.23.6
CPS: https://www.verisign.com/cps
X509v3 CRL Distribution Points:
URI:http://EVIntl-crl.verisign.com/EVIntl2006.crl
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto
X509v3 Authority Key Identifier:
keyid:4E:43:C8:1D:76:EF:37:53:7A:4F: F2:58:6F:9 4:F3:38:E2 :D5:BD:DF
Authority Information Access:
OCSP - URI:http://ocsp.verisign.com
CA Issuers - URI:http://EVIntl-aia.verisign.com/EVIntl2006.cer
ASKER
That's a pretty sweet tool, but while I see you specified port 1433 in your command, the results posted are for 443. What I had found was that most of the tools I used for diagnosing SSL issues are OpenSSL based and didn't give me what I needed when testing it against MS SQL. What I concluded, and probably incorrectly, is that these tools did not work for me on MS SQL as those connections need to exchange a couple of TDS packets that I assumed OpenSSL did not know how to handle. I ended up using Microsoft's Network Monitor for these particular hosts.
Thanks
Thanks
ASKER
If either of you have any further ideas, I'd be glad to hear them, otherwise I'll just split the points and move on. This whole exercise was to enable me to tell if the SSL vulnerabilities were valid as I have a lot of app teams claiming this to be a false positive.
Thanks,
Jeff