Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

News & Commentary

3/7/2017
04:00 PM
Elad Menahem
Elad Menahem
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Googles SHA-1 Countdown Clock Could Undermine Enterprise Security

In the wake of a recently documented 'collision' attack, Google researchers should consider delaying the release of the code behind the crack until companies can roll out adequate patches. Here's why

The recent announcement from Google that researchers documented a collision with theSecure Hash Algorithm 1 (SHA-1) cryptographic hash function has enormous implications for the IT industry.

Whether it’s file reputation and whitelisting services or browser security, SHA-1 plays a critical role in today’s IT infrastructure. The algorithm allows, for, among other things, unique identification of datasets. Many content and file whitelisting vendors rely heavily on SHA-1 to distinguish between benign and malicious content.

The same is true for file reputation services. Within storage, vendors have used the algorithm to identify duplicate files. The algorithm is also used for digital signatures and file integrity verification, which secure credit card transactions, electronic documents, GIT open-source software repositories and software distribution.

From a security perspective, having datasets hash to the same SHA-1 digest (what’s called a “collision”), undermines the safety of the algorithm. Attackers could potentially create a malicious file with the same hash as a benign file, bypassing current security measures.

Equally alarming, though, is Google’s conduct in this manner. Google researchers say that they will publish the code - not merely a paper - enabling someone to create two PDF files with identical SHA-1 hashes within 90 days in accordance with the vulnerability policy practice by Project Zero, Google’s security and vulnerability research team. They have also released a tool that checks whether a file is vulnerable for collisions.

Time is of the Essence
The scale and severity of the problem may well require more than the 90 days for most vendors to publish patches, and for customers to apply them. SHA-1 is so widely deployed that it will take far too long to make the necessary infrastructural changes across every relevant product in the network.  

Obviously, we don’t know the details of the exact code Google will release in 90 days, but we are concerned that any code could accelerate the creation of a successful SHA-1 attack. Currently, most hackers are unlikely to reproduce the attack, if only because of the significant cost of the computational power needed to crack SHA-1.

A vendor’s ability to eliminate SHA-1 support will depend on several factors, including:

  • The product architecture
  • How the vendor managed the file hash database
  • How much the vendor depends on a specific hashing algorithm
  • Whether it’s easy to make the code change

This definitely will not be a quick fix for some vendors. While service providers will not face as many challenges as appliance vendors, thanks to the speed of service updates, it is unfair to force enterprises into a race to beat a Google-created SHA-1 countdown clock.

Rather, Google should provide a paper describing the attack in 90 days, and then release the code at a later date. This deviates from Google’s normal practice, but the mere documentation of a SHA-1 collision will be sufficient to accelerate the change to a better hashing algorithm.

“Told You So” is Not the Answer
Google’s blog seems to anticipate some of these issues by pointing out that they’ve long called for the elimination of SHA-1: “For the tech community, our findings emphasize the necessity of sun setting SHA-1 usage. Google has advocated the deprecation of SHA-1 for many years, particularly when it comes to signing TLS certificates,” according to the blog.

In fact, Google is hardly unique in its wish to eliminate SHA-1. In 2005, cryptanalysts first suggested that SHA-1 may not be secure enough for ongoing use, and since 2010 many organizations have recommended its replacement by SHA-2 or SHA-3. Further, Microsoft, Apple, Mozilla and Google have all announced that their respective browsers will stop accepting SHA-1 SSL certificates by 2017.

But the business of IT has always been about prioritizing the here-and-now over tomorrow. Companies try to maximize their resources by bringing products to market - not with every possible feature, but just the right features at the right time. Until now, SHA-1’s theoretical limitations have made replacing the algorithm a “to be” feature rather than an immediate concern. There had not yet been a practical SHA-1 collision, leaving vendors to continue using the algorithm as a hashing function.

What You Can Do
CISOs and their teams should immediately ask security vendors about their plans for replacing SHA-1. They should also implement plans to patch or update their systems to the latest revision.

All network and endpoint security vendors using whitelisting mechanisms for files should rely on a more secure hashing algorithm, such as SHA-256 or SHA-3, not  SHA-1.  Vendors should align their databases with the new hashes respectively.

Finally, enterprises will want to be sure that their vendors do not work with third-party resources, such as reputation services, that rely on SHA-1 or MD5, an even older, more insecure hashing algorithm.

Google has an aggressive approach to teaching vendors about security. We've seen this in several of the latest Project Zero publications and we see it in this issue. Google has long advocated for the depreciation of SHA-1; releasing the code now will assuredly achieve that aim.

Related Content:

 

Elad Menahem is the head of security research at Cato Networks, a disruptive cloud-based enterprise platform with a mission to make networking and security simple again. Elad served in an elite tech unit in the Israel Defense Forces (IDF) Intelligence Corps, and has more than ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Shantaram
50%
50%
Shantaram,
User Rank: Ninja
3/12/2017 | 3:07:00 PM
Re: 192.168.l.l
Well-written and interesting post. Thanks
pdp11hacker01
50%
50%
pdp11hacker01,
User Rank: Apprentice
3/7/2017 | 8:44:52 PM
Publishing the code is a non-issue
Publishing the code is a non-issue.  The code can't be used directly to forge certificates--that would be a serious practical improvement over what they have done.  Anyone who can make that improvement should also be able to re-create the code based on the paper.  Looking at it a different way: the attack is estimated to cost well over $100k to execute.  Anyone who can afford to execute the attack can afford to pay a grad student to read the paper and write the code.
How Attackers Infiltrate the Supply Chain & What to Do About It
Shay Nahari, Head of Red-Team Services at CyberArk,  7/16/2019
US Mayors Commit to Just Saying No to Ransomware
Robert Lemos, Contributing Writer,  7/16/2019
The Problem with Proprietary Testing: NSS Labs vs. CrowdStrike
Brian Monkman, Executive Director at NetSecOPEN,  7/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-12551
PUBLISHED: 2019-07-22
In SweetScape 010 Editor 9.0.1, improper validation of arguments in the internal implementation of the Memcpy function (provided by the scripting engine) allows an attacker to overwrite arbitrary memory, which could lead to code execution.
CVE-2019-12552
PUBLISHED: 2019-07-22
In SweetScape 010 Editor 9.0.1, an integer overflow during the initialization of variables could allow an attacker to cause a denial of service.
CVE-2019-3414
PUBLISHED: 2019-07-22
All versions up to V1.19.20.02 of ZTE OTCP product are impacted by XSS vulnerability. Due to XSS, when an attacker invokes the security management to obtain the resources of the specified operation code owned by a user, the malicious script code could be transmitted in the parameter. If the front en...
CVE-2019-10102
PUBLISHED: 2019-07-22
tcpdump.org tcpdump 4.9.2 is affected by: CWE-126: Buffer Over-read. The impact is: May expose Saved Frame Pointer, Return Address etc. on stack. The component is: line 234: "ND_PRINT((ndo, "%s", buf));", in function named "print_prefix", in "print-hncp.c". Th...
CVE-2019-10102
PUBLISHED: 2019-07-22
aubio 0.4.8 and earlier is affected by: null pointer. The impact is: crash. The component is: filterbank. The attack vector is: pass invalid arguments to new_aubio_filterbank. The fixed version is: after commit eda95c9c22b4f0b466ae94c4708765eaae6e709e.