Cisco USC Nessus non-credentialed scans

[JEMS]

I’m currently trying to scan Cisco UCS devices using Nessus Scanner but I’m keep getting non-authenticated scans. Under the scan results I cannot find the Plugin ID 110095, shows as no data. I was able to scan these devices with authenticated scans back to February prior a Firmware update, wondering if the "key exchange algorithms" that Cisco UCS is currently using is no longer supported by the Nessus Scanner. I’m currently getting Intermittent Authentication Failure under Plugin ID 117885, It shows 4 connection timed out or was dropped during key exchange. Please if anybody have any idea will be great and highly appreciated. Thanks.

[Roger Kallberg]

As this has nothing to do with Collaboration, but is related to Data Center, I’ll help you out and move your post into that part of the community.

[Steven Tardy]

What model (PID) UCS device?
What version (firmware) is on the UCS device?

Could be UCS is old SSH and Nessus is new SSH or vice versa.
This is a semi-common scenario as SSH versions / ciphers / kex / etc change over time and older "insecure" combinations are retired.

If UCS is up to date, then that would be a Nessus problem to fix.
If UCS is old, then upgrading UCS may allow Nessus to connect.

[JEMS]

Hi, I'm using the following specs

Model: UCS-FI-6332-16UP-U

Firmware Version: 4.2.2d

I was thinking if the algorithm that the UCS devices are using are not longer compatible with Nessus, because I was able to get credentials scans back to February before we update the firmware. Please let me know what do you think about this, thanks.

[Kirk J]

I've had a couple of customers have issues with older versions of putty connecting to newer UCSM versions for the reason's Steve's already mentioned (older ciphers being retired), and resolved with newer version of putty.

As UCSM isn't created for "Nessus" functionality, I'd say it's up to Nessus to have up to date ciphers.

UCSM not responding to Nessus isn't a bad thing from UCSM security perspective ; )

Kirk...

[JEMS]

Hi there and thanks for the input.

Is there a link that contains details about the latest firmware udpate improvements? So I find the specific updated protocol and submit this as final explanation/confirmation. Thank you.

[Kirk J]

General release notes: https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/release/notes/cisco-ucs-manager-rn-4-2.html

From a wireshark capture for SSH negotiation with a UCSM running 4.22e
diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,!ssh-rsa,rsa-sha2-256,rsa-sha2-512 aes128-ctr,aes192-ctr,aes256-ctr aes128-ctr,aes192-ctr,aes256-ctrhmac-sha2-256,hmac-sha2-512,hmac-sha2-256,hmac-sha2-512,none,zlib@openssh.comnone,zlib@openssh.com

CiscoSSH 1.8.23, OpenSSH_8.0p1, CiscoSSL 1.1.1l.7.2.289-fips

Kirk...

[BSOXMAN59]

I am unable to get credentialed Nessus Security Scans with CP-8832NR VOIP Phones that support SSH and EAP as well. The Tenable and ACAS Nessus User Group response was vague, not one SME said they could get a credentialed scan. I believe this is a Linux or proprietary kernel embedded on the firmware that Tenable Nessus Professional does not support for credentialed scans. If this is the case, if a credentialed Nessus scan of the CUCM software would not produce valid results. I wish the CISCO Applications Engineers would chime in and support the users on this critical security vulnerability issue. A custom use case using CVEs appears to be the best option.

[BSOXMAN59]

I am unable to get credentialed Nessus Security Scans with CP-8832NR VOIP Phones that support SSH and EAP as well. The Tenable and ACAS Nessus User Group response was vague, not one SME said they could get a credentialed scan. I believe this is a Linux or proprietary kernel embedded on the firmware that Tenable Nessus Professional does not support for credentialed scans. If this is the case, if a credentialed Nessus scan of the CISCO Unified Call Manager (CUCM) software would not produce valid results. I wish the CISCO Applications Engineers would chime in and support the users on this critical security vulnerability issue. A custom Test case using Critical Vulnerability Exploits (CVEs) appears to be the best option.