Mobile Penetration Testing 101

‍

Transcript of Mobile Penetration Testing 101

‍

Hi, everyone, and thanks for being here. I'm Aaron Bishop, a principal penetration tester at Security Metrics. I've been in the cybersecurity game for over fifteen years, and the last twelve have been spent trying to break into systems, ethically, of course, as a penetration tester.

I'm passionate about helping organizations like yours stay one step ahead of the bad guys. And today, I'm thrilled to dive into the world of mobile penetration testing with you. We'll explore what it is, why it's crucial, and share some examples to bring it all to life.

Let's dive into the world of mobile penetration testing.

We'll tackle two fundamental questions head on. First, we'll demystify the concept of a mobile penetration test. What is it exactly? What's the goal?

Second, we'll pull back the curtain and see what actually happens during a pen test. What do we look for? We'll also share case studies and examples from past engagements. We'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.

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.

First, we'll address the fundamental question, what is a mobile penetration test?

In simple terms, it's like a friendly controlled attack on your app. 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, 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, obviously, 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 in scope too.

We know you're the experts on your own app. You and your team have lived and breathed this thing probably for years. We'll only be spending a few days with it, so we definitely wanna 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 up front.

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.

Now some of the key things we do include source code review. 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, hard code secrets, or potential weak spots that attackers could exploit.

We'll take a close look at what the app is storing on the device. Is there any sensitive data lying around? Where is data being stored? Is stored data being encrypted?

Are there any sneaky ways that data could leak out?

We'll see how the app interacts with other apps on the device. Is it sharing data securely? Are there any communication channels that could be hijacked? And, of course, we'll examine how the app talks to the outside world, cloud services, APIs, that sort of thing. 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 back end servers, 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 back end, but what if someone's 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 back end. 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 authentication flaws, things like weak password policies, session management issues, or even just plain insecure ways of logging in, access control problems.

We'll see if we can trick the app into letting us access data or functions we shouldn't be able to.

Injection attacks. This is where we try to sneak in sneak in malicious payloads like SQL injection to see if we can make the back end do something it's not supposed to.

Cloud misconfigurations.

If your app uses cloud services, we'll also keep an eye out for any misconfigurations that could leave sensitive data exposed.

Moving on, let's review some case studies specifically related to mobile penetration testing.

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 those can also be found during a traditional web application penetration test. So those examples won't be included here. Instead, I will focus on three cases to highlight mobile specific vulnerabilities, how they were exploited, and the potential impact.

Through these examples, you'll get a glimpse into vulnerabilities found in mobile app applications, or we'll explore how well intentioned features can be leveraged to compromise accounts, extract sensitive data, or even take control of the of the device.

These stories will showcase the importance of thorough mobile app security testing and the ingenuity required to stay one step ahead of the of potential threats.

Case one. This application wasn't available on an official app store, but had a built in feature to check for updates whenever it was launched. Sounds convenient. Right? Especially since it was a private internal application, so it 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 here.

Using a technique called art 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.

This highlights a crucial point.

Permissions are powerful.

The install packages permission is especially dangerous.

Developers need to treat these permissions with the utmost care and build in strong security checks to prevent unintended actions on a user's device.

This next 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 health care 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. It means someone could create a seemingly harmless app that secretly steal your health care information.

That could lead to identity theft, insurance fraud, all sorts of bad stuff. 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, safe from prying apps, 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, it was all port pulled down and stored on on a 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. That's like leaving your diary open on a park bench.

Any other app on a device with external storage permissions could just waltz over and read it.

This image is from a sample application demonstrating another app could read what was written to external storage. We had access to config files, the tables from the database, 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 run it. This could be abused to access files in local storage or perform arbitrary acts actions in the context of the vulnerable application.

So what's the takeaway?

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.

Okay. Let's wrap it up with some key takeaways and actionable steps you can take from today's dive into mobile penetration testing.

First and foremost, let's face it. Mobile app security is not optional. We're essentially putting potentially sensitive information into what can be a very hostile environment. With an 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.

I 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.

First, hunt for hard coded keys or credentials.

These are like leaving your house keys under the welcome mat. Scour your code and configuration files for any sensitive information that shouldn't be there.

Two, check for for traditional web application vulnerabilities.

Many of the same issues that plague web apps can also affect the back end of mobile apps. Look look for SQL injection, XML external entity injections, and other common flaws.

There's a false assumption that those those types of vulnerabilities won't exist and can't be triggered the same way because there isn't a browser in front of of the back end.

Those requests can still be manipulated. Those vulnerabilities can still exist.

Three, secure your data storage. Only store the information you absolutely need, and make sure it's encrypted and protected. Don't leave sensitive data lying around for the taking.

Four, secure your interprocess communication channels. Make sure other apps on the device can't unintentionally access your data or functionality.

These steps can go a long way in hardening your mobile app against potential attacks.

OWASP has a site, m a s dot oASP dot org. You can see it over there on the on the side of the slide. It has fantastic resources and checklists for improving your mobile application security. I highly recommend checking it out.

Thank you for your time today. If you have any questions or would like to discuss your specific security needs, please don't hesitate.

‍