We have a vendor configured Cisco ASA 5505 running on our network to provide VPN connectivity into their networks. The ASA 5505 was purchased by us but configured by the vendor and we have no administrative access.
During a pen-test, we because aware that this device has port 500 open to the outside world on it. Running ike-scan against it, we get the following output:
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
1.2.3.4 Aggressive Mode Handshake returned
HDR=(CKY-R=e1e93d76445283e9)
SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
KeyExchange(128 bytes)
Nonce(20 bytes)
ID(Type=ID_IPV4_ADDR, Value=1.2.3.4)
Hash(20 bytes)
VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
VID=09002689dfd6b712 (XAUTH)
VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)
VID=1f07f70eaa6514d3b0fa96542a500100 (Cisco VPN Concentrator)
Ending ike-scan 1.9: 1 hosts scanned in 0.023 seconds (43.78 hosts/sec). 1 returned handshake; 0 returned notify
Running psk-crack against the handshake up to 6 chars with a A-Z, a-z, 0-9 has yielded no results. We don't have a hashcat setup to allow us to try 7, 8 or more characters realistically.
We also note that there is a resource exhaustion vulnerability for IKEv1 slots: http://cxsecurity.com/issue/WLB-2006080002
I have briefly tested this using this script:
#!/bin/bash
while true
do
ike-scan 1.2.3.4 -B 10M -q
done
And as expected, port 500 stops responding. I suspect the other end of the VPN connection would behave the same.
I see there has been these previous question similar to this, but I have some additional queries.
- I would assume that using IKEv1 in aggressive mode should be avoided as there are viable alternatives. This would mitigate the issue with PSK cracking.
- Does port 500 open like this certainly mean that the vendor has configured the ASA 5505 to accept incoming VPN connections, or could it be a side effect of the outgoing connection?
- Is there any fix to the resource exhaustion vulnerability? I presume as it is using UDP it is hard to block.
- Should the recommendation to the vendor be that we would like them to change the setup?