From: Clifford, Shawn A [shawn.a.clifford@LMCO.COM]
Sent: Monday, January 31, 2000 10:11 AM
To: VULN-DEV@SECURITYFOCUS.COM
Subject: Re: distributed.net and seti@home

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 ;)