Alohomora

Hi friends!
Time for another post.
A few weeks ago a friend came to me with a request.
He installed an app locker app and forgot the password, the rest is really self-explanatory.

Although it’s a highly rated popular App from a big company (10M+ downloads) I decided to take my chances and try to bypass it’s protection mechanism and maybe find some more interesting stuff while doing so.

I strongly advise you to read the previous article –  “Better Luck Next Time – APK Patching”. It contains the basics of the Android APK format which I assume you already familiar with.
Before I begin, I tried to contact the developer by mail but got no answer.
If you know how to reach him I’d appreciate if you leave a comment with the details.

Stage 1 – Recon
The goal here is quite straightforward – get as much information as you possibly can. But even before digging in, the first step I take in every vulnerability research is to explore the target as a normal user. Before I jump to more complex steps I want to grasp a better understanding of the target – size, complexity, bugs, requirements…

I really try to get into the developer’s head and figure out where are the weak spots of the target.

When I have a solid understanding of the app I start to gather all the information I can. Really, every little piece of it can make the difference between success and failure.
An example for valuable information can be documentation, source code, libraries, binaries, symbols, manufacture info, previous vulnerabilities etc…

Stage 2 – Mappings
Time to take a look at the app itself, starting with its manifest.
I will use jadx for the static analysis of the app.

That’s a lot of permissions, some of them not being used at all.
This is a good sign for us to start with.

The app defines two permissions of its own – sync.data and C2D_MESSAGE. Unfortunately, they are enforced by signature. (It worth mentioning that sometimes, apps from the same developer share signatures).

I strongly advise you to take a look at the strings XML of the app and to take a look at a few classes. Sometimes you can find valuable information about hidden functionality within them.

To take the mapping procedure one step forward I will use ADB (the basic android debugger) and drozer by “MWR InfoSecurity” for the rest of it.

The first command I issue is “run app.package.info -a com.jiubang.alock” which gives you all the basic information about the app.

The next thing I do is to browse the app’s directory for interesting files.
Third-party apps are stored in /data/data/<package name>

The first thing that pops up immediately is the databases directory.

Android offers multiple standard facilities for data storage – Shared Preferences, SQLite databases, and files.
Most of the apps make use of the SQLite DB because of its robustness, simplicity, and maturity.

SQLite stores data in DB files. db-shm and db-wal extensions are used for caching.
I pulled the “alocker” DB files and parsed them. It contains 6 tables.

The tables are used for basic configuration info and settings.
A really promising table is the “secure” table.
it contains two keys and values

You don’t need to be a genius to figure these out.
locker_secure1 is the password length and locker_secure1token is the password hash.
A quick run in CrackStation reveals the plaintext password.

Vuln 1 – Insecure Data Storage

Stage 3 – IPC Attack Surface
So, in spite of the phone being unlocked, I wanted to go deeper and look for more potential vulnerabilities.

Before we go on, I want to introduce one of the most important additions to Android’s Linux Kernel – the Binder driver.

Binder is an IPC mechanism based on a modified version of OpenBinder. The relatively small driver (~4000 lines of code) takes a great effect on much of Android’s functionality.
In a nutshell, the binder operates in a client-server architecture and allows the process to invoke methods in “remote” processes synchronously. The bottom line – it is the base of APP’s IPC mechanism.

One of the most common vulnerabilities in Android apps is Insecure IPC endpoints. The “Android Hacker’s Handbook” describes:
“The common interprocess communication (IPC) endpoints—Services, Activities, BroadcastReceivers, and Content Providers—are often overlooked as potential attack vectors. As both data sources and sinks, interacting with them is highly dependent on their implementation; and their abuse case dependent on their purpose.

At its most basic level, protection of these interfaces is typically achieved by way of app permissions (either standard or custom).”

In order to find the IPC attack surface, I issued the following command – “run app.package.attacksurface <app name>”

From now on the work should be quite straight forward.
The command to list IPC endpoints look like that –
“run app.<service/activity/broadcast/provider>.info -a <app name>”

Then, search for the class in jadx-gui and get a basic understanding of what it does. To shorten things up I’ll just go ahead and jump to the vulnerable functions.
Let’s take a look at “com.jiubang.alock.ui.services.LockerService”

We can see a lot of possible actions.
In order to invoke one of them, I wrote a simple app in java using Android Studio that all it does is to send the proper intent.
In this case the action is “service.dismiss.locker”.

(You can also use the provided IPC mechanism of drozer in order to do that. For me it’s too simple and lacks important functionality.)
Now launch an app that prompt’s the locker app and then runs the specially crafted app. The Lock Screen is dismissed as if you entered the correct password and you are free to use the app as you wish.

Vuln 2 – Authentication bypass via Insecure IPC

The next class We going to take a look at is “activities.EncodeBySharingActivity”

We can see that it performs some kind of authentication check.
Taking a deeper look, the only thing being checked is whether a password exists or not. No authentication needed.

Afterward, the class checks some parameters and Encode Files according to them.
Time to craft another app.

When launching the app, we found out that the requested file in the parameters is now encoded – taking it one step forward it turns out that it’s possible to encode all the files that the app has write permission on.

Vuln 3 – File encoding via Insecure IPC

I decided to stop my research here.
I’m sure that there are a lot more vulnerabilities to find here so feel free to check it out.

In conclusion, it seems that app security still suffers from a lack of awareness compared to other platforms. I think it’s a field worth taking focus on for the near future, as attackers and as defenders.
Hope you enjoyed reading, feel free to leave comments. Thanks!

You can find a lot of information and great tutorials at the “android hacker’s handbook”.
Feel free to comment, ask questions, and correct me. Thanks!