#AndroidHackingMonth Q&A With Android Hacker bagipro

Mobile hacking has become an essential part of the bug bounty hunter’s tool belt, and no one knows the space better than Android hacker bagipro.

With years of experience, he’s currently ranked as the number one hacker for Google Play Security Reward Program on HackerOne. We sat down with him to learn his tips and tricks and find out more about how he got started.

Q: Why did you choose mobile as your area of expertise?

A: I didn’t actually plan this. When I was 17, I applied to a university and moved out here to Moscow from a little town called Yelets, Lipetsk Region. I didn’t expect that I could learn any real-life practical things at university (I learned a lot of math, but not much programming and no security at all), that’s why I started looking for a part/full-time job, so I could combine real-world learnings with my studies. Prior to that, I programmed C++ for fun and worked online for uTest as a QA engineer for about 2 years, using only basic web security skills. I created a resume with all the experience I had and posted it on headhunter.ru (and I titled it “C++ Programmer”!), and I got a few calls related to continue working in QA, but the positions seemed too simple and I didn’t think I would learn anything new. On the next day, I got a call from a Positive Technologies recruiter. They had 3 open positions: “Unix Junior Security Specialist,” “Junior Security Specialist” and “Mobile Junior Security Specialist.” I said, “Let’s try the Unix one!” but she told me that they wanted to interview me for mobile, and I agreed. I had two interviews (I thought that I completely messed up all of them), and for some reason, I was accepted. I worked there for 5 years. My responsibility was to perform security audits for iOS/Android client/server-side for the company’s customers, which were mostly Russian banks.

Q: Are there any prerequisites to learning mobile hacking? Are there any languages I should familiarize myself with?

A: It’s always better to be familiar with as much as possible. At the very least, you should know Java. Nowadays, I see a lot of apps (or their parts) written in Kotlin, but it doesn’t matter since it could be decompiled to valid Java too. Moreover, Java and decompiled (de)obfuscated Java are different, so you will have to learn to understand the decompiled version.

Q: What are some of your favorite mobile hacking resources for someone that’s new to mobile hacking?

A: I would recommend reading disclosed reports, downloading older versions of affected apps and trying to reproduce the behavior.

Q: Did you have a mentor when you were learning mobile hacking? Or did you learn everything on your own?

A: When I started my career, I was taught the basics of Android hacking. But most of the techniques I currently use were researched by myself. But research is not hard, it’s interesting. You download the 1000 most popular Android apps and see how, for example, WebViewClient.shouldOverrideUrlLoading is statistically used, find the most popular mistakes developers make and repeat that for all popular and potentially sensitive methods and classes. Sometimes it can be hard and can take a long time to understand the sources of Android Framework, so you can create two apps: a “victim” app and an “attacking” app and test the different configurations separately.

Q: What kind of vulnerabilities do you usually look for when testing for android apps?

A: I actually look for all kinds of vulnerabilities that present any risk :) Most popular are: token leakage by URL substitution in WebViews or http libraries such as OkHttp, Retorfit; theft of all cookies from all sites via WebViews; theft of arbitrary files (via WebViews, content providers, activities that send arbitrary files to arbitrary URLs, and activities that copy protected files to unprotected locations); overwriting of arbitrary files (which could lead to e.g. corruption user data or arbitrary code execution when e.g. a native library is modified); local code execution (usually happens when apps without any or with bypassable verifications try to code via ClassLoaders from different apps because they consider they are their plugins; also Apache Commons Collections4 vulnerabilities are pretty popular on Android); unprotected intent starts (for activities, receivers) with sensitive data attached; insecure data storage (with world-readable flags in internal directory or in public directories), and so on.

Q: Do you use a physical phone or a virtual device by using genymotion or similar tools?

A: Nope, I use only my Samsung Galaxy S8 :)

Q: Do you follow a checklist like OWASP when looking for vulnerabilities in Android applications?

A: No, because I don’t think that the OWASP checklist covers the most popular mobile bugs. There are a lot of platform-specific bugs for Android and iOS, and it’s hard to follow a common checklist without missing a lot of things. Also, when you do a pentest for any computer system, you should understand how it works

Q: Do you prefer using Frida over other tools like Xposed?

A: I think I started using Xposed before Frida was announced, so I stick with that because I’m too lazy to learn Frida and I am completely satisfied with Xposed.

Q: What's the effective way to bypass SSL pinning on Android applications? What are some of your favorite resources for this topic?

A: Use Xposed + SSLUnpinning. Sometimes when super tricky SSL pinning is implemented, I just decompile the app via apktool, change protocols from https to http, compile back and sign, and create a rewrite rule in Charles that replaces the protocol from http to https. That works! :D

Q: How is dynamic analysis performed on android apps when it comes down to looking for OWASP Top 10 bugs?

A: I actually use dynamic analysis as a part of the whole testing. There could be unclear/obfuscated conditions and you may not understand why a bug couldn't be reproduced. In such cases, I use Xposed to hook different parts of the app to see is that code executed as expected by me. I would recommend combining all methods to perform a good analysis, manual review to understand to an app and how its parts work with each other, understand their interfaces, find potentially vulnerable parameters, look which files are created in internal and external directories, their permissions, network logs, etc.

Q: If the webview for an app has access to internal file systems (e.g. file://) and I have the ability to execute, what are some common vulnerabilities to test for?

A: WebView is the most popular component used in Android and there are a lot of different techniques for that. These are some of the things I see most frequently:

• Known things like JavaScript interfaces that could be accessed by thing party code leading to performing sensitive actions or accessing private data (see report https://hackerone.com/reports/401793)
• Sensitive data (e.g. token) leakage in requesting URL or in headers
• Theft of arbitrary files via XHR requests with file://scheme. WebSettings.setAllowUniversalAccessFromFileURLs should be explicitly set to true value.
• Access to app protected components via intent:// scheme URIes (see https://www.mbsd.jp/Whitepaper/IntentScheme.pdf)
• Theft of all cookies from all sites. The main idea is to set a cookie with XSS payload that sends current document contents to an external server. After, you make a symlink with .html extension to the file with cookies and force a WebView to open the symlink. SQLite database file will be parsed as an HTML document, XSS will trigger and leak all the data from the database. This works with default WebView configuration, and JavaScript should be explicitly enabled (it’s enabled by developers all the time). But it will lead to leakage of arbitrary files that you can infect with your own payload with XSS
• Theft of (arbitrary) files by abusing WebViewClient.shouldInterceptRequest method. Usually implementation of this method check that url starts with a predefined thing e.g. mycustomscheme://localfile/ and then substrings the beginning and returns contents of the file
• Access to internal deeplink systems. Some of the deeplinks are “protected” and handled by WebViewClient.shouldOverrideUrlLoading. Such unexpected access (by developers) could lead to different circumstances.
• Overwriting of arbitrary files by a vulnerable implementation of DownloadListener.onDownloadStart
• Universal-XSS when URL first time comes from e.g. getIntent() in onCreate method, and a second time from onNewIntent

Q: Are host validation vulnerabilities such as https://hackerone.com/reports/431002 still common and relevant?

A: Of course! I’ve never actually seen a good host validation on most of the applications I have looked at.

Q: How do you confirm that the api_keys extracted from an android app are sensitive?

A: Obviously you should understand why they are here, find the library/service using them, check for their docs and realize if the keys should be kept in secret or can be publicly disclosed e.g. in apps. There are only a few super popular and a couple of common ones, so it could be easy to memorize all of them.