It's 2016. Can we stop using MD5 in malware analyses?

Posted by   Martijn Grooten on   Jul 26, 2016

When a security researcher comes across a new piece of malware, the first thing he (or she) does is check the file hash to see if it has been seen, or maybe even analysed, before. For that reason, if the researcher does end up writing an analysis, it is considered good practice to add the hashes of the analysed samples to the report.

It is still fairly common for these hashes to be generated using the MD5 algorithm, which is odd given that it was officially broken in 2004, when a collision was found. Since then, it has been broken a lot further, and in 2012 it was found that the Flame malware exploited weaknesses in MD5 to create a fake certificate to sign updates supposedly coming from Microsoft.

In recent months I have given a number of presentations on the exploitability of weaknesses in cryptographic protocols, my conclusion being that, while we should stop using weak protocols, the risks vary from small to negligible.

This is also true when it comes to using MD5 hashes in malware analyses. Firstly, to create another file with the same hash as a given piece of malware is not a trivial task, to put it mildly. And secondly, the harm someone with this power could do would likely be restricted to creating some frustration.

Still, there is a strong argument as to why using MD5 is bad even in this case: it reinforces bad practices. Some security products still use MD5 internally, and there have been reported cases of products using MD5 hashes to whitelist previously analysed suspicious files. Given that it would be feasible to create two executables, one malicious and the other harmless, with the same MD5 hash, an attacker could send the harmless file to such a product first and then take advantage of the whitelisting to get a free pass for the malicious file.

So let's just stop using MD5 everywhere. And, while we're at it, do the same with SHA-1, a collision for which is expected to be found this year, and skip straight to SHA-256.

Finally, if you're worried that your Tweets will be too long if you use SHA-256 hashes to refer to malware samples, use a link to the file's report on VirusTotal or malwr.com instead, which takes up fewer characters than even MD5. Or, if you really want to, find a way to encode SHA-256 hashes into emojis.

ostrich.png

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest posts:

VB2018 paper: The modality of mortality in domain names

Domains play a crucial role in most cyber attacks, from the very advanced to the very mundane. Today, we publish a VB2018 paper by Paul Vixie (Farsight Security) who undertook the first systematic study into the lifetimes of newly registered domains.…

VB2018 paper: Analysing compiled binaries using logic

Constraint programming is a lesser-known technique that is becoming increasingly popular among malware analysts. In a paper presented at VB2018 Thaís Moreira Hamasaki presented an overview of the technique and explained how it can be applied to the…

Virus Bulletin encourages experienced speakers and newcomers alike to submit proposals for VB2019

With a little less than a month before the deadline of the call for papers for VB2019, Virus Bulletin encourages submissions from experienced speakers and newcomers alike.

VB2018 paper: Internet balkanization: why are we raising borders online?

At VB2018 in Montreal, Ixia researcher Stefan Tanase presented a thought-provoking paper on the current state of the Internet and the worrying tendency towards raising borders and restricting the flow of information. Today we publish both his paper…

The malspam security products miss: banking and email phishing, Emotet and Bushaloader

The set-up of the VBSpam test lab gives us a unique insight into the kinds of emails that are more likely to bypass email filters. This week we look at the malspam that was missed: banking and email phishing, Emotet and Bushaloader.

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.