Recently I gave a two-hour workshop about power attacks at PHDays conference. After the workshop, I understood that two hours are not enough to present and explain power attacks to people who never worked with Side Channel Analysis before. Luckily, I was invited to give a 4-hour workshop at ZeroNights, so I would like to make a series of posts to explain power analysis attacks in a better way and then use these posts (and, hopefully, comments) to improve my workshop at the forthcoming conference. I will try to make high-level yet detailed enough explanations, otherwise the workshop may require more time.
Power attacks is a group of Side Channel Attacks that analyze devices’ power consumption to:
- extract binary data; for example, secret keys of cryptographic algorithms;
- understand timing of a particular operation;
- dump the opcode values (Side Channel Based Reverse Engineering.
This looks unrealistic but statistical methods applied in Side Channels can distinguish a bit switch 1 to 0 from a bit switch 0 to 1. Since these operations can be distinguished, an attacker can extract processed binary data and get confidential information.
This post explains the very basics of power attacks, namely, when digital circuit consumes power, how power consumption can be modeled and thus used to reveal algorithms’ data. At the end of the post I will explain how power traces measured during DES execution can be analyzed to get the correct 6 bits of a DES round key. Some of the Side Channel Attack properties were discussed in the previous post ‘Timing attacks – Part 1′, so I encourage you to read that post first. Continue reading
In May I attended Positive Hack Days, a.k.a. PHDays, in Moscow. This is one of the three largest security events taking place in Russia. PHDays included a conference, Capture the Flag competition, workshops, hands-on activities, roundtables, investment proposal presentations, etc. Attendees from different countries and various security domains presented their results and shared their knowledge with approximately 2,000 visitors (the event was taking place during two days). In this post I would like to highlight several observations and insights that could be of interest to you.
The video of all the talks can be found here and presentations here.
The talks were given in parallel at four different halls, so I could not attend all of them. From the talks I saw I would like to select the following presentations for a mention in this post:
- Smart TV Insecurity by Donato Ferrante and Luigi Auiremma. The presentation showed that an attacker can have root access or dump the entire application code of modern TVs.
- My Journey Into 0-Day Binary Vulnerability Discovery in 2014 by Alice Schevchenko. I was pleasantly surprised. Twice. Firstly, I was surprised to discover Alice’s business acumen and her personality, since I have not met many women in the reverse engineering and fuzzing software field who are founders of their own companies. Secondly, I was surprised by the fact that there are plenty of 0-day vulnerabilities in binaries even in the latest software from the biggest companies.
Bus Pirate v3
The Bus Pirate is an open source electronic circuit developed by Dangerous Prototypes. They also sell it at minimal cost. The Bus Pirate allows the communication between a PC with a USB connection and any chips through serial protocols like I²C and SPI. Recently I discovered that the Bus Pirate is JTAG capable.
A large community is using this device for diverse things like repairing devices, and recently it was used during a challenge at Insomni’hack CTF to communicate to a MSP430 microcontroller and exploit a software buffer overflow on this architecture. I explain below how to communicate with, and upgrade the Bus Pirate and how to use it with OpenOCD software to debug chips. Continue reading
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: