Attacking IoT is really easy

A few days ago, Metasploit has announced that their famous tool is now available to car hackers, and soon for any connected object.

Metasploit is a well-known tool for web apps, and extending it to objects simply makes these objects as easy to hack as web apps. Indeed, there are many aspects in common between a Web App and a Connected Object: they can be reached from internet, they run complex software, they can be targeted by ransomware, and they can be misused.

Then, there are differences, and these differences make objects easier to hack than web apps. The most commonly cited is the lack of supervision of connected objects. This has allowed the creation of very large botnets of connected objects, and will most likely continue and worsen in the next few years, because few people realize that their fridge is in a botnet.

There is another difference, more subtle, but with great consequences on security: the objects’ availability. When targeting a web app, an attacker may know some of the software that has been used to build the app. He may even be aware of some vulnerabilities in this software. However, the attacker will know nothing of the product’s configuration, or of the security products and countermeasures deployed to protect it.

In order to design an attack, information must be gathered by probing the web app “live”, taking the risk of being detected by a sophisticated IDS or IPS, or of hitting a honeypot that will record his attack techniques. Metasploit helps by providing tools and a database of known issues, but such attacks still require great skills.

Now, let’s consider a connected object, even a complex one like a car. The attacker can tear the object apart, get access to memory chips, dump their content, and analyze it. This analysis will take time and resources, but there is no risk of getting caught, and countermeasures will eventually be exposed together with vulnerabilities. Metasploit will make the task even easier if the device includes known vulnerabilities. In the end, the attacker will obtain a viable attack path, by working in the security of a lab.

Detection is very difficult in such conditions. An IDS will protect a connected car, for instance, against random remote attacks. But a skilled attacker will only perform a live attack on a Connected Car after verifying that the IDS doesn’t catch it.

And this is only the beginning. Security research on connected objects is rather new, and focuses on the easiest targets. Skills will improve over time, making more sophisticated targets vulnerable. Now, let’s add to this equation an AI to assist in the reverse engineering and the identification of vulnerabilities. Traditional defenses are toast.

In a few years, if there is a vulnerability in a connected object, someone will find it and maybe exploit it. Encryption will provide a temporary protection. Trusted Execution Environments will add some hurdles. But these are just new countermeasures, not game changers.

That’s what I like in formally proven software. A mathematical proof that a piece of software does not leak information is a good countermeasure against reverse engineering AIs. With such a proof, finding a vulnerability is not about finding a software bug, it’s about finding an issue in a formal model that could lead to a wrong proof that could hide a bug. And that’s orders of magnitude more difficult, even for an AI.

Originally published on LinkedIn.


Fighting poker-winning AIs on IoT Security

Published attacks tend to repeat themselves this year, but in the last few days, there has been a few interesting events and publications, in particular: Adi Shamir has made gloomy predictions about security in the next 15 years. Bruce Schneier has published a long essay about IoT security, with a vibrant and desperate call for […]


Traffic cameras, legal rules, and accusers

A few days ago, I watched Gone Girl on TV, a story about mounting evidence against an innocent person. And then, I looked at an article about challenging a traffic camera citation (in the US). The link between the two stories is evidence, of course. Traffic camera evidence incriminates a car, not a driver. The […]


The lowest hanging card

The latest news on six second card hacking is very entertaining, and frankly, not reassuring. This thing is just as simple that it is stupid. The CVV2/CVC2 is a secret number computed by banks using a secret key, so they are validated by the issuing bank. Apparently, most (all?) of them have chosen not to […]


Resilience for Connected Objects

Attacks occur, especially on IoT. While it is very hard to avoid an attack altogether, we can minimize its consequences. The first factor to consider is the impact of an attack; there are many ways to analyze such impact, for instance from a financial or technical point of view. In a very simple analysis, we […]


IoT Security as Externality: Cluelessness, Denial, and more

Not my problem. That’s the 3-word definition of an externality: something that you don’t need to deal with, because the adverse consequences are not affecting you directly. This has been an issue for cybersecurity forever (Schneier, 2007), and it is widely known that the issue is particularly pressing with IoT (Schneier again, 2016). I have […]


Logical Attacks in the Java Card security landscape

Logical attacks on Java Card have been known for a long time, and they have also been a focus of a lot of academic research, which still continues today. Earlier this week at Cardis 2016, there have been two presentations on logical attacks. I will not discuss the details of the attacks that are being […]


SMS-based 2-factor: Good or Bad?

Wired published recently an article about how SMS-based 2-factor authentication is not good. This article is making a buzz, and an article appeared on that topic in Fortune. The basis for these articles is that SMS-based authentication is not associated to something you have (your phone), but with something you are loosely associated to (your […]


Java Card software attacks

There have been two papers at SSTIC’16 that outline the limits of bytecode verification in the context of Java Card. One of the papers, by Guillaume Bouffard and Julien Lancia, describes a bug found in Oracle’s bytecode verifier through fuzzing (yes, it’s been fixed). The second one, by Jean Dubreuil, outlines several logical and combined […]


Beyond Java Card

When Java Card was created, the market for smart cards was quite simple: chip vendors would design specific chips, chip vendors would develop an operating system for the chips and produce cards embedding the chip. Since then, this market has become much more complicated. For traditional payment and ID, changes are minimal, as card vendors […]