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" <dataholicat_private> ... > > 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
This archive was generated by hypermail 2b30 : Sun Feb 10 2002 - 15:02:25 PST