Category Archives: Mobile Security

Post navigation

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?

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!

Roughly three months ago when iOS 9 was still the newest version available for the iPhone, we encountered a bug in the Twitter iOS app. When doing a transparent proxy setup for one of our iOS app security tests, a Twitter HTTPS request turned up in the Burp proxy log. This should never happen, as the proxy’s HTTPS certificate is not trusted on iOS and therefore connections should be rejected. Being shocked, we checked that certainly we did not install the CA certificate of the proxy on the iPhone and verified with a second non-jailbroken iPhone. The bug was repoducible on iOS 9.3.3 and 9.3.5.

After opening a Hackerone bug report with Twitter I took some time to further investigate the issue. Changing the seemingly unrelated location of the DHCP server in our test setup from the interception device to the WiFi access point made the bug non-reproducible. Moving the DHCP server back to the interception device the issue was reproducible again. This could only mean this was a bug that needed exact timing of certain network related packets. After a lot of back and forth, I was certain that this has to be a race condition/thread safety problem.

Dissecting the network packets with Wireshark, I was able to spot the bug. It seems that if the server certificate in the server hello packet is invalid, the TLS session is not removed fast enough/in a thread safe manner from the TLS connection pool. If the race condition is triggered, this TLS session will be reused for another TLS connection (TLS session resumption). During the TLS session resumption the server hello packet will not include a server certificate. The TLS session is already trusted and the client has no second opportunity to check the server certificate. If an attacker is able to conduct such an attack, the authentication mechanism of TLS is broken, allowing extraction of sensitive OAuth tokens, redirecting the Twitter app via HTTP redirect messages and other traffic manipulations.

I was not able to reproduce the issue on iOS 10. Twitter additionally fixed the issue on their side in Twitter iOS version 6.44, but noted that this was probably related to an Apple bug. We did not further investigate the issue, but the assumption seems plausible.

As I didn’t need to push the entire app configuration, I didn’t write a push-all.sh script. That could get messy with the permissions and I didn’t want to do a chmod 777. But of course you can do that if you like.

These simple scripts got me some really nice results during pentests. Activate apps that I only had in the free version. Reset the app’s PIN lock count. Disable ads showing in the application.

This is actually nothing very new, but what probably a lot of people do for a long time already. You can use this technique to do security reviews, to crack license mechanisms of apps, check how easy it is to modify your own app or do malware research. I’m not saying you should or shouldn’t do any of these. As usually tested on Mac OSX only but should work on Linux or other Unix, too.

After you run the disassemble.sh file you find the smali code for your app in the “outputs/smali-output” directory. Now you can change the app as you like. Here are three suggestions:

I recommend to add the android:debuggable=”true” attribute in the AndroidManifest.xml to your application tag. Afterwards you will be able to see the log messages of the application in logcat (“adb logcat” command when your phone is connected via USB).

Replace one of the png files in the ressources folder

If your application is making a new instance of a SecreKeySpec for encryption (something like “new-instance v1, Ljavax/crypto/spec/SecretKeySpec” in smali, grep for it), try to dump the contents of the secret key. That’s pretty easy with IGLogger. Download the IGLogger files and put the iglogger.smali file in the folder “outputs/smali-output/<you app’s name>/smali/”. Then open the file where you found the SecreKeySpec intialisation. Add a new instruction after the invoke-direct line which will initialize the SecretKeySpec (e.g. “invoke-direct {v4, v5, v6}, Ljavax/crypto/spec/SecretKeySpec;->([BLjava/lang/String;)V”). This is the place where the secret key is passed to the SecretKeySpec constructor. As we know that the first argument is the secret key, we have to log the Dalvik VM’s register v4. Add “invoke-static {v4}, Liglogger;->d([B)I” after the initialisation statement.

After you have done all your modifications, run reassemble.sh. There will be an apk file you can install on your device (see the last message that reassemble.sh will print). If you have added IGLogger, you will see a line in logcat that prints the secret key (for example run “adb logcat|grep -i IGLogger”).

Happy hacking
floyd

Here’s the disassemble.sh that will disassemble your apk file to smali code:

I’m a pretty happy owner of a Samsung Galaxy S3, Android Version 4.1.2. I don’t know if these things apply to the Galaxy S3 only, or if it’s the Android system that’s broken, but I’m pretty sure a lot of these things apply to all Android 4.1.2 phones.

As you might have noticed I’m a little paranoid, so of course I want all security features enabled. Especially an encrypted internal memory and encrypted SD card is important. So while I wanted to set up the encryption for the internal memory, the device asked me to set up a lock screen password first, that contains at least one number.

First mistake. Why a number? There are enough reasons not to force such complexity rules. Maybe I would put a longer password in there with only lower and upper case. Now I have to press and hold one of the number buttons, which takes about 2 seconds. An alternative is to press 3 buttons to get a number. When you’re a fast typer you can type in 3 lowercase letters in that time, which is a lot stronger than having only a single number in it (if the attacker can still not rule out a number). Ok, whatever, let’s go on. But wait.

Second mistake. Why do I have to set up a lock screen password for device encryption? Answer: The disc encryption password is the lock screen password. Device encryption and lock screen are two different things. One scenario is a cold boot attack attacking the disc encryption password. The other one is when an attacker finds a device that is still running (let’s call it running device attack). If we want a shorter password for the lock screen for convenience reasons, then of course the security will decrease and running device attacks will get easier. But security does not decrease for cold boot attack scenarios if you’re able to use two different passwords. Of course you can argue that the running device attack is much more likely for mobile phones. But with some crypto you can easily make two different attack scenarios with different risks, depending on each password. So why do they have to be the same? The only conclusion I drawed at this point was that the disc encryption key will be properly wiped when the lock screen is enabled. So to unlock it you would need the disc encryption password (I was so wrong).

After setting the password I encrypted the SD card first, then the device. From that point on, I had to type in that long password every time I unlocked the screen. Annoying, but at least it’s secure as long as nobody is looking over my shoulder when I’m unlocking my phone (again, he would get the password for the cold boot AND the running device attack).

I took a month to think about the next security measure: Setting up SamsungDive. It’s the Samsung service where you can locate/wipe/ring your phone in case it got stolen or you lost it. I wasn’t sure if I wanted to do that. What if there is a security breach at samsungdive.com and somebody wipes my phone? And do I really want to give all that private information to Samsung? In the end I decided I wanted the feature anyway, so I set up a SamsungDive account. When I logged in, I realised there is another feature: Unlocking the screen remotely. Of course this would work for non-encrypted devices, but it won’t work for encrypted ones, because the encryption key was wiped when the screen was locked, right? Wrong.

Third mistake. The encryption key is not wiped when you lock your screen. It’s merely just to annoy the user that the lock screen password has to be the encryption password. After encrypting the device you can not change the lock screen type any more, everything is grayed out, except the password:

But let’s unlock the screen from the SamsungDive web site:

Now there is no screen lock anymore. Disabled. Gone. You don’t have to type in your password anymore. Look, swipe means no lock screen:

And when we want to change the type of lock screen mode again (clicking on Screen lock – Swipe), we get the same picture again:

The lock screen does not wipe the encryption key after all.

After reverting to the password lock, I wanted to show a picture to one of my friends… but the SD card pictures were not recognised anymore.

Fourth mistake: The SD card encryption is disabled, the data not accessible. I restarted my phone, but the usual message that the SD card is encrypted didn’t pop up. And there is no option in the Android preferences to tell the system that the SD card is encrypted. The only option is to encrypt the SD card again. And that would double encrypt the already encrypted files. Fuuuu! So far I didn’t have enough time to check how I could restore the data, I might write a blog post about it, but for a start, check the Android source for the encryption. So far I copied down the encrypted files, but probably they’re unrecoverable. I guess the master key on the device was overwritten when I enabled encryption for the SD card again.

And I hate so say it, because there are too many Apple fan boys out there (I don’t need individuality, iPhone, iPhone, iPhone!), but: Yes, regarding device encryption, the newest iPhones are at least a little bit better. We are not talking about a device PIN of 4 digits, everybody knows that’s crap, but at least the disc is partially locked with this PIN when you lock your screen. It will protect your mail index, the keychain and files specially tagged by developers when your screen is locked. It’s a thought through concept of different encryption keys, although in the end that might not help that much (PIN bruteforcing, exploits, forensics…). Funny part is, that your mails won’t be stored encrypted on the iCloud (but that’s another story too). Well, let’s just say Apple is at least trying.

Unrelated fifth mistake: Factory Data Reset is totally broken for my phone. It was even better on my old Android 2.2, where it was at least deleting some stuff on the internal memory. That’s not the case for the Galaxy S3. I factory reset the device three times, it didn’t reset anything, just deleted the apps from the screens. All pictures, files, music, etc. is still on the internal and external memory. I wonder what it’s actually doing at all except from removing the icons from the different screens. Maybe this problem is because the phone was rooted once, but I properly unrooted it, so I doubt it.

As a pentester you sometimes get access to the source code of the application you are reviewing. Sometimes you can look manually through the files, but sometimes you get million lines of code and you don’t have time to spend sitting there, reading line after line.

The first approach that came to my mind was to use static code analysis tools. There are a lot of them out there, you can find lists of tools on the flawfinder page or you can have a look at Wikipedia’s list of tools for static code analysis. It definitely makes sense to use these tools, but it needs time to download/compile them and most of them are written for one particular language.

You will be reading a lot of code. If you want to do yourself a favour, use an IDE like eclipse to look at the code. Especially when looking at Java code you will find yourself quite often changing from one class to another and changing between files. With eclipse you only need one click for that. But still, you need different IDEs for different programming languages. So this is still not a universal approach.

As a penetration tester you often want to find the interesting parts of the code. To name some interesting things: everything related to cryptography, encryption, SQL queries, file read and writes, URLs and sockets, obfuscation, passwords and so on. And there is one really universal tool that let us find these parts of the code: grep.

The script I wrote here is pretty focused on Java/Android and Objective-C/iOS. But I also got some JSP and spring java framework specific code. So here we go, no rocket science, but I hope it’s helpful for someone in the future.

Of course the script produces a lot of false positives, but it should be a tool that supports you in your manual analysis. I’m sure there are a million more interesting strings we can add to the script. If you think something is missing, leave it in the comments and I’ll add it.

Oh and if you already looked at one version of a source code and you get a new version, you better use the “diff” command line tool and first have a look at the parts that changed.

Disclaimer: I’m not a Java internals specialist. Let me know if I got a point wrong here.

Wiping sensitive information when you don’t need it anymore is a very basic security rule. It makes sense to everyone when we talk about hard discs, but the same rule should be applied to memory (RAM). While memory management is quite straight forward in C derived languages (eg. allocate some memory, override it with random bytes when the sensitive information is not needed anymore), it’s quite hard to do it in Java. Is it even possible? Java Strings are immutable, that means you can not change the memory allocated for a String. The Java VM will make a copy of the String and change the copy. So from this perspective, Strings are not a good way to store sensitive information. So let’s do it in char arrays I thought and wrote the following Java class:

Does that make any sense? How does the Java VM handle this? And how does the Android Dalvik Java VM handle this? Does the Android system cache the UI inputs anyway (so there would be no point in wiping our copies)? Is the data really going to be wiped when I use this class? Where are the real Java internals heroes out there?

Update 1, 11th September 2013: Added Beerware license. Note: This was just some idea I had. Use at your own risk.

Just this last time I will talk about this encryption key, but then I’ll shut up (for me this is so 2011). I presented this thing last year at conferences, but if you just look at the slides I think it’s hard to get the point.

During my Android research in 2011 I encountered several bad practises that are wide spread. Especially hard-coded symmetric encryption keys in the source code of Android apps are often used. One special occurence of one of these encryption keys I just couldn’t forget: Why would Google (Ads) themself use such a thing? It’s not a big deal, but it just adds no real protection and I kept wondering.

445 apps I decompiled used Google Ads code and included the following AES symmetric encryption key:

This AES key is used to encrypt the last known location of the user (all location providers: GPS, WIFI, etc) and send it to Google via the JSON uule parameter. Most of the time the key is located in com.google.ads.util.AdUtil.java, com.google.ads.LocationTracker.java or if the app uses an obfuscator in u.java or r.java. Here’s the corresponding code:

This code was produced by a decompiler, so it won’t compile, but you get the idea. Instead of using symmetric crypto, they should have used asymmetric crypto (public key in app, private key on server). There would be no way to intercept the last known location on the network then. Ok, here’s the timeline:

June 2011: Notified security@google.com (auto-response)
October 2011: Talked about it at 0sec / #days and spoke to two friends at Google who are not in the Android/Ads team. One of them (thank you!) sent my mail to the responsible people at Google.
Februar 2012: After a couple of emails I got the answer that they are going to switch to SSL

If you ever find the uule parameter on your network, let me know. One last thing: Depending on your decompiler, the AES key will look like this (wrong decompilation):

This is not a valid way to define a byte array in Java, because the integers must be between -127 and 128 (signed integers). That’s another funny fact: if you ever have to brute force a Java byte array like this, I would start with keys where every byte starts with a 0 bit (MSB=0). I saw a lot more of those keys. It seems that some Java developers don’t know about the instantiation with signed integers and therefore choose only numbers between 0 and 128.

There is a lot of discussion going on how to store credentials on the Android platform. What I’m going to discuss is focused on the Android platform, but you’ll notice that most of the things can be applied to all mobile plattforms. There are some differences, e.g. that you should use the much more evolved secure keystore of the iOS. There will be a keychain in Android 4.0. But of course you can screw up the secure storage on all platforms or even examples of the vendor show you how to screw up.

Before you start storing credentials the most important question is:

Do I really want to store that data and why?

Before you simply answer “yes”, consider the following:

Do you want to authenticate the user inside the app to check if he is allowed to access the app and other data?

Then use a secure cryptographic hash function (e.g. SHA-2). Use a salt which is long enough and randomly generated on the fly. You can store the salt in plain along with the generated hash. Use multiple hashing rounds (e.g. 10’000).

Before I go back to how you should store the credentials: Please use a secure channel to the server. One possibility is to use SSL (e.g. a HTTPS connection), but make sure you check the server certificate. Another possibility is to include a public key and have the corresponding private key on the server (actually I like this version even better, because you don’t have to trust hackable CA root companies).

Change the server side. Talk to your customer if you are developing an app for someone else, it’s not a big deal to change something on the server side. Try to store a session token instead of the password. Even increasing the expiry time for sessions is better than storing passwords on the client. Only increase it if the request is coming from the Android app, but not for all clients (like standard browser authentication).

If your really can’t change the server side and you can not use a token, you have a problem. Whatever you are doing from now, you have to store the password in reversable form, but the client isn’t a good option for that. Attackers equipped with root exploits and reverse engineering skills will always be able to get that password from somewhere (most of the time from the code or the filesystem). Consider that people often reuse passwords, which is a bad habit and if the password for your application is extracted, there might be other services that have to suffer from the laziness of the user.

There are several ways of how you could try to protect the credentials, but again, they’re all useless against a sophisticated attacker: E.g. encryption (key in the source code) and good obfuscation (some are just useless). EDIT: With the new Android KeyChain you are even better off if you have a hardware-backed storage on the device. Simply use the KeyChain to store a private key that you use to encrypt the password. The password can only be decrypted when the attacker is in the posession of the device, as he can not extract the private key from the device. Well of course he can extract the key, but root permissions are not sufficient and it means messing with the hardware (which is very expensive).

At least tell the user how the credentials are stored, why it could be a problem and what they can do to be protected (e.g. disable “remember password”).

Last weekend I had a talk at #days in Lucerne about the Android topic again. Because the slides are nearly identical, I just provide the 0sec slides here. The conference was amazing, I really enjoyed it. Additionally I can really recommend the “Win32 Exploit Development Bootcamp” by Corelan, it’s one of the best courses I’ve ever attended.