Hello and welcome to AppSecWriteups.com! I’m Jivan Magare, and in today’s post, I’ll walk you through one of my recent security assessments involving an Android app, where I identified the use of default credentials, a common misconfiguration that could affect application security if not addressed properly.
Before diving into the technical details, I want to clarify that all vulnerability write-ups published on AppSecWriteups.com are based on issues that have already been fixed by the respective companies. All testing was conducted ethically, as part of responsible disclosure programs, in collaboration with the affected organizations to help improve their security and protect users online.
Now, understanding the scope of the company where the vulnerability was discovered, I won’t be sharing the specific target details or company name due to security and disclosure reasons. Instead, I’ll refer to the application as [Redacted Android App] throughout this write-up.
Initially, the bug bounty policy clearly stated that any digital assets owned and operated by the company were in scope. Once I saw this, it presented a valuable opportunity to explore to all available digital assets for potential misconfigurations and security issues.
After reading the bug bounty policy, I searched to see whether any mobile applications were owned by the company, and I found a few Android apps listed on the Play Store. I selected my first target app for testing and began my analysis.
During the initial phase, I directly started with dynamic analysis and confirmed that the application was using SSL pinning, which is a good security practice. I then moved to the next phase and started observing the API traffic of [Redacted Android App], but I didn’t find any sensitive information in the API requests during this stage.
After bypassing SSL pinning on [Redacted Android App], the app was launched on an emulator, and it started with the Login Activity, where users are required to enter a username and password to access the application. There was no option to register as a new user, which meant the entire assessment had to be conducted as a black-box test, where I needed to explore potential logic flaws or check for default credentials.
Before starting the testing, I had a clear plan to approach the application logically. My first step was to analyze the login functionality and attempt to manipulate the responses to see if there were any flaws in the authentication process.
If this approach failed, my next step was to check for any rate-limiting issues on the login endpoint by testing with common, guessable usernames and passwords. This is one of the most common techniques I follow during black-box testing, especially when there’s no option to create a new user account.
Sometimes, I also look for hardcoded credentials within the app binary or use Google dorks to uncover public information that could help form a complete access chain.
This wasn’t my first time testing this kind of setup in my previous security assessments, I’ve discovered multiple vulnerabilities in apps and websites with similar black-box conditions, where no registration or account creation functionality is available. Many of those findings have been rewarded, giving me enough experience to confidently handle these types of scenarios.
This was the plan I followed while testing the [Redacted Android App] at that time.
To begin, I navigated to the “Forgot Password” functionality to observe how the server responded to invalid input. I first entered a random username, such as “test”, and submitted the request. The server responded with: “Entered ID: username is not found.” This confirmed that the username was not registered which was expected, since I didn’t have any valid credentials at that point.
Before moving forward with any rate-limit testing, I sent this request to the Repeater tab and changed the test username to “admin”. After sending the request again, this time the server responded with a 200 OK status and returned a message: “Password reset email is sent to the registered user email.”
From this, I was able to confirm that “admin” is a valid username. The next step in my testing process was to explore potential ways to obtain or reset the password for this user under ethical and policy-compliant boundaries.
Now, I moved back to the login functionality to verify the previously confirmed username. I entered “admin” as both the username and password, then submitted the request.
I captured the request using Burp Suite, and the server responded with a 401 Unauthorized status code confirming that the credentials were incorrect.
When I saw the 401 Unauthorized response, I initially thought it would be difficult to gain access and that I would need to spend more time analyzing the issue. However, during testing, I realized I had overlooked an important detail there was an option available during login to select the environment type, either Live or Training.
In the request I analyzed earlier, the environment type was set to “Live” by default. (Refer to the screenshot above for reference.)
Now, I changed the environment type from Live to Training, used the same credentials (admin:admin), and sent the request again.
This time, the server responded with a 200 OK status code instead of a 401 Unauthorized. I was able to successfully log in to the admin account on the [Redacted Android App] within the training environment.
If you look closely at the request above, you’ll notice that it allowed access to the admin account during testing, confirming that the credentials were valid in the selected environment. Let’s take a closer look at why this misconfiguration is important from both a security and application design perspective.
The [Redacted Android App] appears to be designed for internal administrative use. After logging in, the application displayed a message: “Please do not collect data on different devices with the same username, as this can result in data loss.” This clearly indicated that the app is intended for internal personnel only.
Upon further exploration, I noticed features such as data deletion were available within the interface. It appeared that this functionality could potentially affect application-wide data, depending on how access control and permissions were implemented.
Recognizing the potential impact of this misconfiguration, I decided to halt further testing to avoid any unintended changes or data loss. I then submitted a detailed and responsible disclosure report to the company.
After discovering this issue, I found that another Android app by the same company had similar functionality and was also vulnerable to the same misconfiguration. I promptly reported this second issue as well.
Within just half an hour, I identified and responsibly reported two security issues in separate Android applications maintained by the same company.
Both reports were acknowledged and accepted as High Severity issues, due to their potential impact on the business and their relevance to the CIA triad (Confidentiality, Integrity, and Availability).
🙏 Thanks for taking the time to read my write-up!
This case highlights how even small misconfigurations like weak default settings or overlooked access checks can lead to significant security risks if not addressed. It also reinforces the importance of carefully reviewing all features during security testing, especially in limited-access scenarios.
Interestingly, I found a similar issue in another Android app from the same company within a short time, showing the need for consistent security practices across all platforms.
If you found this post helpful or learned something new, feel free to connect or share your thoughts I always appreciate feedback from the community.
Until next time — stay curious, stay focused, and keep learning. 🚀🔐
