The BitErrant attack is a fun little exploit that shows what can go wrong in the BitTorrent protocol when SHA1 collisions become reality.
SHA1 collisions resulting in chunks of the downloaded file become replaceable with a chunk that is completely different, corrupting the downloaded file OR triggering backdoor functionalities.
An attacker can alter the execution path of the executable by serving altered chunks when the victim is downloading the executable using the BitTorrent protocol.
Thank you good folks at Google and CWI for making SHA1 collision become a reality with the SHAttered attack!
Here are two EXE files with different functionality (evil has a meterpreter that will listen on all interfaces), but yielding the same .torrent file. biterrant_poc.zip
SHA1: eed49a31e0a605464b41df46fbca189dcc620fc5 (ya know, because what can go wrong?)
Also, here is a sophisticated (LOL) framework on how to generate such executables.
Current AV stats:
Good file on virustotal
Evil file on virustotal
How BitTorrent works (oversimplified explanation)
The first step to distribute a file over BitTorrent is to generate a “.torrent” file from the original file (DATA). This is done by slicing the file into fix sized chunks then calculating SHA1 hash on each of the chunks. The hash bytes are then concatenated together and stored under the torrent file’s “pieces” dictionary key.
When someone tries to download the DATA file using BitTorrent, first the “DATA.torrent” file needs to be downloaded and parsed. Based on the information stored in the DATA.torrent file, the client searches for peers and downloads chunks of the original file (DATA). In order to make sure rouge peers will not be sending malicious data, the client verifies each downloaded chunk against the hash data stored in the DATA.torrent file. If the hash data in the torrent file doesn’t match the SHA1 hash of the downloaded chunk, then the bad chunk gets discarded.
The malicious intent
An attacker can create an executable file which when executed looks harmless, but will change its execution path based on what data is inside the SHATTER region. Of course when checked with AntiVirus software the file will look okay as the malicious code is hidden in an encrypted blob, and will never get executed. Right?
Well, not quite. If the attacker has two chunk sized blob of data with matching SHA1 hash -looking at you SHAttered- and taking some constraints into account, generating two executables with different data but yielding the same .torrent file is possible!
If the previously mentioned constraints are fulfilled, the two executables now have one chunk of data which is interchangeable. The attacker can replace this chunk to trigger the malicious functionality in the code.
One example on how the shellcode can be executed (or not) based on which chunk has been retrieved over the BitTorrent protocol.
The principle is that the decryption yields garbage when the incorrect SHATTER data is used. For example, shatter-2.pdf collision data is used for encryption, shatter-1.pdf data is used for distribution. During the download the attacker starts seeding his file where the shatter-2.pdf data is used, effectively replacing that one chunk thus triggering the decrpyion and execution of the shellcode in clients who were uncluky enough to download that specific chunk from the attacker.
Is this something serious?
NO. at least not right now. I might reevaluate this statement when this gets used in the wild.
How can I protect myself?
Always cross-check the MD4 MD5 SHA1 SHA256 hash of the downloaded file. Good luck finding torrent sites that publish such hashes 🙂
There is an option when generating torrent files to include the MD5 hash of the full datafile in the generated torrent file. Most of the time it’s not used, not even sure if all torrent clients respect it.