An Old Cisco OpenSSH Bug

From support issue to 0day… sort of.

Introduction

Sometimes bugs are found by accident.

Earlier this year, one of my colleagues, Katie Sexton, was triaging a support issue escalated to her regarding a possible false positive in our detection of CVE-2018–10933. As a refresher, this was the LibSSH bug that allowed a user to present an affected SSH server with a SSH2_MSG_USERAUTH_SUCCESS message out of order, which bypassed authentication.

During her evaluation of the issue, Katie noted the service in question was not an affected LibSSH version, but there was definitely something funny going on that warranted further investigation.

The following post details the findings of our investigation.

Unsupported Products

But first! It should be noted that the products in question have long since been unsupported. The SSH implementation discussed here appears to be fixed in both newer Cisco devices and mainline OpenSSH versions. The affected products we tested in our lab (a variety of Cisco products) were also out of support or end of life.

That being said, who cares? We figured that since we were able to replicate the customer’s issue in our lab and had a confirmed case of these devices still being used within a large enterprise, further investigation was warranted. Additionally, a sample banner check of a single affected product (Cisco Small Business Switch — SF-500–48, an end-of-sale device) on Shodan indicated 2500+ affected devices exposed publicly.

We tested on a variety of dated Cisco switches and firewalls, each of which had an OpenSSH version of SSH-2.0-OpenSSH_5.9p1.RL or prior.

We could not replicate this on any version of mainline OpenSSH or later versions used in Cisco products. This isn’t to say that this issue does not exist in other versions, but we were unable to confirm. Cisco was not able to provide us with a list of products — supported or unsupported.

The Bug

As with the LibSSH issue, the flaw here deals with improper sequence handling. A typical SSH authentication sequence goes something like this:

https://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/095/9566/9566f2.jpg

For the LibSSH issue, it was possible for the client to send the server a SSH2_MSG_USERAUTH_SUCCESS message out of order (instead of a USERAUTH_REQUEST as above), which would simply bypass the authentication routine altogether. In OpenSSH and patched versions of LibSSH, when attempting this, you’ll be met with a MSG_UNIMPLEMENTED response, a closed connection, or similar failure.

Nessus attempts to check for CVE-2018–10933 by sending the USERAUTH_SUCCESS out of order and checking if the target opens a valid channel (CHANNEL_OPEN_CONFIRM), which generally indicates that further interaction is permitted and authentication has been successfully “completed.” .

Nessus Plugin
...
session.sshsend(code:sshlib::PROTO_SSH_MSG_SERVICE_REQUEST, data:sshlib::mk_ssh_string("ssh-userauth"));
session.sshrecv_until(end_states:make_list("SERVICE_REQUEST_SUCCESS", "SOC_CLOSED"));
if(session.cur_state.val != "SERVICE_REQUEST_SUCCESS")
{
  session.close_connection();
  exit(1, "Did not receive SERVICE_ACCEPT for ssh-userauth authentication.");
}
session.cur_state.set("USERAUTH_REQUEST");
session.sshsend(data: mkdword(0, order:BYTE_ORDER_BIG_ENDIAN), code:sshlib::PROTO_SSH_MSG_USERAUTH_SUCCESS);
...
if(channel && channel.state == sshlib::CHANNEL_STATE_ACCEPTED)
{
  session.close_connection();
  report =
    'Nessus was able to successfully open a channel on the libssh server\n' +
    'with no credentials.\n';
  security_report_v4(port: port, severity:SECURITY_HOLE, extra:report);
  exit(0);
}

This is where our customer’s false positive originated. Their device wasn’t killing the connection, but was instead opening a valid channel. In its current state, this channel wasn’t very useful. After a bit more prodding, however, we realized we could continue sending further requests and get an interactive login prompt for the Cisco IOS shell.

At this point, it was clear that we stumbled upon a valid bug, but was it a vulnerability? What security impact, if any, is there?

As it turns out, this is a complete bypass of certain security features. By sending the USERAUTH_SUCCESS out of order and getting the login prompt to show up, even when password authentication is disabled via SSH, you are still able to login to the device provided you have valid credentials.

For example, if an administrator has decided to disable password authentication on the device in favor of private key authentication, this restriction can be bypassed by exploiting the flaw discussed here. To exaggerate this impact a bit, it’s possible that this restriction could also mean passwords are not rotated often or changed from their defaults since the administrator is under the impression these credentials are no longer useful.

The PoC

The proof-of-concept code below is a modified version of the existing exploits for CVE-2018–10933.

https://github.com/tenable/poc/blob/master/cisco/small_business_sf_bypass.py

Sample output:

# Password Authentication Disabled
$ ssh admin@<target>
admin@<target>: Permission denied (publickey).
# Running Proof-of-Concept Script
$ python poc.py <target> 22 "show version"
...
DEBUG:paramiko.transport:IN: 00 00 00 6C 0F 5E 00 00 00 00 00 00 00 53 0D 0A    ...l.^.......S..
DEBUG:paramiko.transport:IN: 0D 0D 0A 0D 0A 0D 0A 55 73 65 72 20 4E 61 6D 65    .......User Name
DEBUG:paramiko.transport:IN: 3A 61 64 6D 69 6E 0D 0A 0D 50 61 73 73 77 6F 72    :admin...Passwor
DEBUG:paramiko.transport:IN: 64 3A 2A 2A 2A 2A 2A 2A 2A 2A 0D 0A 0D 0D 0A 0D    d:********......
DEBUG:paramiko.transport:IN: 0A 43 69 73 63 6F 53 46 35 30 30 2D 34 38 23 73    .CiscoSF500-48#s
DEBUG:paramiko.transport:IN: 68 6F 77 20 76 65 72 73 69 6F 6E 0D 0A 0D 0D 0A    how version.....
DEBUG:paramiko.transport:IN: 0D 56 BA 97 35 EC 4E 13 D0 B8 EB C5 4E 69 3D 71    .V..5.N.....Ni=q
...

Conclusion

After our investigation, despite these devices being unsupported, we reported the issue to Cisco out of due diligence.

Even though the vulnerable devices are unsupported, Cisco noted that they would investigate the issue to see if other products — particularly currently supported products — are affected. They were not able to provide further information.

While this obviously isn’t the most impressive bug, especially given its age, it’s definitely still useful in scenarios where credentials have been compromised (or worse, left as default), but additional authentication methods have been enabled and need to be bypassed.

This bug has long since been fixed in mainstream versions of OpenSSH (if it ever existed in them at all, we were unable to verify) and newer versions used in Cisco products. Given that we received this support inquiry in 2019, however, it’s evident that even though these products are officially end of life and out of support as far as Cisco is concerned, they are definitely still in use today by major organizations. This begs the question: What other unsupported products are these companies using with much more severe issues hidden under the hood?

The above issues are also detailed in TRA-2019–21. Cisco released cisco-sa-20190501-scbv as well.