Watch this to have a better understanding of what goes into a mobile penetration test and how it helps protect your data, your company, and your users.
Hi, everyone. Welcome back.
My name is Aaron Bishop, and today we'll follow-up mobile penetration testing one zero one where I touched on what is a mobile penetration test with a focused look at what happens during a mobile penetration test. I will be going more in-depth answering questions such as what is the analyst actually doing? What vulnerabilities are they looking for?
By the end of this session, you'll have a better understanding of what goes into a mobile penetration test and how it helps protect your data, your company, and your users.
I'll use an intentionally vulnerable application to demonstrate different vulnerabilities, but this won't be a deep dive into the technical how tos. If you're interested in learning more, I've got some great resources for you at the end. So let's explore what actually happens during a mobile penetration test. Think of this as a behind the scenes tour of the process. I'm gonna be using an intentionally vulnerable app, Insecure Shop, to demonstrate part of the process and some sample vulnerabilities.
Insecure Shop has multiple challenges or vulnerabilities that could be exploited.
This isn't a walk through of Insecure Shop. We're not going to cover all of the challenges, but I will present solutions to a few of the challenges.
So spoiler alert. If you're planning on tackling this on your own, you may wanna skip parts of this presentation.
We'll start at the beginning. Getting started, this includes quickly installing the app to a test device, setting up a proxy to view traffic, and a walk through of the application. Next, we'll move on to identifying attack vectors. This is where things get interesting. We'll look for potential weaknesses in the application.
Then we'll shift our focus to exploiting vulnerabilities.
Here, we test those weaknesses to see how much damage they could cause and justify the risk. We'll wrap up with some final thoughts where I'll include some takeaways and key recommendations. Before testing begins, we ask our clients to provide an APK or an IP IPA for the application that we are testing. We're starting from that point.
We have an APK for Insecure Shop, and I'm gonna use a tool called MobSF to get an overview of the app to essentially get a map of areas I may want to explore further. When you launch MobSF, you're presented with an option to upload an APK or an IPA, and after a few seconds, a report is generated. I already uploaded the APK, so now it shows up in my recent scans, and I can go over and view the static report. At the top of the report, it shows exported activities, services, receivers, providers.
I'll explore those more in-depth later. This is interprocess communication that could be an avenue for attack. We also have the option to view the Android manifest and to view the source code. Continuing down, we see the permissions that the app requests. Some of those permissions are labeled dangerous and will require further investigation.
For instance, what is being written to external storage? Is it sensitive?
What information is being read?
How is it being used?
I won't cover all of the sections as the report is rather large. There's a lot of information that provides a great foundation when you're starting testing. One area I do wanna focus on for this presentation is the hard coded secrets. The reason I'm gonna focus here is one of the hard coded secrets or the only one appears to be for an external resource, and we're gonna use that later for identifying vulnerabilities and exploiting it. Let's take a look at the app on a device. We're gonna use a process called sideloading, which means we're installing the application. We're not going through a traditional Play Store.
Sideloading an APK is easy. If you have Android Studio, you have something called the Android debug bridge or ADB.
ADB install gets the app or installs the app on the device. Once it shows success, the app should be ready to use.
At this point, I like to start my intercepting proxy. This captures all traffic from the application as I explore its functionality.
For mobile testing, I like to use a tool called HTTP toolkit.
It works well even with apps that try to bypass system proxy settings. This screen shows HTTP toolkit on the left and my emulated device on the right. I'll search for ADB and HTTP toolkit and launch it. And this will start a VPN between my emulated device and my laptop.
When I launch the application, network traffic will be captured. Now Insecure Shop doesn't use an API, so we don't see any traffic. Before testing begins, we request credentials from our clients. This insider access allows us to thoroughly explore the application's functionality, simulating unknown users' experience.
However, depending on the client's objective, we may conduct a black box assessment where no credentials are provided.
That's the situation we're in with Insecure Shop. I could dig into the source and look for API information such as keys or requests and recreate them.
However, I know Insecure Shop doesn't use an API.
So I'll step back and look at the hard coded AWS secret, then I'll take a look at the source to see if I can find a way to get in. That means we are moving on to the identifying attack vector section. There's a great presentation that Andreas Bianco, sorry if I miss Merrell's name there, shared at BlackHat in twenty nineteen.
The presentation contained a Python script that leverages the AWS identity pool ID to get AWS credentials.
The script is run using the AWS identity pool ID that we identified in MobSF.
An access key, secret key, etcetera, are returned.
I'll use those later in the exploitation phase to see what I actually gained access to. For now, I'll move on to exploring the source code. First, I need to decompile the APK.
I use a variety of tools for this depending on the situation. My code viewer is useful for its multiple decompilers. JADX GUI has some nice features and accepts APKs.
I'm gonna start with JD GUI. I can click on a function and jump straight to the definition, which I'll need shortly. First, I need to convert the APK to a format that JD GUI can can open.
Dex to JAR will convert the APK into a JAR file.
Opening it in JD GUI reveals applications contents.
There's no API to investigate, so instead, I'll focus on the login activity. If login activity open, we see something similar to what the original source code might have looked like.
We can scroll down and view the functions that are called to better understand the application's behavior.
The function I'm most interested in is on login.
As I examine the functionality of on login, I see two locations where text input from the application are read. Here, string two, and here, string one.
If we look further, we see username is pass the log function, and the variable string two is included in the message as well as password with the variable string one.
It's a strong indicator that sensitive information will appear in the logs generated by the application.
We can verify that shortly by looking at logcat.
Just below the log calls, you see a verify username password, and string two and string one are passed in as arguments.
If we click on the function name, verify username password, we jump to the corresponding class and function call.
We're now in the util class. It checks that the values are not null and then calls to get user creds function. We'll go ahead and click on get user creds, and we jump up in the util class, and we see what may be credentials for a user of the application.
Here we see the Insecure Shop app at the top left, HTTP toolkit open in the top right, and Logcat open at the bottom.
HTTP toolkit is monitoring for any network traffic generated by the app. I have log cabin open to observe any log messages and any potential sensitive information that may be disclosed.
I'm going to log in as shop user.
I've copied the password we saw in the source code.
So I'll go ahead and paste that and hit log in. We can see some HTTP request requests were generated and captured.
Those requests appear to be requests for the photos that are used to populate the shop. A number of log messages have been generated as well.
As we scroll up, we see the username and password are included in debug messages. Before moving on, I'm going to explore another option to bypass the login.
I'm going to hook the verify username and password function.
Hooking changes the behavior of a function. In this case, I'll make verify username and password always return true, so any value can be used for the username and password. This requires a patched version of the app or device that you can run a Frida server on, neither of which I'll get into in this presentation.
To leverage Frida, I need to create a script that will override a given function.
Here's a script I came up with. It simply returns true when verified username, password is called. With that finished, I can go ahead and launch Frida with the option to load the script and attach to the Insecure Shop process. Back on the Insecure Shop app, I can now go ahead and enter a as the username and a as the password and gain access to the application.
Well, I'm not going to touch on all possible vulnerabilities.
I'm gonna show one more attack vector that'll bring us to our final topic, exploitation.
For this, I'll start with a tool called Drosir and look at the attack surface. This shows six activities, one content provider, and one service are exported, meaning they're accessible to other apps on the device.
We already saw this information on MobSF.
Focusing specifically on the content provider, we see it's com dot insecure shop dot content provider dot insecure shop provider.
I'm going to invest investigate this a little further in the source. Jumping to com dot insecure shop dot content provider dot insecure shop provider, we can see just how this is being called, what values are needed, what the behavior actually is. And we could determine that if the URI is set to insecure, the username and password from shared preferences will be returned.
Trying to demonstrate it using drove Droser returns an error because it lacks the necessary permissions. So we'll need to take a different approach, which brings us to our final topic, exploiting vulnerabilities. Looking at the Android manifest, the entry for insecure shop provider shows that a read permission is needed.
I have a simple malicious app that I've added that read permission to. I also added functionality to query the provider.
When my malicious app is run, the credentials are retrieved and displayed. Now imagine this in a real world scenario.
The malicious app is a free game, something that a lot of users may install and forget that it's even installed.
The vulnerable app is the medical app I talked about in the last video.
All communications from your doctor could be intercepted and shipped off to unknown parties for unknown purposes.
In the case of this app, your credentials could be intercepted and shipped off to an unknown user for unknown purposes.
Alright. Let's jump back and put those AWS credentials to work. I'll use the AWS CLI and pass in the access key and the secret key and the token, and then use the LS command to see the buckets that we have access to. You can see that we have access to a couple buckets here. We can go ahead and dig into the contents and see what's contained in there. Sometimes it's treasure trove of information.
We found passwords, SSH keys, API access keys, and customer data, like credit card information or health care data sort as well. I want you to take a minute and consider what may be unintentionally exposed in buckets that that you control or you manage.
I'll go ahead and let you review the contents of these buckets on your own if you decide to recreate this vulnerability and see what you find. In this demonstration, we first uncovered hard coded credentials. Specifically, we found an AWS identity pool ID embedded directly in the app code. Exploiting this allowed us unauthorized access to s three buckets.
Next, we explored bypassing client side controls. By hooking one of the app's functions, we effectively bypassed an authentication check. We also highlighted the dangers of insecure interprocess communication.
We showed how a seemingly harmless separate app could interact interact with an improperly exported provider.
This allowed that harmless app to directly access sensitive data, like user credentials that insecure shop had stored.
These examples explode expose cloud keys, easily bypass client side logic, and secure data sharing are really just scratching the surface of what's possible within Insecure Shop. They represent only a small sample of common mobile application vulnerabilities.
The vulnerabilities and risks aren't limited to the ones that we covered in this presentation.
For instance, in a previous presentation, I discussed a real world scenario where an app downloaded its entire user database and then carelessly stored it in external storage.
This made sensitive data accessible to potentially any other application that was stored on that was installed on the same device.
Furthermore, everything we've looked at so far focuses on the mobile app itself.
We haven't even delved into attacking the back end APIs that power these applications.
Many classic web app application vulnerabilities like SQL injection, command injection, broken authorization controls are frequent frequently found in these mobile APIs.
It's common to find that mobile APIs haven't undergone the same rigorous scrutiny as traditional web applications, creating another significant attack surface.
Alright. And now for the grand finale, my final final thoughts and recommendations.
It's the same final thoughts as last time. Mobile app security is paramount. Replacing sensitive data in a potentially hostile environment and proactive vulnerability identification is crucial.
Mobile penetration testing remains invalid invaluable for simulating real world attacks and finding weaknesses automated tools miss. It's an ongoing process, not a one time fix, especially given the evolving mobile threat landscape.
To reiterate, here are key immediate steps.
Eliminate hard coded credentials. Address web app vulnerabilities in your mobile back end.
Secure data storage. Harden inter process communication.
Remember, as we demonstrated today, vulnerabilities like hardcoded credentials and unprotected interprocess communication can lead to serious problems.
And last but not least, the resources I promised.
A few of the resources or tools that were used. The presentation I referenced is also included in this list, and there's a link to Insecure Shop if you wanna download it, install it, and explore it further. Maybe practice exploring the vulnerabilities we talked about here.
Thank you all for joining me, and stay vigilant.
.svg)
