Co-authored by meatwad and @bl4ckt0ts
In the context of the OpenSSL Heartbleed vulnerability we started to scan the whole IPv4 Internet. The goal was to understand how many machines were impacted but also to measure the rate at which vulnerable systems are patched.
The OpenSSL library is broadly used to provide SSL and TLS support. For example, mod_ssl is an interface to OpenSSL for Apache HTTP Server to serve web pages over HTTPS. Another example is courier-IMAP, which is also able to rely on OpenSSL to deliver IMAP over SSL services.
For that exercise we focus on looking for HTTPS servers vulnerable to Heartbleeed. We thus scanned four days in a row the whole routable IPv4 Internet on port 443. Every time the port was open, we initiated an HTTPS handshake. Upon success, we checked the service for the Heartbleed vulnerability by sending a heartbeat packet with a crafted size. That allowed us to spot vulnerable systems.
What we found is that there are around 30 million machines answering to HTTPS requests on port 443. Of these 30 million, about 1.5 million are vulnerable to Heartbleed.
|Vuln to Heartbleed
The good news is that sys admins were patching, even over the weekend :)
The bad news is that if the patching rate does not increase, we’ll never have a Heartbleed-free Internet. Let see how it’s going to evolve over the next few days.
Edit: The graph scale was changed to go down to zero.
Since Monday, April 7, the Internet is being rocked by the news about Heartbleed (CVE_2014- 0160), a serious vulnerability in the popular OpenSSL crypto library.
Our friends from Kudelski Security’s advanced threat intelligence unit provided a quick and easy “Heartbleed in a Nutshell” infosheet (summarizing findings on the topic from open sources) on what this bug’s discovery means for the users of HTTPS servers, and recommendations on what should be the very first steps for risk mitigation. The file is available for download from the link below:
NORX is a new cipher designed by Philipp Jovanovic, Samuel Neves, and yours truly (in this order). NORX’ features make it superior to legacy algorithms like the AES standard. For example it offers
Authentication: NORX protects not only the confidentiality (secrecy) of a message, but also its integrity. For comparison, AES requires complex constructions such as Galois Counter Mode (GCM) to protect integrity.
Parallelism: NORX can be executed in parallel on multiple cores, as found in modern CPU architectures. For example, if 4 cores are available then NORX is about 4 times as fast as with a single core, whereas legacy ciphers are generally designed for serial processing.
Simplicity: To understand NORX and implement it, you don’t need to understand math notions such as finite fields or polynomials. The only operations in NORX are bitwise AND, XOR and bit shifting. These operations are readily available as instructions on all CPUs, and straightforward to implement in dedicated hardware.
Interoperability: Developers often have to determine a structure to represent inputs and outputs of a cipher, which reduces interoperability across implementations and may even affect security. NORX thus defines a dedicated datagram to represent multiple data items as a single byte string.
Side-channel robustness: Whereas AES suffers from timing leaks and requires complex countermeasures, NORX was designed to run in constant time on any reasonable platform, and only uses operations that can be protected from side-channel leaks.
NORX’ site norx.io contains specifications and reference source code. The NORX code is also available on GitHub, and support the NEON and SSE family of instruction set extensions.
Before further details on NORX, I’ll briefly present our initial motivation: the CAESAR competition.
This year's Insomni'hack CTF was even better than the previous years, with a higher level both on the challenges side and on the participating teams side. The excellent Dragon Sector finished first, followed by StratumAuhuur, HackingForBeers, More Smoked Leet Chicken, and int3pids. Scores details can be found on CTFtime.
This year I played in the one-shot HackingForBeers team, with a couple of friends who like me happened to be teamless for that CTF. I'd like to thank them for the fun, as well as all the other participants, and the staff from SCRT for the effort they put in making this happen.
My first CTF writeup won't be on a very difficult challenge, though no team managed to solve it after 10 hours of CTF. Our team spent quite some time on it, and we were frustrated to feel so close to the solution. I later asked the organizers for some hints, and finally managed to solve it! (I would've never found without hints though.) Here's how it goes:
This week I was in San Francisco to attend the RSA Conference, where I gave and attended a couple of talks, met some old and new friends, walked around the exhibition hall, and enjoyed this amazing city. Here’s some highlights:
A few weeks ago, we received a request to publish an article on behalf of an author residing in China. After review of its content, we are sharing these insights on the CyberSmashup blog.
We hope you enjoy this post, learn something new about privacy and censorship, and if feeling compelled to respond or react, will not hesitate to post a comment, or contact us to contribute your opinion in a form of a blog post.
On December 12-13, I attended The TRUDEVICE workshop in Freiburg. There, experts in hardware security from various domains met to discuss methods to increase the hardware security of integrated circuits. Below I present some of the subjects which I found most interesting.
One of the topics concerned the detection of hardware Trojans and more generally checking the integrity of integrated circuits. A European project called HINT was launched in 2012 to find solutions to this problem and to create a common framework to verify a system’s integrity. Initial results from this project were presented at TRUDEVICE by Julien Francq from CASSIDIAN.
Although the universe of hardware Trojan possibilities is diverse, they managed to identify two main solutions for their detection: Logic scanning and side channel leakage comparisons. Functional logic scanning is not well adapted for identifying Trojans, as they are likely to be designed to not alter the functional behavior. A statistical approach was proposed targeting the rare events of a circuit which may contain the Trojan features. A circuit containing a Trojan should have a different current consumption and electromagnetic emission profile. This means that side channel analysis could help to identify tampered hardware. The main problem of this approach is that you must own at least one hardware implementation without any Trojan to have reference traces. Three other presentations were dedicated to hardware Trojan detection and insertion during this workshop. Continue reading