Solved

How To Detect SSL Running on a Port

Posted on 2013-11-12
8
2,622 Views
Last Modified: 2013-12-03
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 initialization
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
0
Comment
Question by:jpetter
  • 3
  • 2
  • 2
  • +1
8 Comments
 
LVL 76

Assisted Solution

by:arnold
arnold earned 250 total points
ID: 39643741
The encryption triggering mechanism is initiated by the client.
http://technet.microsoft.com/en-us/library/ms189067(v=sql.105).aspx
I am unfamiliar on whether

The fix to your Nessus reported issues applies to the system in its entirety.

The fix is to update the schannel/crypto within the registry that limits to the non-vulnerable ciphers/methods

http://social.technet.microsoft.com/Forums/windowsserver/en-US/a3a3d1e3-95f8-481a-8cef-42e386464be5/how-to-disable-sslv2-and-weak-ciphers-in-windows-2008-iis-70?forum=windowsserver2008r2webtechnologies

If you have a firewall with DPI it can detect SSL traffic.
0
 
LVL 61

Accepted Solution

by:
btan earned 250 total points
ID: 39644989
0
 

Author Comment

by:jpetter
ID: 39648994
Thank you both. I have read those articles - actually read most of them prior to posting, and have been using the manual methods with the openssl binary for years. I guess I'm going to have to rethink this. I was looking for a quick way to be able to determine remotely, whether an instance of MS SQL was using SSL or not. Initially I was thinking I could run a packet capture against the MS SQL host, open another terminal and execute an openssl connect against the host on 1433, and be able to see part of the SSL handshake. This will work with many SSL enabled ports where I can see the SSL handshake just from executing something like openssl s_client -state -connect <host>:<port>. This doesn't seem to work with MS SQL - suspect MS is implementing SSL a bit differently.

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
0
 
LVL 61

Expert Comment

by:btan
ID: 39649751
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.
0
Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 76

Expert Comment

by:arnold
ID: 39649860
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.
0
 

Author Comment

by:jpetter
ID: 39692310
Sorry for the long time delay. I appreciate your help.

Thanks
0
 
LVL 14

Expert Comment

by:Giovanni Heward
ID: 39693125
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:1433

Open in new window


Testing 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/businessCategory=Government Entity/serialNumber=Government Entity/C=US/ST=Virginia/L=McLean/O=Central 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:94: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
0
 

Author Comment

by:jpetter
ID: 39693192
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
0

Featured Post

What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

Join & Write a Comment

Malicious software is nothing new. Viruses have been created and spread since before physical networks became popular; back then viruses spread via floppy disk and modem connections with shared systems. Viruses weren't so rampant and protecting your…
Read about achieving the basic levels of HRIS security in the workplace.
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…
This video demonstrates how to create an example email signature rule for a department in a company using CodeTwo Exchange Rules. The signature will be inserted beneath users' latest emails in conversations and will be displayed in users' Sent Items…

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now