search

drwetter / testssl.sh

Testing TLS/SSL encryption anywhere on any port
https://testssl.sh
GNU General Public License v2.0
7.95k stars 1.02k forks source link

False positive generated by Secure Client-Initiated Renegotiation? #234

Closed GianpaoloPedrazza closed 8 years ago

GianpaoloPedrazza commented 8 years ago

It seems to me that a server is marked as vulnerable against Secure Client-Initiated Renegotiation if a client-initiated renegotiation works. I tested against the save server and I got:

./testssl.sh --openssl=/usr/local/ssl/bin/openssl --wide DUT Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat

python sslyze.py DUT:443 --reneg Session Renegotiation : Client-initiated Renegotiations: Honored Secure Renegotiation: Supported

openssl s_client -connect DUT:443 Secure Renegotiation IS supported

drwetter commented 8 years ago

Am 11/12/2015 um 03:07 PM schrieb GianpaoloPedrazza:

It seems to me that a server is marked as vulnerable against Secure Client-Initiated Renegotiation if a client-initiated renegotiation works. I tested against the save server and I got:

1.

./testssl.sh --openssl=/usr/local/ssl/bin/openssl --wide DUT
Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat

2.

python sslyze.py DUT:443 --reneg

*

Session Renegotiation :
Client-initiated Renegotiations: Honored
Secure Renegotiation: Supported
  1. openssl s_client -connect DUT:443

Secure Renegotiation IS supported

Thx Gianpaolo. But bugreports are useless without the IP/hostname.

Pm is fine too.

/Dirk

drwetter commented 8 years ago

Hi @GianpaoloPedrazza,

this issue automatically closes soon if I do not get more input from you.

Cheers, Dirk

GianpaoloPedrazza commented 8 years ago

I have found on your code at line 3056 echo R | openssl s_client -legacy_renegotiation -msg -connect DUT:PORT According with following blog post http://www.exploresecurity.com/the-small-print-for-openssl-legacy_renegotiation/ it is not the best solution. I would suggest to use instead the tlsextdebug option like echo R | openssl s_client -tlsextdebug -msg -connect DUT:PORT If secure renegotiation is supported, it will show RENEGOTIATING TLS server extension "renegotiation info" (id=65281), len=25 which according with RFC 5746 is a proof that the DUT is protected. See the link below for more informations about http://www.oracle.com/technetwork/java/javase/overview/tlsreadme2-176330.html

drwetter commented 8 years ago

Ok && thx @GianpaoloPedrazza, I'll look into that.

You still have a hostname for me? (BTW: exploresecurities table doesn't reflect that either, so isn't Ivan's latest edition of his book. Not sure about the one statement in the errata though).

GianpaoloPedrazza commented 8 years ago

Sorry I don't have any hostname I can tell you because the server is running on a private LAN and is unreachable from external IPs.

drwetter commented 8 years ago

Thx anyway, @GianpaoloPedrazza.

If anybody else has an example where my test so far seems to fail pls let me know.

anwar-reddick commented 8 years ago

It seems that Secure Renegotiation (CVE-2009-3555) refers to whether the server implements RFC 5746.

And Secure Client-Initiated Renegotiation refers only to DoS and not to RFC 5746. It will be marked as "VULNERABLE (NOT ok), DoS threat" if a server allows renegotiation, because it potentially may be susceptible to DoS.

Am I right???

GianpaoloPedrazza commented 8 years ago

@drwetter: a few months later I have a hostname for you, but it is only for you. Please let me know how I can tell you

drwetter commented 8 years ago

:-) Sure, shoot!

(mail address: grep SWCONTACT testssl.sh)

Bear with me a bit pls. Currently my workload is high.

chrcoluk commented 8 years ago

It reports insecure on my exim servers, but I assumed it was reporting the correct result, however I tested just now on proftpd which I know is not vulnerable and yes is a false positive.

I will try again with the proposed code changes. My hostname is the same as in the other ticket.

chrcoluk commented 8 years ago

Ok so I adjusted the following line from

legacycmd="-legacy_server_connect"

to

legacycmd="-no_legacy_server_connect"

and the false positive is gone.

reference here http://www.exploresecurity.com/the-small-print-for-openssl-legacy_renegotiation/

bellwood commented 8 years ago

What line is this and in what version? The version updated 5 days does not hav:

"legacycmd="-legacy_server_connect"

# cat testssl.sh | grep legacycmd
     local legacycmd=""
               legacycmd="-legacy_renegotiation"
          echo R | $OPENSSL s_client $OPTIMAL_PROTO $BUGS $legacycmd $STARTTLS -msg -connect $NODEIP:$PORT $SNI $PROXY >$TMPFILE 2>>$ERRFILE &
               echo R | $OPENSSL s_client $legacycmd $STARTTLS $BUGS -msg -connect $NODEIP:$PORT $SNI $PROXY >$TMPFILE 2>>$ERRFILE

Thank you.

chrcoluk commented 8 years ago

To be honest I am definitely not sure in what I posted been accurate, plus another tester is reporting exim vulnerable as well.

I have access to a second exim server where the other tester says its not vulnerable, I checked the exim config, but there is nothing special in there which would affect ssl renegotiation so is odd. The second exim server is still marked as vulnerable with this script.

I am pretty sure my proftpd is a false alarm as it has a specific setting for this which I have configured.

Also the version is the dev version.

--edit--

I see in the latest dev the line is different now.

ventz commented 8 years ago

Hi,

Just tested against a jabber server - seeing this issue still:

The problem is the comparing of the return (the openssl check itself is completely valid):

# second try in the foreground as we are sure now it won't hang
               echo R | $OPENSSL s_client $legacycmd $STARTTLS $BUGS -msg -connect $NODEIP:$PORT
$SNI $PROXY >$TMPFILE 2>>$ERRFILE
               sec_client_renego=$?                                                  # 0=client is  
renegotiating & doesn't return an error --> vuln!
               case "$sec_client_renego" in
                    0)
                         pr_svrty_high "VULNERABLE (NOT ok)"; outln ", DoS threat"
                         fileout "sec_client_renego" "NOT OK" "Secure Client-Initiated              
Renegotiation : VULNERABLE (NOT ok), DoS threat"

Calling it manually:

# Note: on os X w/ homebrew client - thus the path
echo R | /usr/local/opt/openssl/bin/openssl s_client -legacy_renegotiation -msg -connect host.tld:port#

Produces this result:

CONNECTED(00000003)
>>> TLS 1.2  [length 0005]
    16 03 01 01 2f
>>> TLS 1.2 Handshake [length 012f], ClientHello
    01 00 01 2b 03 03 c4 65 79 1f 2d 95 07 59 9a 37
    d4 77 be d1 a3 ce 05 66 9c 96 0b 03 27 05 f9 ef
    fa 7a dc 4b 56 8f 00 00 ac c0 30 c0 2c c0 28 c0
    24 c0 14 c0 0a 00 a5 00 a3 00 a1 00 9f 00 6b 00
    6a 00 69 00 68 00 39 00 38 00 37 00 36 00 88 00
    87 00 86 00 85 c0 32 c0 2e c0 2a c0 26 c0 0f c0
    05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0
    23 c0 13 c0 09 00 a4 00 a2 00 a0 00 9e 00 67 00
    40 00 3f 00 3e 00 33 00 32 00 31 00 30 00 9a 00
    99 00 98 00 97 00 45 00 44 00 43 00 42 c0 31 c0
    2d c0 29 c0 25 c0 0e c0 04 00 9c 00 3c 00 2f 00
    96 00 41 00 07 c0 11 c0 07 c0 0c c0 02 00 05 00
    04 c0 12 c0 08 00 16 00 13 00 10 00 0d c0 0d c0
    03 00 0a 00 ff 02 01 00 00 55 00 0b 00 04 03 00
    01 02 00 0a 00 1c 00 1a 00 17 00 19 00 1c 00 1b
    00 18 00 1a 00 16 00 0e 00 0d 00 0b 00 0c 00 09
    00 0a 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02
    06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01
    03 02 03 03 02 01 02 02 02 03 00 0f 00 01 01
140735129973584:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1458792783
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

The part that should be detected is the string:

Secure Renegotiation IS NOT supported
drwetter commented 8 years ago

Am 24. März 2016 05:17:44 MEZ, schrieb Ventz Petkov notifications@github.com:

Hi,

Just tested against a jabber server - seeing this issue still:

The problem is the comparing of the return (the openssl check itself is completely valid):

# second try in the foreground as we are sure now it won't hang
echo R | $OPENSSL s_client $legacycmd $STARTTLS $BUGS -msg -connect
$NODEIP:$PORT
$SNI $PROXY >$TMPFILE 2>>$ERRFILE
sec_client_renego=$?                                                  #
0=client is  
renegotiating & doesn't return an error --> vuln!
              case "$sec_client_renego" in
                   0)
             pr_svrty_high "VULNERABLE (NOT ok)"; outln ", DoS threat"
fileout "sec_client_renego" "NOT OK" "Secure Client-Initiated          

Renegotiation : VULNERABLE (NOT ok), DoS threat"

Calling it manually:

# Note: on os X w/ homebrew client - thus the path
echo R | /usr/local/opt/openssl/bin/openssl s_client
-legacy_renegotiation -msg -connect host.tld:port#

Produces this result:

CONNECTED(00000003)
>>> TLS 1.2  [length 0005]
   16 03 01 01 2f
>>> TLS 1.2 Handshake [length 012f], ClientHello
   01 00 01 2b 03 03 c4 65 79 1f 2d 95 07 59 9a 37
   d4 77 be d1 a3 ce 05 66 9c 96 0b 03 27 05 f9 ef
   fa 7a dc 4b 56 8f 00 00 ac c0 30 c0 2c c0 28 c0
   24 c0 14 c0 0a 00 a5 00 a3 00 a1 00 9f 00 6b 00
   6a 00 69 00 68 00 39 00 38 00 37 00 36 00 88 00
   87 00 86 00 85 c0 32 c0 2e c0 2a c0 26 c0 0f c0
   05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0
   23 c0 13 c0 09 00 a4 00 a2 00 a0 00 9e 00 67 00
   40 00 3f 00 3e 00 33 00 32 00 31 00 30 00 9a 00
   99 00 98 00 97 00 45 00 44 00 43 00 42 c0 31 c0
   2d c0 29 c0 25 c0 0e c0 04 00 9c 00 3c 00 2f 00
   96 00 41 00 07 c0 11 c0 07 c0 0c c0 02 00 05 00
   04 c0 12 c0 08 00 16 00 13 00 10 00 0d c0 0d c0
   03 00 0a 00 ff 02 01 00 00 55 00 0b 00 04 03 00
   01 02 00 0a 00 1c 00 1a 00 17 00 19 00 1c 00 1b
   00 18 00 1a 00 16 00 0e 00 0d 00 0b 00 0c 00 09
   00 0a 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02
   06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01
   03 02 03 03 02 01 02 02 02 03 00 0f 00 01 01
140735129973584:error:140770FC:SSL
routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
   Protocol  : TLSv1.2
   Cipher    : 0000
   Session-ID: 
   Session-ID-ctx: 
   Master-Key: 
   Key-Arg   : None
   PSK identity: None
   PSK identity hint: None
   SRP username: None
   Start Time: 1458792783
   Timeout   : 300 (sec)
   Verify return code: 0 (ok)
---

The part that should be detected is the string:

Secure Renegotiation IS NOT supported

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/drwetter/testssl.sh/issues/234#issuecomment-200657319

Hi Petkov,

thx for catching ip.

I take care of that during Eastern.

Cheers, Dirk

Sent from my mobile

drwetter commented 8 years ago

Update: I did some weeks back a comparison of the IP @GianpaoloPedrazza supplied privately and checked also some other hosts with SSLlabs. That all was consistent, i.e. not difference between SSLlabs and testssl.

no_legacy_server_connect is not in every openssl binary available. On one of my machines there's openssl 1.0.1X, it is supported. This current branch with @PeterMosmans fork has not support for it anymore.

Besides I couldn't find this option in the checklist of Jerome (exploresecurity), though he's explicitly referring to it in the link above.

drwetter commented 8 years ago

Classic example of a vulnerable host -- don't ask me why akamai is having this:

dirks@laptop:~|0% openssl s_client -connect blogs.akamai.com:443  -no_ign_eof  <<< R
CONNECTED(00000003)
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./OU=Corporate Communications/CN=blogs.akamai.com
   i:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
 1 s:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
   i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
 2 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
   i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFjDCCBHSgAwIBAgIULbJODICxcm1FIY0wfUjAcUEZhVcwDQYJKoZIhvcNAQEL
BQAwgY0xCzAJBgNVBAYTAk5MMRIwEAYDVQQHEwlBbXN0ZXJkYW0xJTAjBgNVBAoT
[..]
----END CERTIFICATE-----
subject=/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./OU=Corporate Communications/CN=blogs.akamai.com
issuer=/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
---
No client certificate CA names sent
---
SSL handshake has read 4448 bytes and written 416 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 14EDD21D1A77704EA43CF6F471E7F8E6724FFA22F97641A2586461EF976CCE8F
    Session-ID-ctx: 
    Master-Key: 7F682960655A2DDDE4A1851C9795914228140E21AA8EB03042AEDE8185BC81BC290637D8C24AC742D7F8B16B83940264
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - c2 9a a3 f3 de 01 f8 68-fc ce da 21 41 46 6d 84   .......h...!AFm.
    0010 - de af 4b 02 52 f3 53 a2-88 96 16 99 42 61 5b 46   ..K.R.S.....Ba[F
    0020 - e3 07 cf 3c 97 be 60 51-4a 24 b2 72 36 50 41 cd   ...<..`QJ$.r6PA.
    0030 - e5 f7 09 f8 47 43 fe 56-f7 f5 32 78 6f de 85 48   ....GC.V..2xo..H
    0040 - bc 38 82 11 c9 62 f4 81-da a4 07 37 09 43 2f cd   .8...b.....7.C/.
    0050 - de e7 ba 93 6f f8 e0 67-de 91 83 3b 2b 1a 1f eb   ....o..g...;+...
    0060 - 21 3d 24 c7 d8 db 59 44-35 e3 9a d6 c8 1d de 95   !=$...YD5.......
    0070 - 8d d3 c0 d5 4d d5 ba 5e-fe 89 3f 28 b2 1b 36 6f   ....M..^..?(..6o
    0080 - 79 c8 ba a8 a8 f2 86 d7-48 6b d8 a4 53 8b 48 be   y.......Hk..S.H.
    0090 - ca 82 e6 ef c3 2d e5 64-6f 17 09 f9 9f 97 da 14   .....-.do.......

    Start Time: 1473450842
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
RENEGOTIATING
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
dirks@laptop:~|0% echo $?
0
dirks@laptop:~|0%

You see after RENEGOTIATING it comes again a part of the certificate. It's more obvious if you use the openssl option state or trace.

A non vulnerable host shows the following:

dirks@laptop:~|0% openssl s_client -connect mail.ru:443  -no_ign_eof  <<< R
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = GeoTrust Inc., CN = GeoTrust SSL CA - G3
verify return:1
depth=0 C = RU, ST = RUSSIAN FEDERATION, L = Moscow, O = LLC Mail.Ru, OU = IT, CN = mail.ru
verify return:1
---
Certificate chain
 0 s:/C=RU/ST=RUSSIAN FEDERATION/L=Moscow/O=LLC Mail.Ru/OU=IT/CN=mail.ru
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF7jCCBNagAwIBAgIQafrjsoNQMIGwkH5fIxdtMDANBgkqhkiG9w0BAQsFADBE
[..]
JtvFn/OuFARJneRlrHY4zGY2G8FntzkESTaAnmzR/JAm3g==
-----END CERTIFICATE-----
subject=/C=RU/ST=RUSSIAN FEDERATION/L=Moscow/O=LLC Mail.Ru/OU=IT/CN=mail.ru
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3307 bytes and written 516 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 4C7CFD446D616CE600192433E97DB2658E904D0172C87786083678D108194B78
    Session-ID-ctx: 
    Master-Key: 799A0FBA9885584F3255CDE90632E39A28CF7594647919276AEC154D55DD238059F87C634017FFAED3A5E8B017872AFE
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - ba e2 15 9b 7a ab d9 68-ea 83 ea 2f 45 20 73 39   ....z..h.../E s9
    0010 - 6c af da 18 fa 48 ee fe-84 e7 b5 b6 7d bb 1b f9   l....H......}...
    0020 - f9 06 6e 82 f0 8e b1 32-2a 75 20 bd 64 1b 6f 38   ..n....2*u .d.o8
    0030 - 2a 61 0b 48 53 24 8a 1c-3a f0 02 64 c6 6c cd 8b   *a.HS$..:..d.l..
    0040 - e4 b9 4e 97 16 a2 7c d4-fa 2d f3 03 03 5c 2d 0d   ..N...|..-...\-.
    0050 - e2 3a 1e b4 68 ed e4 96-7f 47 a1 a6 92 f3 a3 b9   .:..h....G......
    0060 - 00 c9 32 55 31 55 99 c7-67 39 51 6a cd ea fc c6   ..2U1U..g9Qj....
    0070 - 21 41 3f 52 e0 2f 46 3e-45 05 ab b8 80 10 bf c1   !A?R./F>E.......
    0080 - d9 90 75 f1 0a 88 b8 16-9a e2 f2 ca fd fb 6a a8   ..u...........j.
    0090 - 86 3b 04 45 14 d9 89 8b-aa 22 0a 0b 34 d8 f1 cc   .;.E....."..4...
    00a0 - 47 7d 8a fd 1d c3 6a ff-a8 6b 46 66 19 9a 56 d7   G}....j..kFf..V.

    Start Time: 1473451170
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
RENEGOTIATING
140053718468496:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
dirks@laptop:~|1% 
echo $?
1
dirks@laptop:~|0%
drwetter commented 8 years ago

For a pentest last year I was confirming this bug on a webserver by a DoS tool from THC.

DISCLAIMER: Don't run this on machines which aren't yours or you didn't ask for permission. This can have legal consequences for you...

insiderblast commented 5 years ago

That is cool Also visit my github and download my hacking new tool https://github.com/kittyzomm/ColtSploit