Identifying Firewalls from the Outside-In. Or, "There's Gold in them thar UDP ports!"

Published: 2014-09-04. Last Updated: 2014-09-04 03:18:09 UTC
by Rob VandenBrink (Version: 1)

In a penetration test, often the key to bypassing a security control is as simple as knowing identifying the platform it's implemented on. In other words, it's a lot easier to get past something if you know what it is. For instance, quite often you'll be probing a set of perimeter addresses, and if there are no vulnerable hosts NAT-ed out for you, you might start feeling like you're at a dead end. Knowing what those hosts are would be really helpful right about now. So, what to do next?

Look at UDP, that's what. Quite often scanning the entire UDP range will simply burn hours or days with not a lot to show for it, but if you target your scans carefully, you can quite often get some good information in a hurry.

Scanning NTP is a great start. Way too many folks don't realize that when you make a network device (a router or switch for instance) an NTP client, quite often you also make it an NTP server as well, and NTP servers love to tell you all about themselves. All too often that port is left open because nobody knows to block it.

Another service that quite often bypasses all firewall ACLs is the corporate remote access IPSEC VPN specifically IKE/ISAKMP (udp/500). Even if this is a branch firewall with a site-to-site VPN to head office, often IKE is misconfigured to bypass the interface ACL, or the VPN to head office is enabled with a blanket "any any" permit for IKE.

Let's take a look at these two sevices - we'll let's use NMAP to dig a little deeper. First, let's scan for those ports:

nmap -Pn -sU -p123,500 --open x.x.x.x
Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-29 12:13 Eastern Daylight Time

Nmap scan report for some.fqdn.name (x.x.x.x)
Host is up (0.070s latency).
PORT STATE SERVICE
123/udp open ntp
500/udp open isakmp

Nmap done: 1 IP address (1 host up) scanned in 46.69 seconds

OK, so we found open UDP ports - how does this help us? Let's run the SECOND set of scans against these two ports, starting with expanding the NMAP scan to use the ntp-info script:

C:\ > nmap -Pn -sU -p123 --open x.x.x.x --script=ntp-info.nse

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-29 12:37 Eastern Daylight Time

Nmap done: 1 IP address (1 host up) scanned in 48.91 seconds

Oops - ntp-info not only tells more about our host, it also discloses the NTP server that it's syncing to - in this case check that host IP in red - that's an internal host. In my books, that can be rephrased as "the next target host", or maybe if not next, at least on the list "for later". Interestingly, support for ntp-info requests positions this host nicely to act as an NTP reflector/amplifier, which can then be used in DDOS spoofing attacks. The send/receive ration is just under 1:7 (54 bytes sent, 370 received), so not great, but that's still a 7x amplification which you can spoof.

Back to the pentest - ntp-info gives us some good info, it doesn't specifically tell us what OS our target host is running, so let's take a look at IKE next, with service detection enabled:

C: \> nmap -Pn -sU -p500 -sV --open x.x.x.x

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-29 13:10 Eastern Daylight Time

Nmap scan report for some.fqdn.name (x.x.x.x)
Host is up (0.010s latency).
PORT STATE SERVICE
500/udp open isakmp
Service Info: OS: IOS 12.3/12.4; CPE: cpe:/o:cisco:ios:12.3-12.4

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 159.05 seconds

Ah - very nice! Nmap correctly tells us that this device is a Cisco Router (not an ASA or any other device)

The ike-scan utility should give us some additional IKE info, let's try that with a few different options:

A basic verbose assess (main mode) gives us nothing:

C: > ike-scan -v x.x.x.x
DEBUG: pkt len=336 bytes, bandwidth=56000 bps, int=52000 us
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
x.x.x.x Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=ea1b111d68fbcc7d)

Ending ike-scan 1.9: 1 hosts scanned in 0.041 seconds (24.39 hosts/sec). 0 returned handshake; 1 returned notify

Ditto, main mode IKEv2:

C: > ike-scan -v -2 x.x.x.x
DEBUG: pkt len=296 bytes, bandwidth=56000 bps, int=46285 us
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
---     Pass 1 of 3 completed
---     Pass 2 of 3 completed
---     Pass 3 of 3 completed

Ending ike-scan 1.9: 1 hosts scanned in 2.432 seconds (0.41 hosts/sec). 0 returned handshake; 0 returned notify

with just nat-t, still nothing:

C: > ike-scan -v -nat-t x.x.x.x
DEBUG: pkt len=336 bytes, bandwidth=56000 bps, int=52000 us
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
x.x.x.x Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=ea1b111d8198ef48)

Ending ike-scan 1.9: 1 hosts scanned in 0.038 seconds (26.32 hosts/sec). 0 returned handshake; 1 returned notify

Aggressive mode however is a winner-winnner-chicken-dinner!

C: > ike-scan -v -A x.x.x.x
DEBUG: pkt len=356 bytes, bandwidth=56000 bps, int=54857 us
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
x.x.x.x Aggressive Mode Handshake returned HDR=(CKY-R=ea1b111d4f1622a2)
SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=2
8800) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=afcad71368a1f1c96b8
696fc77570100 (Dead Peer Detection v1.0) VID=1fdcb6004f1722a231f9e4f59b27b857 VI
D=09002689dfd6b712 (XAUTH) KeyExchange(128 bytes) ID(Type=ID_IPV4_ADDR, Value=x.x.x.x) Nonce(20 bytes) Hash(20 bytes)

Ending ike-scan 1.9: 1 hosts scanned in 0.068 seconds (14.71 hosts/sec). 1 returned handshake; 0 returned notify

We see from this that the remote office router (this is what this device is) is configured for aggressive mode and XAUTH - so in other words, there's likely a userid and password along with the preshared key to authenticate the tunnel. Note that ike-scan identifies this host as "Cisco unity", so while it gives us some new information, for basic device identification, in this case NMAP gave us better info.

What should you do to prevent scans like this and the exploits based on them? The ACL on your perimeter interface might currently end with a "deny tcp any any log" - consider adding on "deny udp any any log", or better yet, replace it with "deny ip any any log". Permit *exactly* what you need, deny everything else, and just as important - LOG everything that gets denied. Logging most of what is permitted also is also a good idea - if you've ever had to troubleshoot a problem or backtrack a security incident without logs, you are likely already doing this.

Adding a few honeypots into the mix is also a nice touch. Denying ICMP will often defeat scripts or cursory scans. Many network devices can be configured to detect scans and "shun" the scanning host - test this first though, you don't want to block production traffic by accident with an active control like this.

Have you found something neat in what most might otherwise consider a common and relatively "secure" protocol? Please, use our diary to share your story !

===============
Rob VandenBrink
Metafore

Keywords:

0 comment(s)

ISC StormCast for Thursday, September 4th 2014 http://isc.sans.edu/podcastdetail.html?id=4133

Internet Storm Center

Identifying Firewalls from the Outside-In. Or, "There's Gold in them thar UDP ports!"

Comments