This morning Matta Consulting posted an advisory for the F5 BigIP equipment. The advisory states that certain BigIP devices contain a SSH private key on its filesystem that is trusted for remote root access on every other BigIP appliance. Although Matta did not provide the private key, they did provide the public key itself:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAvIhC5skTzxyHif/7iy3yhxuK6/OB13hjPqrskogkYFrcW8OK4VJ T 5 Fx7wd4sQCnVn8rNqahw/x6sfcOMDI/Xvn4yKU4t8TnYf2MpUVr4ndz39L5Ds1n7Si1m2suUNxWbK v58I8 NMhlt2ITraSuTU0NGymWOc8 LNi MHXdLk= SCCP Superuser
F5 has published a patch for this issue, but you can bet that many users will be unaware of the issue , and even those that are aware may not want to take down their load balancer to apply it( applying the fix does not result in any downtime as stated in the comments below ). The private key is likely still on a large number of production appliances and any attacker with the access to a virtual or physical appliance can extract the key.
A quick review of my personal research project's data shows that it identified 7701 BigIP systems of which 3409 of them have SSH open to the world. If this trend is representative (and it should be via random IP sampling), this puts the overall exposure at 43% of all F5 BigIP systems.Note that this sampling was for devices running Apache with the following string in the default page: "F5 Networks Configuration Utility" (not devices with a Server banner of BigIP, which had a much lower rate of SSH exposure).
One nifty feature within Metasploit is the ability to "half-scan" SSH servers with only the public key. This will tell us whether the server would accept authentication with that key, even if we do not possess the corresponding private key. This is a great way to ensure that a terminated employee's keys have been removed from your network and check for backdoor keys such as the one introduced accidentally by F5. We can use the public key from this advisory with the ssh_identify_pubkeys module to quickly identify any F5 equipment with this insecure key still in place. Once we get a copy of the private key, this will be used to add a full-on exploit module to Metasploit.
Metasploit Pro customers can quickly test all SSH servers identified in their current workspace. Just choose the Bruteforce component, set the Depth to "known only", select only the SSH-PUBKEY protocol, and under Advanced Options, paste the SSH public key into the Additional Credentials field. Launch the Bruteforce task and wait for it to complete. Any vulnerable systems will now have a public key credential associated with them in the Credentials tab of the host view and listed in the Authentication Tokens report.
Metasploit Framework and Pro command-line users can accomplish the same thing through the Metasploit console.
To get started, place the target SSH key into a text file on the local filesystem ("f5.pub") and launch msfconsole
msf > use auxiliary/scanner/ssh/ssh_identify_pubkeys
msf auxiliary(ssh_identify_pubkeys) > set USERNAME root
msf auxiliary(ssh_identify_pubkeys) > set KEY_FILE f5.pub
msf auxiliary(ssh_identify_pubkeys) > set RHOSTS 192.168.0.5
msf auxiliary(ssh_identify_pubkeys) > run
[*] 192.168.0.5:22 SSH - Trying 1 cleartext key per user.
[ ] 192.168.0.5:22 SSH - [1/1] - Accepted: 'root' with key '71:3a:b0:18:e2:6c:41:18:4e:56:1e:fd:d2:49:97:66' - SCCP Superuser
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
If you'd like to give this a try yourself, download Metasploit now.