|
|
At first, that subject may sound like a bunch of BS, but that's exactly what we did here. We analyzed traces left by an active fingerprinting session against our own machines in order to determine which tool the attacker was using. This isn't always possible given the number of custom scripts out there, but with some help from the author of this paper, it was pretty easy. Here are 4 of the 6 packets, followed by a discussion of the remaining two, which we don't have firewall logs for. Apr 21 20:19:08 firewall kernel: IPTABLES DROP: SRC=24.2.167.203 LEN=32 TOS=0x00 \ PREC=0x00 TTL=121 ID=27321 PROTO=ICMP TYPE=17 CODE=0 000 : B3 02 3D C4 00 00 00 00 ..=..... Apr 21 20:19:08 fire kernel: IPTABLES DROP: SRC=24.2.167.203 LEN=64 TOS=0x00 \ PREC=0x00 TTL=121 ID=27322 PROTO=ICMP TYPE=13 CODE=0 000 : A5 2F 03 00 47 F4 52 00 55 55 55 55 55 55 55 55 ./..G.R.UUUUUUUU 010 : 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU 020 : 55 55 55 55 55 55 55 55 UUUUUUUU Apr 21 20:19:08 firewall kernel: IPTABLES DROP: SRC=24.2.167.203 LEN=64 TOS=0x00 \ PREC=0x00 TTL=121 ID=27323 PROTO=ICMP TYPE=15 CODE=0 000 : A4 07 04 00 FB F4 52 00 55 55 55 55 55 55 55 55 ......R.UUUUUUUU 010 : 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 UUUUUUUUUUUUUUUU 020 : 55 55 55 55 55 55 55 55 UUUUUUUU Apr 21 20:19:08 firewall kernel: IPTABLES DROP (IN): SRC=24.2.167.203 LEN=46 \ TOS=0x00 PREC=0x00 TTL=121 ID=27325 PROTO=UDP SPT=2776 DPT=0 LEN=26 000 : 08 00 49 5C 03 00 01 00 61 62 63 64 65 66 67 68 ..I\....abcdefgh 010 : 69 6A ij From top to bottom, we have an ICMP type 17 (Address Mask Request), 13 (Timestamp Request), 15 (Information Request), and a UDP port 0 packet with content that resembles the echo request contents from a Windows ping.exe program. You can look up these types/codes and get links for descriptions at this link at IANA. The remaining two packets were a normalized echo request (ICMP type 8 code 0) and a very abnormal ICMP type 8 code 19. For the record, there is no (legitimate) use for type 8 code 19, except for recon by invoking identifiable differences in various TCP/IP stacks for the purpose of OS fingerprinting.The following analysis by the aforementioned author quickly shows how this might be done using the hping2 program, and goes on to discover the real source of this scan (GFI Languard). My best guess here would be some type of mapping or OS fingerprinting tool. The reason I say that is that NMAP uses UDP/0 for fingerprinting and it is pretty common to use invalid fields/protocols for fingerprinting. So here's my breakdown on why these would have been sent: ICMP type 17 code 0- address mask request, gain info on network and store response for fingerprinting ICMP type 13 code 0 - timestamp, get info on uptime/system time, also used for fingerprinting ICMP type 15 code 0 - information request, fingerprinting or other data gathering? UDP 0 - definitely fingerprinting - see http://seclists.org/lists/nmap-dev/2003/Jul-Sep/0024.html ICMP type 8 code 19 - fingerprinting, I bet different systems respond differently ...Interesting note on this one, I thought that I would be slick and try it out using hping2. Oddly enough I'm finding that hping2 will only let me sent legit icmp messages which sort of defeats it's purpose. The only other option is to create the ICMP header myself and use rawip which is a royal pain and too much time. Now I'm interested in whether or not different systems respond differently to odd codes under type 8. What do firewalls do if they are assuming that all type 8 will be code 0? # sudo ./hping2 -V -1 -C 9 -K 6 192.168.0.10 using eth1, addr: 192.168.0.1, MTU: 1500 HPING 192.168.0.10 (eth1 192.168.0.10): icmp mode set, 28 headers + 0 data bytes [send_icmp] Unsupported icmp type! Never mind, I'm wrong - it is sending my packets but everything in the world thinks that they're just echo requests. Here's the debug output, note that in the raw IP header it is showing ICMP type 8 code 19. Even better, when a Linux 2.6 machine responds it used type 0 code 19! [0813 specifies type 8 code 19] # sudo ./hping2 -D -1 -C 8 -K 19 192.168.0.10
DEBUG: Output interface address: 21.229.245.135
DEBUG: if lo: The address doesn't match
DEBUG: if eth1: OK
using eth1, addr: 192.168.0.1, MTU: 1500
:DEBUG: Trying to open PF_PACKET socket... DEBUG: PF_PACKET, SOCK_RAW open OK
HPING 192.168.0.10 (eth1 192.168.0.10): icmp mode set, 28 headers + 0 data
bytes
45 00 00 1C 94 83 00 00 40 01 00 00 C0 A8 00 01 C0 A8 00 0A 08 13 D5 AF 22
3D 00 00
len=46 ip=192.168.0.10 ttl=64 id=30827 icmp_seq=0 rtt=2.2 ms
08:40:16.750471 IP 192.168.0.1 > 192.168.0.10: icmp 8: echo request seq 0
4500 001c f139 0000 4001 084c c0a8 0001
c0a8 000a 0813 c1af 363d 0000
08:40:16.750698 IP 192.168.0.10 > 192.168.0.1: icmp 8: echo reply seq 0
4500 001c 786f 0000 4001 8116 c0a8 000a
c0a8 0001 0013 c9af 363d 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000
08:40:17.752953 IP 192.168.0.1 > 192.168.0.10: icmp 8: echo request seq 256
4500 001c adc5 0000 4001 4bc0 c0a8 0001
c0a8 000a 0813 c0af 363d 0100
08:40:17.753191 IP 192.168.0.10 > 192.168.0.1: icmp 8: echo reply seq 256
4500 001c 7870 0000 4001 8115 c0a8 000a
c0a8 0001 0013 c8af 363d 0100 0000 0000
0000 0000 0000 0000 0000 0000 0000
But wait! It's gets better, when I do the same thing to a wireless router I get a different response! Now I get type 0 code 0 as a response! # sudo ./hping2 -D -1 -C 8 -K 19 192.168.0.2
DEBUG: Output interface address: 60.239.255.105
DEBUG: if lo: The address doesn't match
DEBUG: if eth1: OK
using eth1, addr: 192.168.0.1, MTU: 1500
DEBUG: Trying to open PF_PACKET socket... DEBUG: PF_PACKET, SOCK_RAW open OK
HPING 192.168.0.2 (eth1 192.168.0.2): icmp mode set, 28 headers + 0 data
bytes
45 00 00 1C E9 2F 00 00 40 01 00 00 C0 A8 00 01 C0 A8 00 02 08 13 B9 AF 3E
3D 00 00
len=46 ip=192.168.0.2 ttl=60 id=12 icmp_seq=0 rtt=5.5 ms
# sudo /usr/sbin/tcpdump -x -n -i eth1 host 192.168.0.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
08:44:56.661882 IP 192.168.0.1 > 192.168.0.2: icmp 8: echo request seq 3072
4500 001c db21 0000 4001 1e6c c0a8 0001
c0a8 0002 0813 adaf 3e3d 0c00
08:44:56.662842 IP 192.168.0.2 > 192.168.0.1: icmp 8: echo reply seq 3072
4500 001c 0018 0000 3c01 fd75 c0a8 0002
c0a8 0001 0000 b5c2 3e3d 0c00 0000 0000
0000 0000 0000 0000 0000 0000 0000
08:44:57.662576 IP 192.168.0.1 > 192.168.0.2: icmp 8: echo request seq 3328
4500 001c b213 0000 4001 477a c0a8 0001
c0a8 0002 0813 acaf 3e3d 0d00
08:44:57.663510 IP 192.168.0.2 > 192.168.0.1: icmp 8: echo reply seq 3328
4500 001c 0019 0000 3c01 fd74 c0a8 0002
c0a8 0001 0000 b4c2 3e3d 0d00 0000 0000
0000 0000 0000 0000 0000 0000 0000
So, the scanner isn't crazy; it knows very well how illegitimate headers and values can invoke different responses from different systems. It likely has a database of those behaviours much like NMAP's fingerprinting database. Later, this morning the culprit was determined to be GFI Languard per the following information article on active fingerprinting: http://securitypronews.com/securitypronews-24-20030929OSFingerprintingwithICMP.html |
|