Hello, welcome to my second blog post. Today we will be discussing the impacts of different attacks on an android application. Websites tend to contain more endpoints and as a result stores more information on the server. Generally, a web application is compacted into an android application which is very small and less responsive with respect to a web application. The impact of endpoints not been secured can lead to some critical data exposure and the possibility of manipulation of the same.
A week ago, I came across a few critical bugs on an android application, which could lead to full account takeover of the user without any interaction. In this blog, I will walk through each case study and also stating my experience in finding these bugs.
The following are the two case studies which I will discuss in detail:
- OTP bypass leading to full account takeover.
- Password change of another user without interaction.
Both of these bugs are a result of misconfigured API and access to unnecessary privileges given to a user to perform operations. As a result of no sufficient checks on the links, sensitive data was disclosed which compromised the user’s account. Only an admin should have the privileges to change another user’s password as well as monitor the OTP sent to the user’s mobile device.
Software/Tools used:
- Genymotion Emulator: Used for loading and testing of an Android Application.
- Burp Proxy: Used for intercepting communications between the application and the server.
Let us assume the site to be example.com (The program doesn’t allow public disclosures)
Case 1: OTP Bypass leading to full account takeover
In mobile applications, it is most likely for the OTP to be brute-forced which is an interesting vulnerability itself. The OTP in this application was sent when the user clicks on Forgot Password and enters a mobile number for verification. In this case, when an OTP was entered in the OTP request page, there was no request sent to the server from the application. This seemed strange! I thought that my Genymotion wasn’t connected to the internet or the proxy wasn’t set properly.
On checking the History Panel under the Proxy column in my Burp. All the previous requests sent by the application to the server were visible when requesting for OTP. While checking the response for that request, it was found that the server sent out OTP in the response.
The application sent out a post request as:
POST /api/otp_password?countrycode=91&mobile=XXXXXXXXXX HTTP/1.1
Host: api.example.com
And we got a response as:
HTTP/1.1 200 OK
{“status”:”success”,”message”:null,”otp_code”:”XXXXXX”}
To Verify, the request was forwarded to the repeater and sent again. But this time it threw back an error stating that there was a time limit for the user to resend the request. The request was then resent after a time period of 1min as this was the period of the OTP to expire. On hitting button Go Now, the server responded with another OTP. After entering the OTP in the password reset section, we found that somehow the OTP wasn’t being accepted by the server. The only option to prove the existence of the bug was to show the Proxy History and copying the OTP generated by the server during the request made by the application. While making the Proof of Concept video, the OTP obtained from the history panel of requests was pasted, which gave access to the account. The application now allowed any user to set a new password for any mobile phone. This is a critical bug as an attacker could take over an account by just knowing the mobile number of the victim.
Case 2: Password change of another user without interaction
After performing more tests on the application, a password reset page was hidden in the background and was accessible after the correct OTP was entered. It is on this page the user enters a new password for his account. When the request was submitted, the password resets and the user logs in to his account. The application was connected through the Burp Proxy the entire time while it was firing these requests. The History of requests was then examined.
There was one URL having 2 parameters: Mobile Number and Password
POST /api/update_password?password=password&mobile=XXXXXXXXXX HTTP/1.1
Host: api.example.com
The request was captured in the repeater to test whether the request would fire if the password was changed. If the request was successful, User gained admin privileges and could change the password bypassing two-factor authentication.
The request was then sent in the repeater with a different password, where the response was now a success with status code 200. This concluded that the parameter password had no access control set on it and any attacker having the mobile number of victims could change his password and take over his entire account.
To completely test my theory, a different account using another mobile number as well as a different password was used to sign into the application. The request from the repeater was then fired after making the appropriate changes in parameters. The server gave out a success in response. The new set of credentials was now tested on the application which was later accepted by the server logging the attacker on behalf of the victim.
Unfortunately, both of these bugs were marked as duplicate by the program manager as these bugs were already reported a few months back by some researcher. It was an amazing find and so wanted to share it.
#Bug Bounty Tip – If a website does not verify your email, you can try signing up with <email>@domain.com (the mail id of the company). Sometimes you can get privileges like viewing/deleting any other users’ profile. To show a small example, an application in a private program was put to test. The web application did not verify the email and so any anonymous user could sign up with hello@example.com (where example.com was the actual domain name of the website). While logging in, an application feedback page was encountered which was hidden to users with emails from other domains.
nice one Yarr looking for more update
New post coming up soon. Stay Connected!
Great find!!!