[Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect KevinCryan
riptide at digitaltorque.com
riptide at digitaltorque.com
Tue Jun 29 09:25:52 GMT 2004
I think you did well in portraying the intent of this snort detect.
There is one statement, however, that I think should be corrected if you
will be dedicating part 1 of your paper towards buffer overflows. You say
that, "A buffer overflow is an attempt of the attacker to overflow
the stack allowing them to overwrite the instruction pointer."
That statement is mostly true, however there are buffer overflow attacks
that do not involve the stack like heap attacks. I know it's kind of a
minor detail to point out, but you are dedicating the first part of your
paper towards buffer overflows.
I really liked the detail you got into explaining the string of C's and
why they are used.
Say hi to the SOC for me
- Marcus Wu
> Detect #1 Buffer Overflow
>
> [**] [1:1390:4] SHELLCODE x86 inc ebx NOOP [**]
> [Classification: Executable code was detected] [Priority: 1]
> 10/02/02-05:13:47.256507 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800
> len:0x5EA
> 81.19.69.18:8000 -> 115.74.249.65:63742 TCP TTL:46 TOS:0x0 ID:15191
> IpLen:20
> DgmLen:1500 DF ***A**** Seq: 0x6812E8FB Ack: 0x97C707F Win: 0xFFFF
> TcpLen:
> 20
>
> 05:13:47.256507 00:03:e3:d9:26:c0 > 00:00:0c:04:b2:33, ethertype IPv4
> (0x0800), length 1514: IP (tos 0x0, ttl 46, id 15191, offset 0, flags
> [DF],
> length: 1500, bad cksum 98a6 (->914)!) 81.19.69.18.8000 >
> 115.74.249.65.63742: . [bad tcp cksum 40b (->7478)!] 1746069755:1746071215
> (1460) ack 159150207 win 65535
> 0x0000: 0000 0c04 b233 0003 e3d9 26c0 0800 4500 .....3....&...E.
> 0x0010: 05dc 3b57 4000 2e06 98a6 5113 4512 734a ..;W at .....Q.E.sJ
> 0x0020: f941 1f40 f8fe 6812 e8fb 097c 707f 5010 .A. at ..h....|p.P.
> 0x0030: ffff 040b 0000 4854 5450 2f31 2e31 2032 ......HTTP/1.1.2
> 0x0040: 3030 204f 4b0d 0a53 6572 7665 723a 2074 00.OK..Server:.t
> 0x0050: 6874 7470 642f 322e 3232 6265 7461 3420 httpd/2.22beta4.
> 0x0060: 3134 6e6f 7632 3030 310d 0a43 6f6e 7465 14nov2001..Conte
> 0x0070: 6e74 2d54 7970 653a 2069 6d61 6765 2f6a nt-Type:.image/j
> 0x0080: 7065 670d 0a44 6174 653a 2057 6564 2c20 peg..Date:.Wed,.
> 0x0090: 3032 204f 6374 2032 3030 3220 3134 3a31 02.Oct.2002.14:1
> 0x00a0: 323a 3434 2047 4d54 0d0a 4c61 7374 2d4d 2:44.GMT..Last-M
> 0x00b0: 6f64 6966 6965 643a 2057 6564 2c20 3032 odified:.Wed,.02
> 0x00c0: 204f 6374 2032 3030 3220 3132 3a35 323a .Oct.2002.12:52:
> 0x00d0: 3132 2047 4d54 0d0a 4163 6365 7074 2d52 12.GMT..Accept-R
> 0x00e0: 616e 6765 733a 2062 7974 6573 0d0a 436f anges:.bytes..Co
> 0x00f0: 6e6e 6563 7469 6f6e 3a20 636c 6f73 650d nnection:.close.
> 0x0100: 0a43 6f6e 7465 6e74 2d4c 656e 6774 683a .Content-Length:
> 0x0110: 2033 3635 390d 0a0d 0aff d8ff e000 104a .3659..........J
> 0x0120: 4649 4600 0102 0000 6400 6400 00ff ec00 FIF.....d.d.....
> 0x0130: 1144 7563 6b79 0001 0004 0000 000d 0000 .Ducky..........
> 0x0140: ffee 000e 4164 6f62 6500 64c0 0000 0001 ....Adobe.d.....
> 0x0150: ffdb 0084 0013 1010 1811 1826 1717 2630 ...........&..&0
> 0x0160: 251e 2530 2c25 2424 252c 3b33 3333 3333 %.%0,%$$%,;33333
> 0x0170: 3b43 3e3e 3e3e 3e3e 4343 4343 4343 4343 ;C>>>>>>CCCCCCCC
> 0x0180: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC
> 0x0190: 4343 4343 4301 1418 181f 1b1f 2518 1825 CCCCC.......%..%
> 0x01a0: 3425 1f25 3443 3429 2934 4343 4340 3340 4%.%4C4))4CCC at 3@
> 0x01b0: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC
> 0x01c0: 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC
> 0x01d0: 4343 4343 4343 ffc0 0011 0800 7100 9603 CCCCCC......q...
> 0x01e0: 0122 0002 1101 0311 01ff c400 8100 0002 ."..............
> 0x01f0: 0301 0100 0000 0000 0000 0000 0000 0304 ................
> 0x0200: 0002 0506 0101 0101 0101 0000 0000 0000 ................
> 0x0210: 0000 0000 0000 0001 0203 1000 0201 0204 ................
> 0x0220: 0404 0308 0105 0100 0000 0001 0203 0011 ................
> 0x0230: 2131 1204 4151 2213 6171 8105 f091 32a1 !1..AQ".aq....2.
> 0x0240: b1c1 d1e1 4223 14f1 5262 7282 3406 1101 ....B#..Rbr.4...
> 0x0250: 0101 0002 0202 0301 0000 0000 0000 0000 ................
> 0x0260: 0111 2131 4102 7112 5161 8132 ffda 000c ..!1A.q.Qa.2....
> 0x0270: 0301 0002 1103 1100 3f00 5a38 8a3a d80c ........?.Z8.:..
> 0x0280: 7a6c 29bd cbbb 1312 0373 c478 5495 7b56 zl)......s.xT.{V
> 0x0290: 9546 ad0d ab4d f3a2 c538 9256 9864 149f .F...M...8.V.d..
> 0x02a0: b2b7 a16e e4d2 2ff2 6a2c a797 ce94 070a ...n../.j,......
> 0x02b0: e8e1 7d1b 6d64 e4a5 ab96 3290 350e 14f5 ..}.md....2.5...
> 0x02c0: a95b 536a 5855 56e4 d85c 0ce9 5d0b dad6 .[SjXUV..\..]...
> 0x02d0: 52c4 1373 cbd6 82d3 34c1 5d8e 9238 f0ff R..s....4.]..8..
> 0x02e0: 0015 58e6 8e67 b30d 372b a9b5 619e 745e ..X..g..7+..a.t^
> 0x02f0: 9a32 ee54 a042 0dfa 7d3c 6981 b331 22cc .2.T.B..}<i..1".
> 0x0300: 86e5 5012 a71c 0d02 65d9 dd9e 376b 0c4e ..P.....e...7k.N
> 0x0310: 1a81 a4ff 00b8 a540 5723 2055 b1cb 222a ....... at W#.U.."*
> 0x0320: 0bc4 345e ee49 37f5 abc7 2870 6100 0245 ..4^.I7...(pa..E
> 0x0330: fcad ca82 1ed1 ea5f a810 07e3 5604 0965 ......._....V..e
> 0x0340: 6385 9748 3e27 3a41 7740 4a95 7be0 085c c..H>':Aw at J.{..\
> 0x0350: b1e5 4f6d 2566 903c 9900 48bb 5ce5 9521 ..Om%f.<..H.\..!
> 0x0360: 1632 292d 6d20 e92b 8dcf 0a11 33ee 4858 .2)-m..+....3.HX
> 0x0370: b162 48c3 0cb3 aa83 fbb4 ecec 740b 01f5 .bH.........t...
> 0x0380: f9d0 7612 1ee2 e9c0 a2d5 6352 1fab 2170 ..v.......cR..!p
> 0x0390: 7d2b c8ad 16a9 0305 232f 955b d610 5954 }+......#/.[..YT
> 0x03a0: 070e 0dd8 dbd2 9adc 4520 7218 0639 b1ce ........E.r..9..
> 0x03b0: 8321 450b 230f f1c2 9f1b a994 3901 1f50 .!E.#.......9..P
> 0x03c0: cc36 02a5 567a 3da5 096e 9392 e77a 74ef .6..Vz=..n...zt.
> 0x03d0: 2dd0 882e 4677 c796 5493 c2aa 8252 0991 -...Fw..T....R..
> 0x03e0: 71c0 e1e5 4fed 7666 78c3 a901 88fa 5b1a q...O.vfx.....[.
> 0x03f0: 0ccf ec3f 72e2 fab3 387c 6152 bdfe bb89 ...?r...8|aR....
> 0x0400: fb76 1727 4fd5 f187 db52 ae83 4f27 6d2f .v.'O....R..O'm/
> 0x0410: a829 e171 9fe5 4b6d 6526 4607 0233 af3d .).q..Kme&F..3.=
> 0x0420: c248 d56c ea5b 0b80 39d2 7b78 a52a 655c .H.l.[..9.{x.*e\
> 0x0430: 3e39 5651 d16d 9c3e dd8c a706 363c 30ca >9VQ.m.>....6<0.
> 0x0440: b9e9 82ac 8c88 4940 6e47 3aa2 c4f2 0235 ......I at nG:....5
> 0x0450: 6232 04d6 8ff5 b6e0 0d65 8361 90b8 3e42 b2.......e.a..>B
> 0x0460: a43b 211c 52ee 17a0 82a2 993e d92b 2836 .;!.R......>.+(6
> 0x0470: 0a99 6ae6 d534 cdb4 7ee2 1d21 8627 9d5d ..j..4..~..!.'.]
> 0x0480: b7ed 276a 1761 dabf 52df 8df8 fdf4 3e54 ..'j.a..R.....>T
> 0x0490: dab2 edf5 472e 2a7a 4db1 fba9 9fea 48ec ....G.*zM.....H.
> 0x04a0: 0226 956c 8b8b 03e5 8d56 6486 2955 a190 .&.l.....Vd.)U..
> 0x04b0: 0238 5b57 a9ab bc52 680c b282 45c8 4c6d .8[W...Rh...E.Lm
> 0x04c0: 8e7e 428b 0b76 d902 2b70 3a8d a9d6 4925 .~B..v..+p:...I%
> 0x04d0: 5378 d800 3571 cb9e 148a 42e6 540d a187 Sx..5q....B.T...
> 0x04e0: 0231 1879 7d94 7fef 4961 1a36 82a4 e189 .1.y}...Ia.6....
> 0x04f0: f4e3 6a28 db59 5480 01b2 adc9 f0c6 8cd2 ..j(.YT.........
> 0x0500: ff00 5255 dcb0 06c1 8691 9f56 46b3 4ab4 ..RU.......VF.J.
> 0x0510: 8e5a f627 16e9 cff3 af77 7b79 237e e269 .Z.'.....w{y#~.i
> 0x0520: 6be3 d38e 1ebf 755d 6466 8429 d414 88d8 k.....u]df.)....
> 0x0530: 62da 8f1f 3aa4 b017 8068 c4bb 0b5c f019 b...:....h...\..
> 0x0540: 5449 e791 bb0d 2295 3d1a 72a1 ac92 c326 TI....".=.r....&
> 0x0550: 8070 5370 1b1b 7d94 04f7 1578 ed18 cd05 .pSp..}....x....
> 0x0560: dbca 92da 49a9 ec49 d371 f2ad 9f71 8e68 ....I..I.q...q.h
> 0x0570: d7bc f6d4 b6bb 0c7e ae06 f597 b68b bae4 .......~........
> 0x0580: c802 822e 34f1 f415 654b 1ab3 a48e 2375 ....4...eK....#u
> 0x0590: b76c 0b9f 524e 1f65 7bb4 dcff 005d bb87 .l..RN.e{....]..
> 0x05a0: 0045 d8e7 85f0 1f65 e971 ba33 a955 3a56 .E.....e.q.3.U:V
> 0x05b0: da15 73e1 ceaa ece0 31d3 d2ab 6b92 0655 ..s.....1...k..U
> 0x05c0: 1a50 cc9a c1d4 6f7b eaf0 cf2c ea50 3fb0 .P....o{...,.P?.
> 0x05d0: a21b 802e 4dcf f9a9 5a43 92c8 11b0 17f2 ....M...ZC......
> 0x05e0: a00d ff00 6d4a b22a 927c ....mJ.*.|
>
>
>
> 1. Source of Trace
>
> http://www.incidents.org/logs/Raw/2002.9.2
>
> The packets in this file have dates of 2002.10.1 20:02 through 2002.10.2
> 19:59.
>
> Search for source mac addresses
> tcpdump -ner 2002.9.2 | awk ‘{print $2}’ | sort -u
> 0:0:c:4:b2:33 CISCO
> 0:3:e3:d9:26:c0 CISCO
>
> Search for destination mac addresses
> tcpdump -ner 2002.9.2 | awk ‘{print $4}’ | sort -u
> 0:0:c0:6b:e9:c6 Western Digital Corporation. Only 1 packet #13241
> 0:0:c:4:b2:33 CISCO
> 0:3:e3:d9:26:c0 CISCO
>
> http://standards.ieee.org/regauth/oui/index.shtml
>
> The devices
> 0:0:c:4:b2:33
> 0:3:e3:d9:26:c0
>
> Source addresses using 0:0:c:4:b2:33
> tcpdump -ner 2002.9.2 ether src 0:0:c:4:b2:33 | awk ‘{print $11}’ |
> awk -F \.
> ‘{print $1 “.†$2 “.†$3 “.†$4}’ | sort -u
> 115.74.249.202
> 115.74.249.65
>
> Destination addresses using 0:0:c:4:b2:33 tcpdump -ner 2002.9.2 ether src
> 0:0:c:4:b2:33 | awk ‘{print $13}’ | awk -F \. ‘{print $1 “.†$2
> “.†$3 “.â€
> $4}’ | sort -u
> 147.208.133.112
> 149.174.32.3
> 152.163.209.25
> 194.67.23.251
> 194.67.35.196
> 194.8.167.244
> 195.209.49.242
> 199.45.45.132
> 202.39.225.96
> -snip-
> 66.163.171.143
> 66.250.30.219
> 66.35.229.104
> 81.19.66.111
>
> Source IP’s with 0:3:e3:d9:26:c0
> tcpdump -ner 2002.9.2 ether src 0:3:e3:d9:26:c0 | awk ‘{print $11}’ |
> awk -F
> \. ‘{print $1 “.†$2 “.†$3 “.†$4}’ | sort -u
> 12.235.32.237
> 12.40.107.250
> 136.1.240.145
> 138.81.11.6
> 142.161.254.208
> 143.182.124.3
> 147.178.2.110
> 148.63.97.250
> 151.202.83.164
> 158.116.125.10
> 161.24.47.98
> 163.19.248.253
> 164.109.153.225
> 164.109.27.193
> 192.18.19.107
> 198.170.170.173
> 198.65.246.41
> 200.249.46.195
> 200.67.226.113
> 200.69.218.121
> 202.145.73.165
> 202.7.209.125
> -snip-
> 80.67.66.7
> 81.19.69.18
>
> Destination IP’s with 0:3:e3:d9:26:c0
> tcpdump -ner 2002.9.2 ether src 0:3:e3:d9:26:c0 | awk ‘{print $13}’ |
> awk -F
> \. ‘{print $1 “.†$2 “.†$3 “.†$4}’ | sort -u
> 115.74.0.0/16
>
> Network Diagram
>
> Internal Network <-----------> Cisco - IDS - Cisco<------------> External
> Network 115.74.0.0/16 0:0:c:4:b2:33 0:3:e3:d9:26:c0
>
>
>
> 0:3:e3:d9:26:c0 is letting in the following ports
> tcpdump -ner 2002.9.2 ether src 0:3:e3:d9:26:c0 | awk ‘{print $13}’ |
> awk -F
> \. ‘{print $5}’ | sort -u 139:
> 21
> 515
> 53
> 6192
> 61266
> -snip-
> 64889
> 64995
> 8080
> 80
> 8452
>
> The outside interface seems to be letting pretty much everything in. This
> interface is probably owned by the customers ISP and therefore would not
> block any ports.
>
> 0:0:c:4:b2:33 is letting out the following ports
> tcpdump -ner 2002.9.2 ether src 0:0:c:4:b2:33 | awk ‘{print $13}’ |
> awk -F \.
> ‘{print $5}’ | sort -u 1066:
> 1071
> 1500
> 1506
> 1536
> 1697
> 1863
> 80
>
>
> Web Server
> tcpdump -ner 2002.9.2 src net 115.74.0.0/16 and src port 80 | awk
> ‘{print
> $11}’ | awk -F \. ‘{print $1 “.†$2 “.†$3 “.†$4}’ |
> sort -u
> 115.74.249.202
>
> 2. Detect was generated by
>
> The packets in the dump were produced by snort that was setup to log
> binary
> dumps of packets that caused alerts. It is unknown what ruleset was used.
> You
> probably noticed that the packet has a bad checksum error. This is due to
> the
> IP addresses being obfuscated. Also, the Dmglen is 1500 in the detect but
> 1514 in the tcpdump output because tcpdump includes the ethernet layer
> which
> is 14 bytes.
>
> snort -c /etc/snort/snort.conf -l ./logs -r ./2002.9.2 -k none -dyev >
> snort.txt
> -c config-file
> Use the rules located in file config-file.
> -l log-dir
> Set the output logging directory to log-dir. All plain text
> alerts and packet logs go into this
> directory. If this option is not specified, the
> default
> logging directory is set to
> /var/log/snort.
> -r tcpdump-file
> Read the tcpdump-formatted file tcpdump-file. This will
> cause
> Snort to read and process the file
> fed to it. This is useful if, for instance, you've got a
> bunch
> of SHADOW files that you want to
> process for content, or even if you've got a bunch of
> reassembled packet fragments which have
> been written into a tcpdump formatted file.
> -k checksum-mode
> Tune the internal checksum verification functionality with
> alert-mode. Valid checksum modes
> include all, noip, notcp, noudp, noicmp, and none. All
> activates checksum verification for all
> supported protocols. Noip turns off IP checksum
> verification,
> which is handy if the gateway
> router is already dropping packets that fail their IP
> checksum checks. Notcp turns off TCP
> checksum verification, all other checksum modes are on.
> noudp
> turns off UDP checksum verifica-
> tion. Noicmp turns off ICMP checksum verification. None
> turns
> off the entire checksum verifica-
> tion subsystem.
>
> -d Dump the application layer data when displaying packets in verbose
> or
> packet logging mode.
> -y Include the year in alert and log files
> -e Display/log the link layer packet headers.
> -v Be verbose. Prints packets out to the console. There is one big
> problem with verbose mode: it's
> slow. If you are doing IDS work with Snort, don't use the
> '-v'
> switch, you WILL drop packets.
> ==========================================================================
>
> Snort processed 69196 packets.
> Breakdown by protocol: Action Stats:
>
> TCP: 69196 (100.000%) ALERTS: 129641
> UDP: (0.000%) LOGGED: 129641
> ICMP: (0.000%) PASSED: 0
> ARP: (0.000%)
> EAPOL: (0.000%)
> IPv6: (0.000%)
> IPX: (0.000%)
> OTHER: (0.000%)
> ==========================================================================
> Wireless Stats:
> Breakdown by type:
> Management Packets: (0.000%)
> Control Packets: (0.000%)
> Data Packets: (0.000%)
> ==========================================================================
> Fragmentation Stats:
> Fragmented IP Packets: 1 (0.001%)
> Rebuilt IP Packets: 0
> Frag elements used: 0
> Discarded(incomplete): 0
> Discarded(timeout): 0
> ==========================================================================
>
> TCP Stream Reassembly Stats:
> TCP Packets Used: 69196 (100.000%)
> Reconstructed Packets: (0.000%)
> Streams Reconstructed: 1472
> ==========================================================================
>
> snarf -d snarf/ -cgidir /usr/local/snortsnarf/cgi/
> -rulesfile /etc/snort/snort.conf logs/alert
>
> Signature
> Alerts
> Src's
> Dst's
> SHELLCODE x86 inc ebx NOOP
> 8
> 1
> 1
>
>
> Description of attack
>
> There are a lot of alerts in this snort output. We have some scanning, a
> possible trojan, and lots of traffic from a popular worm at that time.
> What
> stood out for me were the shellcode alerts. Considering part 1 of my paper
> is
> on Buffer Overflows this might be a good a chance to put in to practice
> what
> was talked about. A buffer overflow is an attempt of the attacker to
> overflow
> the stack allowing them to overwrite the instruction pointer. This allows
> the
> attacker to execute arbitrary code. The buffer generally consists of some
> NOOP's, the shellcode, then the buffer. After the buffer is where the
> attacker inputs the address to their shellcode. Calculating the correct
> address is hard and using NOOP's helps. A NOOP is a null instruction and
> the
> process will just skip over them. If the address which the attacker
> supplies
> points to anywhere in the NOOP sled it will make it to the shellcode.
>
> [**] [1:1390:4] SHELLCODE x86 inc ebx NOOP [**]
> [Classification: Executable code was detected] [Priority: 1]
> 10/02/02-05:13:47.256507 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800
> len:0x5EA
> 81.19.69.18:8000 -> 115.74.249.65:63742 TCP TTL:46 TOS:0x0 ID:15191
> IpLen:20
> DgmLen:1500 DF ***A**** Seq: 0x6812E8FB Ack: 0x97C707F Win: 0xFFFF
> TcpLen:
> 20
>
>
> alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"SHELLCODE
> x86
> inc ebx NOOP"; content:"CCCCCCCCCCCCCCCCCCCCCCCC";
> classtype:shellcode-detect; sid:1390; rev:5;)
>
> So what is this alert looking for. The rule doesn't specify a source and
>
> destination IP address or the destination port. It does however specify
> the
> source port. The variable $SHELLCODE_PORTS is defined as follows:
> var SHELLCODE_PORTS !80
> It is saying to not alert on traffic sent from port 80. This is due to the
> high probability of a false positive in web traffic. In the packet content
> it
> looks for a string of C's.
> "CCCCCCCCCCCCCCCCCCCCCCCC"
> A C translates to 0x43 in hex. If you read my paper you are probably
> wondering
> why this signature isn't looking for 0x90(NOOP). Well a 0x43 is the
> instruction 'inc ebx' on an x86 system. There is a signature that looks
> for
> 0x90's and attackers try to bypass this by using another instruction that
> leads to the same effect. Incrementing ebx has pretty much no effect in
> most
> cases so it works just as good as a NOOP instruction.
>
> In total there were 8 packets that set off these alerts.
>
> [**] [1:1390:4] SHELLCODE x86 inc ebx NOOP [**]
> [Classification: Executable code was detected] [Priority: 1]
> 10/02/02-05:13:47.256507 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800
> len:0x5EA
> 81.19.69.18:8000 -> 115.74.249.65:63742 TCP TTL:46 TOS:0x0 ID:15191
> IpLen:20
> DgmLen:1500 DF
>
More information about the Intrusions
mailing list