Finding Hidden Threats: How I Found Leaked AWS Credentials in an Android App API Using DAST

Hi everyone, welcome back! I haven’t written a blog in a while, I’m excited to share this recent finding with the bug bounty community. During my latest bug bounty hunting adventure, I discovered a critical vulnerability involving leaked AWS credentials within an Android App API. This vulnerability had the potential to a takeover of the AWS infrastructure. Let’s dive into how I uncovered this hidden threat using Dynamic Application Security Testing (DAST) techniques.

Understanding DAST (Dynamic Application Security Testing)

What is DAST?

Dynamic Application Security Testing (DAST) is a method of testing an application’s security by analyzing it in its running state. Unlike static analysis, which examines the code without executing it, DAST interacts with the application in real-time to identify vulnerabilities that could be exploited by attackers.

Advantages of DAST:

• Real-World Simulation: Tests the application as it runs, providing insights into how it would behave under actual attack scenarios.
• Comprehensive Coverage: Can identify vulnerabilities that might not be apparent through static analysis alone.
• Continuous Testing: Can be integrated into the CI/CD pipeline for ongoing security assurance.

Difference Between Static and Dynamic Analysis:

• Static Analysis (SAST): Examines the source code, bytecode, or binary code of the application. It’s useful for finding issues early in the development process.
• Dynamic Analysis (DAST): Tests the application in its running state, providing a more realistic view of how the application performs under attack.

Toolkit:

To discover this vulnerability the tool I used was Mobile Security Framework (MobSF) is an automated security testing framework for mobile applications. It supports both Android and iOS platforms and provides comprehensive static and dynamic analysis capabilities.

Static Analysis:

In a previous blog post “Hacking SMS API Service Provider of a Company |Android App Static Security Analysis | Bug Bounty POC“, we delved into Android App static analysis , which include examining the source code for vulnerabilities, identifying insecure coding practices.

Focus on Dynamic Analysis:

For this blog post, we’ll focus on the dynamic analysis capabilities of MobSF.

Setting Up the Testing Environment

Before diving into the discovered vulnerability let’s talk about the setup and usage.

Preparing the Testing Environment:

If you have any issues Installing MobSF or setting up Devices for Dynamic Analysis consider reading the official documentation here https://mobsf.github.io/docs/#/dynamic_analyzer most of the part regarding setting up environment for testing is taken from there.

1. Setting up MobSF: Download the latest tagged MobSF docker image

docker pull opensecurity/mobile-security-framework-mobsf:latest

2. Setting up Android emulators: Setting up these devices to run the applications.

I usually use Android Studio Emulator so will share the steps here…

• Create an Android Virtual Device (AVD) without Google Play Store.

• Choose an Image, MobSF Supports arm, arm64, x86 and x86_64 architecture with Android Version 5.0 – 9.0, upto API 28

Do not start the AVD from Android Studio IDE/AVD Manager UI, Instead Run AVD from command line using emulator commands.

• Append your Android SDK emulator directory to PATH environment variable.

Example locations:

Mac - /Users/<user>/Library/Android/sdk/emulator
Linux - /home/<user>/Android/Sdk/emulator
Windows - C:\Users\<user>\AppData\Local\Android\Sdk\emulator

AVD command line

$ emulator -list-avds
Pixel_2_API_29
Pixel_3_API_28
Pixel_XL_API_24
Pixel_XL_API_25

• Run an AVD before starting MobSF using emulator command line options.

• Do not start the AVD from Android Studio IDE/AVD Manager UI

$ emulator -avd Pixel_3_API_28 -writable-system -no-snapshot

• Identify the emulator serial number. In this example, the identifier is emulator-5554.

• Set MOBSF_ANALYZER_IDENTIFIER as emulator-5554 when running MobSF docker image.

Run MobSF:

docker run -it --rm -p 8000:8000 -p 1337:1337 -e MOBSF_ANALYZER_IDENTIFIER= opensecurity/mobile-security-framework-mobsf:latest

Testing Process:

MobSF is actually pretty easy to use, There are a few tutorials & course online you can follow to learn how to use MobSF.

Upload & Analyze

It’s basically drag and drop to scan and Analyze the Application. Once it’s completed it will redirect you to the Static Analysis page of that application.

On this page you can click “Start Dynamic Analysis”

MobSF will initiate the Dynamic Analysis Module here’s what the interface looks like

The interface is pretty simple to navigate, for this blog will focus on the Activity testing module of Dynamic Testing component.

During my dynamic testing using MobSF, I focused on what requests are made behind the application runtime. For this I mainly used the Activity Tester Option, what it does is it launches all the activities one by one and records everything that happens.

Once the Activity is completed I simply generated a Dynamic Analysis Report

Using the “HTTP(S) Traffic” button on the Dynamic Analysis Report page we can see all the Requests that were made behind when the Activity Launches.

This opens the file web_traffic.txt

Searching for Leaks

When I usually follow this route I look for certain keywords in the Web traffic file such as

Secret
apikey
token
Authorization
AWS
AWSAccessID
AWSSecretKey

I did the same here and this is what i found

So The application was making a request to api.target.com/services.svc when a specific activity was launched and thus in response to that POST request AWSAccessID & AWSSecretKey was leaked.

To validate these leaked credentials I configured these credentials with my awscli and ran a few basic commands to validate the access these keys had.

Running the command aws s3 ls showed me that I had access to more then 65 AWS S3 Buckets

We can even upload files & remove files from the buckets that can cause Subdomain takeover scenarios as well.

Running the command aws ec2 describe-instances showed me the ec2 instances I had access to.

Impact Analysis:

Further escalating for POC I ran a script that enumerate your permissions querying the IAM service, and if that’s not an option we can brute force permissions. I tried to run all the list*, describe*get* commands from all the AWS services using the CLI and indicate the ones that worked. By using this I found out that I had significant access to that AWS account.

At this point I had enough evidence and impact to report this vulnerability do I did.

Well that was it, We’ve explored how DAST can be used to uncover critical vulnerabilities, such as leaked AWS credentials, in mobile applications API. By leveraging tools like MobSF. Hope the blog was helpful and you learned something. If you have any questions or suggestions feel free to comment. 🙌

Post Views: 3