Frank Abagnale is world-famous for pretending to be other people. The former teenage con-man, whose exploits 50 years ago became a Leonardo DiCaprio film called Catch Me If You Can, has built a lifelong career as a security consultant and advisor to the FBI and other law enforcement agencies. So it's perhaps ironic that four and a half years ago, his identity was stolen—along with those of 3.6 million other South Carolina taxpayers.
"When that occurred," Abagnale recounted to Ars, "I was at the FBI office in Phoenix. I got a call from [a reporter at] the local TV news station, who knew that my identity was stolen, and they wanted a comment. And I said, 'Before I make a comment, what did the State Tax Revenue Office say?' Well, they said they did nothing wrong. I said that would be absolutely literally impossible. All breaches happen because people make them happen, not because hackers do it. Every breach occurs because someone in that company did something they weren't supposed to do, or somebody in that company failed to do something they were supposed to do." As it turned out (as a Secret Service investigation determined), a government employee had taken home a laptop that shouldn't have left the office and connected it—unprotected—to the Internet.
Government breaches of personal information have become all too common, as demonstrated by the impact of the hacking of the Office of Management and Budget's personnel records two years ago. But another sort of organization is now in the crosshairs of criminals seeking identity data to sell to fraudsters: doctors' offices. Abagnale was in Orlando this week to speak to health IT professionals at the 2017 HIMSS Conference about the rising threat of identity theft through hacking medical records—a threat made possible largely because of the sometimes haphazard adoption of electronic medical records systems by health care providers.
For more than six years, the SHA1 cryptographic hash function underpinning Internet security has been at death's door. Now it's officially dead, thanks to the submission of the first known instance of a fatal exploit known as a "collision."
Despite more than a decade of warnings about the lack of security of SHA1, the watershed moment comes as the hash function remains widely used. Git, the world's most widely used system for managing software development among multiple people, relies on it for data integrity. The GnuPG e-mail encryption program still deems SHA1 safe. And hundreds if not thousands of big-name software packages rely on SHA1 signatures to ensure installation and update files distributed over the Internet haven't been maliciously altered.
A collision occurs when the two different files or messages produce the same cryptographic hash. The most well-known collision occurred sometime around 2010 against the MD5 hash algorithm, which is even weaker than SHA1. A piece of nation-sponsored espionage malware known as Flame used the attack to hijack the Windows update mechanism Microsoft uses to distribute patches to hundreds of millions of customers. By forging the digital signature used to cryptographically prove the authenticity of Microsoft servers, Flame was able to spread from one infected computer to another inside targeted networks.
Whether it is rebuilding a car engine or diagramming a sentence, people can learn about many things simply by taking them apart and putting them back together again. This process of breaking something down to understand it, build a copy to improve it, is known as reverse engineering. The process of reverse engineering was originally […]
The post Top 8 Reverse Engineering Tools for Cyber Security Professionals appeared first on InfoSec Resources.
Cryptographic hash functions like SHA-1 are a cryptographer’s swiss army knife. You’ll find that hashes play a role in browser security, managing code repositories, or even just detecting duplicate files in storage. Hash functions compress large amounts of data into a small message digest. As a cryptographic requirement for wide-spread use, finding two messages that lead to the same digest should be computationally infeasible. Over time however, this requirement can fail due to attacks on the mathematical underpinnings of hash functions or to increases in computational power.
Today, 10 years after of SHA-1 was first introduced, we are announcing the first practical technique for generating a collision. This represents the culmination of two years of research that sprung from a collaboration between the CWI Institute in Amsterdam and Google. We’ve summarized how we went about generating a collision below. As a proof of the attack, we are releasing two PDFs that have identical SHA-1 hashes but different content.
For the tech community, our findings emphasize the necessity of sunsetting SHA-1 usage. Google has advocated the deprecation of SHA-1 for many years, particularly when it comes to signing TLS certificates. As early as 2014, the Chrome team announced that they would gradually phase out using SHA-1. We hope our practical attack on SHA-1 will cement that the protocol should no longer be considered secure.
We hope that our practical attack against SHA-1 will finally convince the industry that it is urgent to move to safer alternatives such as SHA-256.
What is a cryptographic hash collision?
A collision occurs when two distinct pieces of data—a document, a binary, or a website’s certificate—hash to the same digest as shown above. In practice, collisions should never occur for secure hash functions. However if the hash algorithm has some flaws, as SHA-1 does, a well-funded attacker can craft a collision. The attacker could then use this collision to deceive systems that rely on hashes into accepting a malicious file in place of its benign counterpart. For example, two insurance contracts with drastically different terms.
Finding the SHA-1 collision
In 2013, Marc Stevens published a paper that outlined a theoretical approach to create a SHA-1 collision. We started by creating a PDF prefix specifically crafted to allow us to generate two documents with arbitrary distinct visual contents, but that would hash to the same SHA-1 digest. In building this theoretical attack in practice we had to overcome some new challenges. We then leveraged Google’s technical expertise and cloud infrastructure to compute the collision which is one of the largest computations ever completed.
Here are some numbers that give a sense of how large scale this computation was:
- Nine quintillion (9,223,372,036,854,775,808) SHA1 computations in total
- 6,500 years of CPU computation to complete the attack first phase
- 110 years of GPU computation to complete the second phase
While those numbers seem very large, the SHA-1 shattered attack is still more than 100,000 times faster than a brute force attack which remains impractical.
Mitigating the risk of SHA-1 collision attacks
Moving forward, it’s more urgent than ever for security practitioners to migrate to safer cryptographic hashes such as SHA-256 and SHA-3. Following Google’s vulnerability disclosure policy, we will wait 90 days before releasing code that allows anyone to create a pair of PDFs that hash to the same SHA-1 sum given two distinct images with some pre-conditions. In order to prevent this attack from active use, we’ve added protections for Gmail and GSuite users that detects our PDF collision technique. Furthermore, we are providing a free detection system to the public.
You can find more details about the SHA-1 attack and detailed research outlining our techniques here.
About the team
This result is the product of a long-term collaboration between the CWI institute and Google’s Research security, privacy and anti-abuse group.
Marc Stevens and Elie Bursztein started collaborating on making Marc’s cryptanalytic attacks against SHA-1 practical using Google infrastructure. Ange Albertini developed the PDF attack, Pierre Karpman worked on the cryptanalysis and the GPU implementation, Yarik Markov took care of the distributed GPU code, Alex Petit Bianco implemented the collision detector to protect Google users and Clement Baisse oversaw the reliability of the computations.
Introduction It has been a few days since I discovered a great tool called Wuzz which is a Command Line Interface tool for HTTP inspection. His author, asciimoo, has done a really good job with this. Security Researchers mainly use this tool during assessments to have a better view of what is going on with […]