Re: Infecting the KaZaA network? (moving here thread from 'traq)

[John Hall <j.hall () f5 com>]

This was originally a reply to GertJan de Leeuw's message on bugtraq.
The moderator killed the thread there and suggested it be moved here
to vuln-dev.

The new problem (#3 for those counting) *does* make it significantly
harder to infect users of the KaZaA network, but probably not impossible.
It is quite possible given two plaintexts of sufficient size, to ensure
that they both have the same MD5 checksum.  I hope that the combined
size of the spoofing data plus virus would in all cases be larger than
the size of a chunk downloaded from any given peer.  The virus payload
does not have to be too large.  All it needs to know how to do is download
and execute the actual virus (which could then infect all the KaZaA files
on the new victim's machine).

The thing to worry about here is that it doesn't have to work too often
to become a real problem and that it's likely that it would not be too
difficult for a single attacker to add hundreds, if not thousands, of
compromised hosts to the KaZaA network using an already acquired zombie
network as I described below.  I mention a possible solution below,
but even that would fail in the face of the zombie network attack.  You
should *always* be very paranoid and suspicious of the source when
downloading executable code.

JMH


-- Original reply to GertJan de Leeuw's message here --

The two problems you bring up would make it significantly harder to exploit
the KaZaA network, but may not prevent it entirely.  I have not examined a
KaZaA download, but it seems likely that it breaks any given executable up
into chunks to be downloaded using a consistent methodology.  In order to
successfully create an exploit, an attacker would need create an attack that
would fit entirely within one chunk of the download and when integrated with
the original binary produced the same checksum (if a checksum is even used). 
Even assuming that KaZaA uses some random scheme to divide the download into
chunks, it seems quite possible to me that a small virus payload could be
integrated along with it's checksum fixing data that would get downloaded by
at least some percentage of the attempting hosts.  The smaller the size of
the virus package, the more likely it would be to survive downloads.

There seem to be few ways to prevent this type of attack from succeeding. 
One possible way would be to make the effective chunk size very small and
variable (say from one to 8 bytes) using some cryptographic key supplied by
the client.  Each server for a particular download would then need to
extract the segments of it's contribution, combine them and pass them to the
client which would piece them together.  So, for example, the first two bytes
would come from server 1, the next five from server 2, the next one from
server 1, the next six from server 2, and so on.  (If anyone uses this
method, please send me money.  k? thanks  ;-).

Another thing that would help would be to increase the number of servers
contributing pieces to the final download, although the more servers
contributing the less efficient the file sharing network will be due to the
packet overhead.  Finally, the checksum (or hash) used could be made even
more cryptographically secure; or more than one type of hash could be used,
which would make file tampering more evident.

Note that none of these methods ensures that you will not eventually be
infected by an executable downloaded.  They just raise the bar for the
prospective attacker.

A very insidious attack against the KaZaA network would be to download
a trojaned executable to a previously acquired network of compromised
hosts that would then attach themselves to the KaZaA network, thereby
greatly increasing the number of sources of your particular flavor of
that executable.

I'm going to stop now and go sit in my faraday cage until the willies
subside.  :)

JMH

Raistlin wrote:
> From: "GertJan de Leeuw" <dataholic () punkass com>
...
> > 1.The installation MUST have the same size as the
> > orginal distribution package, since kazaa will look on
> > its network for the filename with the exact filesize (for
> > multiple downloads at one time from different clients)
> > Because you need to 'inject' your evil code the
> > filesize will be bigger. Ofcourse you could pack it with
> > a pe packer like upx and add bytes till the exact
> > filesize is there , but then we have problem 2:
> >
> > 2.As we all know, KazaA downloads from multiple
> > users, so IF you have success with step 1, you will
> > fail at this point, because you will have an invalid exe
> > (a evil version merged with the orginal distro).
>
> There's a third major problem:
>
> 3) Kazaa uses MD5 to check that files are identical when starting a multiple
> download and/or looking for "alternate sources" for a given file (this is
> explained on their site). In fact if you just change a letter in the ID3 of
> an MP3 file, it will not be listed as a "copy", even if otherwise identical.
> You can, instead, alter the filename without risk.
>
> Stefano "Raistlin" Zanero
> System Administrator Gioco.Net
> public PGP key block at http://gioco.net/pgpkeys