Version 1.4.10.06 resolves this vulnerability. I have pushed this version out successfully to multiple production SF300-48's and verified with Security Center scans that the vulnerability is now mitigated successfully   Final Note from SR:  686073737 (Now closed)   Hello Chris, We posted Maintenance Releases for Sx200/300/500 and Sx250/350/550 including new features and security vulnerabilities. Here is the link to the release notes - Sx200/300/500 1.4.10 - https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbss/sf20x_sg20x/release_notes/R_1_4_10_6_RN.pdf   CDETS CSCvo94676 is a duplicate of CSCvo28588 Firmware release 1.4.10.6 can be download here: https://software.cisco.com/download/home/283019685/type/282463181/release/1.4.10.06   Please let us know if you have question. Thanks. Lee, Yiu Kay Technical Consulting Engineer - Case Management ... View more

Update: I have not forgotten about this thread and nor have I given up on Cisco (SR686073737). I am pushing them hard to work/resolve this issue (no information has come from them since ticket creation as of yet).   On the other side of the equation Tenable has done exactly what they said they would do, by relabeling and updating the vulnerability in there database as follows. This is the exact same vulnerability just updated to be less misleading. I will update this thread when I have more information/resolution.   SSH Protocol Authentication Bypass (Remote Exploit Check) (118154) Synopsis The remote server is vulnerable to an authentication bypass.   Description The remote ssh server is vulnerable to an authentication bypass. An attacker can bypass authentication by presenting SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST method that normally would initiate authentication.   Note: This vulnerability was disclosed in a libssh advisory but has also been observed as applicable to other applications and software packages.   Solution Upgrade to libssh 0.7.6 / 0.8.4 or later, if applicable. Otherwise, contact your product vendor. Plugin Output Nessus was able to successfully open a channel on the libssh server with no credentials. ... View more

Update: I have not forgotten about this thread and have not given up on Cisco (SR686073737). I am pushing them hard to work/resolve this issue.   On the other side of the equation Tenable has done exactly what they said they would do, by relabeling and updating the vulnerability in there data base as follows. This is the exact same vulnerability just updated to be less misleading. I will update this thread when I have more information/resolution.   SSH Protocol Authentication Bypass (Remote Exploit Check) (118154) Synopsis The remote server is vulnerable to an authentication bypass.   Description The remote ssh server is vulnerable to an authentication bypass. An attacker can bypass authentication by presenting SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST method that normally would initiate authentication.   Note: This vulnerability was disclosed in a libssh advisory but has also been observed as applicable to other applications and software packages.   Solution Upgrade to libssh 0.7.6 / 0.8.4 or later, if applicable. Otherwise, contact your product vendor. Plugin Output Nessus was able to successfully open a channel on the libssh server with no credentials. ... View more

I have opened a new Cisco Service Request(686073737) with the below information I got back from Tenable. I will update this thread if/when I get good data back from Cisco support in regards to this matter.   I opened a Tenable case (00744582) and we gathered some diagnostics scans and packet captures and they have come back telling me that these model switches are indeed vulnerable. The report I got back from them is as follows:   Chris, The product team reviewed the scan results and logs and responded. The response is detailed, but I will start with a short summary.   The Cisco SF300 switch is vulnerable to this exploit. The Nessus logs confirm it. The plugin itself, in its description, is a bit misleading and we are looking to update it. While it references a libssh vulnerability, we have seen this exploit affect other SSH servers.   First, here is the relevant portion of the debugging log report from the scan results that shows the SSH server being exploited.   [2019-01-25 21:40:17] [session 0] ssh_client_state.set: ** Entering STATE KEX_DONE ** [2019-01-25 21:40:17] [session 0] session.sshsend: Outgoing Raw Unencrypted packet [PROTO_SSH_MSG_SERVICE_REQUEST] : 0x00: 00 00 00 1C 0A 05 00 00 00 0C 73 73 68 2D 75 73 ..........ssh-us 0x10: 65 72 61 75 74 68 D5 35 6B E2 74 40 F1 60 9F 2D erauth.5k.t@.`.- 0x20: [2019-01-25 21:40:18] [session 0] session.sshrecv: Incoming Decrypted packet [PROTO_SSH_MSG_SERVICE_ACCEPT] : 0x00: 00 00 00 1C 0A 06 00 00 00 0C 73 73 68 2D 75 73 ..........ssh-us 0x10: 65 72 61 75 74 68 BC 84 4E 1D 00 B5 3B 72 36 EA erauth..N...;r6. 0x20: [2019-01-25 21:40:18] [session 0] session.sshrecv_until: Handling packet.type: 6 [PROTO_SSH_MSG_SERVICE_ACCEPT] [2019-01-25 21:40:18] [session 0] client_cb_msg_service_accept: Entering handler. [2019-01-25 21:40:18] [session 0] ssh_client_state.set: ** Entering STATE SERVICE_REQUEST_SUCCESS ** [2019-01-25 21:40:18] [session 0] ssh_client_state.set: ** Entering STATE USERAUTH_REQUEST ** [2019-01-25 21:40:18] [session 0] session.sshsend: Outgoing Raw Unencrypted packet [PROTO_SSH_MSG_USERAUTH_SUCCESS] : 0x00: 00 00 00 0C 06 34 00 00 00 00 EE 26 E3 32 C8 F6 .....4.....&.2.. 0x10: [2019-01-25 21:40:18] [session 0] session.sshsend: Outgoing Raw Unencrypted packet [PROTO_SSH2_MSG_CHANNEL_OPEN] : 0x00: 00 00 00 2C 13 5A 00 00 00 07 73 65 73 73 69 6F ...,.Z....sessio 0x10: 6E 00 00 00 00 00 00 FA 00 00 00 7D 00 0F 6D 15 n..........}..m. 0x20: 7F F8 4D D3 AC 41 38 44 DF 45 18 F7 EE 56 53 52 ..M..A8D.E...VSR 0x30: [2019-01-25 21:40:20] [session 0] session.sshrecv: Incoming Decrypted packet [PROTO_SSH2_MSG_CHANNEL_OPEN_CONFIRMATION] : 0x00: 00 00 00 1C 0A 5B 00 00 00 00 00 00 00 00 00 00 .....[.......... 0x10: 01 00 00 00 00 80 01 71 2A 82 D5 E1 B5 C2 B9 DD .......q*....... 0x20: [2019-01-25 21:40:20] [session 0] session.sshrecv_until: Handling packet.type: 91 [PROTO_SSH2_MSG_CHANNEL_OPEN_CONFIRMATION] [2019-01-25 21:40:20] [session 0] client_cb_channel_open_confirm: Entering handler. [2019-01-25 21:40:20] [session 0] session.close_socket: Closing socket. [2019-01-25 21:40:20] [session 0] ssh_client_state.set: ** Entering STATE SOC_CLOSED **   If an SSH server receives a USERAUTH_SUCCESS packet from a client, it should close the connection, because that packet type should never come from a client.   A vulnerable SSH server will accept the USERAUTH_SUCCESS packet from a client and update the session to an authenticated state, bypassing authentication. The plugin tests to see if the exploit worked by trying to open a channel, something that can only be done post-authentication.   The target SSH server in this scan opened the channel and sent the server-side channel number back as confirmation. The target is vulnerable to the exploit because it accepted a USERAUTH_SUCCESS packet from a client and transitioned the session to an authenticated state where a channel request was accepted, without a USERAUTH_REQUEST being made from the client.   This is a remote exploit plugin and the output is based on the remote SSH server being exploitable, not the product name or version reported by the SSH server banner. The SSH server banner may be configurable and may not be accurate to what is running on the target, so it's not a good indicator of vulnerability.   The plugin is working as designed and has found have the same vulnerability as libssh. We are requesting that the plugin name, description, solution, and output should be updated to be more generic rather than assuming the SSH server is libssh, and to and present the vulnerability simply as "server accepts USERAUTH_SUCCESS without a USERAUTH_REQUEST" which is exactly what the plugin is checking for.   The above details came directly from our engineers on the product team. The switch is vulnerable to this exploit and you can ignore the reference to libssh. ... View more

We run an internal Security Center Nessus based scanner and all of our Small Business switches have been flagged with this vulnerability. CLI output shows that they run openssh and not libssh however at the time the open source documentation for version 1.4.9.x was not available so I opened a SR and requested the document as well as questioned why if indeed this was the case it was coming back as a match. below is the details of that SR. I have not contacted Nessus yet. I plan to do so as my next steps to see what they say about the positive flag.   Open source document is now available for download  I have attached it along with the SA Open Source used in Cisco Sx300 Series Switches 1.4.9.x to this reply.     SR 685547180 We are currently running version 1.4.9.4 firmware on all of our SF300 switches. Our nessus scanner has reported a vulnerability in regards to libssh. CLI shows that these appliances use openssh and not libssh which should nullify the finding, however the Open Source document for version 1.4.9.x is not available from the website to have documentation of this fact. Please provide us with the new Open Source document that corresponds to our current version.   CLI Output switch#show version SW version 1.4.9.4 ( date 04-Jun-2018 time 00:07:58 ) Boot version 1.3.5.06 ( date 21-Jul-2013 time 15:12:10 ) HW version V02 switch#show ip ssh SSH Server enabled. Port: 22 RSA key was generated. DSA(DSS) key was generated. SSH Public Key Authentication is disabled. SSH Password Authentication is disabled. Active incoming sessions: IP address SSH username Version Cipher Auth Code ----------------- -------------- ----------- ----------- -------------- xxx.xxx.xxx.xxx user SSH-2.0-OpenSSH_7.4 aes128-ctr hmac-sha1   Hi,  Attached is the “open source used” document for the 300 series switches, firmware v1.4.9.x. It’ll be available on the website soon, as well. Thanks for pointing out that it was missing. As for the security advisory you forwarded, I’m waiting to hear back. I suspect that’s also an oversight. As near as I can tell, it wouldn’t apply to the Small Business switches since they don’t run libssh. The latest open source documents for the 300/500/350/550 series show all of them running openssh instead, from what I can see. I’ll let you know when I hear something more official.   Hi,  I’m back in the office and have heard back on this issue. Official word is that the vulnerability in question does not affect the Small Business line and that they do not run libssh. I’m not sure why the Nessus software is triggering on it, but it may be making an assumption that a Cisco device must be running IOS (incorrectly in this case), and libssh may be present on those systems. Also, to quote from https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181019-libssh: “Any product not listed in the Vulnerable Products section of this advisory is to be considered not vulnerable.” Please let me know if I can be of further help. Otherwise, I’ll move the case toward closure. ... View more