In my last post we had determined that the trace file contained a session where a single honed network based intrusion prevention system had attempted to stop an attack from an HTTP client to a Web server. We concluded that the client’s data request did look rather suspicious, and proved a third party system (the NIPS) was responsible for the reset packets transmitted during the session.
In this post we still need to answer two questions:
- Was the attack successful?
- Why did the Web server ignore the TCP reset packet transmitted by the NIPS?
Was the attack successful?
The attacker was looking to identify if the file “startstop.html” was located in the “Administrator” directory. Let’s take a look at one of the packets sent to the attacker after the reset packets were transmitted:
tshark -n -r challenge1.cap -x frame.number==11
11 0.711825 12.33.247.4 -> 148.78.247.10 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]
0000 00 50 8b ea 20 ab 00 b0 d0 20 7d e3 08 00 45 00 .P.. …. }…E.
0010 01 a7 37 47 40 00 40 06 73 8b 0c 21 f7 04 94 4e ..7G@.@.s..!…N
0020 f7 0a 00 50 69 2a 3a 88 39 cd 6a 97 b9 4c 80 19 …Pi*:.9.j..L..
0030 19 20 8c d4 00 00 01 01 08 0a 3d 76 0e d3 00 ec . ……..=v….
0040 48 4b 48 54 54 50 2f 31 2e 31 20 34 30 34 20 4e HKHTTP/1.1 404 N
0050 6f 74 20 46 6f 75 6e 64 0d 0a 44 61 74 65 3a 20 ot Found..Date:
0060 54 75 65 2c 20 32 35 20 4a 75 6e 20 32 30 30 32 Tue, 25 Jun 2002
0070 20 30 30 3a 33 34 3a 35 38 20 47 4d 54 0d 0a 53 00:34:58 GMT..S
0080 65 72 76 65 72 3a 20 41 70 61 63 68 65 0d 0a 43 erver: Apache..C
0090 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f 73 65 onnection: close
00a0 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 ..Content-Type:
00b0 74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 61 72 73 text/html; chars
00c0 65 74 3d 69 73 6f 2d 38 38 35 39 2d 31 0d 0a 0d et=iso-8859-1…
00d0 0a 3c 21 44 4f 43 54 59 50 45 20 48 54 4d 4c 20 .<!DOCTYPE HTML
00e0 50 55 42 4c 49 43 20 22 2d 2f 2f 49 45 54 46 2f PUBLIC “-//IETF/
00f0 2f 44 54 44 20 48 54 4d 4c 20 32 2e 30 2f 2f 45 /DTD HTML 2.0//E
0100 4e 22 3e 0a 3c 48 54 4d 4c 3e 3c 48 45 41 44 3e N”>.<HTML><HEAD>
0110 0a 3c 54 49 54 4c 45 3e 34 30 34 20 4e 6f 74 20 .<TITLE>404 Not
0120 46 6f 75 6e 64 3c 2f 54 49 54 4c 45 3e 0a 3c 2f Found</TITLE>.</
0130 48 45 41 44 3e 3c 42 4f 44 59 3e 0a 3c 48 31 3e HEAD><BODY>.<H1>
0140 4e 6f 74 20 46 6f 75 6e 64 3c 2f 48 31 3e 0a 54 Not Found</H1>.T
0150 68 65 20 72 65 71 75 65 73 74 65 64 20 55 52 4c he requested URL
0160 20 2f 63 66 69 64 65 2f 41 64 6d 69 6e 69 73 74 /cfide/Administ
0170 72 61 74 6f 72 2f 73 74 61 72 74 73 74 6f 70 2e rator/startstop.
0180 68 74 6d 6c 20 77 61 73 20 6e 6f 74 20 66 6f 75 html was not fou
0190 6e 64 20 6f 6e 20 74 68 69 73 20 73 65 72 76 65 nd on this serve
01a0 72 2e 3c 50 3e 0a 3c 2f 42 4f 44 59 3e 3c 2f 48 r.<P>.</BODY></H
01b0 54 4d 4c 3e 0a 00 03 00 07 TML>…..
So the answer to the attacker’s question; “Is the file located on the server?, is answered in every packet the server set to the client after the reset packets were issued. Now the question becomes, did the attacker see this information?
When the reset packet was sent to the attacker, the reset should have killed the TCP session. This means that when this data arrived, the receiving port (TCP/26922) should have been in a closed state. Had this in fact been true, I would expect to see a reset/ACK coming back from the attacker’s system telling us that TCP/26922 is now closed. We never see those packets.
So why didn’t the remote port close? The reset packet is valid, so it should have killed the session. A savvy attacker is going to run a packet sniffer in the background while performing their attack. It is possible that the attacker would have figured out what was going on and simply created a firewall rule on their attack system filtering out all inbound reset packets. This would have permitted their tool to continue functioning. Even without the firewall filter their packet sniffer would contain the answers they seek. So there is a very good chance the attacker has figured out what we are vulnerable to, despite the fact a NIPS is protecting the network.
Why did the Web server ignore the reset packet?
Our final question is why did the Web server ignore the reset packet sent by the NIPS. This is causing two problems:
- The info the attacker wanted is continuing to leak out
- If the attacker does multiple file probes, they could fill up the session table on the Web server
The second item is kind of scary because it would actually be the NIPS causing the DoS attack by only killing one side of the connection properly. So even if we were patched and up to date, vendor gear we paid money for would end up killing our Web server. Gee I hate it when I spend money to DoS myself. 
Let’s take another look at those reset packets:
tshark -n -r challenge1.cap frame.number==6 or frame.number==7
6 0.031319 12.33.247.4 -> 148.78.247.10 TCP 80 > 26922 [RST, ACK] Seq=1 Ack=222 Win=0 Len=0
7 0.031385 148.78.247.10 -> 12.33.247.4 TCP [TCP ACKed lost segment] 26922 > 80 [RST, ACK] Seq=1 Ack=222 Win=0 Len=0
Notice that tshark is telling us packet 7 is a lost segment. In other words, tshark is telling us that the TCP sequence number is not within the window the host is expecting. A look at the sequence and acknowledge numbers explains why. The values are identical to the ones in packet 6. You may remember from the last post that packet 6 and 7 also had the same IP ID value (45298).
So it appears that here is what happened:
- Client sent an HTTP attack to our Web server
- NIPS detected the attack
- NIPS sent a valid TCP reset to the attacker to kill the session
- NIPS swapped the source and destination IP addresses in the packet, recalculated the CRCs, and then sent the same reset to the Web server
- Web server ignores the reset because it does not contain an acceptable sequence number
You may be asking yourself, “How did the vendor miss this?”. My best guess is that the vendor ran some simulated attacks; the attack tool did not show them vulnerable files, so they assumed everything was working OK. In other words, a vendor who created a product to protect networks on the wire never bothered to look at what their product was actually doing on the wire. Hummm…
Bonus question
OK, if you are having fun with this one, here’s a bonus question to answer that will definitively prove your uber-geek status upon the top of the secret pyramid:
Assume we place a stateful inspection firewall between this subnet and the attacker. Will the attacker still be able to see the answers with a packet sniffer?
I’ll post the answer next week.
Related posts:
