OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=error: dh key too small

[wchen-r7]

I run into the following error while attempting to run glassfish_login or glassfish_deployer against a Glassfish 3.1.2.2 (Win Server 2003) test box:

[04/15/2016 03:31:57] [i(2)] core: Reloading auxiliary module scanner/http/glassfish_login. Ambiguous module warnings are safe to ignore
[04/15/2016 03:32:03] [e(0)] core: Error running against host 192.168.1.109: SSL_connect returned=1 errno=0 state=error: dh key too small
/Users/wchen/rapid7/msf/lib/rex/socket/ssl_tcp.rb:136:in `connect'
/Users/wchen/rapid7/msf/lib/rex/socket/ssl_tcp.rb:136:in `block in initsock_with_ssl_version'
/Users/wchen/.rvm/rubies/ruby-2.1.9/lib/ruby/2.1.0/timeout.rb:75:in `timeout'
/Users/wchen/rapid7/msf/lib/rex/socket/ssl_tcp.rb:134:in `initsock_with_ssl_version'
/Users/wchen/rapid7/msf/lib/rex/socket/ssl_tcp.rb:88:in `initsock'
/Users/wchen/rapid7/msf/lib/rex/socket/comm/local.rb:339:in `create_by_type'
/Users/wchen/rapid7/msf/lib/rex/socket/comm/local.rb:33:in `create'
/Users/wchen/rapid7/msf/lib/rex/socket.rb:47:in `create_param'
/Users/wchen/rapid7/msf/lib/rex/socket/tcp.rb:37:in `create_param'
/Users/wchen/rapid7/msf/lib/rex/socket/tcp.rb:28:in `create'
/Users/wchen/rapid7/msf/lib/rex/proto/http/client.rb:181:in `connect'
/Users/wchen/rapid7/msf/lib/metasploit/framework/login_scanner/glassfish.rb:66:in `send_request'
/Users/wchen/rapid7/msf/lib/metasploit/framework/login_scanner/glassfish.rb:36:in `check_setup'
/Users/wchen/rapid7/msf/modules/auxiliary/scanner/http/glassfish_login.rb:176:in `run_host'
/Users/wchen/rapid7/msf/lib/msf/core/auxiliary/scanner.rb:121:in `block (2 levels) in run'
/Users/wchen/rapid7/msf/lib/msf/core/thread_manager.rb:100:in `call'
/Users/wchen/rapid7/msf/lib/msf/core/thread_manager.rb:100:in `block in spawn'

Note that this used to work (https://github.com/rapid7/metasploit-framework/pull/3716), so the bug came in after that.

[wchen-r7]

It looks like it's not specific to GlassFish.

Here's me testing https://metasploit.com w/ curl:

$ curl -v https://metasploit.com
* Rebuilt URL to: https://metasploit.com/
*   Trying 54.192.137.71...
* Connected to metasploit.com (54.192.137.71) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: www.metasploit.com
* Server certificate: Go Daddy Secure Certificate Authority - G2
* Server certificate: Go Daddy Root Certificate Authority - G2
> GET / HTTP/1.1
> Host: metasploit.com
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 200 OK

And then the same using auxiliary/scanner/http/ssl:

msf auxiliary(ssl) > set SSLVersion TLS1.2
SSLVersion => TLS1.2
msf auxiliary(ssl) > set SSL true
SSL => true
msf auxiliary(ssl) > run

[*] Error: 54.192.137.71: OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: sslv3 alert handshake failure
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(ssl) > 

[firefart]

@wchen-r7 https://bugzilla.redhat.com/show_bug.cgi?id=1232110 and https://bugzilla.redhat.com/show_bug.cgi?id=1255417

looks like your openssl version is too new :) It looks like they dropped support for small DH keys which does not really help on pentesting machines :(

[wchen-r7]

ahhhh, so annoying.

Thanks @FireFart

[busterb]

Sort of feels like we need to create an alternate ruby SSL wrapper to deal with old stuff. We can't really rely on the system ruby for any particular feature, especially old and insecure ones.

[firefart]

@busterb right but reimplementing the SSL stack is kinda over the top :) I think the small DH keys can only be enabled on openssl compile time. The same problem exists with browsers refusing connections to old, insecure SSL protocols.

Is it possible to ship a custom compiled openssl version with metasploit? where all the old stuff like SSLv2, export ciphers and small diffie helman keys are enabled?

[busterb]

That's more like what I meant; an alternate linked implementation. We do ship a local version with the Omnibus installers, but Kali currently ships whatever happens to come with Debian upstream. We need a solution more like sslscan, which statically links a 'kitchen sink' openssl build: https://github.com/rbsec/sslscan#openssl-issues

[firefart]

@busterb so would it be possible to ship openssl as a rubygem / precompiled in a special folder, manipulate the PATH variable on start of msf* to include the path in the first position and trick ruby into using our own openssl version?

[wchen-r7]

Do you guys want me to reopen this ticket? It feels many people can run into this problem.

[busterb]

Yeah, we should address it somehow, since only more people will begin seeing it.

[sekritskwurl]

Bump. I ran into this issue with tomcat_mgr_deploy. I'm going to give recompiling Openssl to support weaker DH groups a shot so I can get the exploit to work, but it is far from the ideal solution.

[bcook-r7]

perhaps this broken-out version of the ruby openssl extension could be repurposed for use internally by metasploit: https://github.com/rubysl/rubysl-openssl

[naterobbified]

Anyone find a way to resolve this error? Got the same error while attempting a different metasploit exploit recently.

[karllll]

One possible bypass is to set the Net::HTTP ciphers option, excluding Diffie Hellman ciphers as described here ( https://zackhobson.com/2014/02/10/ssl_and_ruby_part_2/ ). I used http.ciphers = ['AES128-SHA'].

[twinvega]

Not a fix, but you could proxy your traffic through something like Burp which wouldn't have the issue.

[jepunband]

hi did anyone solve this please??

[-] Auxiliary failed: OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=error: certificate verify failed [-] Call stack: [-] /opt/metasploit-framework/embedded/lib/ruby/2.4.0/net/protocol.rb:44:in connect_nonblock' [-] /opt/metasploit-framework/embedded/lib/ruby/2.4.0/net/protocol.rb:44:in ssl_socket_connect' [-] /opt/metasploit-framework/embedded/lib/ruby/2.4.0/net/http.rb:948:in connect' [-] /opt/metasploit-framework/embedded/lib/ruby/2.4.0/net/http.rb:887:in do_start' [-] /opt/metasploit-framework/embedded/lib/ruby/2.4.0/net/http.rb:876:in start' [-] /opt/metasploit-framework/embedded/lib/ruby/2.4.0/net/http.rb:1407:in request' [-] /opt/metasploit-framework/embedded/framework/modules/auxiliary/gather/shodan_search.rb:59:in shodan_query' [-] /opt/metasploit-framework/embedded/framework/modules/auxiliary/gather/shodan_search.rb:109:in run' [*] Auxiliary module execution completed

[egypt]

Issue still exists on recent Kali. A coworker hit it with ibm_websphere_java_deserialize.

[BeanBagKing]

Hit this issue on scanner/http/http_login

Edit: For anyone looking for a workaround, proxy the traffic through Burp, which will ignore the certificates, e.g. set Proxies http:127.0.0.1:8080 - I would imagine this would work for any module getting this error.

[coblax]

have anybody was solve this problem

[Raphaeangelo]

Bump! I'm getting

Exploit failed [unreachable]: OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=error: dh key too small

[cnotin]

Same here with an old server that only supports RC4 and DES which aren't supported anymore since OpenSSL 1.1.0... See this discussion on the Kali bug tracker: https://bugs.kali.org/view.php?id=5158 Right now Kali rolling uses OpenSSL 1.1.1d-2 but the unsafeopenssl package (see limitations in post) was created and offers version 1.0.2t-0kali1

[lesterpotter]

I'm getting... Exploit failed [unreachable]: OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=error: sslv3 alert handshake failure

I'm working around it using Burp with... set Proxies 127.0.0.1:8080

[pich4ya]

workaround

$ sed -i 's,^\(MinProtocol[ ]*=\).*,\1'TLSv1.0',g' /etc/ssl/openssl.cnf 
$ sed -i 's,^\(CipherString[ ]*=\).*,\1'DEFAULT@SECLEVEL=1',g' /etc/ssl/openssl.cnf

[github-actions[bot]]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

[BeanBagKing]

As far as I know, this issue still exists and the report should probably be left open.

[Z3d6d]

set SSL false before running the exploit Make sure you remove the proxy before doing this.

[victorlapshev]

set SSL false before running the exploit Make sure you remove the proxy before doing this.

But what if target uses SSL? Will it still works if I will disable SSL option?

[BeanBagKing]

set SSL false before running the exploit Make sure you remove the proxy before doing this.

But what if target uses SSL? Will it still works if I will disable SSL option?

No, I'm pretty sure Z3d6d is misunderstanding what the issue is here.

[bmilliron67]

This is still an issue. I'm getting this error with the f5_icontrol_rce module. I've tried changing the settings in the /etc/ssl/openssl.cnf to no avail. Looks like metasploit has it's own version at /usr/share/metasploit-framework/config/openssl.conf however this doesn't appear to be configured correctly. Nessus ships with it's own version of openssl binary. I think metasploit should do the same.

[adfoster-r7]

Looks like metasploit has it's own version at /usr/share/metasploit-framework/config/openssl.conf however this doesn't appear to be configured correctly

@bmilliron67 When this issue was created, Metasploit didn't have its own openssl conf file - it's only been added recently for openssl 3 support. If there's additional changes to make to the config file now - pull requests are more than welcome :+1:

Nessus ships with it's own version of openssl binary. I think metasploit should do the same.

If you install Metasploit via the Rapid7 nightly installer, it should come bundled with openssl 1.1.1 - https://docs.metasploit.com/docs/using-metasploit/getting-started/nightly-installers.html

[mzpqnxow]

As far as I can tell, this is still an issue

It's not an issue with openssl.cnf nor does bundling openssl 1.1.1 address it. The DH key size check has been in place since before 1.1.0 (I'm not sure which exact version added it, but probably somewhere in 1.0.x)

If I remember correctly, it's hard-coded into the openssl SSL/TLS code and can not be turned off- except (maybe) by using a low level custom callback

As another on this thread mentioned, one approach to a workaround would be instructing metasploit to not choose a DH-enabled cipher-suite (as long as some are available on the server)

... however, I can't get this to work. metasploit seems to ignore it without throwing any error as to why (which should perhaps be a new GH issue)

After confirming a specific remote host has a non-DH kex cipher-suite using testssl.sh (which has excellent backwards compatibility):

TLS 1
 x39     DHE-RSA-AES256-SHA                DH 512     AES         256      TLS_DHE_RSA_WITH_AES_256_CBC_SHA                   
 x3a     ADH-AES256-SHA                    DH 512     AES         256      TLS_DH_anon_WITH_AES_256_CBC_SHA                   
 x35     AES256-SHA                        RSA        AES         256      TLS_RSA_WITH_AES_256_CBC_SHA                       
 x33     DHE-RSA-AES128-SHA                DH 512     AES         128      TLS_DHE_RSA_WITH_AES_128_CBC_SHA                   
 x34     ADH-AES128-SHA                    DH 512     AES         128      TLS_DH_anon_WITH_AES_128_CBC_SHA                   
 x2f     AES128-SHA                        RSA        AES         128      TLS_RSA_WITH_AES_128_CBC_SHA                       
 x07     IDEA-CBC-SHA                      RSA        IDEA        128      TLS_RSA_WITH_IDEA_CBC_SHA                          
 x18     ADH-RC4-MD5                       DH 512     RC4         128      TLS_DH_anon_WITH_RC4_128_MD5                       
 x05     RC4-SHA                           RSA        RC4         128      TLS_RSA_WITH_RC4_128_SHA                           
 x04     RC4-MD5                           RSA        RC4         128      TLS_RSA_WITH_RC4_128_MD5                           
 x16     EDH-RSA-DES-CBC3-SHA              DH 512     3DES        168      TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA                  
 x1b     ADH-DES-CBC3-SHA                  DH 512     3DES        168      TLS_DH_anon_WITH_3DES_EDE_CBC_SHA                  
 x0a     DES-CBC3-SHA                      RSA        3DES        168      TLS_RSA_WITH_3DES_EDE_CBC_SHA                      
 x15     EDH-RSA-DES-CBC-SHA               DH 512     DES         56       TLS_DHE_RSA_WITH_DES_CBC_SHA                       
 x1a     ADH-DES-CBC-SHA                   DH 512     DES         56       TLS_DH_anon_WITH_DES_CBC_SHA                       
 x09     DES-CBC-SHA                       RSA        DES         56       TLS_RSA_WITH_DES_CBC_SHA    

In msfconsole I then use the following, to force it to a non-DH cipher-suite on TLS1.0:

set SSLCIPHER AES128-SHA
set SSLVERSION TLS1
run

I still end up with:

Exploit failed [unreachable]: OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=error: dh key too small

I also tried using the IANA/RFC name for the cipher ( TLS_RSA_WITH_AES_256_CBC_SHA) but had the same behavior. Perhaps I'm not using set SSLCIPHER correctly?

I ran into this years ago with an old Python interpreter build I had to maintain- the only way I was able to address it was by hand-patching the check in the openssl source

Should the issue I'm having with SSLCIPHER be a new issue? Or am I doing something wrong there? Surely I should at least be getting a warning that it didn't choose the cipher-suite I told it too, right?

EDIT: Oops, forgot to mention the version- from nightly-installers as of 2/16/2023, msfconsole -v reporting 6.3.3-dev-