sslcert in auxiliary/server/capture/* isn't validated as an ssl cert

h00die commented 5 years ago

There doesn't seem to be any validation that the sslcert file is anything more than a real file, so without connecting to the service you are hosting to test, you'd have no idea if it works.

For instance.

/etc/os-release as sslcert

msf5 > use auxiliary/server/capture/ftp
msf5 auxiliary(server/capture/ftp) > echo "" > /root/.msf4/logs/framework.log
[*] exec: echo "" > /root/.msf4/logs/framework.log

msf5 auxiliary(server/capture/ftp) > set ssl true
ssl => true
msf5 auxiliary(server/capture/ftp) > set srvport 990
srvport => 990
msf5 auxiliary(server/capture/ftp) > set sslcert /etc/os-release
sslcert => /etc/os-release
msf5 auxiliary(server/capture/ftp) > set verbose true #does nothing
[-] The following options failed to validate: Value 'true #does nothing' is not valid for option 'VERBOSE'.
verbose => false
msf5 auxiliary(server/capture/ftp) > set verbose true
verbose => true
msf5 auxiliary(server/capture/ftp) > run
[*] Auxiliary module running as background job 0.
msf5 auxiliary(server/capture/ftp) > 
[*] Started service listener on 0.0.0.0:990 
[*] Server started.

msf5 auxiliary(server/capture/ftp) > curl -k --ftp-ssl --user admin:password123 ftps://127.0.0.1:990
[*] exec: curl -k --ftp-ssl --user admin:password123 ftps://127.0.0.1:990

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

We bomb out? Why, because its not a real cert/pem. However, w/o testing ahead of time, you'd have no idea. The logs don't help much either, since it just says the SSL negotiations failed.

msf5 auxiliary(server/capture/ftp) > cat /root/.msf4/logs/framework.log
[*] exec: cat /root/.msf4/logs/framework.log

[11/03/2018 21:55:41] [e(0)] core: The following options failed to validate: Value 'true #does nothing' is not valid for option 'VERBOSE'.
[11/03/2018 21:56:01] [e(0)] core: The accept() returned nil in stream server listener monitor:  #<Socket:fd 13>

This all came from trying to write some cool docs for server/capture/ftp utilizing impersonate_ssl, however trying to debug WHY the connection wasn't valid has taken several hours with no end in sight.

While this isn't necessarily part of the ticket, it stemmed from these docs, and if you have insight on getting it to work, let me know so at least i have known good to go with! (the PKCS1 vs 8 part is just my guessing since i've made a self-signed cert in pkcs8 that did work with the server)

FTPS with auxiliary/gather/impersonate_ssl and curl

Of note, impersonate_ssl creates a PKCS#1 format .key file (-----BEGIN RSA PRIVATE KEY-----). This needs to be converted into a PKCS#8 format (-----BEGIN PRIVATE KEY-----), which can be facilitated with openssl.

Server:

msf5 > use auxiliary/gather/impersonate_ssl
msf5 auxiliary(gather/impersonate_ssl) > set rhosts metasploit.com
rhosts => metasploit.com
msf5 auxiliary(gather/impersonate_ssl) > run

[*] metasploit.com:443 - Connecting to metasploit.com:443
[*] metasploit.com:443 - Copying certificate from metasploit.com:443
/OU=Domain Control Validated/CN=www.metasploit.com
[*] metasploit.com:443 - Beginning export of certificate files
[*] metasploit.com:443 - Creating looted key/crt/pem files for metasploit.com:443
[+] metasploit.com:443 - key: /root/.msf4/loot/20181103211913_default_205.251.207.63_metasploit.com_k_522494.key
[+] metasploit.com:443 - crt: /root/.msf4/loot/20181103211913_default_205.251.207.63_metasploit.com_c_548655.crt
[+] metasploit.com:443 - pem: /root/.msf4/loot/20181103211913_default_205.251.207.63_metasploit.com_p_551118.pem
[*] Auxiliary module execution completed
msf5 auxiliary(gather/impersonate_ssl) > openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in /root/.msf4/loot/20181103211913_default_205.251.207$
[*] exec: openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in /root/.msf4/loot/20181103211913_default_205.251.207.63_metasploit.com_k_522494.key$

msf5 auxiliary(gather/impersonate_ssl) > cat /root/.msf4/loot/metasploit_pkcs8.key /root/.msf4/loot/20181103211913_default_205.251.207.63_metasploit.co$
[*] exec: cat /root/.msf4/loot/metasploit_pkcs8.key /root/.msf4/loot/20181103211913_default_205.251.207.63_metasploit.com_c_548655.crt > /root/.msf4/lo$

msf5 auxiliary(gather/impersonate_ssl) > use auxiliary/server/capture/ftp
msf5 auxiliary(server/capture/ftp) > set srvport 990
srvport => 990
msf5 auxiliary(server/capture/ftp) > set ssl true
ssl => true
msf5 auxiliary(server/capture/ftp) > set sslcert /root/.msf4/loot/metasploit.pem
sslcert => /root/.msf4/loot/metasploit.pem
msf5 auxiliary(server/capture/ftp) > run
[*] Auxiliary module running as background job 0.
msf5 auxiliary(server/capture/ftp) >
[*] Started service listener on 0.0.0.0:990
[*] Server started.

Client:

# curl -k --ftp-ssl --user admin:password123 ftps://127.0.0.1:990
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 127.0.0.1:990

h00die commented 5 years ago

Following along at home, from what I can tell, execution flow looks like: https://github.com/rapid7/metasploit-framework/blob/a3d74d926cdcc96cecd8b21c284e4d3ddfbe35fe/lib/msf/core/exploit/tcp_server.rb#L66 https://github.com/rapid7/rex-socket/blob/912a11fdadd76c026c5d2dbe9834fb158e5ef50e/lib/rex/socket/parameters.rb#L145 https://github.com/rapid7/rex-socket/blob/912a11fdadd76c026c5d2dbe9834fb158e5ef50e/lib/rex/socket/ssl.rb#L82 https://github.com/rapid7/rex-socket/blob/912a11fdadd76c026c5d2dbe9834fb158e5ef50e/lib/rex/socket/x509_certificate.rb#L24

Which seems to actually parse the two files correctly.

msf5 auxiliary(server/capture/ftp) > irb
[*] Starting IRB shell...
[*] You are in auxiliary/server/capture/ftp

>> require 'openssl'
=> false
>> OpenSSL::PKey::RSA.new("-----BEGIN PRIVATE KEY-----\nMIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBAK+FhBqrb3h46TFo\nBe7FH7JRojpIr38Cpzcy2k3W5mEBMHusZPp0HLtSTUMYH6UBnq29sgGc6N3LjSXk\nR5l2M/Z7LpeqHzTfiEhU3+vpWURZvxamKjsfz5pLhw5AAthXiaVj2tPjp6FU1tLl\nYiyxts5TxO9D+N9mfHd9GwjNUANNAgMBAAECgYB8picxAXrCZavF6If+D4P5ETxS\ng/gODQZPjw+1o94sGboiukVkED2vUj2IXoNqnYHhBQx7VMGTcdEljb7DX0x6mmoU\nw0pUcXzTCHw5gyTCKxwVejyCThVWjC3YOZ/ubFUaNV6gIYljKZqXLqEFj9lpUN+6\n9HxQkWvREqYQCb3HyQJBAOnqwph6jSdgOMRbD4/AMNwmnEjdnPNqm6KkZJC1pK7/\nAc+BaH2GeIA7D1QjPulXBccurDmkBU4H65XyHx4bGpsCQQDAF3h03VJjFIgPbbFq\n0uDSUpCHgm5OPCgA4PdrYbUBJ97krwUGQpN9LOHj0RtMnuCu8qAsDY+T08nx7GHv\ndqQ3AkEAnQ+IAaGnzVyKQS1zUW4WYHt8TGCg1cArKBWBgLi2DtoieRXG9yGnH1KI\nhFH2F+7ablckRL+g4DfpMxETW7+PKQJAHXZ8H1CjBldr1xH4GG5n1VqcmGxFBvLr\nH9dhm7LM1HSNF35QwvkLLjPoIc085q+nvq2wK5GY6A+f9d9P1i7YWQJAc2e/u7l9\nnAckdJmQDJjQrZdpruojFWEm2Um1n9sUAuR8lP3zvbZyuY3p+GzSu/wvPLvOhPG9\nXU4DkM1gAkpoOA==\n-----END PRIVATE KEY-----")
=> #<OpenSSL::PKey::RSA:0x00005622fa44b150>
>> OpenSSL::X509::Certificate.new("-----BEGIN CERTIFICATE-----\nMIICLTCCAZagAwIBAgIJAeFDOKa42/xxMA0GCSqGSIb3DQEBCwUAMEAxITAfBgNV\nBAsTGERvbWFpbiBDb250cm9sIFZhbGlkYXRlZDEbMBkGA1UEAxMSd3d3Lm1ldGFz\ncGxvaXQuY29tMB4XDTE1MTIwODE4MDMzOFoXDTE4MTIwODE4MDMzOFowQDEhMB8G\nA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRswGQYDVQQDExJ3d3cubWV0\nYXNwbG9pdC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK+FhBqrb3h4\n6TFoBe7FH7JRojpIr38Cpzcy2k3W5mEBMHusZPp0HLtSTUMYH6UBnq29sgGc6N3L\njSXkR5l2M/Z7LpeqHzTfiEhU3+vpWURZvxamKjsfz5pLhw5AAthXiaVj2tPjp6FU\n1tLlYiyxts5TxO9D+N9mfHd9GwjNUANNAgMBAAGjLzAtMAwGA1UdEwEB/wQCMAAw\nHQYDVR0OBBYEFLqkd66EsETnaMj/aR2Bpb4cjvW4MA0GCSqGSIb3DQEBCwUAA4GB\nABJsz4aAnOSMir20W7GfDPFqkdUlQhSXxs7xsVFQfcrh/7Mg+mI+mC19B/SbWt2M\n8IpfCLJOU9AFkmGg1xTC5098D5EQ4BTQSPA2S3gT90APqlbhT+SZydlYaFseQesx\n3Lrff4zByZhq+hUUyi457WureUbE+P7LYWiqK+Z46Tyv\n-----END CERTIFICATE-----")
=> #<OpenSSL::X509::Certificate: subject=#<OpenSSL::X509::Name CN=www.metasploit.com,OU=Domain Control Validated>, issuer=#<OpenSSL::X509::Name CN=www.metasploit.com,OU=Domain Control Validated>, serial=#<OpenSSL::BN:0x00005622fb072cf8>, not_before=2015-12-08 18:03:38 UTC, not_after=2018-12-08 18:03:38 UTC>

pseudoeuro commented 5 years ago

The same issue seems to happen with multi/handler

https://github.com/rapid7/metasploit-framework/issues/11014

With a fresh install from Kali the issue seems to be resolved, so I'm assuming is something on our machine or some broken update on Kali.

github-actions[bot] commented 3 years ago

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.

rapid7 / metasploit-framework

sslcert in auxiliary/server/capture/* isn't validated as an ssl cert #10908

/etc/os-release as sslcert

FTPS with auxiliary/gather/impersonate_ssl and curl