The main purpose of a penetration test is to stay one step ahead of the bad guys by finding your weaknesses with the help of experts exploring your mobile app and supporting systems.
This blog is the transcript of the SecurityMetrics’ Webinar “Mobile Pen Testing 101,” hosted by Aaron Bishop. Check out the video webinar here.
The main purpose of a penetration test is to stay one step ahead of the bad guys by finding your weaknesses with the help of experts exploring your mobile app and supporting systems. However, one area you might not have considered exploring with a pen test is your mobile security.
In this blog, we’ll dive into the world of mobile penetration testing:
We'll also pull back the curtain and see what actually happens during a pen test, including what pentesters are looking for. We'll also share case studies from past engagements. You'll get a glimpse into the kinds of vulnerabilities we uncover and the creative ways we exploit them.
And to wrap things up, we'll distill everything down to some key takeaways and actionable recommendations.
We hope you'll walk away with a clear understanding of how to improve your mobile security posture, even if you're not ready for a full-blown pen test just yet.
We also have other great resources covering different types of pen testing, like Internal Pen Testing, External Pen Testing, and Web Application Pen Testing.
First, let’s address the fundamental question: what is a mobile penetration test?
We're essentially putting on our hacker hats and trying to break in, but with the goal of helping you, not harming you. We start with your mobile application and try to find any weak spots or any vulnerabilities that a real attacker could exploit to cause damage to your business, or even worse, to your customers.
Our main mission is to assess the overall security of your app and everything that makes it tick. That includes the mobile app itself, but it also extends to the APIs or back-end systems that your app talks to. If there are any cloud resources involved, those are also in scope.
We know that you're the experts on your own app. You and your team have lived and breathed this thing for years, most likely. We'll only be spending a few days with it, so we definitely want to hear from you. If there are any specific areas you're worried about or particular goals or objectives you have for the test, let's talk about them upfront.
Your insights are incredibly valuable in helping us focus our efforts, so you get the most out of the pen test.
Now that we've touched on what it is, we'll move on to core activities and processes involved in a mobile penetration test.
When we kick off a penetration test, the app itself is our starting point. We roll up our sleeves and get hands-on with it, digging into its inner workings.
To guide our efforts, we rely on the OWASP mobile application security testing guide and the associated checklist. They are fantastic resources packed with industry best practices and known vulnerabilities. This ensures our assessment covers all the critical bases.
After that, one of the key things we perform is a source code review, if it’s provided. Many Android and cross-platform apps can be decompiled back to a semblance of the original source code. We'll also ask if you're willing to provide access to the source code.
If we can get our hands on the code, we'll comb through it, looking for any vulnerabilities, hardcoded secrets, or potential weak spots that attackers could exploit.
We take a close look at what the app is storing on the device and ask questions like:
We also see how the app interacts with other apps on the device to try and see if it’s sharing data securely and if there are any communication channels that could be hijacked. And, of course, we'll examine how the app talks to the outside world, cloud services, APIs, those sorts of things. We need to make sure those connections are secure, and data is protected in transit.
Most mobile apps don't exist in a vacuum. They're constantly talking to backend servers and sending and receiving data through HTTP requests.
And while that's great for functionality, it also opens up a whole new world of potential vulnerabilities, the kind of stuff that keeps security folks up at night. Think of it like this: your app is chatting with the backend, but what if someone is eavesdropping on that conversation? Or worse, what if they're trying to inject their own malicious payloads into the mix? That's where our testing comes in.
We'll intercept the traffic between your app and the backend. Think of it like tapping a phone line, but for your app's data. Once we have that access, we can start actively probing for weaknesses.
Some of the key things we'll be on the lookout for include:
The mobile environment presents unique challenges and attack surfaces, creating opportunities for vulnerabilities that are distinct from traditional web applications.
There are plenty of examples of vulnerabilities like SQL injection, XML entity injection, and access control issues that affect the associated API, but these can also be found during a traditional web application penetration test. So these examples won't be included here.
Instead, we’ll focus on three cases to highlight:
Through these examples, you'll get a glimpse into vulnerabilities found in mobile applications, we'll explore how well-intentioned features can be leveraged to compromise accounts, extract sensitive data, or even take control of the device.
These stories showcase the importance of thorough mobile app security testing and the ingenuity required to stay one step ahead of potential threats.
This application wasn't available on an official app store, but it had a built-in feature to check for updates whenever it was launched.
Sounds convenient, right? Especially since it was a private, internal application, that didn't have the normal update process of apps you get through the App Store.
The problem was it didn't do its due diligence. It didn't bother to double-check if it was talking to the real update server or if the update it was downloading was even legitimate.
We saw an opportunity there. Using a technique called ARP poisoning, we tricked the app into thinking a server we controlled was the update server, then we served up a malicious APK. Once the app installed that bad update, we had shell access to the device.
The ‘install_packages’ permission is especially dangerous. Developers need to treat these permissions with the utmost care and build strong security checks to prevent unintended actions on a user's device.
This next case study highlights a significant security concern related to how mobile apps share data.
On mobile devices, each app is like its own little world, isolated from others for security. If you're familiar with UNIX file permissions, you can see each app is owned by a unique user, and the contents are only accessible to that user. But sometimes, apps need to talk to each other, maybe to share a photo or a document.
We were testing a healthcare app that let users interact with their doctors and share medical records.
These files were stored in the app's local storage, so no other application on the device should have been able to access them.
The problem was this application accidentally exposed a provider. Think of it like an open door. Any other app on the phone could walk right in and access those private medical records.
We demonstrated this by creating a simple application that exploited this vulnerability to read records that had been stored.
This is a big deal since it means someone could create a seemingly harmless app that secretly steals your health care information. That vulnerability could have led to identity theft and insurance fraud.
This reminds us that even with app isolation, developers need to be extremely careful about how they share data. Even a small mistake can have huge consequences for user privacy and security.
This final case study is a bit of a head-scratcher. We just talked about how apps are supposed to be isolated, right? Their data should be tucked away and safe from prying eyes and other applications.
Well, this app decided to throw that out the window. We think it was designed for shared devices.
To handle situations where the device lost Internet access, it did something wild. It downloaded the entire user table from the production database when it was first launched and stored that on the device.
Usernames, emails, password hashes were all pulled down and stored on the mobile device.
Now here's where it gets really interesting. Instead of keeping that sensitive data locked down in its own private storage, it dumped it all into external storage, which would be like leaving your diary open on a park bench. Any other app on the device with external storage permissions could just waltz over and read it.
We had access to config files, the tables from the database, and all sorts of other interesting information.
To make matters worse, the credentials that were retrieved weren't just for the mobile app or the associated back end. They worked for their main website as well. So anyone who got their hands on that device could potentially log in as any user.
But wait, there's more. This app also had a peculiar feature where it would execute any shell script - basically, little programs - found in the communication folder in external storage.
Again, any app could drop a script there, and this app would blindly run it. This could be abused to access files in local storage or perform arbitrary acts in the context of the vulnerable application.
External storage is convenient, but it's also a security minefield. Developers need to be extremely cautious about what they store there, especially sensitive data. And executing code from untrusted sources, that's just asking for trouble.
Ultimately, we want to give you some key takeaways and actionable steps you can take from today's dive into mobile penetration testing.
First and foremost, mobile app security is not optional.
We're essentially putting potentially sensitive information into what can be a very hostile environment. With the increasing sophistication of cyberattacks, it's absolutely crucial to proactively identify and address vulnerabilities before they can be exploited.
That's where mobile penetration testing comes in. It gives us a unique and invaluable perspective, allowing us to simulate real-world attacks and pinpoint weaknesses that automated tools might miss. It's like having a friendly hacker on your side, helping you fortify your defenses. And remember, the mobile environment is constantly evolving.
New threats and vulnerabilities emerge regularly, making ongoing security assessments an essential part of your app's life cycle. It's not a one-and-done situation.
We strongly encourage you to consider implementing a regular mobile penetration testing program.
But even if a full-fledged pen test isn't feasible right now, there are steps you can take immediately to improve your app security posture.
These steps can go a long way in hardening your mobile app against potential attacks.
OWASP has a great site with fantastic resources and checklists for improving your mobile application security. We highly recommend checking it out.
If you have any questions about mobile security, pentesting, or just want to learn more, visit our website and talk with one of our cybersecurity experts. You can also use our pen testing calculator to help budget and prepare for your next pen test.
.svg)
