[Dshield] Signature-based defense in '03/'04

Chris Brenton cbrenton at chrisbrenton.org
Tue Jan 6 20:37:37 GMT 2004

On Tue, 2004-01-06 at 11:56, Mrcorp wrote:
> I feel this question is a 'depends'.  There is no silver bullet in security that does everything
> and helps identify, contain, report and catch the attacker.  But when we layer security, thats
> when we get more of the big picture.  

Amen brother! One of the things that has me worried is the move to "all
in one" security products. While this makes management easier, you don't
necessarily get the same level of security as true defense in-depth.

Let me throw out an example I've started using in track 2. If you hate
reading traces or you are not an UBER bit-weenie, hit "delete" now or
skip to the executive summary. ;)

18:29:08.441969 0:50:8b:ea:20:ab 0:b0:d0:20:7d:e3 0800 78: > S 1788328046:1788328046(0) win
65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 15485003 0>
18:29:08.442049 0:b0:d0:20:7d:e3 0:50:8b:ea:20:ab 0800 78: > S 982006220:982006220(0) ack
1788328047 win 5792 <mss 1460,nop,nop,timestamp 1031147147
15485003,nop,wscale 0> (DF)
18:29:08.471310 0:50:8b:ea:20:ab 0:b0:d0:20:7d:e3 0800 70: > . ack 1 win 65535
<nop,nop,timestamp 15485003 1031147147>

OK, we are monitoring the network on the same subnet as the Web server.
Note the MAC addresses. The local router ends in 20:ab while the Web
server ends in 7d:e3. The TCP three packet handshake has just completed.

18:29:08.472756 0:50:8b:ea:20:ab 0:b0:d0:20:7d:e3 0800 291: > P 1:222(221) ack 1 win 65535
<nop,nop,timestamp 15485003 1031147147>
0x0000   4500 0111 2a96 0000 3106 cfd2 944e f70a        E...*...1....N..
0x0010   0c21 f704 692a 0050 6a97 b86f 3a88 39cd        .!..i*.Pj..o:.9.
0x0020   8018 ffff 42fc 0000 0101 080a 00ec 484b        ....B.........HK
0x0030   3d76 0e8b 4745 5420 2f63 6669 6465 2f41        =v..GET./cfide/A
0x0040   646d 696e 6973 7472 6174 6f72 2f73 7461        dministrator/sta
0x0050   7274 7374 6f70 2e68 746d 6c20 4854 5450        rtstop.html.HTTP
0x0060   2f31 2e30 0d0a 486f 7374 3a20 3132 2e33        /1.0..Host:.12.3
0x0070   332e 3234 372e 340d 0a55 7365 722d 4167        3.247.4..User-Ag
0x0080   656e 743a 204d 6f7a 696c 6c61 2f35 2e30        ent:.Mozilla/5.0
0x0090   205b 656e 5d20 2857 696e 3935 3b20 5529        .[en].(Win95;.U)
0x00a0   0d0a 5265 6665 7265 723a 2068 7474 703a        ..Referer:.http:
0x00b0   2f2f 3132 2e33 332e 3234 372e 342f 0d0a        //
0x00c0   582d 466f 7277 6172 6465 642d 466f 723a        X-Forwarded-For:
0x00d0   2031 3438 2e36 342e 3134 372e 3136 380d        .
0x00e0   0a43 6163 6865 2d43 6f6e 7472 6f6c 3a20        .Cache-Control:.
0x00f0   6d61 782d 7374 616c 653d 300d 0a50 7261        max-stale=0..Pra
0x0100   676d 613a 206e 6f2d 6361 6368 650d 0a0d        gma:.no-cache...
0x0110   0ace f843 76                                   ...Cv

Here is a full decode of the next packet. Humm. That URL looks pretty
suspicious, eh? This is a well known Cold Fusion exploit. So we
obviously have someone on the Internet looking for our weak spots.

18:29:08.473288 0:50:ba:8f:e0:c 0:50:8b:ea:20:ab 0800 54:
> R 1:1(0) ack 222 win 0
18:29:08.473354 0:50:ba:8f:e0:c 0:b0:d0:20:7d:e3 0800 54: > R 1:1(0) ack 222 win 0

Note what happens next. We see a RST/ACK going to both ends of the
connection to tear down the session. What's very interesting is the
source MAC is the same on both packets, even though the first packet
claims to be the Web server while the second claims to be our nasty host
out on the Internet. Hummm....

So what happened? We obviously have a local IDS or IPS at the MAC
address 0:50:ba:8f:e0:c setup to kick out RST packets when an attack
signature is identified. So the IDS/IPS is doing its job and trying to
kill this session. Let's see what happens next:

18:29:08.473579 0:b0:d0:20:7d:e3 0:50:8b:ea:20:ab 0800 441: > P 1:372(371) ack 222 win 6432
<nop,nop,timestamp 1031147150 15485003> (DF)
18:29:08.473633 0:b0:d0:20:7d:e3 0:50:8b:ea:20:ab 0800 70: > F 372:372(0) ack 222 win 6432
<nop,nop,timestamp 1031147150 15485003> (DF)
18:29:08.693807 0:b0:d0:20:7d:e3 0:50:8b:ea:20:ab 0800 441: > FP 1:372(371) ack 222 win 6432
<nop,nop,timestamp 1031147173 15485003> (DF)
18:29:09.153794 0:b0:d0:20:7d:e3 0:50:8b:ea:20:ab 0800 441: > FP 1:372(371) ack 222 win 6432
<nop,nop,timestamp 1031147219 15485003> (DF)
18:29:10.073781 0:b0:d0:20:7d:e3 0:50:8b:ea:20:ab 0800 441: > FP 1:372(371) ack 222 win 6432
<nop,nop,timestamp 1031147311 15485003> (DF)

Hey wait a minute, we kicked out a RST but our internal host seems to be
ignoring it. Let's take a look at one of the decodes:

18:29:08.473579 0:b0:d0:20:7d:e3 0:50:8b:ea:20:ab 0800 441: > P 1:372(371) ack 222 win 6432
<nop,nop,timestamp 1031147150 15485003> (DF)
0x0000   4500 01a7 3744 4000 4006 738e 0c21 f704        E...7D at .@.s..!..
0x0010   944e f70a 0050 692a 3a88 39cd 6a97 b94c        .N...Pi*:.9.j..L
0x0020   8018 1920 8d1a 0000 0101 080a 3d76 0e8e        ............=v..
0x0030   00ec 484b 4854 5450 2f31 2e31 2034 3034        ..HKHTTP/1.1.404
0x0040   204e 6f74 2046 6f75 6e64 0d0a 4461 7465        .Not.Found..Date
0x0050   3a20 5475 652c 2032 3520 4a75 6e20 3230        :.Tue,.25.Jun.20
0x0060   3032 2030 303a 3334 3a35 3820 474d 540d        02.00:34:58.GMT.
0x0070   0a53 6572 7665 723a 2041 7061 6368 650d        .Server:.Apache.
0x0080   0a43 6f6e 6e65 6374 696f 6e3a 2063 6c6f        .Connection:.clo
0x0090   7365 0d0a 436f 6e74 656e 742d 5479 7065        se..Content-Type
0x00a0   3a20 7465 7874 2f68 746d 6c3b 2063 6861        :.text/html;.cha
0x00b0   7273 6574 3d69 736f 2d38 3835 392d 310d        rset=iso-8859-1.
0x00c0   0a0d 0a3c 2144 4f43 5459 5045 2048 544d        ...<!DOCTYPE.HTM
0x00d0   4c20 5055 424c 4943 2022 2d2f 2f49 4554        L.PUBLIC."-//IET
0x00e0   462f 2f44 5444 2048 544d 4c20 322e 302f        F//DTD.HTML.2.0/
0x00f0   2f45 4e22 3e0a 3c48 544d 4c3e 3c48 4541        /EN">.<HTML><HEA
0x0100   443e 0a3c 5449 544c 453e 3430 3420 4e6f        D>.<TITLE>404.No
0x0110   7420 466f 756e 643c 2f54 4954 4c45 3e0a        t.Found</TITLE>.
0x0120   3c2f 4845 4144 3e3c 424f 4459 3e0a 3c48        </HEAD><BODY>.<H
0x0130   313e 4e6f 7420 466f 756e 643c 2f48 313e        1>Not.Found</H1>
0x0140   0a54 6865 2072 6571 7565 7374 6564 2055        .The.requested.U
0x0150   524c 202f 6366 6964 652f 4164 6d69 6e69        RL./cfide/Admini
0x0160   7374 7261 746f 722f 7374 6172 7473 746f        strator/startsto
0x0170   702e 6874 6d6c 2077 6173 206e 6f74 2066        p.html.was.not.f
0x0180   6f75 6e64 206f 6e20 7468 6973 2073 6572        ound.on.this.ser
0x0190   7665 722e 3c50 3e0a 3c2f 424f 4459 3e3c        ver.<P>.</BODY><
0x01a0   2f48 544d 4c3e 0a00 0300 07                    /HTML>.....

So even though our IDS/IPS identified the packet as evil and tried to
kill the session, our Web server just keeps plugging along, ignored the
RST, and puked its guts. Why you may ask? Look at the sequence #'s in
the RST packets. They are close, but incorrect. In other words, our
IDS/IPS is kicking out RST packets like we told it to, but its not
getting the sequence numbers right so the RSTs are being ignored.
Obviously this is a bug in the code.

Well that begs the question, why did the attacking host honor the RST
when the internal host did not? My guess is it didn't. The sequence
numbers are wrong, so the attacking host should have ignored the RST as
well. We don't see any more packets from the attacking host however, so
something must have happened.

The answer lies in the firewall. A stateful firewall is designed to
remove the state entry when the session ends. In other words, it watches
for FIN/ACK exchanges or RST packets and when it sees them, the state
entry gets purged.

So what happened exactly? There is a stateful firewall protecting either
our network and/or the attacker's network. When the firewall saw the
outgoing RST it said "okely dokely, the Web server just reset the
session so I'll just remove that state table entry.". This dropped the
ability of the two systems to continue that session. You could probably
consider this a bug in the firewall code as well because what's
happening is the firewall is monitoring the flag settings but not the
sequence numbers (like a true end host). 

So the firewall was fooled by these RST packets, but the end hosts were
not. This was a "good thing (TM)" however because it blocked our Web
server from reporting the status of the attack attempt. Note that if the
firewall had been Firewall-1, the attack would have continued because
FW-1 allows ACKs to recreate state entries. So when our firewall
reported the status of the attack, FW-1 would have gladly passed the
traffic. :(

Sooooo, the limitations of the two devices combined together to create a
more secure posture. Had this been an "all in one" device that had the
firewall and IDS/IPS combined on the same box, chances are this attack
would have blown right through.

So I absolutely agree, defense in-depth is the way to go. Its proved its
value to me many times over. :)


More information about the list mailing list