Connect with us

Security

SHA-1 collision attacks are now actually practical and a looming danger

Published

on

Attacks on the SHA-1 hashing algorithm just got a lot more dangerous last week with the discovery of the first-ever “chosen-prefix collision attack,” a more practical version of the SHA-1 collision attack first carried out by Google two years ago.

What this means is that SHA-1 collision attacks can now be carried out with custom inputs, and they’re not just accidental mishaps anymore, allowing attackers to target certain files to duplicate and forge.

SHA-1 collision attacks

The SHA-1 hashing function was theoretically broken in 2005; however, the first successful collision attack in the real world was carried out in 2017.

Two years ago, academics from Google and CWI produced two files that had the same SHA-1 hash, in the world’s first ever SHA-1 collision attack –known as “SHAttered.”

Cryptographers predicted SHA-1 would be broken in a real-world scenario, but the SHAttered research came three years earlier than they expected, and also cost only $110,000 to execute using cloud-rented computing power, far less than what people thought it might cost.

2017-02-24.png

Image: Google

SHA-1 chosen-prefix attacks

But last week, a team of academics from France and Singapore has taken the SHAttered research one step further by demonstrating the first-ever SHA-1 “chosen-prefix” collision attack, in a new research paper titled “From Collisions to Chosen-Prefix Collisions – Application to Full SHA-1.”

“Finding a practical collision attack breaks the hash function badly of course, but the actual damage that can be done with such a collision is somewhat limited as the attacker will have little to no control on the actual data that collides,” Thomas Peyrin, one of the researcher told ZDNet via email over the weekend.

“A much more interesting attack is to find a so-called ‘chosen-prefix collision,’ where the attacker can freely choose the prefix for the two colliding messages. Such collisions change everything in terms of threat because you can now consider having collisions with meaningful data inside (like names or identities in a digital certificate, etc).”

What this means is that SHA-1 collision attacks aren’t a game of roulette anymore, and now, threat actors can forge any SHA-1-signed documents they want, ranging from business documents to TLS certificates.

SHA-1 chosen-prefix collision attacks are now also cheap

But the work of Peyrin and his colleague –Gaetan Leurent– have done goes far beyond than proving SHA-1 chosen-prefix collision attacks are theoretically possible.

They also showed that such attacks are now cheap and in the budget of cybercrime and nation-state attackers.

“These chosen-prefix collisions are believed to be much harder to find than classical collisions. For SHA-1, the best previous search method required 2^77 SHA-1 evaluations, which remained out of reach in practice,” Peyrin told ZDNet.

“The novelty in our article is that we explain how to drastically reduce the cost of finding chosen-prefix collisions for SHA-1, down to almost the same cost as finding a classical collision,” he said.

“We are currently working on further improvements (unpublished yet), and we evaluate now that one can find a chosen-prefix collision for SHA-1 with a budget of less than $100,000, which is really practical.”

This is about the same cost as the original SHAttered research, yet, this version of the attack is what attackers would likely use if they’d ever want to attack SHA-1-protected data.

“We have tested all subcomponents of the attack, but we have not tried to compute a chosen-prefix collision example,” Peyrin said.

“Our initial estimations were $1 million to compute the chosen-prefix collision, which is an amount of money we simply don’t have. Thanks to our latest improvements, the cost went down below $100,000 and we are currently working on computing the first chosen-prefix collision for SHA-1.

“Hopefully, we will be able to announce new results soon,” the researcher said.

Moving away from SHA-1

Browser vendors have long ago started deprecating support for SHA-1-signed TLS traffic inside their products; however, other applications still rely on it.

“There are still many users with older browsers and many protocols and software that allow SHA-1 signatures. Concretely, it is still possible to buy an SHA-1 certificate from a trusted CA, and many email clients accept an SHA-1 certificate when opening a TLS connection,” Peyrin told us.

“SHA-1 is also widely supported to authenticate TLS and IKE handshake messages. Now, what protocol can be attacked and to what extent is hard to tell at the moment, because it needs careful scrutiny of the inner working of the protocol and how the digital signatures / certificates are used, etc..

“However, what we can say is that our attack put at possible risk products using digital signatures, or certificates based on SHA-1,” Peyrin said.

“The take-home message should really be that using SHA-1 for digital
signatures or certificates is very dangerous, and should not be allowed. People doing so are strongly advised to change to SHA-2 or SHA-3 now.”

What to use?

“The attacks against SHA-1 are only going to get better,” Scott Arciszewski, Chief Development Officer at Paragon Initiative Enterprises, and a leading cryptographer, told ZDNet in a separate email.

“Everyone should switch to (in order of preference):

  • BLAKE2b / BLAKE2s
  • SHA-512/256
  • SHA3-256
  • SHA-384
  • Any other SHA2-family hash function as a last resort

“…unless they’re storing passwords! In which case, they should switch to (in order of preference):

  • Argon2id with memory >= 32MiB, >= 2 rounds, and >= 2 parallelism
  • scrypt / yescrypt with memory >= 32 MiB, >= 4 rounds, and >= 1 parellelism
  • bcrypt (for PHP devs, password_hash() and password_verify() does the trick)
  • PBKDF2-SHA512 with 85,000 iterations as a last resort

“But SHA1 should no longer be used anymore. No excuses,” Arciszewski said.

Related cybersecurity coverage:



Source link

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Security

Managing Vulnerabilities in a Cloud Native World

Published

on

This free 1-hour webinar from GigaOm Research brings together experts in Cloud Native Vulnerability Management, featuring analyst Iben Rodriguez and special guest from Palo Alto Networks, John Morello. The discussion will focus on optimizing cloud security posture and integration with enterprise tool sets.

We will review platforms delivering Security Posture Management and Workload Protection for Microservice based and Hybrid Cloud Workloads.

Registrants will learn how new customers can benefit from Prisma Cloud to better secure their complex multi-cloud environments. Existing customers will learn about new features they can take advantage of and how to optimize their limited resources.

Register now to join GigaOm and Palo Alto Networks for this free expert webinar.

The post Managing Vulnerabilities in a Cloud Native World appeared first on Gigaom.

Continue Reading

Security

Security Tools Help Bring Dev and Security Teams Together

Published

on

Software development teams are increasingly focused on identifying and mitigating any issues as quickly and completely as possible. This relates not only to software quality but also software security. Different organizations are at different levels when it comes to having their development teams and security teams working in concert, but the simple fact remains that there are far more developers out there than security engineers.

Those factors are leading organizations to consider security tooling and automation to proactively discover and resolve any software security issues throughout the development process. In the recent report, “GigaOm Radar for Developer Security Tools,” Shea Stewart examines a roundup of security tools aimed at software development teams.

Stewart identified three critical criteria to bear in mind when evaluating developer security tools. These include:

  • Vendors providing tools to improve application security can and should also enhance an organization’s overall security posture.
  • The prevailing “shift-left” mindset doesn’t necessarily mean the responsibility for reducing risk should shift to development, but instead focusing on security earlier in the process and continuing to do so throughout the development process will reduce risk and the need for extensive rework.
  • Security throughout the entire software development lifecycle (SDLC) is critical for any organization focused on reducing risk.

Figure 1. How Cybersecurity Applies Across Each Stage of the Software Development Lifecycle *Note: This report focuses only on the Developer Security Tooling area

Individual vendors have made varying levels of progress and innovation toward enhancing developer security. Following several acquisitions, Red Hat, Palo Alto Networks, and Rapid7 have all added tooling for developer security to their platforms. Stewart sees a couple of the smaller vendors like JFrog and Sonatype as continuing to innovate to remain ahead of the market.

Vendors delving into this category and moving deeper into “DevSecOps” all seem to be taking different approaches to their enhanced security tooling. While they are involving security in every aspect of the development process, some tend to be moving more quickly to match the pace of the SDLC. Others are trying to shore up existing platforms by adding functionality through acquisition. Both infrastructure and software developers are now sharing toolsets and processes, so these development security tools must account for the requirements of both groups.

While none of the 12 vendors evaluated in this report can provide comprehensive security throughout the entire SDLC, they all have their particular strengths and areas of focus. It is therefore incumbent upon the organization to fully and accurately assess its SDLC, involve the development and security teams, and match the unique requirements with the functionality provided by these tools. Even if it involves using more than one at different points throughout the process, focus on striking a balance between stringent security and simplifying the development process.

Read more: Key Criteria for Evaluating Developer Security Tools, and the Gigaom Radar for Developer Security Tool Companies.

The post Security Tools Help Bring Dev and Security Teams Together appeared first on Gigaom.

Continue Reading

Security

Key Criteria for Evaluating User and Entity Behavior Analytics (UEBA)

Published

on

Cybersecurity is a multidisciplinary practice that not only grows in complexity annually but evolves nearly as quickly. A survey of the security landscape today would reveal concerns ranging from the classic compromised servers to the relatively new DevSecOps practices aimed at securing the rapid deployment of new code and infrastructure. However, some things remain constant no matter how much change is introduced. While technology evolves and complexity varies, there is almost always a human component in
risks presented to an organization.

User Behavior Analysis (UBA) was designed to analyze the actions of users in an organization and attempt to identify normal and abnormal behaviors. From this analysis, malicious or risky behaviors can be detected. UBA solutions identify events that are not detectable using other methods because, unlike classic security tools (an IDS or SIEM for example), UBA does not simply pattern match or apply rule sets to data to identify security events. Instead, it looks for any and all deviations from baseline user activity.

As technology advanced and evolved, and the scope of what is connected to the network grew, the need to analyze entities other than users emerged. In response, entity analysis has been added to UBA to create UEBA or User and Entity Behavior Analysis. The strategy remains the same, but the scope of analysis has expanded to include entities involving things like daemons, processes, infrastructure, and so on.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

The post Key Criteria for Evaluating User and Entity Behavior Analytics (UEBA) appeared first on Gigaom.

Continue Reading

Trending