lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
From: wrees at htoc.com (Warren Rees) Subject: modifying shadowchode exploit The code that you provided below worked like a charm on my 1601 (running 11.2(21)). Here's the interface stats after running it (from a console connection of course :)) zeta#sh int e0 Ethernet0 is up, line protocol is up Hardware is QUICC Ethernet, address is 0010.7bc1.a850 (bia 0010.7bc1.a850) Description: connected to Linksys 10/100 Switch Internet address is 10.0.0.254/8 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 242/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:10:12, output 00:00:06, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 75/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec Filled the input queue up, and I have to do a hard reset to clear it... -Warren -----Original Message----- From: full-disclosure-admin@...ts.netsys.com [mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Michal Zalewski Sent: Saturday, July 19, 2003 5:20 PM Cc: full-disclosure@...ts.netsys.com Subject: Re: [Full-Disclosure] modifying shadowchode exploit On Sat, 19 Jul 2003, Ben Matlock wrote: > I took a look at the output of the released Cisco exploit and added 2 > lines to make it generate random payload. More could be done. Can be indeed. It seems that the trigger of this vulnerability is simply a <queue size> of IP packets of a group of protocols (such as 55), as pointed out on INCIDENTS. And it's being done - I've been hit (and missed) today with something that appears to be an unpublished exploit for that vulnerability. I was quite confused at first, seeing it reaching a Linux box, but then realized it's the same protocol that the one used in shadowchode... made me feel so special. The one I've captured does not seem to use such a big payload and uses incremental TTLs, suggesting it might be more advanced. For more information, you might want to to go http://lcamtuf.coredump.cx/mobp (exhibit #12, will probably remove it at some point), here's a sample packet dump: 22:53:00.340000 80.50.156.4 > 195.117.3.59: ip-proto-55 0 (ttl 2, id 60107) 4500 0014 eacb 0000 0237 1b01 5032 9c04 c375 033b 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 035a 383d ..and here's a playback utility if you wish to test it (I haven't): http://lcamtuf.coredump.cx/mine.c -- ------------------------- bash$ :(){ :|:&};: -- Michal Zalewski * [http://lcamtuf.coredump.cx] Did you know that clones never use mirrors? --------------------------- 2003-07-19 21:49 -- -- ------------------------- bash$ :(){ :|:&};: -- Michal Zalewski * [http://lcamtuf.coredump.cx] Did you know that clones never use mirrors? --------------------------- 2003-07-19 23:12 -- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Powered by blists - more mailing lists