Vulnerability Development mailing list archives
Re: distributed.net and seti@home
From: shawn.a.clifford () LMCO COM (Clifford, Shawn A)
Date: Mon, 31 Jan 2000 10:10:57 -0500
If you are in the same broadcast domain as the client/target, might an ARP cache poison work? I've modified Mike Shiffman's 'poink' code so that you can specify target/dest Ethernet addresses for the purpose of ARP poisoning, rather than a DoS on Window$. Here's what you might do (on Solaris, anyway): 1) nslookup/ping the server (setiathome.ssl.berkley.edu ?) - save the IP address 2) ping <target> 3) arp <target> - save the ethernet address (for destination) 4) arp <my_host> - save the ethernet address (for target) 5) poink -s <my_ether> -d <target_ether> <server_ip> No you have 5 minutes (or ARP cache timeout) in which the SETI client should try to connect to a server on your machine to get data from SETI (or the specified IP address). Right? The get_arps.pl script below comes in the documentation for the LibPcap Perl module. You can verify your ARPs from poink are working with this script. Poink requires 'libnet' from the Packet Factory (www.packetfactory.net) and the LibPcap module from perl is from CPAN (www.cpan.org). Root is required to open the network interface. Incidentally, doing a broadcast ARP (dest ether addr = 00:00:00:00:00:00 or FF:FF:FF:FF:FF, is there a difference?), and specifying a bogus source ether for a given WinNT machine's IP address has the effect of a window dialogue on the victim's computer notifying him that his IP address is being used by someone else. So don't broadcast an ARP poison. I assume it would be possible to modify 'poink' so that a victim would receive a RARP reply storm (DoS attack) by broadcasting RARP requests with a spoofed source of the victim's ether? Well, that is getting off subject... Cheers, -- S
If the clients contact the server, the only way to exploit the clients is to make the client contact your own server I suppose. This could be done via changing DNS records manually on a upstream DNS server, a hacked client, an entry in the hosts file, etc. The all require pretty much elevated access to the network (admin status) or the computer, in which case you don't have to use the distributed clients to hack into the machine. I think it is possible in some cases to insert a DNS cache entry into a DNS server manually, and you can fool all the clients that use that DNS server to contact your own server. Then you could send custom packets back to the client to overflow it, etc. That's about all I can think about right now. It's the weekend, and I am going to be lazy ;)
<HR NOSHADE> <UL> <LI>application/octet-stream attachment: et_arps.pl_ </UL> <HR NOSHADE> <UL> <LI>application/octet-stream attachment: oink.c_ </UL>
Current thread:
- Re: distributed.net and seti@home Sen_Ml Sen_Ml (Jan 30)
- Re: distributed.net and seti@home Stefan Aeschbacher (Feb 01)
- <Possible follow-ups>
- Re: distributed.net and seti@home Robert Wojciechowski Jr. (Jan 31)
- Re: distributed.net and seti@home Sebastian (Jan 31)
- Re: distributed.net and seti@home Clifford, Shawn A (Jan 31)
- Re: distributed.net and seti@home Seth R Arnold (Jan 31)
- Re: distributed.net and seti@home CyberPsychotic (Jan 31)
- Re: distributed.net and seti@home Oliver Friedrichs (Feb 01)
- Re: distributed.net and seti@home Iván Arce (Feb 02)
- Re: distributed.net and seti@home Oliver Friedrichs (Feb 01)
- Re: distributed.net and seti@home Sen_Ml Sen_Ml (Feb 01)
- Re: distributed.net and seti@home Kerneels (Feb 02)
- Re: distributed.net and seti@home Granquist, Lamont (Feb 03)
- Re: distributed.net and seti@home Steffen Zahn (Feb 04)
- Re: distributed.net and seti@home Sen_Ml Sen_Ml (Feb 01)
- Possible DHCP DOS attack Paul Keefer (Feb 02)