Announcing the first SHA1 collision

February 24, 2017 – 5:49 AM

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, more than 20 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.


New ASLR-busting JavaScript is about to make drive-by exploits much nastier

February 18, 2017 – 7:01 AM

For a decade, every major operating system has relied on a technique known as address space layout randomization to provide a first line of defense against malware attacks. By randomizing the computer memory locations where application code and data are loaded, ASLR makes it hard for attackers to execute malicious payloads when exploiting buffer overflows and similar vulnerabilities. As a result, exploits cause a simple crash rather than a potentially catastrophic system compromise.

Now, researchers have devised an attack that could spell the end of ASLR as the world knows it now. The attack uses simple JavaScript code to identify the memory addresses where system and application components are loaded. When combined with attack code that exploits vulnerabilities in browsers or operating systems, the JavaScript can reliably eliminate virtually all of the protection ASLR provides. The technique, which exploits what’s known as a side channel in the memory cache of all widely used modern CPUs, is described in a research paper published on Wednesday. The researchers have dubbed the technique ASLR Cache or AnC for short.
“Fundamentally insecure”

The researchers said the side channel attack is much more damaging than previous ASLR bypasses, because it exploits a micro-architectural property of the CPU’s that’s independent of any operating system or application running on it. Whereas heap spraying and other forms of ASLR bypass can often be mitigated by software tweaks, there isn’t much that can stop or lessen the effects of the JavaScript, which targets a CPU’s MMU, or memory management unit. That’s because CPU caching behavior and strong address space randomization are mutually exclusive. (Apple, however, recently hardened its Safari browser to partially mitigate such attacks. It’s also possible to prevent JavaScript from running in a browser, but such blocking often severely degrades a site’s usability.)


This ‘invisible’ memory-based malware is infiltrating organisations across the globe

February 9, 2017 – 4:53 AM

Cybercriminals are launching ‘invisible’ attacks to infiltrate the networks of organisations to steal login credentials and financial data — and the only tool they’re using is legitimate software.

It’s thought that over 140 organisations including banks, telecommunications companies, and government organisations across the globe have fallen victim to these hidden malware attacks.

Discovered by cybersecurity researchers at Kaspersky Lab, the attacks use widely-available tools, including penetration-testing and administration software as well as the PowerShell framework for task automation in Windows, to hide malware in victims’ computer memory, instead of the more traditional tactic of dropping it onto the hard drive.

This form of attack leaves investigators with almost no evidence that an attack took place, and any indication of an incident is removed when the system is rebooted.

The discovery came after Kaspersky Lab was contacted by banks which had found Meterpreter penetration-testing software in the memory of their servers when it wasn’t supposed to be in that location.

Meterpreter had its code combined with legitimate PowerShell scripts and other utilities, with the aim of stealing administrator passwords and remotely controlling machines and systems. All of these factors indicate the attackers are attempting to make off with credentials about financial processes.

This ‘invisible’ method of attack makes it difficult to uncover details about incidents because a lack of traces of hacker activity mean the normal processes of incident response don’t apply.


A Study on Private Browsing: Consumer Usage, Knowledge, and Thoughts

February 3, 2017 – 11:53 AM

At DuckDuckGo, our vision is to raise the standard of trust online. To that end, we strive to understand what people know about online privacy and how they use the privacy features available to them. This report focuses on the feature in web browsers commonly referred to as “Private Browsing.”

“Private Browsing,” “Privacy Mode,” “Secret Mode,” or “Incognito Mode” is a system of web browsing that clears browsing history and file cache after use. Despite Private Browsing being one of the most commonly known and used privacy features, we find that most people misunderstand the privacy protections it provides.

Our findings are based on a survey conducted with a random sampling of 5,710 Americans who were asked to share their experiences with Private Browsing.

Source (pdf download):

Look before you paste from a website to terminal

February 1, 2017 – 4:04 PM

Most of the time when we see a code snippet online to do something, we often blindly copy paste it to the terminal. Even the tech savy ones just see it on the website before copy pasting. Here is why you shouldn’t do this.


Page 6 of 351« First...45678...203040...Last »