This week, a group of researchers from Google and Centrum Wiskunde & Informatica (CWI) announced real possibilities for SHA-1 collision attacks. We investigated how far and how deep this issue can affect people and organizations in real-world attacks in order to advise on how to prevent unnecessary damage.
The concerns about SHA-1 are not a new thing; this paper demonstrates theoretical proof of collision possibilities. This paper also got a lot of attention on The Cryptographers' Panel at RSA 2016, where Adi Shamir made a prediction about the possibility of the real SHA-1 collision attack in the next few months. After that discussion, some companies began publicly proclaiming their concerns about usage of SHA-1 in future. But there was a lot of skepticism around this type of attack because no practical proof was presented in the real-world environment.
During the last year, many companies started deprecating usage of SHA-1 in order to prevent any theoretical attack. But, with the proof and real-world attack scenario outlined this week by Google and Centrium Wiskunde, the spotlight is shining once again on SHA-1 collision attacks. The open source code for collision detection is publicly available here. We can no longer say that this type of attack is only theoretical. So, how can we fix the problem?
Last month, we mentioned some malicious tricks with Microsoft signed executables in our blog. Now, we’ll go deeper into the problems in terms of SHA-1 collisions and possibilities for malware.
A few years ago, a similar approach with chosen-prefix collision was used against the MD5 algorithm. In practice, the most well-known example of this attack for MD5 was created by Flame malware. But let’s think about what kind of target this can be the next for malware developers.
We found one interesting example - the Microsoft Kernel-Mode Code Signing Policy. This attack relied on signature verification for loading only signed kernel-mode drivers. Here are signature requirements include MS Windows 10:
Figure 1
(https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-)
As we can see, the requirements for the hash function is SHA-1 or later. So, this attack opened the doors for possibilities to abusing signed drivers for delivery malicious code into kernel-mode. But how does this work in practice? How rare are SHA-1 signed drivers? Turns out, SHA-1 signed drivers aren’t rare at all and, in fact, it is still common practice to use this algorithm. As you can see, we found different vendors that are still using SHA-1:
Figure 2
Figure 3
But how many ‘vulnerable’ default drivers you can find in newer Microsoft Window 10 installations? Due to third-party drivers, it turns out you can find more than you might expect. Microsoft has mostly deprecated SHA-1 support on the latest Windows OS offerings, but third-party drivers still exist by default, even in these new Windows builds. In addition, previous versions (MS Win7 and 8) contain a lot of signed drivers, which are not updated over the years.
For example:
Figure 4
Figure 5
Figure 6
Figure 7
You can see how SHA-1 quickly becomes a huge problem for many organizations and systems. Beyond just internet security, the legacy of these problems is built right into legacy operating systems used in huge numbers at giant organizations. As usual, built-in problems in systems and third-party software that runs in the background can grow into a huge security problem unless they are dealt with at their core, which is a huge lift for many software companies.
Digging even deeper, we started to uncover what else could be affected at the firmware or hardware level. One example is TPM 1.2, which is still very common, but supports only SHA-1. SHA-1 also directly affects firmware security due to trusted boot schemes, such as Secure Boot, which can be based on old keys using the insecure SHA-1 algorithm. Microsoft already has some restrictions on the Win10 systems. For instance, their device encryption does not support TPM 1.2.
The story about real-world SHA-1 collision attacks is just beginning, but the era of using SHA-1 for security should end today. The clock is ticking, and it’s really only a matter of hours and days for now. Google will be published the source code of the tool for creating SHA-1 collisions after the next 90 days.
How Likely is This Type of Attack Going to Be Used in the Wild?
Evidence suggests that attackers can't just collide with a known hash, but they must have access to the original document. Additionally, since the attack leverages directed edits, not every edit will be valid. In other words, breaking a Certificate used in a TLS session or an SSH key here is exceptionally unlikely. The attack requires very carefully directed changes to the original.
Modifying a signed binary could be in scope, but it’s a lot easier to do a more free-form message like a PDF where an attacker’s edits needed to collide may well be ignored or invisible by the victim. Modifying binaries using this technique looks like it may be a destructive operation at first glance, as attackers simply need too much structure that you can't generally change. Further research may be needed to determine the reality of capability of this attack to modify binaries in the real world.
The attack could probably be done much cheaper/faster if the attacker was using specialized equipment similar to that developed to do dedicated bitcoin mining.
The big shift in the paper released describing this attack was making this approach proactive by focusing on a GPU-optimized version of the current state of the art on attack research, and focusing on efficient distributed operations. This optimization brought it to the point where the attack is now feasible for a broad set of adversaries. The other interesting development here is when you calculate cost if using AWS or cloud resources you get one output for the price. If you develop hardware, you can amortize the cost (minus the power to run it) over as many as you want.
How Can We Fix the Problem and Prevent Future Attacks?
For developers and security teams, the simplest way to secure against this type of attack is to use either SHA-256 (recommended), or use SHA-1 of byte 0-N and byte 1N, or use two separate hash algorithms.
