full-disclosure - modifying shadowchode exploit

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <007e01c34e49$a51d5d10$0100000a@beta>
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