Rapid7 encouraged owners of its Nexpose appliances this week to apply an update to their systems to tweak how SSH is configured by default.
The company warned on Wednesday the devices were shipped with an SSH configuration that could have let some obsolete KEX, encryption and MAC algorithms be used for key exchange.
Nexpose devices are preconfigured servers, deployed in server racks, designed to help users gauge vulnerabilities, manage vulnerability data, and limit threat exposure. All physical Nexpose appliances are affected per a disclosure by Samuel Huckins, a program manager with the company, published on Wednesday.
Disclosure on CVE-2017-5243: Nexpose hardware appliance SSH enabled obsolete algorithms https://t.co/DHI7uLJ5yj (Thanks to @LiamMSomerville)
— Rapid7 (@rapid7) May 31, 2017
Liam Somerville, a researcher based in Scotland, discovered the vulnerability (CVE-2017-5243) and reported it to the company three weeks ago.
Nothing needs to be downloaded to resolve the issue, but a file does need to edited, Rapid7 said. According to Huckins, to fix the vulnerability a user with root access has to edit /etc/ssh/sshd_config in the appliance to ensure only modern ciphers, key exchange, and MAC algorithms are accepted. This should lessen the likelihood of any attacks involving authentication.
Prior to the fix, weak and out of date encryption algorithms such as AES192-CBC, Blowfish-CBC, and 3DES-CBC, and KEX algorithms such as diffie-hellman-group-exchange-sha1, could have been enabled.
“This change should not impact connections from Nexpose instances to the physical appliance. The main impact is shoring up access by SSH clients such that they cannot connect to the appliance using obsolete algorithms,” Huckins wrote.
According to Tod Beardsley, Research Director at Rapid7, the vulnerability could have let an attacker in a privileges position on the network force an algorithm downgrade between an SSH client and Nexpose during authentication.
“The privileged position is crucial to making the attack a success, since it’s a man-in-the-middle (MitM) attack — first, the attacker needs to be able to insert himself between the client and server, which usually means the attacker is on the same network as either endpoint, or has compromised an ISP along the way (in which case you have bigger problems),” Beardsley told Threatpost late Friday, “Once there, the attacker can pose as both sides of the initial SSH handshake, and rewrite the handshake to request one of these older, obsolete algorithms. Once that’s done, the attacker then records the session, and then can decrypt the session offline.”
Beardsley says that removing server-side support for the algorithms makes the aforementioned kind of attack impractical and that overall, the actual risk of exploitation is fairly low.
“These appliances don’t tend to be exposed on public networks, so attackers need to be ‘on the inside’ to begin with,” Beardsley said, “… The whole point of SSH is to be resistant to this kind of session meddling, even in the face of an attacker who’s in the right place and has the right expertise and resources to mount this sort attack. By strengthening what’s available on the server, we can help keep that promise of confidentiality.”
*This article was updated at 4:30 p.m. EST to include comments from Tod Beardsley of Rapid7.
