Android Nougat’s certificate pinning security mechanism

If you are a pentester like me, chances are you are doing mobile application reviews on Android. One of the most important things to check is the server API. On the other hand we might want to see what possibilities a server has to influence the Android app with its responses. For both the easiest and most straight forward method is to do a Man-In-The-Middle attack in the lab and look at the network traffic. How do we do this if the mobile app uses TLS? Easy, just install a user CA certificate.

Before Android 7 that was straight forward. After you installed the CA certificate, there was a little annoying screen showing a warning in the notifications every time you start up your phone, but it worked fine for everyone. However, starting with Android 7 installing a CA certificate is not affecting mobile apps, I tested that and the official announcement about this user-added certificate security is here. User installed CA certificates won’t be trusted by mobile apps and Android claims there is some security gain from this. So let’s look at this new “security” feature of Google’s Android.

First of all who is affected by this security feature? I think only the defender side has to jump through this hoop. Every real-world attack vector I can think of is not very realistic. First of all, a user would need to fully cooperate to let an attacker exploit this. As Android is not opening the security settings automatically when you download a certificate (like iOS), an attacker would have to convince the user to go to the settings dialogue, go to the security settings, scroll down, tap on “install certificate” and choose the correct file from the file system. Let’s say an attacker will setup a Wi-Fi access point and forces the user to do this or otherwise the user won’t get Internet access. This is the only scenario I can think of where a user might at all consider installing such a certificate. You might say that can happen with non-technical users, but then why don’t we just add a big red warning that websites trying to convince you to install a CA certificate are evil? That would suffice in my opinion. If a user would be so ignorant and install an unknown CA despite the warnings, we are in much bigger trouble. That user will probably also type all his usernames and passwords into any website forms that look remotely like a known login form, has an invalid TLS certificate or doesn’t use TLS at all. So for example the attacker could do easy phishing. For users of personal Android phones this is probably the biggest issue.

But let’s also consider corporate Android phones. I understand that administrators don’t want their users to decide on such a security critical topic. But why doesn’t Android just implement an Administrator API rule that would disabling installation of user CA certificates and delete all already installed ones on managed phones? There is already an Administration API that does various such things.

Secondly, why does Android think that a user installed certificate is less trusted than the hundreds of preinstalled, nation-state-attacker-owned CAs? Your Android already comes with various preinstalled CAs, which are not very thrustworthy in my opinion.

It seems Android is raising the bar for defenders, not for attackers. I don’t believe Android is defending against any real attack vector. It boarders to pretending to do security (snakeoil).

On the other hand I know how to disassemble an app and reassemble it to circumvent this new security feature. There are also Android apps that will allow you to install CA certificates in the root CA store on rooted phones, which is by far the best solution on rooted phones. Use Magisk and you have your perfect phone for security analysis.

I thought I’ve seen many strange Android security decisions, this is exceptional. Or is it just me?

Free OWASP membership

Timeline:

  • Beginning of 10.2011: OWASP was informed (including details) that the OWASP membership registration has a logic flaw (“please inform vendor”).
  • Beginning of 10.2011: Response from OWASP, vendor can not reproduce problem. Sent more details.
  • Beginning of 10.2011: Response from OWASP, vendor still can’t reproduce problem. Sent video below.
  • 19.10.2011: Bug report opened.
  • 15.02.2012: Checked back and asked OWASP if problem is resolved.
  • 26.02.2012: They don’t know. Checked flaw again, it still exists. Advised OWASP to get in touch with one of the organisation’s security expert to handle the issue (no response from OWASP).
  • 30.03.2012: Checked flaw again, it still exists. Informed OWASP and vendor directly that the video will be released in two weeks if it doesn’t get fixed.
  • 30.03.2012: Response from OWASP, they would find a solution until end of April. Agreed to wait until end of April.
  • 04.04.2012: Response from vendor, it’s fixed.

In my opinion half a year is long enough. Putting on some more pressure (regarding the release of the video) worked very well. I felt like I owe it to all the paying OWASP members.

Enough words, enjoy the video: http://www.floyd.ch/download/free-owasp-membership.mov

Officially untrusted

I’m very proud to anounce that my site is now officially hacker untrusted! It was a lot of work to get the certification and the certification process was very expensive. We cultivated value-added interfaces, orchestrated bleeding-edge ROI and iterated cross-platform partnerships. But finally we’re done. In the end it I know it will pay out. As a proof I’m proud to feature the official Hacker Untrusted logo in this blog post, which I received by myself and was approved by myself:

I hope I’ll be as successful with my new logo as the other guys here (read it and lol).

Ticket machine fail

I had to make a photo of it. Sloppy error handling: Swiss bus/train ticket machine. Failed RMI call on windows command line. I guess it’s Windows CE. I was able to move the mouse cursor and do single clicks using the touch screen. Fortunately there is no keyboard to type in commands!