Metasploit-framework: 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:inssl_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:indo_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:inrequest'
[-] /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:inrun'
[*] 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