Process

• Always decompile the app. You can use apktool to do this.
• Search the AndroidManifest.xml for sensitive information.
• Search for xml strings such as res/values/strings.xml for sensistive information.
• Search for database files. They will normally be sqlite3.

Getting the APKs

• Search the APK on your with adb shell pm list packages.
• Get the path to the apk with adb shell pm path [package value from previous command]
• Get the APK with adb pull [path from previous command].

Installing a trusted CA on your device

• You will need to root your device to do this. If you are using an emulator, you should get one that does not have the Google Play Store installed!
• You will also want to get an emulator/device with Android < 29 so that you can temporarily make /system temporarily writeable without many issues.
• Start the emulator with a writeable system mount: .\emulator.exe -avd $deviceName -writable-system
• Run the following to make /system writeable:

adb root
adb disable-verity
adb reboot
adb root
adb remount
adb shell mount -o rw,remount /

• https://docs.mitmproxy.org/stable/howto-install-system-trusted-ca-android/

Then, to intercept traffic, depending on the UI, you might have to click and hold the network preferences in the wifi settings.

Java Beans XMLDecoder Deserialization

Whenever a backend uses the Java Beans XMLDecoder class, we can deserialize data as code to gain remote code execution.

This is great to check whenever you can submit any sort of XML payload to a Java backend.

• Cheatsheet

Finding Deserialization Vulnerabilities in Java Source Code

Were to find Java deserialization vulnerabilities?

• Serializable objects are often transported in HTTP heaaders, parameters, and cookies since they essentially represent transportable Java class instances.

What does a serialized Java object look like?

Double Url Encoding Bypass

Useful trick in directory traversal/bypass which can sometimes be used to bypass web proxies.

Before you start

• Django prefers using models rather than SQL queries to access its database. This means that it will generally be less prone to SQL injection attacks.
• Django keeps its middleware configurations in the settings.py file. It’s SECRET_KEY variable is also stored there and is a good target to attack to fully compromise the app.
• Django is written in python, so code injection attempts should be in python and/or bash.

SQL Injection

• Custom SQL queries could be prone to this if they are not parameterized. For the most part, developers will use the Django models to indirectly (and securely) access the database.
• You can search for curs.execute() queries in application code during white box testing.

Broken Authentication

• Sometimes, developers implement a blacklist of attributes for their User model. Since their custom User model inherits from the Django base model, you might be able to create a user with the is_staff and is_superuser attributes.
  • This can be prevented with the use of a whitelist of permitted attributes.
• Avoid using CookieStorage for user session storage because this opens up possibilities for attackers to steal the cookie and then authenticate. It also allows attackers to analyze cookies and session state information opening up the server to session prediction attacks and possibly identifying that the session is a serialzied object, giving more context for attacking the app’s deserialization mechanism.
  • This can be prevented by keeping all session state on the server.
• On the prevoious note, avoid using the PickleSerializer to serialize session information because if an attacker discovers the app’s SECRET_KEY variable, they will have remote code execution.
  • More information on how to exploit that here

Broken Authorization

• Sometimes, you will be able to attempt actions that you were supposedly not allowed to do.
  • If any database change will be made, always be sure to check that the user is authorized before doing so.
  • Always perform an authorized check before any data is returned back to the user.
    • That said, you might be able to find access data implicitly through other means to leak information you were not supposed to see.

XSS

• Django renders data back to users via Jinja2 template files. If you see the safe, var, or escape filters in variable interpolation, then browsers should be able to render XSS attacks there.
  • You can add further defenses against XSS by adding the X-XSS-Protection header in your responses which can be set with the django SECURE_BROWSER_XSS_FILTER variable.

IDOR

• Sometimes, you will find some endpoints/pages that do not require authorization, so you might be able create, update, edit, or delete resources by changing parameter or url values.
  • If any database change will be made, always be sure to check that the user is authorized before doing so.

Vulnerable Components

• In web apps, developers might use front-end web frameworks like React and Angular. If these components are outdated, you might be able to exploit some CVEs in them! Even better, check that the Django app itself is outdated!

Misconfigurations

• Always turn DEBUG mode off.
• Don’t use CookieStorage as the default session store.
• Out of the box, the above two configurations are the default in django.

Weak Cryptography

• Prefer using bcrypt to store password hashes because it is computationally and memory intensive, making it difficult for an attacker to brute force a hash if they get a dump of the database.

CSRF

• Check for any GET requests that act as write operations. These should be vulnerable to CSRF!
• Any code that has the @csrf_exempt tag on will be vulnerable to CSRF. Remove those annotations and set the django.middleware.csrf.CsrfViewMiddleware in settings.py.
  • Django CSRF Reference

Open Redirects

• Check for HTTP 3xx (redirections) where you have direct or implicit control over where the user gets redirected.
  • This can be mitigated by whitelisting/hardcoding where the user should be redirected to.

Business Logic Bugs

• Look for dynamic behavior where you control the input.
• Data concatenation in URLs can be problematic -> SSRF and/or open redirects.
• Data concatenation for functionalities that could possibly involve shell commands -> Remote code execution.
• Data transactions where controlling the state of sensitive information can be maipulated via race conditions. Banking transactions are a good example: you might be able to make two purchases by only paying once!
• Data serialization with Pickle, you can identify base64-encoded pickled data because it will be prefixed with gASVNAAAA -> Remote code execution.

APIs

• Create two accounts.
• Populate as much data as you can for both accounts. Make sure to make at least two instances for each model so that you can test deletion later.
• Streamline the process with Burp’s autorepeater for this.
• Check for IDOR by computing all the remaining API functions with Burp’s autorize extension.
• Get lucky, profit!

Databases

• Some models may reference other models that belong to some other identity, and leak the information!
• Create visual tables so you can visualize relationships between data models.
• Prioritize investigating models that have complex relations so you can attempt to disclose indirect information from them.

Local and remote file inclusions are often found in PHP applications where another source file is included from a user-defined variable. This allows attackers to execute arbitrary code by loading a page that has existing PHP code on it.

• You can detect potential LFI by identifying pages that load PHP snippets from other pages.
• You can exploit LFI by polluting a file with PHP code (potentially a PHP file) and then load it back to the page.
• You can also exploit LFI by attempting to achieve an arbitrary file read on the system.
• Try RFI as well. E.g. fetch an existing file from the local server via the network (e.g. http://localhost) if LFI doesn’t work. Of course, I prefer testing for RFI first because I can control the code that will be loaded by the page.