Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SSL-ENUM-CIPHERS: Probe may give false negative aborting complete cipher detection #254

Closed
eguser opened this issue Dec 5, 2015 · 4 comments
Closed

SSL-ENUM-CIPHERS: Probe may give false negative aborting complete cipher detection #254

eguser opened this issue Dec 5, 2015 · 4 comments
Labels
NSE question

Comments

@eguser
Copy link

eguser commented Dec 5, 2015

In cases where target servers have restricted ciphers and/or protocol (SSLv3), the initial 2 probes sent to detect whether the target server is running TLS/SSL may fail with "no cipher suites in common" or "Client requested protocol SSLv3 not enabled or not supported".

If we detect an SSL alert it is probably safe to assume that the target server is running TLS/SSL so continue with full scan.

Line 877

    local is_ssl = false
    -- probes from nmap-service-probes
    for _, probe in ipairs({
        --TLSSessionReq
        "\x16\x03\0\x00g\x01\0\x001\x03\x03U\x1c\xa7\xe4random1random2random3\z
        random4\0\x00\x0a\0/\0\x0a\0\x13\x009\0\x04\x01\0\0\x30\0\x0d\0,\0*\0\z
        \x01\0\x03\0\x02\x06\x01\x06\x03\x06\x02\x02\x01\x02\x03\x02\x02\x03\x01\z
        \x03\x03\x03\x02\x04\x01\x04\x03\x04\x02\x01\x01\x01\x03\x01\x02\x05\x01\z
        \x05\x03\x05\x02",
        -- SSLSessionReq
        "\x16\x03\0\0S\x01\0\0O\x03\0?G\xd7\xf7\xba,\xee\xea\xb2`~\xf3\0\xfd\z
        \x82{\xb9\xd5\x96\xc8w\x9b\xe6\xc4\xdb<=\xdbo\xef\x10n\0\0(\0\x16\0\x13\z
        \0\x0a\0f\0\x05\0\x04\0e\0d\0c\0b\0a\0`\0\x15\0\x12\0\x09\0\x14\0\x11\0\z
        \x08\0\x06\0\x03\x01\0",
      }) do
      local status, resp = comm.exchange(host, port, probe)
      if status and resp and (
          resp:match("^\x16\x03[\0-\x03]..\x02...\x03[\0-\x03]") or
          resp:match("^\x15\x03[\0-\x03]\0\x02\x02[F\x28]")
          ) then
        is_ssl = true
        break
      end
    end
    return is_ssl
@dmiller-nmap
Copy link

What are you proposing? The existing code does check for an alert (line 894 checks for a response beginning with \x15, the Alert record type), so I don't see how this could be improved. Do you have a specific suggestion?

@eguser
Copy link
Author

eguser commented Dec 7, 2015

Thanks for the comment, you are right! It looks like some server implementations may just kill the connection when an alert is generated, thus not sending a response. Perhaps adding an argument that forces full scan for ciphers may be an option.

if force_check or ( status and resp and (

My apologies for my lack of knowledge, this is my first time dealing with LUA.

@dmiller-nmap
Copy link

NSE has a feature for forcing a script to run, bypassing the rule function.
Use --script +ssl-enum-ciphers to do this, but recognize that this will
send a lot of probes to every open port detected, so it's dangerous to use
if you don't already know that the port is a SSL/TLS service.

I did notice while investigating this that we did not fix the
TLSSessionRequest probe within the script when we made a fix for #199 in
nmap-service-probes. I applied this in r35490, so that should help in cases
like this. If you have suggestions for other modifications to this probe,
we would be glad to hear them.
On Dec 6, 2015 10:54 PM, "eguser" notifications@github.com wrote:

Thanks for the comment, you are right! It looks like some server
implementations may just kill the connection when an alert is generated,
thus not sending a response. Perhaps adding an argument that forces full
scan for ciphers may be an option.

if force_check or ( status and resp and (

My apologies for my lack of knowledge, this is my first time dealing with
LUA.

—
Reply to this email directly or view it on GitHub
#254 (comment).

@eguser
Copy link
Author

eguser commented Dec 8, 2015

Thanks again! Agreed on the risk, I'd only use it on a specific port I know it is SSL/TLS. I think I'm set for now.

@eguser eguser closed this as completed Dec 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NSE question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@eguser @dmiller-nmap