Android Hacker
Kayleen
Microsoft is sounding the alarm about a recently discovered critical security vulnerability on Android named "Dirty Stream" that can let malicious apps easily hijack legitimate apps. Worse still, this flaw impacts multiple apps with hundreds of millions of installs. If you have one of the best Android phones, here's what you need to know to protect your data.
The vulnerability relates to the ContentProvider system prevalent across many popular Android apps, which manages access to structured data sets meant to be shared between different applications. It's basically what lets your Android apps talk to one another and share files. To protect users and ward off unauthorized access, the system includes safeguards such as strict isolation of data, unique permissions attached to specific URIs (Uniform Resource Identifiers), and path validation security.
What makes the Dirty Stream vulnerability so devious is how it manipulates this system. Microsoft has found that hackers can create "custom intents," messaging objects that facilitate communication between components across Android apps, to bypass these security measures. By exploiting this loophole, malicious apps can send a file with a manipulated filename or path to another app using a custom intent, sneaking in harmful code disguised as legitimate files.
"We identified several vulnerable applications in the Google Play Store that represented over four billion installations," Microsoft explained. "We anticipate that the vulnerability pattern could be found in other applications."
Given the nature of how this vulnerability works, it's hard to know exactly how many other legitimate apps may have been impacted. But it's safe to assume this potential risk is on an industrial scale until all apps are patched.
When it comes to staying safe from Android malware, one of the easiest and simplest things you can do is to limit the number of apps on your phone. I know this may sound silly but think of it this way, the fewer apps you have, the less likely that one of them may turn out to be malicious. Before installing any new app, first ask yourself whether or not you actually need it.
You also want to make sure that Google Play Protect is enabled on your device. This pre-installed app scans both your existing apps and any new ones you download for malware. Likewise, if you want extra protection and potentially even some extra features like a VPN or password manager, you also want to check out the best Android antivirus apps.
In order to intercept encrypted network traffic, the emulator needs to trust Burp Suite as a certificate authority (CA). Within Burp Suite, navigate to Proxy > Options Import/export CA certificate > export certificate in DER format. On the following screen, choose a folder and name it for where the certificate will be stored. Mine is saved as burp.cer.
The device needs to be restarted to fully trust the certificate. To configure the emulator to send traffic to the proxy navigate to Settings > Network & Internet > Internet > Select the gear next to AndroidWifi > Select edit in the top-right corner > Advanced Options > Manually configure the proxy
For some Android applications, certificate pinning may be used to prevent unauthorized third-parties from intercepting the traffic. At a high-level, certificate pinning tells the application which SSL certificates should be trusted for communication. Any certificates that are not explicitly trusted, including installed CA certificates, will cause SSL negotiation errors. In those instances, additional tools and scripts may be needed for an SSL pinning bypass. Objection has a built-in command for attempting to bypass common forms of pinning (android sslpinning disable), but it may not be effective in all scenarios. It is good practice to have multiple tools and techniques on hand for when those situations arise.
Picking up where the previous blog left off, let's hook DVBA and try to use the application. The command below will launch the application and inject Frida. Once DVBA is launched, Objection has built-in Frida scripts that can be used to analyze various aspects of the application. One (1) thing that is apparent when we start the app is that DVBA will immediately close.
Right away, it looks like a class is loaded to check if Frida is running, and there is only one (1) method within the class. Watching the identified method may provide some insight into what is happening at runtime. Run the following command that logs calls to the method as well as the return value, then try to relaunch the app.
When DVBA is first launched, the fridaCheck method is called and returns a 1, which signals that Frida is enabled, and results in the app closing. Objection supports the ability to change Boolean return values, but since the method is returning an integer, this functionality may not work for bypassing the controls. Below is an example Frida script that can be used to hook the method call and modify the value that would be returned. Since the return value is 1 when Frida is running, switching the value to 0 should bypass the controls and allow the app to run.
The script can be run within Objection using import bypass_fridaCheck.js. Within the emulator, click on the DVBA icon to run the app and it should load the welcome screen. Back in the terminal, console.log statements show each step of the process that allowed the app to run.
One (1) of the most common issues related to mobile applications is insecure data storage. When dealing with a mobile banking application, there is often PII associated with an account. If a device is stolen or gets infected with malware, access to this information could be detrimental to the device owner.
Using adb pull, these archives can be downloaded to the local system for review. Within the directories that were extracted, there is not a lot of plaintext user data or PII that can be identified. However, there is an XML document containing a JWT within /data/user/0/com.app.damnvulnerablebank/shared_prefs. These tokens contain three (3) different sections: Header, Payload, and Signature. The Header and Payload are encoded with base64 and typically contain information about the algorithm used to generate the signature, when the token was issued, when the token expires, and other details about the access a user should have. Using the JSON Web Tokens extension for Burp Suite, it is possible to decode and see the information contained within the token.
The payload contains the username and an is_admin field. This means the API is relying on user supplied data that could be manipulated to gain access to other usernames or admin functionality. Since the JWT is signed using HS256, we need to look for a signature exclusion vulnerability, or identify if the signature was generated using a weak secret. Using Hashcat, a wordlist can be used to brute-force the secret value:
The server accepted the JWT and provides a 200 OK response, indicating it accepted the modified JWT. Now use the modified JWT to overwrite the value within jwt.xml to see if it can be used to gain access to additional activities within the app.
The file is used to note if the user has logged into the app and caches the account details. Close the app and push the modified jwt.xml to the Android device. The next time the app is launched, the admin account will be logged in.
The search for file extensions returned no results, but the search for a string within the file identified two (2) database files that should be reviewed. Using DB Browser for SQLite, each can be opened and reviewed for content that is unencrypted and could be used for malicious purposes.
Review of the Web Data files shows there are several database tables that may be of interest, including: credit_cards, unmasked_credit_cards, payments_customer_data, and many others. A quick review of each table shows there is no data currently in the database. This is something to keep an eye on during testing because there may be a specific functionality that will populate the information, but the app just needs to be used a bit more.
It is worth noting some activities, such as debugging functionality, are purposefully hidden by developers using secret gestures or may be disabled at build time. An example of this would be swiping from the bottom-left of the screen to the top-right to access a page with application logs. While these activities are not intended to be used by a typical user, they are often left in the code. Additionally, launching activities without authentication may lead to unexpected behavior within the application. Each of the listed activities can be launched using Objection. The command to do this is android intent launch_activity . The device should now display the screen associated with the activity.
The Send Money functionality requires a user to be added as a beneficiary to the account before any money can be transferred. Lets try to transfer money to the account we created earlier. The way this attack will work is:
Once the account has been added, it needs to be approved by the admin. Launch the Pending Beneficiary activity from Objection and select the pending request. The on-screen prompt will ask for the ID to be entered again, which is displayed at the top of the screen (In this case, it is 9).
In order to accomplish this, it may be beneficial to understand the file structure of an Android application. An APK file can be unpacked by changing the file extension to .zip, which can allow for the contents to be extracted.
Within this folder structure is a classes.dex file. This is an executable file (Dalvik Executable bytecode) that contains compiled Java code. The DEX file can be converted into Java class files using a tool like dex2jar. The Java class files can be further decompiled into the source code for easier interpretation. If no code obfuscation was used when building the application, this process can allow for a deeper understanding of the application and vulnerabilities that have been introduced. There are many different tools that can do the decompiling for us, but the tool that will be used for this write-up is JADX. Once installed, the JADX-GUI can be run to provide a graphical interface for loading an APK and reviewing the decompiled source code. Within the user interface, navigate to File > Open and select the dvba.apk.
c80f0f1006