• The device performs its tasks normally, but the attacker also runs other software on it, for instance to make it participate to DDoS attacks.
• The device apparently works normally, but its behavior is somehow altered, for instance by providing wrong information.
• The device doesn’t work or obviously dysfunctions, for instance a car that won’t start.

A second factor to analyze the consequence of an attack is the duration of the attack, or the delay until recovery. Here, we can consider four situations:

• Until next reboot. I am confident that the firmware hasn’t been modified, so a reboot will remove the attack vector from RAM and address the problem.
• Until next hard reset. I am confident that the device will not boot on modified firmware, so a hard reset will restore a « good Â» copy of the last known correct firmware.
• Until next update. I am not sure about the full firmware, but I know that a firmware update will remain possible and will address the issue.
• Until replacement. The firmware update mechanism is corrupted as well (or the device is permanently damaged), so the only solution is to replace the device.

We could go further, but let’s stop here for now. The impact looks essential, but the differences between the three scenarios aren’t that great. An obvious dysfunction is bad, but a device whose behavior has been altered by an attacker can be just as bad, and a device that is controlled by a hacker can easily become dysfunctional. In all three situations, it is obvious that some fix is required.

That’s where duration and recovery are important. The two first options (reboot and hard reset) are only temporary fixes. Even if the attack is transient and can be removed, the vulnerabilities that made the attack possible are still present, and the attack can be reproduced easily. Ideally, a reboot or reset/restore must be accompanied with some operational restrictions (like a “safe mode”) until an update is performed.

What we are analyzing here with recovery methods is resilience, or according to Random House, “the power or ability to return to the original form, after being [attacked]”. It is a valuable property for systems that are submitted to high levels of stress. Resilience is about recovery, in opposition to resistance, which is about protection.

Resilience and resistance are complementary. Resilience is often considered easier to achieve than resistance, but maybe more importantly, resilience may still happen when resistance has failed. Even if an attack on a system has been successful, its recovery is possible is the system is resilient to that attack.

We can here use an analogy with resilience against natural disasters. Although a hurricane can cause massive destruction to coastal areas, (resistance is limited), most U.S. coastal areas are resilient against hurricanes because hurricane evacuation routes have been defined, and shelters are ready to host evacuated people. Such resilience measures rarely fail, and we are shocked when this occurs, like in New Orleans after Katrina.

For an embedded device, resilience is mostly about:

• Secure boot, to restart from a clean sheet upon reboot, and detect a potentially persistent attack.
• Firmware update, to load a new version that is not vulnerable to the attack.

More generally, resilience can be achieved through simple infrastructure means like roads and shelters. In the case of connected devices, resilience can be achieved through low-level features, within or below the operating system, and highly independent of the use case.

However, although resilience mechanisms are simple, they also need to be very robust. A hurricane shelter must be built on high ground with strong material like reinforced concrete that offer strong guarantees of resistance against a hurricane. Similarly, the secure boot and firmware updates of a connected device must be designed and implemented to resist attacks. In both cases, this resistance is easier to build because it is applied on a smaller scale, and it is mutualized:

• Smaller scale. A shelter is a single building, typically used for other purposes (like a stadium) that is relatively easy to reinforce. Similarly, a secure boot is a small mechanism, so is the security-critical subset of a firmware update mechanism. These mechanisms offer a small attack surface, and are therefore easier to protect than an entire software stack.
• Mutualized. A shelter is shared by all members of a community, who will use it together in case of emergency. Similarly, secure boot and firmware update are independent of the device’s role and application. The development and reinforcement efforts can therefore be mutualized, reducing the cost for every device.

Resilience must be proactive

Resilience is the capacity to recover from an attack, and as such, appears to be a highly reactive technology, that comes after the fact. It is of course true that resilience mechanisms are triggered after the fact, but in order to succeed, they need to be proactively prepared.

Just like evacuation routes and shelters need to be planned in advance and designed to resist a hurricane, resilience measures in IoT devices similarly need to be prepared beforehand. A firmware update mechanism is crucial, and it needs to be prepared with great care proactively. In particular, this mechanism must be designed to be highly resistant against attacks.

In the world of connected devices, we know that resistance to attacks will be difficult to achieve, because it requires a very large investment from vendors to fix all vulnerabilities and make their systems resistant to attacks. Resilience, on the other hand, can be achieved on a wide scale with a limited budget, and has the ability to provide a strong basis on which IoT security can gradually be built.

Disagree with http://bit.ly/hq5J6H on raising entry fee of #android dev: organized gangs will still pay. Genuine individuals no.

It sure sounded to me that I agreed with Axelle, and not only because I plan to register as an Android developer one of these days. I checked on the proposal on the naked security blog, and it confirmed that I do disagree with them. Making developers pay for submitting and testing an application is a bad idea; this is what mobile operators and other application distributors were doing before Apple’s App Store, and it didn’t work, because it increasing artificially the cost of developing applications. The cost of vetting an application is an App Store cost, and the idea is that the revenues from the store should cover this cost. Of course, this may not be very easy for Android Market, because their revenue is lower than Apple’s store revenue, but it nevertheless remains their responsibility.

Making application development accessible to developers always makes it just as accessible to hackers and malware developers, but this remains the way to go. If you consider Java Card, it has never been really accessible (just try to get sample cards to run a Java Card application, and you’ll understand what I mean); hackers have largely stayed away from it, and so did developers: creativity on the Java Card platform is dismal, and it sure doesn’t come from independent developers.

So, what can Android Market do about these deliverables? Well, like we said before, vetting is a key element here (i.e., having Google analyze the applications carefully before to actually put them on the market). This is a part where Apple is far from transparent but potentially efficient: few people know the kind of vetting performed on iPhone applications. Of course, malware developers can test concepts, but the opacity of the process allows Apple to update it rapidly when malware is detected.

Let’s follow a few of Crypto Girl’s suggestions, on her Fortinet blog, and on IBM’s blog, to get a few more technical detail. These reads are quite interesting, because they show how the exploits have been embedded in the code. I am not an expert on Linux exploits and I may be wrong, but I have the feeling that a static analyzer could identify a few things that would trigger a security analyst’s interest.

As a lot of people mentioned in the past months, there is increasing interest for mobile malware, especially around Android and iOS, and we expect a race between the good guys and the bad guys. What worries me a bit here is that I don’t see much sign of Google engaging in the race to protect Android. Applications like DroidDream should be caught and rejected before they are released, rather than recalled after being downloaded by thousands of developers. Let’s hope for Google that they get serious before their Android Market becomes completely discredited, because Android is an open system, and competitors could show up.

Basically, this attack shares the following characteristics with many other ones:

• Exploit Android permissions. Android permissions are very wide, and labeled in simple terms. This means that there are many ways to abuse people, especially with combinations. In that particular case, the use of two collaborating applications is a way to hide combinations, but it also makes the attack more difficult.
• Use a side channel for leaking data. Some side channels are obvious (like leaking data on Internet together with other data), and this one is trickier. In fact, there is always a tricky way to leak data, especially when you can do it one bit at a time.
• Be a proof-of-concept. This malware works, but only in a lab. In the real world, it needs someone to download two pieces of malware, dial a credit card support hotline, type a credit card number, and do that for another reason then blocking the card. Possible, quite unlikely.

My main claim is that such a malware is quite unlikely to represent any kind of danger. The scheme is so complex that by the time people get credit card numbers stolen, the malware is very likely to be detected. My second claim is that the Android permission system is not worse than the others around: iOS doesn’t really use permissions, MIDP uses overly detailed ones (granted by network operators in most cases), etc. My third claim is that what really count is that the Android Market is able to vet applications; even if it doesn’t do much today, we can rest assured that Google will make sure that 2011 doesn’t become the year of mobile malware.

Nevertheless, the paper points a few interesting things about Android permissions, and some of them could be fixed:

• The Read contact data permission gives access to the call history. I am not sure that I see the need for that. In fact, my main issue with that is that, in terms of privacy control, I believe that it’s very different to know who I know and who I actually call. I believe that this one should be fixed.
• The Record audio permission allows an application to record the content of phone communication (as well as recording audio in the background, actually). In fact, that’s again a privacy issue: an application that records audio while it is the currently running application is fine; allowing that application to record audio from the background is a very different thing, which worries me. This one also deserves to be fixed.
• The side channel actually doesn’t use any permission in most cases, since it uses channels that don’t require any, like setting the volume repeatedly. Here, I don’t think that there is a big problem, because getting data out is most likely not the main problem today. Five years ago, everybody was worried about connected applications; today, most people consider it normal for an application to be somehow connected to the net (for instance, an application can always claim to backup things, to have a social side, etc.). Malware doesn’t need to be bundled with sensitive, intelligent software, so complicated side channels probably represent a futile complexity.

To conclude, a word about hidden communication channels. I have worked on information flow static analysis, and we haven’t found many practical ways to identify hiddne information flows. Usually, these hidden flows do not use variables or communication APIs to leak data. Instead, they often leak a trickle of information using either an unnecesssarily convoluted computation (which is likely to attract the attention of a human reviewer, but is difficult to find for a static analyzer), or by looping on an apparently innocuous API method (this is what is done here, and we may have detected it using a static analyzer).

3% of all of the Market submissions that have been analyzed could allow an application to send unknown premium SMS messages without the user’s interaction or authorization.

Premium messages, without the user’s authorization. That’s actually true, but not really scary about the applications. This corresponds to the number of applications that request the SEND_SMS privilege (1356 out of 48694). That’s the way Android works: once you have allowed an application to send SMS’s, the application can send any SMS, including premium ones, and this happens without any further user interaction. Abuse attempts are likely, but Google is likely to turn on the kill switch before the bad guy can make any real money.

Similarly, the guys at Smobile have identified real spyware, which actually fowards to another phone all the SMS’s sent and received from a given phone. This application actually describes itself as spyware (search for “spy” on Market, and you’ll find several). All the permissions is needs to do that are SEND_SMS, RECEIVE_SMS, and INTERNET. I am sure that you can do a few things using these permissions. When roaming, I could use a messaging application that uses Internet when available and reverts back to SMS when nothing else is available.

Enough of that. I think that Smobile is pointing at a real issue: once you authorize an Android application to do something (like sending SMS’s or recording audio), it can do it freely until uninstalled. Eventually, a smarter than average hacker will design a good Trojan horse and make some money.

The problem with these reports is that they mislead many people into believing that Android is full of malware. Of course, the reality is that the Android Market is full of apps that could be malware. They just aren’t.

I am a strong supporter of static code analysis, and I think that Android applications definitely are a good target for static analysis. However, the analysis must be much deeper that looking at the permissions requested by the application. For instance, identifying the numbers to which a SMS is sent is much more discriminating. If an application sends messages to a premium number without warning users, it is much closer to qualify as malware. Let’s get that working, and I am sure that we will learn interesting things.

There has been a case recently, in which a Symbian piece of malware has been signed by the Symbian Signed program. This case is rather sad, because it somehow gives arguments in favor of security by secrecy, obscurity, and proprietary measures. Symbian has a transparent process, in at least two ways:

• The antivirus tools used to scan the programs are known by all, which allows malware developers to make sure that their piece of code is not detected.
• Symbian Signed is able to revoke signatures, but this revocation is managed in a way that allows users to ignore it.

Of course, such problems don’t happen with obscure, proprietary programs. Apple doesn’t say anything about their application certification program, and they claim to have the ability to disable any application on any phone (at least as soon as it connects to iTunes or the application store). Even Amazon has shown that they could unilaterally decide to recall a fraudulous book. Don’t get me wrong, I still largely prefer open mobile solutions, but closed systmes score one point here.

So, we get back to the original question: Should we sign malware?

And the answer is … yes, of course.

To justify this answer, we need to get back to the basics. What guarantees do we get through a signature?

• Some knowledge about the developer’s identity. In order to submit to most programs, including the Symbian Signed programs, you need to sign your own code with a certificate obtained against a proof of identity. Actually, that’s a part of the problem that nobody mentioned in the latest Symbian issue: how did the malware develoepr hide, and can we close the loophole?
• Some knowledge about the fact that that the application follows some rules. This knowledge can be obtained through automated tools, like antivirus tools or static code analysis tools, or through a human analysis, like interactive testing or code review. Usually, the analysis is mostly automated, because human analysis is much more expensive (and by a lot, like 100 or 1000 times more expensive).

These guarantees usually don’t mean that the application isn’t malware. Let’s consider may favorite example: how to make sure that an application does not dump use my Internet connection to spam my entire contact base? Well, in most cases, you can’t. You may be able to know through permission requests that this application needs to read your contacts and access Internet, but you will have no idea about the relationship between the two.

There is hope that, eventually, some tools will be available that will allow us to prove that an application is not malware (or at least that it does not do anything from a list of known bad things), but we are not there today.

Static analysis addresses a part of the problem: it allows developers to prove that their applications don’t violate a predefined set of rules. This sounds fine at first: the burden of proof belongs to the developer, which seems fair. However, the problem is in the rules. With today’s static analysis technology, if you want to prove that an application does not dump you contacts on Internet, you must basically prove that your application either uses Internet or uses contacts, but not both. At the research level, some people may even be able to prove that your contacts data can never get to Internet in any way. But what about real life?

In real life, if an application uses your contacts and Internet, they are also likely to send an e-mail to one of the contacts. In that case, part of the contact (the e-mail address) actually goes on Internet, and things become really, really hard to prove.

Now, is this problem impossible to solve? No, of course. However, the solution is hard to get to. The idea is here to design APIs so that they are more difficult to misuse; a direct consequence is that static analysis will work better, making it much simpler for developers to prove that the applications can’t do harm.

To get back to our example, one solution is to use a sendMailToContact API that starts an interaction (managed at system level) to select an e-mail address, and then sends a message to this address, without ever letting the application know about the address itself. Such an API addresses the needs of most applications, while making it very easy to prove that contacts aren’t dumped on Internet: the application does not actually access your contacts.

Of course, this will never work for all applications. If you want to replace the default contact management application on your Android device, you will have to allow this application to access directly your contacts, and also most likely to access Internet. In fact, you will even want this application to dump (backup) your contacts on Internet. But most importantly, you are quite likely to use an application that has been developed by a well-established company or community, and that you trust.

So, once again, as of today, we will most likely keep signing malware. However, when this happens, we should have of some person or some company to be held accountable for it. That’s what the signature processes bring to us.

First, we have the obvious items. Any application doing any of these things obviously is malware, for Google, and for about anybody else:

• discloses the user’s private information to a third party, without the user’s knowledge and consent;
• destroys the user’s data (or the device itself) without the user’s knowledge and consent;
• attempts to automatically spread itself to other devices;

Note the subtle distinction between an action that is performed automatically and an action that is performed without the user’s knowledge and consent. You can recommend an application to your friends, but your recommendation should not include the application itself.

The next one is just as obvious:

• impersonates the user (such as by sending email or buying things from a web store) without the user’s knowledge and consent;

This definition of impersonation is very Internet-oriented. However, since there is no rule about “performing actions that incur a cost to the end user” such as calling a premium number or sending a SMS, I would say that this has to fall into this rule. If you combine that with the permission model that only provides “blanket” permissions at installation time, there is room for a lot of abuse here, or at least for spurious wording from applications that send premium SMS messages.

Next, we have an issue that is specific to mobile devices:

• drains the device’s battery very quickly;

This one shows how thin the boundary is between buggy software and malware. I am sure that a few games will be labeled as malware on this rule, just because they try a bit too hard to be reactive or to otherwise enhance the user experience.

Another category rules out some irritating behavior from Android applications:

• shows the user unsolicited messages (especially messages urging the user to buy something);
• resists (or attempts to resist) the user’s effort to uninstall it;
• hides its files and/or processes;

The first one is quite surprising from a company that lives on advertising, as it somehow rules out any application that performs heavy-handed advertising. Shareware may also be difficult there. The second rule seems to be targeted against Symantec and other security software, and the last one is interesting in many cases.

The last item is the typical catch-all sentence. In that particular case, it goes quite far in being overly broad:

• otherwise degrades the user’s experience with the device.

Now, what is missing? Not much, in fact, because the definitions are very general. I would like to see an explicit mention of “incurring cost”, as well as about attempts to perform unauthorized operations. We would also need the definition of “private information”; for instance, the status of location information may need some clarification. But still, it is interesting to get that definition of malware.