How 950 Million Android Devices became vulnerable (Stagefright Vulnerability)

Imagine remotely executing code by sending an MMS to your victim, crazy right? It’s not that crazy now, considering that researcher  Joshua J. Drake just discovered a very intrusive vulnerability in the Android operating system. It is estimated that this vulnerability exposes 95% of all Android devices.

Stagefright is a library in Android that is responsible for all the media processing. It provides a playback engine and the codecs necessary to playback a variety of media formats. Media processing is a very resource intensive functionality which needs to run as efficient as possible. In order to achieve this, the library is implemented in the C-language (native code). This language is, in contrast with Java, an unsafe language. The reason C is considered unsafe, is due to the fact that a developer writing C code is responsible for controlling the memory region that his code needs. This gives possibilities to a variety of vulnerabilities that can arise due to insufficient bound checks on input data that is being handled by a C routine. The vulnerability in the Stagefright library is an example of a memory vulnerability, which allows an attacker to perform remote code execution.

The Stagefright vulnerability

Not a lot of technical details are known about the vulnerability. This is probably because the vulnerability is going to be presented at Black Hat USA on August 5 and DEF CON 23 on August 7. However, it seems that the specific attacks that are possible, are the attacks that researchers call a ‘buffer overflow attack“. It seems that Cyanogenmod already provided some patches, the following figure shows the patches for the MPEG-4 processing module of Stagefright. The commit comes with a comment that describes a part of the vulnerability in some technical details:

When the ‘chunk_data_size’ variable is less than ‘kSkipBytesOfDataBox’, an integer underflow can occur. This causes an extraordinarily large value to be passed to MetaData::setData, leading to a buffer overflow.

Should I be scared?

No, it’s a serious issue, but you should not go all paranoid. Some precautions can be taken to prevent an attack from executing successfully. In order to trigger the exploit in the Stagefright library, you’d have to execute media first. For the case of SMS/MMS, just disable MMS. Don’t play content that you don’t trust, this includes but is not limited to: MMS (why even use those?), URLs or content from spam e-mails, strange-looking URLs that load in the browser, etc. Using some common sense could bring you a long way.

That’s for the common sense part. Now the technical part is somewhat more reassuring. Android has several security boundaries built-in to contain and block memory exploits from successfully executing. Without going in a lot of details, some of the countermeasures are ASLR and DEP. Which make a memory attack quite difficult to execute, and for the real technical part I refer to a previous article I wrote, on another Android vulnerability. This proves that it is a very intrusive vulnerability but it is not something that should keep you awake at night 😉

Who is to blame?

Collin Mulliner, senior research scientist at Northeastern University, said in an interview, “In this case Google is not the actual one to blame. It’s ultimately the manufacturer of your phone, in combination possibly with your carrier…If you can save money by not producing updates, you’re not going to do that. Since the market is moving that fast, it sometimes doesn’t make sense for the manufacturer to provide an update.”


DroidSec – New Android Reverse Engineering Tool

Quite often I find myself reverse engineering Android applications when I try to review the security of applications. A good reverse engineering tool is critical to perform a good security assessment. DroidSec  is a reverse engineering tool, specifically build for reverse engineering Android applications, and features are built in, which from my experience, have proven to be useful. However, DroidSec is not a silver bullet, it’s more like a Swiss army knife.

How to get DroidSec

DroidSec is hosted at my GitHub account, which can be found here:

The GitHub page displays a, or it can be viewed at the homepage:


Under the hood

DroidSec is built using the AndroGuard codebase, and developed in Python. It uses the DAD decompiler to decompile Android to .java sources.

If you are a security researcher in need of assistance or if you would like to see additional features added, please contact me at and we’ll discuss it further. Please keep in mind that the project is just being bootstrapped, the code is far from optimal and a lot of refactoring will be done once I work towards a first release candidate. I’ll try however to keep the master branch in a building state, so everyone can experiment with nightly builds.

This tool is build for educational purposes only, keep in mind that reverse engineering applications is illegal in most countries and use this tool on your own risk.

Privacy: The Nothing to Hide Argument

When I am having a discussion about mass surveillance and privacy, it is far to often the case that the discussion gets stuck on the argument: if you have nothing to hide, you have nothing to fear. It seems that a lot of people are convinced that the idea of more security for less privacy is a valid reason for giving up on privacy. Not only is this a destructive argument (it makes further discussion completely impossible), it is also a faulty premise. The usage of this argument is a reason to make the reasoning that a lot of people see privacy as hiding something bad or illegal. Why is this? If this were the case, that privacy has this purpose, why is it a human right (see art 12)?

What is privacy?

Understanding privacy is a crucial step, before you can have any valuable or non-destructive discussion. It should be clear that privacy comes in different forms. Privacy is something that is defined by the culture in which you try to define it. The concept of privacy has changed throughout the years due to the introduction of new technologies (i.e. Internet, smartphones, etc ).

For my discussion, I would like to define the concept of privacy as follows. Privacy, in our western culture, is the ability to have control over you information when you share it over media and, when using common sense, expect implied privacy. The concept of implied privacy: if I say something in a private chat to my friend X, I expect the notion of ‘implied privacy’. If I share it with my friend X, I don’t expect my message to end up in some sort of mass surveillance program. If I walk in a public space, and my face is recorded on a CCTV camera, I don’t expect it to be linked with my online messages. Why? Because it is my choice if I want to disclose the link between my location (where the camera has recorded me) and my online conversations or even search history on search engines.

Problems with mass surveillance

The privacy problem I would like to touch here, are the problems that arise with mass surveillance. This type of data gathering is an attack on the fundamentals of free speech and personal privacy. Data is being gathered from the biggest social media and search engines, wires are being tapped and even routers are being backdoored to get to your data.

The problem with mass surveillance on this scale, is the fact that data is stored in central data centers. Pieces of data are linked together behind the user his back. Aleksandr Solzhenitsyn declared:

Everyone is guilty of something or has something to conceal. All one has to do is look hard enough to find what it is.

Which is an ironic remark on the fact, that if you piece data together in some specific way you can make a case against somebody. The context of the data is lost when it is being tapped or gathered, the intention or purpose of the data is not recorded, together with a non-transparant data-gathering program, this is a recipe for privacy breaching measures or wrongfully incriminating an individual. It can be best describe with this scene in Friedrich Dürrenmatt’s novella “Traps,” which involves a seemingly innocent man put on trial by a group of retired lawyers in a mock-trial game, the man inquires what his crime shall be. “An altogether minor matter,” replies the prosecutor. “A crime can always be found.”

Although my article used examples and facts about the spying programs of the NSA, it should be noted that all big governments have these programs. As ordinary people we should demand privacy and take this right in our own hands. We shouldn’t give up on privacy for a deal on more security. The perfect end to this blogpost is a quote of Mikko, which I used in a previous blogpost aswel:

Privacy is implied, privacy is not up for discussion. This is not a question between privacy against security. It’s a question of freedom against control.



Application Security Engineering Analyst @ LSEC

Some of you may know I work part-time for a security firm called LSEC – Leaders in Security, or if you didn’t know, now you know. Some ask me what I do and what keeps me busy, well the upcoming conference is a good chance to explain it. I have the opportunity to go to the Cloud Security Alliance EMEA conference in Rome. This is quite the opportunity, as a lot of great speakers are scheduled to give a talk (Google, Dropbox, Microsoft, LinkedIn, Atos, etc).

Cloud Security Alliance is an organization which focuses on security issues when transitioning to the cloud. Or more in general, security issues which should be considered when you’re talking about running applications in the cloud. My official function at the firm is Application Security Engineering Analyst, quite a mouthful; I know. Basically I do research on the migration to the cloud. More specifically, I will try to pin-point security issues and bundle best practices when a company wants to move their systems to the cloud.

Moving to the cloud has a lot of benefits and is thus becoming increasingly popular. Employees can work from anywhere and the company does not need to manage resources, the cloud does this for you. Scaling is no issues, if you need more resources; you simply update your agreement with the cloud service provider. But as you might sense, these advantages do not come without any issues.

When migrating your traditional software to the cloud, you’ll need to scan your code and architecture. If your software uses some shared resources (specific company data), you’ll have to make the choice to move it to the cloud or not. The outcome of this decision affects the other systems who share the resources. From a security point of view some other, additional questions may arise:

  • Does the CSP provide sufficient data encryption?
  • Does the CSP provide strong authentication (using TPM’s, smartcards, card readers, …)
  • Does the CSP support multi-factor authentication?
  • What if your software uses LDAP for example. This is typically deployed internal in the company’s network. Does it need to be made accessible to the programs running in the cloud or are we replicating LDAP in the cloud?
  • Does the CSP emergency response team respond fast on vulnerabilities (i.e. heartbleed).
  • ….

I think it’s quite clear that there’s a lot to cover when a company decides to migrate their applications to the cloud, a lot of security issues need to be taken care of and be thought well through. So the main part of my job consists of doing research in state-of-the-art security mechanism for cloud platforms and searching for possible security issues. Which is a fun job to do.

Everybody who wants to follow me on the CSA EMEA 2014 conference can check my twitter or the blog on!



Android Security: Dangers of hybrid frameworks (XDA:Devcon14 write-up)

At the end of September I gave a presentation at xda:devcon14 which gave an overview of attack surfaces in Android and security issues in web-based applications. I have put my slides online on slideshare, and a lot of people were asking questions, so I decided to post a write-up.

Attack Surfaces

A big part of the presentation covers attack surfaces in Android, what are they?

Attack surfaces are pieces of code which are executable by everyone who has access to a system. They are called the open flanks of a system and allow input or code execution, not necessarily from a malicious user. A hacker will usually search in these places as these are the most interesting to manipulate.

In order to decide which attack surfaces an attacker will try to attack some properties of the surface are considered, as mentioned in the slides. These properties determine what the gain is for an attacker once he successfully compromises the surface entirely or just the code behind the surface. The general rule here to follow, is that an attacker will try to gain as much privileges as possible with the least amount of investment of resources and time.

I will not cover all the attack surfaces but only the one that is interesting for web-based applications. This is called the remote attack surface, more specific the WebView component. This is a class which offers functionality to render web content using the webkit render engine. This is a broad attack surface as a lot of web technologies and protocols need to be supported. These all represent an attack surface on their own, with their own vulnerabilities and security models which can be in conflict with the Android security model. Which is the case when we consider hybrid frameworks.

To be on the same page, I define a web-based Android application as an application who uses the Webview class to render web content.

JavaScript-Java Bridges, burn them

Security issues arise when you use a JavaScript-Java bridge in your web-based application. Android allows in the Webview class to call Java native code from Javascript, you can register the native code that can be called by using addJavaScriptInterface(). The security issues become apparent when you don’t know which content you are loading.

What happens with JavaScript being loaded in an iFrame? Or more general with JavaScript coming from a third party source?

Basically there is nothing stopping them from calling your Java native code associated with the JavaScript bridge. Android uses a permissions model to allow apps to do certain actions. Third-party JavaScript can call the same public methods associated with the JS bridge. This is because the Same-Origin-Policy is not applied to the bridge. It is in conflict with at one side native code running in a permissions security model and on the other side web content, which is bound to the SOP. These two security models do not interleave perfectly and thus allows attackers to use functionality the user never granted permissions for.

Hybrid Frameworks (Apache Cordova, Sencha Touch, …)

Hybrid frameworks are frameworks who let you develop a web application using HTML5, CSS and JavaScript for example. They allow you to pack your application to run cross-platform. Benefits of this approach is the fact you only need to develop your application once and you can pack it for the different platforms. This saves you time and money if you need to pay the developers.

When packing your application for Android, the following happens. Your web application is nothing more than web-content running in a Webview class. These frameworks come default with a Java-JS bridge which are publicly available. The same problems arise as mentioned here above with simple Webview applications. There are however solutions to these problems.

Domain Whitelisting

Just implement your own origin policy! You decide which third parties you trust. For hybrid frameworks it is fairly easy, just use the domain whitelisting functionality. The funny part here, is the fact that default this is implemented as allow every domain. Yeah, you’re welcome.

In applications using a Webview-component the solution is to just intercept pageloads and resource loading requests and implement whitelist logic to deny loading if you don’t trust the origin. The slides give you the two interesting methods which you need to override in the Webview class: shouldOverrideUrlLoading() and shouldInterceptRequest()

When a third-party ad-network is used the same vulnerabilities are present as ad-networks can inject third-party content. Recent study of MWRLabs discovered the following numbers:

A script was then crafted to automatically download Android applications, decompile them and identify if an ad network was in use, and if so determine if it is vulnerable. Out of the 1,000 top applications 570 were found to be vulnerable.

This means that over 50% of the Top 1000 web-based Android applications are vulnerable. Makes you think, if security is a key aspect and concern, stay away from web-based applications. It is very tricky to get it right, and in the end native coding is more fun 😉


PS: Those who want to see the talk, it was filmed, but is not yet online. Keep an eye on this blog or my twitter feed 😉

First conference talk. Exciting!

So tomorrow starts an exciting and stressy three days. I will be talking at xda:devcon which is a pretty big deal for me. Never did something like this, but because of the topic I have a strange relaxed feeling. Strange in the sense that I would expect to be far more stressed, but that will probably come tomorrow or saturday. *knocks on wood*

I like my topic (Android Security) because it is a topic that combines my two big passions in the field of computer science. An awesome mobile platform (Android) and computer security. Hence my talk will be an introduction to Android, attack surfaces on Android and I will end my talk with the security in web-based Android  applications. For the full abstract of the talk:

Android Security Overview and Safe Practices for Web-Based Android Applications

The talk will start with a brief overview of the different layers of the Android platform, highlighting interesting parts for attackers. Layers covered will be: Android apps, Android Framework, Dalvik Virtual Machine, User-space native code, The kernel.

Next the talk will cover the attack surface for Android. Covering several attack surfaces for example: remote attacks, physical, local…

And last, the bigger part of the presentation will cover web-based apps. These are apps made with web technology and compiled into native apps by using for example: Apache Cordova. Web applications have different security issues than native applications. I will try to inspire developers to take better care of security when using and developing their own web-based app using the WebView component. This component has been a big source of application vulnerabilities along with the JavaScriptInterface logic.

Another thing I like about giving the talk, is the fact that my talk is scheduled on an awesome conference. xda:devcon is a community for and by developers. Helping each other and always raising the bar in Android development. When I joined the community several years ago, I never thought I would one day giving a presentation at a conference organized by XDA-Developers. Really looking forward to meeting new talented people. If you want to stay tuned you can follow me on twitter or fb where I will probably be spamming the living shit out of it.

For the interested, there will be no livestream but the presentation is likely to be filmed and put on YouTube.

Well, wish me luck!


PS: BIG BIG UP for my sister, she graduated today and received her second diploma! Proud brother here!

Internship: Interesting week

Hi there folks! In between washing clothes and studying, I’m having a small break for writing a blogpost. Last week has been a good week, a lot of interesting things happend! I worked on a fork of the BouncyCastle crypto library to use in an Android runtime environment. Something similar to SpongyCastle but to be independent and have our own java security provider, we prefer to fork the BouncyCastle library and add our own changes. My job was to perform an upgrade to the new BouncyCastle version. This means pulling in the code and fixing the problems that arise with incompatible or new code. I finished the project rather early and have some time left on my hands.

Since I have time left, my boss proposed to teach me how to program Hardware Security Modules (HSM’s) and setting up Public Key Infrastructures (PKI’s) which are core systems in for example every security system of a bank. It makes sure your transactions are performed in a secure and trusted environment. This will be a very hands-on experience which I don’t think you can learn in school (apparently some dare to discuss that if you make the right choice of course), the experience of someone in the industry is really big. That’s something I started to realize early on in my internship and now am more than aware of.

Besides work I also did some things which the most part consisted out of studying for my exams. Other than that I also skyped with my girlfriend, which flew to Peru on Tuesday , where she will be staying till the end of december! Thank God for technology like Skype, imagine if I could only write letters or e-mails to her and don’t see her pretty face!

We also had colleagues in, from a dutch company called Advanced Encryption Technology (AET Europe) . Me personally did not have much to do with them, as my project is focused on a whole other part of the business than they are conducting. But this meant that we went for dinner in the evenings on Thursday and Friday. Had the best fish in the world on Friday by the way, truly marvelous. Despite the fact that you learn a lot at the internship itself, you learn more from these dinner talks. How things are done on a managing level, as everybody (besides the spanish intern José and me) sitting at the table have managing positions. Interesting talk with the head manager on how he selects his people and how they do the sales and development of their product. Too much to sum up here.

Signing off for now, got some work to do, groceries and studying => woohoo! This will be my last post originating from a swiss IP. Although I might use a swiss VPN in the future, which technically would invalidate my claim that this will be my last post from a swiss IP-address. Oh well, you get my point.

Cheers, folks!


PS: My last project is being open-sourced at

Interning: week 5: Whirlpool of emotions

Longtime no see, as they say.. last weeks were so busy, full of emotions and passed fast , I hardly found the time to write. Internship is going awesomely well. Finished the first part of the project which was kind of penetration testing and checking for information leaks. Now busy on the second part of the project which is updating a BouncyCastle fork for the Android framework. By far the most interesting library project in Android I have done.

Besides work I also had some free time here in Swiss, I kid you not! =D Although I worked mostly long days, but that is compensated by starting late in the morning. Anyhow, in my weekends I visited a friend up in the mountains, which was a nice experience! Last weekend was magical, my girlfriend came to visit me, had the best weekend so far here in Swiss. Miss her every bit of the way. And coming weekend my sister will visit with her boyfriend! Yeah agreed, I’m spoiled.

Okay, enough with the emotional stuff. Really loving the vibe at work, due to the small size of the team I have a very good contact with everyone in the office. Which basically nowadays is my boss,  a colleague and the other intern haha 😀 Learning a lot of stuff which is impossible to learn at school. Going from the JCA/JCE frameworks in Java and concepts and techniques for implementing crypto systems to working with HSM (Hardware Security Modules) and EJBCA enabled appliances (for PKI’s).

For the interested reader, I will be talking at XDA-DevCon which is from 26th till 28th september in Manchester, UK. My talk will be about “Android Security Overview and Safe Practices for Web-Based Android Applications”. Still tickets available!

Looking forward to the last two weeks (tomorrow is national holiday in Swiss yeaaah), signing off for now!



Week 2: Interning, eating veggie and doing laundry

It has been a while since I wrote a blog post about my internship (more than a week, woooah), anyhow got half an hour to spare as I’m doing the laundry. Yes, for the second time, no I have not ruined my clothes. Yet.

Made some progress at work, nothing too fancy but nevertheless it was a progression. For obvious reasons I won’t go into much detail. Oh and while compiling some stuff, which I needed for a cross-compilation, I managed to wreck my linux distro. On a Friday. Yeah not the best way to end your week.

On Thursday my boss Thomas took me to the oldest vegetarian restaurant in the world: Hiltl. I love meat so needless to say I was a little bit skeptical about eating vegetarian. I must say, that vegetarian burger was quite good. The restaurant was also simply amazing. I would certainly recommend it when going to Zürich, even when you’re not a vegetarian.  After Hiltl we went to a panorama bar in the center of Zürich. First you enter a restaurant and at the end of the restaurant there is an elevator which brings you to the sky bar. It is called Jules Verne, after the famous French writer. The view there was amazing. Not that cheap though 😉

Woops, there goes my alarm. Time to fetch the freshly washed clothes. Look at me, doing all grown up stuff.



PS: Go Belgium!!! Seriously Messi, just have a bad day today, thaaaaat would be great.


Serious crypto vulnerability in Android

The whole mobile/android world was shocked when a new vulnerability was disclosed which, to sum it up, weakens the security of the built-in KeyStore. However, the Android fanboy in me, couldn’t help but notice that a lot of media fail to cover the story in a correct manner. Bear with me here, it will get a little bit technical.

“The vulnerability resides in the Android KeyStore, a highly sensitive region of the Google-made operating system dedicated to storing cryptographic keys and similar credentials, according to an advisory published this week by IBM security researchers. By exploiting the bug, attackers can execute malicious code that leaks keys used by banking and other sensitive apps, virtual private network services, and the PIN or finger patterns used to unlock handsets. The advisory said Google has patched the stack-based buffer overflow only in version 4.4, aka KitKat, of Android. In an update, IBM said the vulnerability affected only version 4.3, which runs on about 10.3 percent of handsets.”

Now, a stack-based overflow itself is not that hard to exploit. However, every self-respecting security team in a big software company knows and implements countermeasures against these exploits/overflows. Android for example uses as 2 major ones: data execution prevention and address space layout randomization (ASLR). Without the technical details, this makes it pretty hard for an attacker to execute its own malicious code. But assume for now, that an attacker has the possibility to do this. It’s still pretty difficult to actually exploit this. Whenever you inject code into the stack on the Android OS, the code is converted to an ASCII 7-bit representation. So what, you may ask. Well basically this reduces the set of instructions that can be executed. Because of this 7-bit representation, the most significant bit is changed to 0 and you can’t encode values less than b’0011000. This restricts us to code words of the form b’ 0xxxxxxx 0xxxxxxx 0xxxxxxx 0xxxxxxx. Now consider this chart which represents the instruction set for an ARMv7 CPU, frequently used in Android devices.

Instruction set ARMv7 CPU

Instruction set ARMv7 CPU

If you look at the chart and interpret the 7-bit representation explained above correctly, you can see that all condition codes must start with a 0. That immediately throws out “always execute”. So every instruction you encode will be conditional. Furthermore, your Rd register always starts with a 0, pain in the ass but not something you can’t bypass. Basically you can only write to half the registers, bummer. Consider the compare functions, these require all a non-ASCII character. Whoops, no comparisons for you. To finish off with, the ADD instruction. The values you can add are constrained by the requirement that they do not include ASCII values below 0x30, so depending on what operand you choose you can only pass in certain values. To sum it up, you can’t use most of the instructions, write to most of the registers and your immediate operands are sharply constrained. Nevertheless the exploit is something that should be taken care off, but not something that should keep you awake at night.