Hello Everyone,
Here I’m going to share one of my findings which I got while enumerating iOS application, below are my findings and the process of exploiting the vulnerability.
let’s assume the application/hostname as “application.com”
OS -> Kali Linux
Device -> iOS
Let’s begin
While enumerating the application i encountered that application was having Jail break detection and SSL pinning enabled. there are certain ways to bypass the Jailbreak detection using liberty, Frida -> objection and for bypassing the SSL pinning I used SSL Kill Switch 2 and frida objection . let me know in the comments if you know a new tool for bypassing the SSL Pinning and jail break detection in iOS.
So I bypassed the Jail Break Detection by using liberty tool and bypassed the SSL pinning using SSL Kill Switch 2 tool (Both the tools are available in Cydia)
So now after bypassing the jail break detection and SSL pinning I was able to intercept the traffic.
Below are the findings i got in the application.
1. Improper Access Control (View/Update).
2. Account Takeover via Old Password Brute Force.
Improper Access Control — Profile
The application was having a profile section, from which it is possible to view or modify user details.
In both the requests application send user’s email ID as ID to identify user in request.
View Details
Request -> data was encoded in URL format below is the decoded request
…
},”requestData”:{“serviceid”:42,”UID”:”ANONYMOUS@GMAIL.COM”,”LANG_ID”:”EN”}}}}]
….Response ->
…
”ProfileDetails\”:{\”MOBILE\”:\”9479XXXX\”,\”PROFILE_IMAGE\”:\”\”,\”DOB\”:\”20\”,\”GENDER\”:\”male\”,\”EMAIL\”:\”anonymous@gmail.com\”,\”NAME\”:\”blabla\”}}”,
…
Update Details
Request ->
…
”UID”:”anonymous@gmail.com”,”EMAIL”:”victim@gmail.com”,”NAME”:”Attacker”,”MOBILE”:”12345",”LANG_ID”:”EN”,”DOB”:”20",”PROFILE_IMAGE”:””}}}}]
….Response ->
…
”RESPONSE”:”{\”status\”:\”Profile details has been successfully updated.\”,”statusCode”:200
….
On replacing UID with email of another user, the application does not validate session and responds only on the basis of provided email.
Impact of above Vulnerability -> An attacker is able to brute force the email parameter trough which he/she read/modify sensitive information of registered user i.e. Username, Gender, Age, Registered Mobile Number. This IDOR can lead to Account takeover as attacker was able to update the victim profile with MOBILE number too, with the advantage to forgot password facility an attacker can ask for recovery PIN on phone number and can takeover the victim account.
Account Takeover via old password brute force
On further enumeration I observed that in change pin functionality I was able to brute force the old password of current user (anonymous@gmail.com = attacker user)
Request -> Change PIN
…
”requestData”:{“serviceid”:40,”UID”:”ANONYMOUS@GMAIL.COM”,”OLD_PIN”:”8634",”NEW_PIN”:”1234",”LANG_ID”:”EN”}}}}}
…
After getting no rate limit on OLD PASSWORD, I thought what if I can brute force the OLD PASSWORD of victim user, the email ID we got from user-enumeration.
Without any further delay I tempered the email ID from anonymous@gmail.com to victim@gmail.com and had generated a brute force pin pattern on 4 digit.
Request -> Change anonymous@gmail.com to victim@gmail.com
…
”requestData”:{“serviceid”:40,”UID”:”VICTIM@GMAIL.COM”,”OLD_PIN”:”8634",”NEW_PIN”:”1234",”LANG_ID”:”EN”}}}}
…
and after certain number of tries I got the golden response I was waiting for
Response -> successfully changed the victim account PIN
…
“isSuccessful”:true,”responseTime”:182,”RESPONSE”:”{\”header\”:{\”status\”:\”PIN had been successfully changed.\”,\,\”TYPE\”:\”M\”,\”status\”:\”1\”}}”,”statusCode”:200
…
Impact of the above vulnerability -> An attacker having a valid user email Address can brute force the OLD password of victim user and can take over the account.
Remediation for above vulnerability :-
1. IDOR : Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata. Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record.
2. No rate limit on OLD Password : limit the number of PIN change requests. Implementation of anti-bot detection such as CAPTCHA. Implement 429 status code for too many requests.
Thank you for the time you invested in reading my finding.
please follow, will be updating my all recent findings. let me know in comments what are you findings.
Twitter -> raj_singh_ch
