2

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.

  1. 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.
  2. 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?
  3. Is there any fix to the resource exhaustion vulnerability? I presume as it is using UDP it is hard to block.
  4. Should the recommendation to the vendor be that we would like them to change the setup?
Cybergibbons
  • 1,191
  • 2
  • 8
  • 21
  • I think that in your 1st sentence you meant "from their network". Please correct if I guessed right. – dan Aug 02 '15 at 01:44

2 Answers2

1

Answers to your questions with their respective numbers:

  1. Yes. Prefer plain mode and IKEv2. These are defined through crypto map on your Cisco router.

  2. port 500 opened is more precisely 500/udp/IP necessary for ISAKMP (the key exchange protocol used).

  3. Yes. The opening of port 500/udp/IP has no reason to be public. It should be opened just for the allowed public IP from the allowed remote admin. Moreover the ISAKMP and esp control ACL should be closed by a closing rule:

    access-list 112 permit esp host authorized_origin_IP host router_IP
    access-list 112 permit udp host authorized_origin_IP host router_IP eq isakmp
    access-list 112 deny esp any any log
    access-list 112 deny udp any any eq isakmp log
    

    to log any attack attempt.

  4. Depending on how skilled you are in writing crypto map your advice (and official policy) could be to become the admin in charge of configuring any VPN enabling access to any of your firewalls. Because this is an access point to the most important point of securing your company network.

dan
  • 3,033
  • 14
  • 34
0

On your second question, the primary motivation to allowing IKEv1 in aggressive mode with PSK on a Cisco 5505 is to allow the traditional Cisco VPN client to establish inbound VPN connections to the device.

If this device is being used to secure IPSec VPN tunnels from your network to/from the vendor network, this is not needed (those can work in main mode).

Perhaps they use the Cisco VPN client to manage the device, but there are other options that could be used (e.g. AnyConnect) that would not require IKEv1 in aggressive mode with PSK. This gets to your first question (and 4th).

timro
  • 1
  • 1