The NSA ShadowBrokers exploit leak included a tool known as “BenignCertain” which triggers an information leak which may result in credential and private key disclosure to unauthenticated parties. Cisco IOS routers, PIX and ASA firewalls with VPN IKE IPSec enabled may be affected.
The NSA toolkit's bc-genpkt, bc-id and bc-parser binaries can be used to generate vulnerability triggering packets, send the packet and store the response, and parse the information leak to reveal VPN credentials such as username and password. Alternatively, the Metasploit Framework contains a module to scan for and trigger this vulnerability known as cisco_ike_benigncertain.
The device appears to leak RAM contents when the fault is triggered:
0000 00 00 00 00 00 00 00 02 00 00 00 00 00 00 2e e0
0010 00 00 2e e0 12 a1 fb 48 00 00 00 00 00 00 00 00
0020 00 00 09 ec 00 00 09 d0 00 00 00 01 01 00 00 0e
0030 00 00 09 c4 00 00 00 01 00 00 00 01 0b 83 d4 d4
... [ snip ] ...
0470 0f ff ff ff 0f ff ff ff 00 00 00 00 00 00 00 00
0480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0490 00 00 00 00 00 00 00 06 A1 44 93 40 00 00 00 00
When conducting subsequent tests, the memory bytes disclosed appear to change which indicates that this is likely vulnerable. Non-Cisco IPSec devices to not dump excessive bytes when responding to the vulnerability trigger (e.g. 10 bytes vs 2500+ bytes for vulnerable devices device).
However, it is important to note that the usable exploit only affects Cisco PIX devices. This device may be vulnerable but due to slightly different implementation may be leaking less valuable information to an attacker or requires tweaking using the NSA bc-genpkt tool.
Ensure the latest patched IOS firmware is installed. If the firmware is confirmed as vulnerable, the preshared VPN keys should also be changed and private keys on the device should be regenerated.
To test a HTTP/S server for weak Diffie-Hellman (DH) SSL / TLS ciphers, you may use the following command (Linux):
$ openssl s_client -connect [target]:443 -cipher "EDH"
EDH requires use of weak DH keys. If it connects, you may GET / HTTP/1.0 to confirm.
A secure host should not connect, e.g.
$ openssl s_client -connect www.gmail.com:443 -cipher "EDH"
139671352862352:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:770:
This is a quick email to bring your attention to a recently publicised OpenSSL security vulnerability known as "Heartbleed". The Common Vulnerabilities and Exposures list has assigned CVE-2014-0160 for this issue.
The vulnerability is currently being exploited in the wild on a small scale.
The vulnerability is a memory disclosure bug. That is, a malicious user can send a trigger packet to an HTTPS service with a vulnerable OpenSSL instance, and the server will respond with the raw memory contents of the HTTP server (such as Apache) or OpenSSL.
Am I vulnerable?
Only OpenSSL versions 1.0.1, 1.0.1a through to 1.0.1f are vulnerable. Version 1.0.1 was released March 2012. Version 1.0.1g was released today and is immune (many distributions have not yet released updates, but they should become available within 24 hours). Versions prior to 1.0.1, such as 1.0.0 and the 0.9.x variants do not include this specific vulnerability.
You can check what version you have by running openssl with the version switch:
# openssl version
OpenSSL 1.0.1f 6 Jan 2014 (vulnerable)
This bug is specific to OpenSSL only. Microsoft products may not be affected, however Windows products which utilise OpenSSL may be affected. Most Linux and unix variants utilise OpenSSL.
It is worth determining what risks this presents to your organisation. As the private key can be compromised and traffic decrypted, consider whether a new private key should be issued and signed by CA (once the server has been patched).
The portal requires users submit a username and password to authenticate. This communication is not encrypted.
Check the HTML source code on the form page, and examine whether the FORM ACTION is GET/POST to a HTTPS:// URI.
1) Enable SSL and disable HTTP for the portal
2) Use two-factor tokens (one time password) for strong authentication.
3) Modify the HTML source to ensure the data is POST'ed to a HTTPS URL.