Openvas cannot find ipsec service on cisco routers

Hi,

found a strange issue with our GSE 20.8.1. When I scan Cisco routers it doesn’t show IPSEC service on UDP port 500, and of cause it doesn’t find any vulnerability related to it.
In tcpdump on the openvas server I do see both request and reply:
18:06:57.032500 IP (tos 0x0, ttl 50, id 29860, offset 0, flags [none], proto UDP (17), length 220)
openvas.server.62532 > vpn.server.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 0011223344556677->0000000000000000: phase 1 I ident:
(sa: doi=ipsec situation=identity
(p: #1 protoid=isakmp transform=4
(t: #1 id=ike (type=enc value=3des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00000001))
(t: #2 id=ike (type=enc value=3des)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00000001))
(t: #3 id=ike (type=enc value=1des)(type=hash value=sha1)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00000001))
(t: #4 id=ike (type=enc value=1des)(type=hash value=md5)(type=auth value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifeduration len=4 value=00000001))))

18:06:57.073466 IP (tos 0xc0, ttl 244, id 58269, offset 0, flags [none], proto UDP (17), length 232)
vpn.server.500 > openvas.server.62532: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 0011223344556677->e2c343b0479db15e: phase 1 R inf:
(n: doi=ipsec proto=isakmp type=NO-PROPOSAL-CHOSEN data=(000000a4000000010000…01b4aeb00e494c7c000000000000001802e59c58))

After it doesn’t try anything else, not any nvt, and there is nothing about udp port 500 in the result. Could someone point in the correct direction where to check what’s a problem? Or can it be some bug in ike scan, so openvas cannot recognize the NO-PROPOSAL-CHOSEN answer as a confirmation that there is a isakmp running on the port udp/500?

I have made more tests and looks like this problem affects only IPSEC/IKE, at least it can find NTP and SNMP without any problem.

A few things to check are:

  • is your feed recent enough that it includes the VT “IKE / ISAKMP Service Detection (UDP)” (OID: 1.3.6.1.4.1.25623.1.0.117461)? -> This is a fairly new VT, there haven’t been any IKE / IPSEC detection previously
  • is the port 500/udp included in your port list used within the target configuration?
  • is the scanner (openvas binary started via ospd-openvas) running as root / correctly configured? -> https://github.com/greenbone/ospd-openvas/tree/v21.4.1#optional-configuration
  • is the service allowing connections from the scanner at all? (e.g. the device itself or some network devices in between might generally block probes of vulnerability scanners for specific services / ports)

A few additional notes:

  • The IKE / IPSEC service detection is fairly new and might not cover / support the detection of all possible different devices supporting this protocol yet. The detection coverage will increase in the next couple of months
  • In the tcpdump output i can see the 0011223344556677 cookie (Initiator SPI). The previously mentioned service detection is using a more random string so not sure where the posted probes are coming from.
1 Like

Thanks for explanations!
Yes, if I remove all filters and view at log level, I see this service in Results:
|Details:|[IKE / ISAKMP Service Detection (UDP) OID: 1.3.6.1.4.1.25623.1.0.117461]
|Version used:|2021-07-23T09:08:23Z|
I just thought that it should be listed in the application list, but nothing is there.

I captured the traffic on the openvas server, so these two packets is the only communication between the openvas server and the cisco router. What is strange, why the openvas, after it found that there is a IKE on the udp port 500, doesn’t try to run any test against VTs it has? As I can see there are at least 12 NVT just for cisco IKE, and according to logs and tcpdump, openvas sends one request during the scan, receives the answer, logs that IKE service found, but then doesn’t try to send anything to this port.

1 Like

Thanks a lot for confirming that the detection is working as expecting. Some additional notes:

Yes, this is expected. Within the application list only “real” applications like Apache web server and similar is expected to be shown. Detected services or protocols are not listed there.

This is because there is currently only the detection for the service (OID: 1.3.6.1.4.1.25623.1.0.117461) as well as one single vulnerability VT (OID: 1.3.6.1.4.1.25623.1.0.10941, only running with safe checks disabled) which are actively probing / accessing such a service available within the feeds.

All other existing VTs are working based on software versions (e.g. exposed via a remote banner or gathered via SSH login on the target device).

yes, ok, that is sad. I thought it could find before, but maybe I confused it with other scanners, because nessus and qualys are able to find IKE vulnerabilities.
Thanks for explanation!

Unfortunately there isn’t much coverage in the feed for IKE vulnerabilities which are actively checked (Reasons are unknown, could be historical).

But one for CVE-2002-1623 is currently under review, some additional ones might follow in the future.