Cisco Security Advisory: Default Credentials
(Feel free to sing along here if you know this song...)
Cisco released a Critical security advisory today that applies to the Cisco Nexus 3000 Series and 3500 Platform Switches. It seems Cisco has a blind spot in their security testing program for this type of vulnerability to be a repeat offender in different products, as our own Daniel Wesemann pointed out 8 months ago with "Cisco Default Credentials - Again!"
Summary from the Cisco page:
"The vulnerability is due to a user account that has a default and static password. This account is created at installation and cannot be changed or deleted without impacting the functionality of the system. An attacker could exploit this vulnerability by connecting to the affected system using this default account. The account can be used to authenticate remotely to the device via Telnet (or SSH on a specific release) and locally on the serial console."
Cisco has released software updates that address this vulnerability. Workarounds that address this vulnerability are available.
tony d0t carothers --gmail
Exploit o' the day: DROWN
Details about a new vulnerability related to SSL and TLS, entitled Decrypting RSA with Obsolete and Weakened eNcryption, or DROWN, have surfaced that takes advantage of a weakness in SSLv2. The most significant impact of this vulnerability to date relates to OpenSSL, which released an update today that addresses this vulnerability, and several others. The US-CERT published a notification today as well, stating "Network traffic encrypted using an RSA-based SSL certificate may be decrypted if enough SSLv2 handshake data can be collected." Microsoft IIS version 7.0 and greater is not impacted, as SSLv2 is disabled by default; unless it has been enabled as part of the deployment, which should be identified during vulnerability testing.
While secure default configurations, patches, and updates will often address the technical shortcomings in applications and libraries, it will not address architectural issues where integrations exist which rely on older encryption methods. Organizations that rely on SSLv2 for integrations may want to consider an enterprise effort to finally make the move, and eliminate the risk entirely.
Additional details
tony d0t carothers --gmail
Comments