10 ms·
One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is
by mabbo 10y ago
One practical attack using this: create a torrent of some highly desirable content- the latest hot TV show in high def or whatever. Make two copies, one that is malware free, another that isn't.
Release the clean one and let it spread for a day or two. Then join the torrent, but spread the malware-hosting version. Checksums would all check out, other users would be reporting that it's the real thing, but now you've got 1000 people purposely downloading ransomware from you- and sharing it with others.
Apparently it costs around $100,000 to compute the collisions, but so what? If I've got 10,000 installing my 1BTC-to-unlock ransomware, I'll get a return on investment.
This will mess up torrent sharing websites in a hurry.
Edit: some people have pointed out some totally legitimate potential flaws in this idea. And they're probably right, those may sink the entire scheme. But keep in mind that this is one idea off the top of my head, and I'm not any security expert. There's plenty of actors out there who have more reasons and time to think up scarier ideas.
The reality is, we need to very quickly stop trusting SHA1 for anything. And a lot of software is not ready to make that change overnight.
- dragonwriter 10y agoI may be confusing p2p protocols, but doesn't BitTorrent grab different chunks from different sources, so that if there are different people spreading different versions that are viewed as the same, people are going to mostly get either the original (and initially more common) version or broken junk that is a mix of the two versions?
- nstj 10y agojinx.
- runeks 10y agoNot only that, BitTorrent also uses a Merkle tree of the torrent data split into pieces (e.g. 1 MB per piece), meaning you need to compute thousands of colliding hashes, with the added restriction that the data must be exactly the piece length. The torrent ID is the Merkle root hash, which is a hash of all the piece-hashes hashed together in a tree structure: https://i.stack.imgur.com/JVdvj.png https://i.stack.imgur.com/JVdvj.png
- sp332 10y agoIf you find a collision for the smallest piece, you don't need to find collisions for any higher nodes on the Merkle tree because you'll just be hashing the same values as the legit version.
- MayeulC 10y agoI don't know enough specifics about sha-1 or bit torrent, but it would seem to me that it depends on the data that is chosen for the base ("leaves") of the tree: if it just consists in taking the hashes, concatenating them, and move higher until you only have one hash, then yes. However, if the data itself is concatenated for the first step, that might not be the case (depending on the sha-1 algorithm). I seem to recall that md5 operates on 512 bit chuncks (padded if necessary), and takes the result to seed the next computation. So, with md5 (if I recall correctly, still), the attack could work if each part of the torrent was a multiple of 512 bits, Merkel or not, and regardless of the base. Of course, you cannot change the whole torrent in that case, as it would be prohibitively expensive. And you still have to keep the same file size. I would love to hear a bit more on the topic from someone more knowledgeable about hashes and torrents.
- the8472 10y agoThe process is fairly simple. Files are concatenated and that blob is then chunked into multiple-of-16KiB-sized pieces. Each piece is hashed. The hashes are concatenated and embedded as string in the torrent file. Then a specific subdictionary of the torrent file including the piece hashes, filenames and the length of the data is hashed to yield the infohash. Magnets only convey the infohash. .torrent files convey the whole metadata, including the pieces hash string.
- Aissen 10y agoThen this smallest piece must also change the file type to an executable, and contain a meaningful payload.
- 10y ago
- ktta 10y agoWell, you really don't need the complete file either. Since torrents are usually shared unzipped, they can just replace a chunk with a bad one (It varies usually from 256KB-2MB) and a single chunk can be replaced with a bad one embedded with malware to cause problems. Especially something like a buffer overflow attack on a video file.
- mavdi 10y agoTo be honest this is a lovely evil plan. cough MPAA cough
- lawless123 10y agoIf they MPAA could subvert torrents of their property and and replace sections of the footage with just warnings (ruinning the download) i would find that much less objectionable than DRM. Frustrate the people pirating instead of punishing everyone else.
- kbart 10y agoIf such technique would be as accurate as their DCMA take-down notices, I wouldn't be surprised in resulting subverted Linux installations and whatnot.
- sp332 10y agoBut instead, they injected torrents into a torrent tracker and then DoS'd it when the files were removed. https://web.archive.org/web/20080530115944/http://revision3.com/?p=153 https://web.archive.org/web/20080530115944/http://revision3....
- zo1 10y agoIt'll only work for a few days/months after people start noticing it.
- babyrainbow 10y agoMalware in a video? Is that possible? How does it work?
- ktta 10y agoYou could have a buffer overflow attack talking advantage of a specific popular video player out there. Since video players are usually not very security focused, someone determined could do it. And since video torrents are unzipped, a single chunk can be replaced with the malicious chunk with the attack code. It can look like a tiny jitter depending on the chunk size/total video size.
- throwaway2048 10y agoYou could just do this with a video you release anyways, and skip the century of GPU runtime. This break requires you control/generate both the original and the evil file.
- svantana 10y agoMy thought exactly, although you would need your malware to incubate for some time to allow it to spread properly first.
- mlonkibjuyhv 10y agoI wonder if you could model this similarly to populations. As in will the malware ever go extinct? Obviously an attacker probably won't stop seeding, but let's say shim does stop seeding. At this point x% of seeders have the payload. Seeders on average share the file y times. Will x tend to zero below a threshold of 50%? And if the attacker does not stop seeding, will the infected quota stabilize?
- Bartweiss 10y agoCouldn't you get nearly the same intermittent-attack behavior just by saying something like "break out of codec, only do malicious behavior one time in 1,000"?
- chaosfox 10y agothis isn't quite true, bittorrent have checksums for each piece in the torrent, I not saying its impossible to do but its significantly harder than just finding 2 files with the same hash.
- deleted 10y ago[deleted]
- cesarb 10y agoWouldn't that make the attack easier, since you just have to manufacture a pair of pieces with the same hash, instead of having to make the whole file have the same hash?
- chaosfox 10y agothat depends on the attacker objective, if you just want to trash the file you can just search for any piece that have a hash collision, but if you want to turn the file into a malware you will need to modify the file in a specific way, possibly spanning multiple pieces, and there's less room for fuzzing the hash.
- heinrich5991 10y agoPeople do exploits by changing 1 bit! I'm sure you can distribute malware using just one chunk, given some cleverness.
- rocqua 10y agoAs mentioned else were in this thread, you can put a lot of the payload outside the single collision piece. People are unlikely to go looking for executable code inside a video. All you need for the colliding pieces is for one to trigger the payload and the other not to trigger the payload.
- andai 10y agoDoes bt have checksums for pieces and files? I thought it was only pieces.
- nstj 10y agoI don't actually know the in's and out's of BitTorrent structure but wouldn't that not work as the 2 files would be completely different? ie: I'd be downloading (and putting together) some blocks of the "real" movie and some blocks of the "malware". I'm guessing the resultant file wouldn't even open?
- kbart 10y agoVideo files are purposely made to work even with some data blocks missing. It's the feature that enables video streaming. Valid header is usually enough for video player to at least try to play a file.
- espadrine 10y ago> the latest hot TV show in high def or whatever Since it takes 6,500 CPU years and 110 GPU years, it won't quite be the latest show, unless you have really deep pockets. There are way less costly ways to make money illegally using simpler vulnerabilities or by being a pay-to-use DDoS provider.
- Turbots 10y ago100,000 dollars to do the computation it seems, not that hard to get funding for if all the computers you infect can participate in your botnet once you do
- Bartweiss 10y agoRealistically, the closest low-cost attack is to just upload a malware-laden torrent of the latest TV show and not even pretend. It won't get seeded as widely, but you can do the same thing again next week.
- deleted 10y ago[deleted]
- yAnonymous 10y ago>This will mess up torrent sharing websites in a hurry. I doubt it. Should this ever become a problem, it would be trivial to change the hashing algorithm. Not worth the effort.
- inetknght 10y agoHow do you propose to ensure backwards compatibility with the millions of torrents already produced?
- VMG 10y agoNew clients could support multiple hash algs, so old torrents would not be a problem. New torrents could provide hashes for multiple algs, depending on the extensiblity of torrent format. Otherwise the torrent sites could provide two URLs or torrent files.
- yAnonymous 10y agoDepends on the implementation, which I'm not familiar with, but there are definitely ways to handle that.
- sktrdie 10y agoBut you can't control the data in the malware. It will be garbage.
- Natanael_L 10y agoThey controlled the visual appearance of the different PDF files in the example. Why couldn't you inject malware instead?
- sktrdie 10y agoBecause controlling the visual appearance would change the data of the PDF, hence change the underlying hash.
- saalweachter 10y agoNon-coding regions. Not every part of a file codes for its apparent output. Comments, symbol names, whitespace, color tables... for most file formats, there are countless variations of the bytes on disk which produce outputs which are visually indistinguishable. The trick is to identify this space in a way that lets you efficiently iterate through it until you find a version which matches the target hash.
- sktrdie 10y agoAre you sure this isn't only possible because of the PDF file format? http://shattered.it/static/pdf_format.png http://shattered.it/static/pdf_format.png Hence shouldn't be possible for general malware.
- Natanael_L 10y agoGeneral malware can be injected in almost anything. Few formats are strict enough to stop that.
- deleted 10y ago[deleted]
- 10y ago
- svantana 10y agoInteresting premise, some objections: 1) wouldn't search time be proportional to file size for hashes? These guys worked on 400kb pdf's, while most popular torrent content is in the GB range 2) Wouldn't this only work for users that got the entire file from you? fileA and fileB may have the same hash, but some random portions from each will have a different hash.
- dcosson 10y agoYou could replace a single chunk with your malware. Then it could be any size and the rest of the chunks could be the legit content. I don't know much about video codecs, but this assumes there's some way to break out of the playback and run your malicious code. Maybe a buffer overflow, or maybe if your malware is the first chunk of the file you could get it to run first somehow before the video? Or even better, torrents of apps sometimes come with an executable that you run to crack the DRM (so I hear). You could swap that out undetected, and you can probably also convince people they have to run it with sudo.
- minitech 10y ago> Maybe a buffer overflow, or maybe if your malware is the first chunk of the file you could get it to run first somehow before the video? If you have an exploit in a video player, you don’t really need the collision. > You could swap that out undetected, and you can probably also convince people they have to run it with sudo. Also don’t need a collision (or more sudo than usual) for this; just make it patch the application (like it’s supposed to!) with something that runs with low probability.
- Ajedi32 10y agoEdit: Nevermind, I misinterpreted something in the report. Collisions between malicious and non-malicious documents are indeed most likely feasible. Original comment: While theoretically possible, I don't really see that particular attack as being an actual, practical problem anytime soon. In order for that to work not only would you have to find _a_ collision, but you'd have to find one with the additional constraints of "one copy is malware free while the other isn't", which would be significantly more difficult (at least, as I understand it). That said, I agree it's probably time for torrents to start moving to another hash function. With time and additional research, it's entirely possible that theoretical attacks like the one you described could eventually become practical.
- Natanael_L 10y agoNo, that's not the big problem. Every collision of this kind so far just requires a random looking section, and allows another section to be whatever you want. You can just swap out one file for malware.
- Ajedi32 10y agoAh, sorry. I got confused by this section on shattered.it, which seemed to be saying that merely requiring a certain level of entropy in the resulting documents would be enough to mitigate the attack: > Are TLS/SSL certificates at risk? [...] it is required that certificate authorities insert at least 20 bits of randomness inside the serial number field. If properly implemented this helps preventing a practical exploitation. After giving it a bit more thought though, I realize now though that this mitigation actually works by preventing the attacker from fully controlling the hash of the first, non-malicious document.
- schoen 10y agoThe project's site is referring to an outdated version of the requirement. As I noted above, the requirement they refer to is only a SHOULD (some CAs might not have complied with it) and was replaced at the end of September with a SHALL which requires 64 bits rather than 20. https://cabforum.org/2016/07/08/ballot-164/ https://cabforum.org/2016/07/08/ballot-164/ Edit: I told them about this and they've fixed it; it now says "64 bits" instead of "20 bits".
- angry-hacker 10y agoIt's easier just to upload malware to a torrent site. Windows crack, let other people or botnet to download it and suckers will get your malware too. If AV complains, say that is an expected behavior.
- vorticalbox 10y agoIt's would more profitable to just develop undetectable malware and spread that from the start.
- ksk 10y ago>Edit: some people have pointed out some totally legitimate potential flaws in this idea. And they're probably right, those may sink the entire scheme. But keep in mind that this is one idea off the top of my head, and I'm not any security expert. Well to be fair to those people, you started out saying its a practical attack when it wasn't even a theoretical one.
- vortico 10y agoWell, it's practical on a small scale. You could wait until a torrent has only 1-2 seeders, and then you can hope to give leechers all blocks of a file. Or, you could deliver a torrent with a 1GB installer (for some software package) and a 100kb keygen (which you replace with malware) fitting inside a 1MB block and you can be sure to spread that around regardless of the number of other seeders.
- dantillberg 10y agoIt doesn't have to be a new torrent. You could just join the swarm for an existing torrent and seed different data for selected parts of the torrent.
- michaf 10y agoI wrote a small proof of concept here: https://github.com/michaf/shattered-torrent-poc https://github.com/michaf/shattered-torrent-poc Both Installer.py and Installer-evil.py result in the same piece hashes, with piece size chosen as 512. The only difference between the files is the shattered pdf fragment, encapsulated in a variable. This fragment starts exactly at the piece boundary, resulting in identical hashes.