Android Nougat’s worst anti-security mechanism

If you are a pentester like me, 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 a good solution and straight forward. There was a nag screen showing up in the notifications every time you start up your phone (which was already a little funny), but it worked fine for everyone. However, starting with Android 7 it will not work, I tested that and the official announcement about this user-added certificate security is here. So let’s look at this new “security” feature of Google’s Android.

First of all who is affected? I think only the defender side has to jump through this hoop. Because every attack vector I can think of is ridiculous. 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 security, 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 even 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 this is probably the worst idea ever? That would totally suffice in my opinion. If a user would be so stupid to install an unknown CA despite the warnings, everything is lost anyway. That user will also type all his passwords into any forms that look remotely like a known login form the attacker provides. Let’s also consider corporate Android phones. I can 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 disable installation of user CA certificates and delete all already installed ones on managed phones?

Secondly, why the hell does Android think that a user installed certificate is less trusted than the hundreds of preinstalled, nation-state-attacker-owned CAs?

Android, you are raising the bar for defenders, not for attackers. You don’t defend against any attack vector. You are not doing security here, you pretend to.

And yes, I know how to disassemble an app and reassemble it to circumvent this “security”. I even consider building an Android app for rooted phones that will pull the CA certificate of Burp, remount the system partition and install the CA there automatically.

Maybe the Android team is just sour because they are losing the rooting-detection game with SafetyNet to Magisk root (good job Magisk guys!). I seriously don’t have a better explanation.

And by the way I’ve heard the joke “Android is open source, change it!” already.

I thought I’ve seen many stupid Android security decisions, but this is exceptionally stupid. Or it’s me, please enlighten me in the comments!

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!