/find@mail

Articles, write-ups, and musings concerning the world of cybersecurity and technology.

MD5 Is Broken: A Memo to the Server Admin, and Should You Publish the Code That Broke It?

Simulated Case Studies  · 1,517 words · 8 min read · by QiO:~$ ·

MD5 Is Broken: A Memo to the Server Admin, and Should You Publish the Code That Broke It?

Disclosure: This post is intended to provide education and information through a hypothetical scenario and memo. The additional analysis and opinions are based on real theory, cases and information with documented sources.

MD5 has been broken for signing certificates since 2008. So why was a "fictional" server still using it, and who is to blame when a researcher publishes the code that proves it?

The Scenario

In this exercise, I'm a security tester working on the network of a fictional company. I've found that it configured one of its Windows Server 2019 computers as an enterprise root CA server, and that the server's administrator selected MD5 as the hashing algorithm for creating digital signatures. The assignment: write a one-page memo explaining the vulnerabilities caused by signing certificates with MD5, citing articles about MD5's weaknesses and Microsoft's own recommendations.

The Memo

To: Server Administrator, ARC Inc.
From: InfoSec
Subject: MD5 Hashing Vulnerabilities

During a recent network security test, I discovered that digital signatures were being created using MD5 hashing. Unfortunately, this represents a significant security vulnerability for the following reasons:

  • MD5 is long deprecated. MD5 is not among the hash functions NIST approves (the SHA-2 and SHA-3 families). Microsoft announced its own MD5 certificate deprecation more than a decade ago, in August 2013. Note that Microsoft's block applied to certificates chaining to its trusted root program. Enterprise-issued certificates, like ours, were not affected, "but should still be updated." That means our server won't be rescued by a Windows update. It has to be fixed on purpose.
  • MD5 collisions are not theoretical. MD5 is susceptible to collision attacks, meaning an attacker can generate two different inputs with the same MD5 hash, and that can be used to forge a valid certificate. This has been done. In 2008, researchers built a rogue CA certificate that could impersonate any website, using a CA that still signed with MD5. In 2012, the Flame malware used an MD5 chosen-prefix collision to forge a Microsoft code-signing certificate.
  • MD5 is also unsuitable for passwords, which is a separate problem. Because MD5 is fast and widely precomputed, unsalted MD5 password hashes are easily cracked with rainbow tables, known-password lists, and widely available tools. To see it for yourself, paste this MD5 hash into a lookup site such as CrackStation: 5f4dcc3b5aa765d61d8327deb882cf99. (Cracking passwords and forging certificates are different attacks, but both come from MD5 being too weak.)
  • We have no technical reason to keep it. In the context of the Windows Server 2019 machine in question, it supports SHA-256 and stronger algorithms, provided the CA uses a Key Storage Provider (CNG) rather than a legacy CSP. SHA-2 is a currently approved hashing standard.

To conclude, the continued use of MD5 hashing for credentials or security certificates on any network host represents a serious security flaw. Please review the material above and make any changes necessary to secure the server. I will be happy to assist you if you have any further questions.

Should You Be Allowed to Publish the Code That Breaks It?

Researching MD5, SHA-1, and MD4 turns up a mountain of articles about their weaknesses, and a long list of programs for breaking them. That raises a question about what is moral or legal in releasing information about hashing algorithms, and software that defeats them.

When it comes to these questions, I am a libertarian. I do not believe that security researchers, reporters, journalists, or interested individuals should face punishment for breaking, or releasing software that is capable of defeating, encryption methods. Below, I will explain this position further through the answers to three questions.

Should people who are able to break a hashing algorithm be allowed to post their findings on the Internet?

Yes, absolutely. The reality of the world we live in is that when something as ubiquitous as a hashing or encryption algorithm is cracked or defeated by a private individual or group, one could fairly assume that state sponsors with far more reach and capability have already discovered the method or vulnerability. Google is a large company, but although their resources are vast, they probably aren't as vast as China's military cyber capability. Therefore, if Google were able to crack a currently secure algorithm like AES, it would be very safe to assume state actors like China were already aware. In a case like this (although hypothetical), announcing it to the world would "out" the vulnerability. The worst case scenario in ANY discovered vulnerability is that it remains known only to those who wish to exploit it. Daylight will instantly get the wheels of the global tech community and standards organizations working on mitigations. In this way, I see such publications as a public service.

This isn't just hypothetical. Flame, the state-built malware above, forged its certificate with an MD5 attack that researchers later reverse-engineered and found was different from the publicly known collision techniques. In other words, someone with far more resources was already exploiting a flaw that the public literature didn't fully describe.

Do you think the reporters that report cracking exploits and details are exercising their First Amendment rights when including the source code or procedure for breaking the encryption in an article?

Yes, in most situations I believe this is true. However, I do believe it is only in the case of 0-days in proprietary software that researchers or others have a responsibility to coordinate their publication efforts with the company. Most decent and ethical security researchers will privately inform Apple or Microsoft of a discovered 0-day in advance of publication to allow them time to develop a patch. However, in some cases these corporations have no fix, or are unresponsive in addressing the vulnerability. In this case (as I stated above), the researcher must publish the vulnerability to force the issue into the light, as one can never assume that malicious attackers or state-sponsored threat actors do not know about, and aren't already exploiting, the vulnerability.

As a security professional, do you think you have to abide by a higher standard when sharing or disseminating source code that breaks hashing algorithms? Explain.

Again, as I stated above, I think things like hashing algorithms that are adopted because of standards institutions and are widely used are not the same as finding bugs and exploits in corporate software. With that said, if I personally developed a means to crack a current hashing or encryption standard, I would make attempts to reach out to NIST or CISA for guidance before going public. Though, like I also said before, if those agencies were unresponsive, I would undoubtedly publish the information publicly, because to be sure, others have already found, and are exploiting, the vulnerability for malicious purposes.

A Middle Path, and the Other Side

Real researchers tend to land close to that last answer. When Google and CWI Amsterdam produced the first SHA-1 collision in 2017, they announced the result right away, but said they would wait 90 days before releasing the tool that lets anyone make lookalike PDF pairs. Publishing the finding immediately, and holding the weapon briefly, gave defenders a head start without hiding anything.

The best case against my position is that a published finding and a ready-to-run tool are different things. Critics argue that dropping working code before a fix exists hands a free weapon to attackers who couldn't have built one themselves, which is the reason coordinated disclosure exists. Google's Project Zero, for instance, uses a 90-day deadline as a standard practice rather than publishing instantly.

The law is murkier than either side. The EFF warns that exploit code can raise legal risk (for example under the DMCA's anti-circumvention rules) and that researchers have received legal threats. But in May 2022 the Department of Justice said it would no longer charge good-faith security research under the Computer Fraud and Abuse Act. This isn't legal advice, just a snapshot of where things stand.

The Takeaway

Here's the thing the MD5 story shows. Researchers published MD5 collisions in 2004 and a working rogue CA in 2008, in public, with code. Nobody at "ARC Inc." was harmed by that publication. What puts the company at risk in 2025 is that nobody migrated. The disclosure did its job, and the warning has been sitting on the internet for over fifteen years. Publishing a break is rarely the dangerous act. Ignoring it is.

Sources

Read next

Field Notes: Finding the OS with Nmap