Skip to content

Android malware hype

There is no better publicity for a security company than a good scare. Apparently, some guys at Smobile are taking publicity seriously. They have published a report entitled Threat Analysis of the Android Market, which got them some news coverage. The report includes some pretty scary statements, like:

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.

Posted 28 June 2010 ‡ Comments (3)
§ Mobile Security § News
° Tagged: , ,

Smart Card Web Server security

UPDATED ON 04/06/10: Additional comments about security requirements

Securing Web servers is hard work, as OWASP periodically reminds us. Of course, this applies to smart card web servers, regardless of the underlying technology. I received a comment from someone who noticed that some of the Java Card 3.0 Connected sample applications have really bad security. Basically, all the attacks from OWASP’s book that can apply will apply.

Of course, one can claim that a piece of sample code is here to show a very basic implementation, not a fully secure application. On the other hand, I often claim that security should be built in from the ground up in applications. Now, here are the problems noticed by Blaufish:

  • Servlet does not validate data in doGet(). That’s really bad, of course. Any HTML injection will work at that stage. The problem is that solving this issue is far from simple. The libraries that provide adequate protection against attacks are actually rather large and/or require significant resources, unless of course we oversimplify them, resulting in strong restrictions.
  • Servlet does not encode output in doGet(). That’s also bad, especially since nothing is done on input. The problem is the same as above.
  • Servlet performs write upon GET, HTTP guidance violation. OK, this is typically due to sample code simplicity.
  • Servlet does not implement anti-XSRF tokens. This is actually rather easy to do in Java Card, and we would expect all SCWS applications to actually include a random string in request in order to avoid XSRF forgeries.
  • Database layer does not validate data. Combined with the absence of validation and encoding in doGet, this is of course unacceptable, since it would allow really terrible attacks. The issue is the same as for other validations, but a solution needs to be found.
  • No user authentication/authorization/session model. Here, my first thought was that there were other opportunities to add security in this application, in particular in the Web descriptor. However, since the operations are specified as query parameters, things may not be that easy. Except that the application is so “stupid” that any access control would be very basic, most likely a binary decision.

So, what should we do? Including complex validation code in basic examples definitely isn’t the solution. However, mentioning that the application is a basic sample that doesn’t include the security measures required in any deployed application, regardless how simple, that could be done, and it may actually already be done. Also, we must recall that not all samples are that simple, and that some of them actually include some security (at least declarative security); we should make sure that there exists at least one example that include state-of-the-art security.

The real challenge, though, is to find appropriate countermeasures, i.e., countermeasures that will work on real applications, running on real cards. That means that they must protect against major attacks, while allowing most uses, and fitting in the card.

Another issue is to identify which attacks actually apply, especially in the limiting context of OMA SCWS, where the mobile phone is the only possible client of the servers. Obviously, some attacks are not a problem: for instance, no risk of denial-of-service attacks. It also reduces the impact of some attacks, because the owner of the phone is the likely victim of most attacks, and many such attacks need to be performed by the owner. A SCWS Web application will not be as exposed as a classical Web application. However, depending on the usage patterns, there is a residual risk, which needs to be identified and countered.

Possibly not a minor challenge. I am not too worried about the first applications; we’ll manage to get them right (well, if we think about security in the first place). But if SCWS spreads, we will have to define a systematic way of including this security, which could be more difficult. Let’s see what happens.

Posted 02 June 2010 ‡ Comments (0)
§ Applications
° Tagged: , ,

Mobile applications may be dangerous

That’s a question that I have been asking myself for quite a while. How dangerous can a mobile application be? How can it be made more dangerous? Or less dangerous?

Here’s a grabbag from Internet today. First, the good side, with two Microsoft articles pointed by Bruce Schneier:

  • The first one is about the authorization dialogs that we face when an application, native or web-based, requires us to take a decision. I was discussing recently with a colleague the fact that these dialogs are sometimes very technical, and that most people are likely to take a decision based on the reputation of the developer or their envy to see the application work. The article is very interesting, and it outlines the interest of graphical interfaces, with icons. It also serves as a reminder that security is often about getting the user to understand what it is about.
  • The second one is a bit more specific, and looks at how we can allow an application to use device sensors, and in particular, cameras. Once again, the trick is to make sure that the user is aware of the use that an application makes of a sensor, in particular when it may violate the device owner’s privacy.

These works are interesting, and shows that Micrososft cares about them. However, since they are advanced research works and they are not very conclusive, they also show that the road to good security interactions is going to be long and bumpy.

On the bad news side, there seems to be a surge in fraudulent premium SMS’s (in French). This time, apparently, the fraudsters are sending a SMS that contains a URL, this URL points to a Web page that opens in a browser, and one of the links in this browser triggers the sending of a multimedia message to the victim’s mobile, which is billed 4,50€. I haven’t seen the thing directly, so I don’t get it directly. However, I am a bit curious of the code of this Web page, because I don’t know how a simple click can cost me 4.50€ without me entering any data, and without a direct link to my operator.

Maybe that the solution is in another piece of news. Orange is making some effort to attract developers with APIs, and these APIs seem to cover messaging among other things. However, looking at the definition rapidly, I did not find a way to bill the user.

All of this leads us to an interesting and potentially dangerous future. With BONDI and the like, the boundary between local and web-based applications is going to become very blurry, and all these applications will be able to use and abuse a lot of sensors and billing systems.

I think that I’m going to look into the static analysis of Javascript one of these days. And all this research in security user interfaces is really becoming important.

Posted 24 May 2010 ‡ Comments (3)
§ Discussions § Mobile Security § News
° Tagged: ,

Smart card security on the radio

Smart card security doesn’t often get on traditional media, so we can all (at least, the French-spaking ones) be happy that France Culture will spend an hour discussing the security of payment cards, trying to provide an answer to the question “Comment améliorer la sécurité des cartes bancaires?“. Among the speakers, we will have Jean-Louis Lanet, from Université de Limoges, and Pierre Chassigneux, from Cartes Bancaires. This talk show follows the publication of an article about the same topic in the French magazine Sciences et Avenir.

This sounds interesting, and I will be listening to the show (maybe not live, but I will definitely get the podcast). I listened many times to France Culture’s science shows, and they are usually serious and interesting. Of course, the question (in English, how to enhance the security of bank cards?) is already a bit aggressive, and I am sure that some people would even challenge that question, claiming that there isn’t much to be enhanced. Well, we’ll see on Friday.

Posted 03 May 2010 ‡ Comments (0)
§ Banking § Discussions § News
° Tagged: , ,

Live from Cardis 2010: Reactions to my presentation

My first Cardis presentation led to a few discussions about possible paths for the exploitation of smart cards, or for challenges to be considered. Here is a selection of the most interesting discussions.

TPM. Somebody asked the question about the relationship of TPM and smart card. The latest TPM specifications give the impression that they are exending their scope in order to embrace the role of generic cryptographic token for a PC platform, possibly in replacement to smart cards. This of course may be true, as every technology tries to gain ground on the others. However, there also are goof arguments that go agaisnt this view. First, a TPM is tied to a machine rather than a person, and this makes it quite difficult to be a representative of a person like a smart card can be. Then, and most importantly, the TPM is a device that is here to guarantee the integrity of a system, whereas the smart card is an identity device. This means that the basic mechanisms that are implemented are fundamentally different. They may be combined, of course, but there is no real reason behind that.

Smart card, storage, and locality. The idea of linking smart cards to storage isn’t new, and we have again talked about it, in particular with the possibility to link a smart card to storage, for instance through a secure MicroSD card. There are advantages to that, but allso drawbacks, as linking two elements reduces the flexibility for the buyer, who is then faced with fewer options. In a similar/opposed question, somebody pointed out the opposition between the perceived “locality” advantage of smart cards and the fact that everything is now available in the cloud. I believe that these discussions are heavily linked, and are also linked to the way in which we see storage.

Today, many people consider that their main storage is on their PC, with a possible backup in the cloud. We may in a while get to a situation where we consider that our main storage is in the cloud, and that the local storage on our PC and other devices simply is a local mirror of that main storage. What we need to understand is that this doesn’t mean that local storage is useless. For instance, we are far from being able to get the appropriate bandwidth to stream a HD video form anywhere, and it will take a while before we get there. Overall, this means that we will keep having local storage for a long time.

Internet of Things. Some people are seeing an interest for smart cards in the Internet of Things, for at least two reasons. The first one is the one that I have been defending for a while: a smart card, in particular one including the latest Java Card and GlobalPlatform technologies, is an incredibly optimized and secure platform, that can be used in a wide variety of ways, in particular as the heart of a small connected device. The second one is that many people in the Internet of Things community don’t focus much on the security aspects of their fields, that smart cards could bring. The main question is here to understand whether there is indeed no compelling reason to secure a network of sensors, or this is just a question of timing, which means that security issues will come up as soon as the main functional/practical issues will be addressed.

My feeling is of course that the second option is the right one; in that case, delaying the security considerations may once again be a big mistake, because a smart card core could of course bring the required security, but it could also do more than that, by providing an application framework and application management capabilities. Of course, if the smart card is only added later, it will only be considered as a security token.

This is of course yet another demonstration of the “ghetto effect” through which smart cards are solely considered for their security features, and never for anything else, although their computing power is often comparable to that of other chips.

Virtualized smart cards. The last discussion was about virtualized smart cards, a topic that I completely overlooked in my presentation. One of the views of a virtual smart cards is to consider several virtual smart cards within a given smart card. This could be interesting, for instance in the context of NFC, as a way to manage a card with several providers. We could even imagine to host several virtual cards with different configurations on a single hardware SE. Another view of virtualized smart cards, which is a bit more science-fiction, is to consider that we could have virtual smart cards in the cloud, with many cards hosted on some faraway secure device. I have no clue what that would lead to, but it sounds like an interesting thing to investigate.

Posted 16 April 2010 ‡ Comments (0)
§ News
°

Live from Cardis2010: Combined attacks on Java Card

I just made my second presentation at Cardis2010, about combined attacks on Java Card (joint work with Anthony Ferrari, now in charge of these things at Trusetd Labs). Sorry, no “public” slides this time, this is related to security evaluation.

Interestingly, the current presenter is Guillaume Barbu, from Oberthur, who is presenting an interesting attack based on the same principle: we load a perfectly legal application on the card, and “magically” make it illegal by using a physical attack. My technique is to replace an instruction with a nop, and his technique is to block the throwing of an exception (execution continues even though it should have failed).

This doesn’t sound very interesting, and not a real novelty. After all, we were already able to get type confusion with simple logical attacks. The main difference is here that the applications we use are actually legal, and that their behavior is modified dynamically (one of my colleagues calls them mutant applications, which makes this really scary). In the microcosm of evaluation labs, this is a game changer, because the main argument used against logical attacks until now was “Bytecode verification is mandatory, so your attacks won’t work”. With mutant applications, this argument doesn’t hold anymore.

But does it really change things when we get out of the evaluation lab? Not really. Writing an attack application may be easy, but exploiting it remains very hard. Smart cards are highly controlled environments, and traceability remains the norm. Our attacker A must be an insider in a company that actually develops an applications. This attacker A then needs to plant a Trojan horse in one of his company’s applications, and have it loaded on a number of platforms. So far, so good.

The problems come by when the attack is actually exploited: with the kind of traceability we have on smart cards, as soon as the attack will be triggered, it will be noticed, and labs will trace the attack back to that application. If you combine that with the fact that this attack required physical access to the smart card that is being attacked, its practical impact becomes quite limited. It is mostly useful if you have a brittle security system, in which disclosing a key breaks the entire system. But in that case, the problem is not really in the Java Card implementation, but in the system itself. Even without this attack, this key would have been compromised.

Posted 15 April 2010 ‡ Comments (0)
§ Java Card 2.x § Research § Security
° Tagged: ,

Live from Cardis2010: User-Centric Smart Card Ownership Model

That speech is by Raja Naeem Akram, from Royal Holloway. He proposes a system in which the end user buys the smart card from the manufacturer, and then customizes it by going to a service point that will interact with smart card service providers. The services would be leased with specific conditions depending on the relationship between the user and the service provider.

The main focus of the talk is about sharing between applications in such a setting. This started by a description of Java Card’s sharing mechanism, and of Multos mechanism (for those of you who don’t know, the Multos sharing mechanism is based on delegating APDUs: the client application creates an APDU command, asks the server application to process it, and gets the APDU response).

These sharing mechanisms have one thing in common: they provide the same access level to all clients, without any notion of privileges. Of course, this is something that we want to fix in a usable model, where a hierarchical model is preferable (dynamic, of course).

Another thing that they want to modify is the relationship between the applications and the runtime environment. The applications should only be authorized to use the features that they have been allowed to by their provider, and the system should be limited to the required access (which is not a requirement in the current Java Card specification).

Privacy is another issue, with three subproblems: application scanning (an application should not be able to discover other applications), profiling user (an application should not be able to profile how users are using other applications), information leakage (no information should leak between applications when they do not actually communicate).

The proposal is here to define a new firewall, associated with resource managers, and in which SIOs are associated to ACLs. Sharing sessions need to be initiated with an explicit binding mechanism, in which the client only gets access to a resource for a limited time, and there is also a delegation mechanism.

Apart for delegation, this looks a lot like the Java Card 3.0 model. But, as the presenter answered to my question, they bring quite a few new things, including their focus on the end user and the formalization of the restrictions between applications and runtime environments, and the explicit binding and delegation. Maybe some good ideas for next releases of Java Card in this…

Posted 15 April 2010 ‡ Comments (0)
§ News
°

Live from Cardis2010: Protecting RNG from side-channel attacks

The next talk is given by Suresh Chari,from IBM’s Watson research center, who are still working on their Caernarvon secure operating system, this time protecting random number generation from side-channel attacks.

The talk starts on an interesting property of security certification. The FIPS140-2 certification scheme mandates the testing of random-number generation (RNG) features before they can be used by an application. By forcing this extensive testing, FIPS140 makes the random number generators more sensitive to side-channel attacks, because the tests intenely use the feature that should be protected.

This is a very nice example of systemic failure. In this case, the risk actually comes from the very security certification that is supposed to reduce risk. Nothing new, but another confirmation that is is extremely hard to design security principles (or certification schemes) that can be universally applied to a wide variety of devices.

This is proven again by the fact that the new smart card platform protection profile (BSI-PP-0035) raises this issue of testing and addresses it. You get a better view of things when you are closer.

Posted 15 April 2010 ‡ Comments (0)
§ News
°

Live from Cardis 2010: Where is our smart card AppStore?

UPDATED: Added slideshare link.

Here is a transcript of my invited presentation at Cardis2010, or at least the things that I thought about before getting there. The slides are available on SlideShare.
Continue Reading »

Posted 15 April 2010 ‡ Comments (0)
§ Discussions § Mobile Security § Research
° Tagged: ,

Live from Cardis 2010: Bertrand is back

I am just sitting in the room where Bertrand Ducastel is starting his speech about The Emotion of Identity, of course starting with a 2500-year old Texan religious painting.

Now, let’s go for the (live) meat. With cloud computing, it is hard to figure out where my computer is in the world, mostly for fiscal/manpower costs reasons. However, this has an impact on government, because governments may want to control where the data actually is.

In terms of security, the three words that come to mind are: Identity, Policy, Privacy. More precisely, Privacy comes with control, choice, and ownership; policy comes with rights, law, commerce, justice; and Identity comes with authentication, authority, reputation, persona.

In the cloud, the new social order is about virtual machines talking to other virtual machines. We started with personal computers, with a model centered on the individual, we then move to networks, centered on the group, and the current network of virtual machines is centered on congregations, close to full human societies.

Next, we get an overview of Maslow’s Pyramid, with a long explanation of bulla (mesopotamian smart cards). Now the question is: how does this scale apply to computers, as they get organized in complex societies, closer to human societies?

Next, Bertrand outlines the link between identity and trust. The first kind is differential identity, or trust by causality (basially, what you are): the second one is experiential identity, or trust by process (basically, what you own/get, this has been formalized in subjective logic). Something interesting is that humans have in history been identified mostly by process, whereas computers are more in causality. More and more, computers are being identified through reputation, and humans through biometrics.

Next recreation, about the compared trust infrastructures of United States and France/Europe. The Declaration of Independance and Déclaration des droits de l’homme et du citoyen are basic trust infrastructures, on which constitutions were built, and then, law systems, etc. It shows that the trust infrastructure is on top, followed by policy infrastructure, and that the same thing should apply to computing.

We then get to the main slide, about emotion and identity. Bertrand introduces a paper by Sheldon Stryker, Integrating Emotion into Identity Theory (2004). Identity is here about status, and when status goes down, emotion kicks in because we get upset. The main thing is about mirror neurons, in which the same neurons re excited when we eat and when we see somebody else eating. And this process is important, because it is about sharing emotions.

Next, privacy. The main statement is that “Privacy is the provisioning of identity”.

Finally, we get a Maslow scale of computer needs, which of course is topped by Computer Theology (recursive trust/policy infrastructure), reputation, and intimacy.

Well, that’s it, and that was pure Ducastel: cluttered, confusing, but full of interesting and inspiring bits.

Posted 14 April 2010 ‡ Comments (0)
§ Discussions
°