Previous posts (part1 and part2) by Markus Vervier (@marver) and myself (@veorq) were about the Java code base and the Android client, now we’ll discuss two bugs potentially affecting users of libsignal-protocol-c, the C implementation of the Signal protocol. More precisely, we identified bugs in the example callback functions used in the unit tests of the library. However, users of the library will need to define their own callbacks and will likely take the code from the unit tests as an example, as the library documentation suggests.
One of the bugs will occur on 64-bit systems, the other bug will occur on 32-bit systems. Both will trigger a SIGSEV, and the second potentially leads to an heap overflow.
Both bugs have been rapidly patched by Open Whisper Systems, as well as a few benign potential null dereferences in serialization library functions.
IMPORTANT: the Signal mobile applications don’t actually use the C implementation of the Signal protocol, and therefore cannot be affected by the bugs discussed in this post. WhatsApp does use this C lib, but allegedly does not use the same callbacks as the example ones where we found the bugs. Therefore WhatsApp doesn’t seem to be affected either.
Call it machine learning, AI, advanced data analytics, or data mining. It all boils down to looking at datasets and finding patterns that tell you something you didn’t know. For example that your average revenue per customer is $192, that the number of intrusion attempts on your network correlates with your number of tweets, or that log entries can be grouped around three cluster centroids.
Your management and customers will focus on the sexy part—the buzzwords and the sophisticated-sounding techniques: support vector machines, deep learning, etc.—but if you’ve already been in this business you’ll know that the actual job is usually 80% boring, with tasks such as
- Figuring out how to convert data from obscure-format X to standardish format Y.
- Decluttering the dataset, fixing misformatted entries, dealing with missing values, and all the data preparation and cleaning steps.
- Finding the right tools for the job and learning how to use them. Maybe you’re joining a team that’s using different tools than the ones you’re used to, or the customer wants you to use this tool they have a license for.
This post is about the last point, tools. I’m not going to explain classification and regression, how to manage your data analysis project, or how to make visualizations that will look impressive in your powerpoint slides.
This post is for readers who 1) are not data scientists, 2) don’t have money to spend on consultants or software licenses, and would rather use free and open-source solutions. If you have the budget, those may be a better option—you’ll learn from experts and you’ll get technical support. Finally, I’ll just assume that, like everyone, you know Python.
Last summer I took some time to finally learn about Z3 as I was solving some crackme (see Using Z3 to solve crackme) but in order to stay true to my hipster reputation I had to try something cooler this year: angr. This tool has already been used numerous times during CTF but rarely with a detailed explanation of what was happening. The documentation is really well written and reading the examples will help you while running into most problems you might face.
I will explain some concepts of angr and its basic usage through examples in this post. All samples and scripts from this post can be found on my github. Continue reading
Greetings from Vegas! Luis and I just gave our Black Hat talk SGX Secure Enclaves in Practice: Security and Crypto Review. It’s the first public report about Intel’s Software Guard Extensions (SGX) based on actual SGX hardware and on Intel’s software development toolchain for Windows and Linux. We showed some undocumented parts of SGX and we released some open-source software as well as a companion paper. All our material is online:
Get in touch with us if you have any question (@veorq, @iamcorso).
Thanks to the Kudelski Security marketing team for their support!
Unmanned Aerial Vehicles (UAVs) offer new perspectives, both from a civilian and a military standpoint; yet, they present vulnerabilities having the potential to lead to disastrous consequences regarding public safety if exploited successfully, as evidenced by recent hacks. These repercussions can be prevented by implementing best practices, continuously assessing the technologies used and most importantly by remaining aware of the environment, of the weaknesses that may be exploited and of the threats that may emerge. The purpose of this article is not to provide countermeasures or solutions, but to outline flaws and vulnerabilities to better understand and address potential threats and threat actors.
Figure 1 UAVs hacks disclosure timeline
As shown by recent hacks, several professional Unmanned Aerial Vehicles (UAV) used byarmed forces, governments, police departments and the private sector are vulnerable to critical attacks which exploit both technical vulnerabilities and design flaws. This can lead to UAVs being spied on, made inoperable or controlled by the attacker unbeknownst to the UAV’s owner. Continue reading
In this simple challenge, we’re given the binary of a remote service:
$ file baby-re
baby-re: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not
This asks for 13 inputs, and then returns `Wrong`, unless we give it
the right input.
I recently attended the TROOPERS conference, held in Heidelberg, Germany. A lot of interesting research was presented, in this blog post I’m going to summarize selected talks that I particularly enjoyed.
The first presentation was by Philippe Teuwen, where he demonstrated his latest attack on white-box cryptography. The idea is to apply existing hardware attacks such as side-channel or fault attacks in order to break white-box cryptography implementations. For example, a simple DPA can be applied to software execution traces to reveal the key with only 16 traces. This approach is really efficient since all publicly available challenges can be broken and this could expose, for example, the incoming Host Card Emulation systems (HCE). In addition, Philippe released all his tools as open source on his GitHub account, allowing everyone to experiment with these attacks. He also posted the instructions on how to use the software on the Insinuator blog. Continue reading