1

I am running a trial of Cobalt Strike which runs over the Metasploit Framework. I am trying to perform an SSH related attack on my laptop, and I get the error in the title for all SSH related attacks. If I try to login via ssh (not an attack) using Metasploit I get an error for the username and pass I know is correct; this might be related to the error in the title. Any ideas on how to fix this?

After changing sshd_conf the following error occurs:

enter image description here

6
  • I'm seeing answers to this with Google searches. Have you tried their suggested remedies?
    – schroeder
    Commented May 31, 2015 at 4:19
  • Yes. One mentioned trying to make the openssh version agree. I tried that and it didn't work
    – dylan7
    Commented May 31, 2015 at 4:27
  • Could you use the Metasploit modules directly (outside Cobalt Strike) so that it is confirmed that the error is related to the Metasploit framework and not some default config in CS?
    – void_in
    Commented May 31, 2015 at 17:28
  • @void_in I ran both ssh_login and the exploit symantec_smg_ssh in the regular msfconsole. ssh_login said the correct username and password failed. The exploit gave the same error in the title again.
    – dylan7
    Commented May 31, 2015 at 20:48
  • @dylan7 The supported Kex (Key Exchange algorithms) are defined at github.com/rapid7/metasploit-framework/blob/master/lib/net/ssh/…. If you could manually look at what kex algorithms are needed for the SSH server, we could add it to the supported algorithms list. A standard SSH server should be able to negotiate with these algorithms; however in your case I think the SSH server is either too outdated or configured only with specific algorithms. The list of supported kex should be in the ssh_config file.
    – void_in
    Commented Jun 1, 2015 at 5:47

1 Answer 1

2

Metasploit uses an SSH implementation written in Ruby which only supports the algorithms listed below.

https://github.com/rapid7/metasploit-framework/blob/b3c7fff32a62739241a223515574674b4a6b483c/lib/net/ssh/transport/algorithms.rb#L31

ALGORITHMS = {
  :host_key    => %w(ssh-rsa ssh-dss),
  :kex         => %w(diffie-hellman-group-exchange-sha1
                     diffie-hellman-group1-sha1),
  :encryption  => %w(aes128-cbc 3des-cbc blowfish-cbc cast128-cbc
                     aes192-cbc aes256-cbc [email protected]
                     idea-cbc none arcfour128 arcfour256),
  :hmac        => %w(hmac-sha1 hmac-md5 hmac-sha1-96 hmac-md5-96 none),
  :compression => %w(none [email protected] zlib),
  :language    => %w() 
}

The server needs to provide a match in each category to create a secure connection. Unfortunately, the Metasploit Ruby algorithms are considered weak by contemporary cryptographic standards, and newer OpenSSH server configurations disable them by default.

Metasploit would require additional Ruby code to implement newer algorithms. The server, however, can enable additional algorithms in the sshd_config. Modify /etc/ssh/sshd_config to specify compatible algorithms:

# Metasploit Client
KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256cbc,arcfour128,arcfour256
# Unsupported Ciphers from Metasploit: [email protected],idea-cbc,none
MACs hmac-sha1,hmac-md5,hmac-sha1-96,hmac-md5-96
# Unsupported MACs from Metasploit: none

This will totally replace the server's algorithms with weaker ones. A better solution would be to add the algorithms, or some subset, to the defaults. Unfortunately, the configuration options require complete specification, so it is OpenSSH version dependant. Defaults can be found in man sshd_config and then specified with the above options as additions.

For Fedora 22, it would be something like:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected],aes128-cbc
KexAlgorithms [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
MACs [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
4
  • I edited the sshd_config file but now ssh won't start. When I do sshd -t I get no hostkeys available. I posted what happened in my questions.
    – dylan7
    Commented Jun 5, 2015 at 20:50
  • 1
    Too be clear, the above lines should be added or replace existing entries in sshd_config. The error messages state ssh host keys are missing. As root, you can run ssh-keygen -A to recreate the host keys. The presence of /usr/local/etc/ instead of /etc/ssh/ makes me think you may have installed OpenSSH from source which took over the systemd unit file. So keys could be in /etc/ssh, but the local installation is looking in the other directory. This could be corrected by providing the proper path via HostKey entries in sshd_config
    – jandryuk
    Commented Jun 6, 2015 at 22:17
  • Thank you. I just have another question. When I ran the ssh tectia_passwd_changereqexploit I got no errors. However, it just stalled at Auths that can continue: 51 . I read that it means the server is trying to tell me what authentication methods are allowed. Wasn't that specified when I wrote MACs into sshd_config?
    – dylan7
    Commented Jun 8, 2015 at 4:09
  • I'm not familiar with tectia_passwd_changereq, but according to the [openssh source] (fossies.org/dox/openssh-6.8p1/…) 51 corresponds to SSH2_MSG_USERAUTH_FAILURE, so it could just be an error response.
    – jandryuk
    Commented Jun 8, 2015 at 12:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .