Overview
Android Applications with no exception are prone to cyber threats and attacks. They are the most widely used applications worldwide and these cyber threats and attacks are a growing concern to both consumers and developers. Malicious actors target these apps as a way to spread malware, steal personal information, and gain unauthorized access to users’ devices. From fake banking apps to social media scams, there is no shortage of ways hackers exploit Android app vulnerabilities. To combat this issue, developers must prioritize security measures during the app creation process by encrypting data, limiting third-party integrations, implementing strong authentication protocols, and conducting regular vulnerability assessments. We were asked to pen test an Android application by a client. In this case study, we’ll discuss the vulnerabilities found and ways used to detect them.
Scenario
We were asked to perform Android Penetration testing on their Android Application to detect possible vulnerabilities.
Major Android Application Risks
Major Android application risks that professionals need to be aware of include security vulnerabilities, data privacy concerns and malware infections.
- Security vulnerabilities can allow attackers to exploit weaknesses within the application code or hardware to gain unauthorized access to sensitive information or system resources.
- Data privacy concerns arise when an application accesses or collects user data without permission, or when it sends that data to third parties who may not be trustworthy.
- Malware infections on Android devices can infiltrate applications, steal sensitive information, and take control of the device to carry out malicious actions without the user’s knowledge.
Professionals must carefully consider these potential risks when developing and deploying Android applications, implementing strong security measures like encryption, secure authentication protocols and frequent security testing throughout the development process.
It is also essential for professionals using Android applications in workplaces or on personal devices to remain vigilant about accessing insecure networks or downloading suspicious applications that could compromise their systems’ security and integrity.
What we found
We classified the risks we found into three categories I.e., Critical, High, Medium, and Low:
- The Critical-level risks involve User credentials exposed in the web-socket response.
- The High-level risks comprise Authorization Bypass Via IDOR- View sensitive information of other users and Application code is not obfuscated.
- The Medium-level risks include Insecure local storage in shared preferences, Authorization Bypass via IDOR- View group Members of other groups, Unrestricted file upload, App log sensitive information, Session not expired, Insecure communication, and Insecure hash function (MD5 hash Used).
- The Low-level risks contain Insecure Permissions and Unknown Permissions.
Brief about what we found
During our examination of the application, we discovered several Critical, High, Medium, and Low vulnerabilities.
Firstly, we found “Credentials exposed in WebSocket Response”. To find this vulnerability, we logged in with a valid username and sent a request to the URL to observe that the response had details like a hash password.
When we logged in with a valid user such as User1, tapped on the “Profile Settings” feature and intercepted the request, it returned the hash password of User 1 on the response side. When the user ID of User1 was changed in the URL to another user ID known as User2, the name and password of User 2 were returned. That’s how we discovered the “Authorization Bypass Via IDOR- View Information of other user” vulnerability.
We’ve discovered that the application code was not obfuscated. This was uncovered by reversing the application, and we’ve discovered that the source code is in a readable and understandable form.
We spun the Android device, accessed the shell and navigated to the shared preference directory. When we opened a particular file, the file contained the “UserAuth” token. We’ve identified “Insecure Local Storage in Shared Preferences” through this.
We unmasked the “Authorization Bypass via IDOR- View Group Members of Other Group” vulnerability when we logged in as a valid user and tapped on to any existing group. When we tapped on a particular group to access group information, it came to light that the URL on the response side exposed the entire information of group members of the particular group. Later, we logged in with another User, clicked on another group, noted the ID of Channel 1 (channel id1) and logged out. We changed the value of the parameter from “channelid1” to “channelid2” and observed that the “channel name” and data are different on the response side.
We’ve also discovered “Unrestricted file upload”. Where the malicious user could upload an image. The attacker selected an image file and changed the extension of the file from “.jpeg” to “.exe”. The attacker then sent a success message indicating that the file had been uploaded successfully and sent the URL to the victim. If the victim clicks on the URL, a file will be downloaded and their system might get compromised.
During the application assessment, we found that sensitive information could be logged. The “Authorization” token is not terminated after the logout feature.
We’ve also discovered that the app communicates with servers using “cleartext network traffic”, such as HTTP. And the traffic risks are being eavesdropped upon and tampered with by third parties. This can lead to information leakage and unauthorized content or exploits being injected into the app.
The hash function used in the application is old and insecure, allowing an attacker to conduct a hash collision attack without changing the hash. Additionally, the application uses the MD5 hashing algorithm for passwords.
Finally, we discovered that the app was insecure and gave unknown permissions.
We helped them mitigate the following risks
- User credentials exposed in the web-socket response:
Sensitive data is confidential information that must be kept safe and out of reach from all outsiders unless they have permission to access it. Access to sensitive data should be limited through sufficient data security and information security practices designed to prevent data leaks and data breaches.
Sensitive data is defined as any information that is protected against unwarranted disclosure. Protection of data may be required for legal or ethical reasons, for issues about personal privacy, or for proprietary considerations.
The risks of exposed user credentials are that threat actors can access additional hosts, install malware, steal data, and disable or modify security controls.
- Application Code is not obfuscated:
Unprotected Android apps increase the risk of exposing your businesses to IP theft, loss of revenue, or reputation damage. App providers must actively protect their apps against emerging threats with a strong layer of defence to safeguard critical code from attackers. Obfuscation is a series of code transformations that turn application code into a modified version that is hard to understand and reverse-engineer.
This way you ensure that your product’s intellectual property is protected against security threats, the discovery of app vulnerabilities and unauthorized access.
In the current scenario, the Android application was not obfuscated and hence revealed the source code of the application.
- Unrestricted File Upload:
Many web applications allow users to upload files that will either be stored or processed by the receiving web server.
It was possible to identify a form which allows files with arbitrary content and extension to be uploaded to the remote server and then stores the uploaded file to a guessable path in the server’s Webroot.
This could be used by a cyber-criminal to host content from the vulnerable server for phishing and Cross-Site Scripting attacks. In cases where the server is configured to execute scripts (PHP, Ruby, etc.) this vulnerability can be used to gain remote code execution on the server.
During the assessment of the application, it was discovered that any file can be uploaded while updating the “Display Picture”.
- App Log Sensitive Information:
The mobile platform provides capabilities for an app to output logging information and obtain log output. There are many legitimate reasons to create log files on a mobile device, such as keeping track of crashes, errors, and usage statistics.
Log files can be stored locally when the app is offline and sent to the endpoint once the app is online. However, logging sensitive data may expose the data to attackers or malicious applications, and it might also violate user confidentiality.
We discovered the application logs, firebase token, meeting ID, user credentials, and User-id AuthKey in the application.
- Unknown Permissions:
Unknown permissions should not be part of the application. The attacker may leverage this permission to manipulate the file system in the device.
During the assessment of the application, it was discovered that unknown permissions were given which might be vulnerable and may lead to accessing of the application by other applications.
Business Risks We Prevented
- Data Breach
- Malware
- Spoofing
- Unauthorized access to data
- Decline in App Downloads
- Financial Loss
- Decline in Reputation
