GitHub Introduces SHA-1 Collision Detection System

Starting March 20, 2017, when calculating SHA-1 hashes on GitHub, any content that has signs of a possible SHAttered attack on the collision of SHA-1 hashes is detected and rejected . The company wrote about this in the official blog. Thus, no one can post files from a pair with the same hashes, but with different content. Although so far in practice no one has carried out such attacks anywhere except torrents , but GitHub decided to play it safe just in case.

Almost a month ago, Google and the Center for Mathematics and Computer Science in Amsterdam presented the first way to generate collisions for the SHA-1 hash function. SHAttered attackwas the result of a two-year study, which began shortly after the publication in 2013 of the work of cryptographer Mark Stevens from the Center for Mathematics and Computer Science in Amsterdam on a theoretical approach to creating the SHA-1 collision. He later continued to search for practical hacking methods along with colleagues from Google. A scientific paper has been published that describes the general principles of generating documents with message blocks that are subject to SHA-1 collision.

Soon after the publication of the document, the first example of its real use in applications appeared: BitErrant attack, which allows you to create two identical torrents (.torrent file) with the same hashes, but which correspond to different files. One is a regular executable file, and the other is a malicious Meterpreter file for the Metasploit framework.

Linus Torvalds says SHA-1 collisions in Git repositories have nothing to fear. He explained that there is a big difference between using a cryptographic hash for digital signatures in encryption systems and for generating “content identification” in a system like Git. In the first case, a hash is a kind of statement of trust. A hash acts as a source of trust that fundamentally protects you from people whom you cannot verify in other ways. In contrast, in projects like Git, the hash is not used for "trust." Here, trust extends to people, not hashes, Linus says. In projects like Git, SHA-1 hashes are used for a completely different, technical purpose - just to avoid accidental conflicts and as a really good way to detect errors.

Despite the opinion of Torvalds, the developers of GitHub decided that reinsurance never hurts, so now this platform is protected from placing files and code from a pair with the same hashes.

Unlike Torvalds, GitHub developers believe that the correct operation of SHA-1 is really important for Git. They do not argue with the very logic of his reasoning, they simply indicate that carrying out such an attack is really possible in practice in Git. They even describe roughly how such an attack might look. Keep in mind that an attack is not possible on previously created objects. To carry it out, the attacker must specifically create at the same time two new objects with the same hashes. They will be the same throughout, except for a small section of different data.

In this case, the attack can be carried out according to the following scenario:

1. Generate a pair of objects where one looks normal and the other does something malicious. This is best done with binary files, where people are unlikely to notice the difference by eye.
   
   
2. Convince the project maintainers to accept the “innocent” half of the pair and wait for them to tag or commit with this object.
   
   
3. Distribute a copy of the repository in which the innocent object is replaced with a malicious one (for example, by placing it somewhere on a third-party server and presenting to everyone evidence of the authenticity of the copy using the identical hash). After checking the signature, everyone will think that the contents of this project correspond to the contents of the original repository.

The SHAttered attack always leaves traces - a certain specific sequence of bytes, the same in both parts of the pair. It can be detected by calculating SHA-1 for any part of the pair. GitHub now does this check every time the hash is calculated.

The code for determining a specific sequence of bytes was written by Mark Stevens and Dan Shamov and published in the public domain .

So far, there hasn’t been a single hash collision on GitHub, she said. The PDFs from the original attack example give the same hashes on their own, but not in the Git repository, because here some more Git technical information is taken into account when calculating the hash.

There is some likelihood that the automatic blocking algorithm will work on any code or file that is not placed for the purpose of subsequent substitution and attack. But there's nothing to be done. You have to change your code to unlock it.

GitHub developers have even calculated how likely it is to accidentally write code that is prone to blocking. If five million programmers will generate one commit per second each, then the chance of a random collision by the time the Sun turns into a red giant is about 50%.

GitHub developers are now working with Git to include a library for collision detection in a common project. In addition, Git is currently developing a plan to migrate from SHA-1 to a more secure hash function with minimal damage to existing repositories.