[2/n]
An account takeover usually refers to gaining persistent access to the victim user's account and performing all the authentication actions as a victim would be able to do. The severity of account takeover issues is usually considered between High to Critical.
[3/n]
However, it also depends upon the complexity and likelihood of the attack.
In general, the account takeover is not a "vulnerability class" itself but an impact result of a vulnerability.
[4/n]
For example, the application was vulnerable to CSRF, and the attacker was able to perform specific actions that led to "Account Takeover".
Below is my methodology for testing different scenarios of Account Takeover:
[5/n] 1. Account Takeover by CSRF
- If your target application is vulnerable to CSRF on functionalities such as "Email/Phone" Change, you can attempt to perform account takeover using it.
a. Perform CSRF to Update Attacker Email/Phone in Victim Account
[6/n]
b. Perform Password Reset using Attacker Email/Phone set in Victim Account
c. Account Takeover Successful.
[7/n] 2. Account Takeover by IDOR (Post Authentication)
- If your target application is vulnerable to IDOR on functionalities such as "Email/Phone" Change, you can attempt to perform account takeover using it.
a. Perform IDOR to Update Attacker Email/Phone in Victim Account
[8/n]
b. Perform Password Reset using Attacker Email/Phone set in Victim Account
c. Account Takeover Successful.
[9/n] 3. Account Takeover by IDOR in Password Reset
- If the application sends `user identifier` in the password reset functionality. Then, one can perform an account takeover. Multiple methods depend upon the functionality. One of the standard methods is:
[10/n]
a. Trigger Password Reset Request
b. Open the Password Reset Link and Change the `user identifier` to `victim user`.
c. Attempt to perform Password Reset.
d. If the password reset is successful, account takeover is achieved.
[11/n] 4. Takeover by Password Reset Poisoning
- If the app is vulnerable to host header injection, an attacker can attempt to perform a password reset poisoning attack by adding an attacker-controlled host to the password reset link and completing takeover in simple steps:
[12/n]
a. Capture the Password Reset Request and Change the Host header value to "attacker-controlled" host.
b. Forward the request and check the email for the password reset link.
[13/n]
c. If the password reset link contains the "attacker-controlled" hostname and the victim clicks on the link, it will be logged on the attacker server.
d. Attacker can use the token and perform account takeover by resetting the password.
[14/n] 5. Account Takeover by Broken Cryptography
- If the password reset token/link generated by the application is not cryptographically strong, an attacker may attempt to find a way to forge a valid reset token.
[15/n]
There are no specific ways to execute these attacks, but the main goal is to identify how the token is generated.
a. Check for the Randomness
b. Check for standard cryptographic methods in use
c. Try to identify if any known token generation library is used by the app
[16/n] 6. Account Takeover by OAuth Misconfiguration
- If the application uses OAuth, there are multiple ways to perform account takeover if the OAuth is misconfigured. Some of the attacks are performing account takeover using CSRF in OAuth, SSO Restriction Bypass, etc.
7. Pre-Authentication Account Takeover
- I have shared an in-depth blog on performing Pre-Authentication Account Takeover that can be found at: hbothra22.medium.com/attacking-soci…
[18/n] 8. Account Takeover due to Improper Rate-Limitation Checks
- If the application doesn't implement proper rate-limitation, it is possible to bypass the authentication in the application that utilizes Phone/Email OTP based login (Assuming OTP is 4 digit & has a long expiry)
[19/n]
a. Initiate a login request and send an OTP.
b. Input Wrong OTP and Fuzz the OTP parameter.
c. Once the valid OTP is received, you will get the proper access token which can be used to login into the user account.
[20/n]
- This issue is also seen in the application having no password policy where an attacker can brute-force the password field.
[21/n] 9. Account Takeover due to Weak Security Policies
- Due to the weak security policies, an attacker may find a way to bypass the authentication & authorization and attempt to gain initial non-persistent access to the victim account.
[22/n]
Once you have initial access, you can attempt to get privileged access depending upon the application use-case & offered functionalities.
[23/n] 10. Account Takeover by Utilizing Sensitive Data Exposure
- Always check for the sensitive data exposure in different components for interesting information such as "Access Tokens", "Session Tokens", and "Credentials".
[24/n]
Sometimes, the access tokens are fresh and not expired that can be used to perform session hijacking and gain non-persistent access to the user account.
- Also, search for the endpoints that might reveal sensitive information such as password hashes, session variables, etc
[25/n] 11. Account Takeover by Cross-Site Scripting
- If you have cross-site scripting, there are ways to steal a user's session cookies & gain a non-persistent account takeover. However, in a situation where you can hijack admin sessions and create more admin accounts or ..
[26/n]
...reset the password for any users, you can perform a persistent account takeover.
- Even if you cannot hijack a session, if there's a way to create an account using an admin account controlled by JS, you can use XSS to trigger it and create a user account.
Premium Features are not widely tested by the crowd due to the involvement of a purchase factor. However, the person who often invests in the premium account is less likely to go disappointed.
(1/n)🧵
Below is my methodology to test for the Premium features:
[Without Purchase] 1. Fuzzing the API endpoints to find out the endpoints that are accessible to premium users.
(2/n)
2. Comparing the difference in the freemium vs premium accounts and creating a threat map of functionalities available in the premium account to make sure if it's really worth an investment.
Many applications in iOS platform provides a functionality to enable touch/face ID to act as an added layer of protection to the application. However, it is possible to bypass this layer.
(1/n)
(2/n)
If the attack has "physical access" to the device, there are multiple options to bypass the checks, however, one of the simplest methods is to use "Objection".
Before, performing the attack ensure that the Frida is running. Also, the Objection must be installed.
(3/n)
# How to perform the attack:
1. Run the following command: objection --gadget <package_name_here> 2. In the objection run following command: ios ui biometrics_bypass
#SecurityExplained S-5: Bypassing Privileges & Other Restrictions with Mass Assignment Attacks.
As per OWASP's definition: Software frameworks sometimes allow developers to automatically bind HTTP request parameters into program code variables or ...
(1/n)
objects to make using that framework easier on developers. Attackers can sometimes use this methodology to create new parameters that the developer never intended which in turn creates or overwrites new variable or objects in program code that was not intended.
(2/n)
(3/n)
There are multiple attacks that can be executed by exploiting this vulnerability such as escalating privileges, bypassing business logic, manipulating payloads and bypassing client-side checks.
The below thread contains an overview of my pentesting methodology on the web application targets:
1. Initially, before starting with the engagement, I start with "Scoping" .........
(1/n)
(2/n)
where I go through the details shared by the client to understand the scope and see if the testing is feasible as per the given timeline. During this phase, I also check if the application is accessible and credentials (if required) are working properly.
(3/n)
If any of the things from "Step-1" are blocking, I reach out to the concerned person and request to unblock the blocking items. 2. Next, I start browsing the application while letting the traffic flow through Burp Suite to populate the "Target" menu.
Captcha is widely adapted by the applications to avoid automated attempts on specific functionality, commonly on the Authentication forms to avoid brute-force attacks.
(2/n)
However, it is possible to bypass Captcha, and sometimes if the function is critical, it can be paid well in terms of bounties.
1. Missing Server-Sides Validation
- Some apps send Captcha Parameters on the client-side but they do not validate this on the server side.
(3/n)
- Simply, Remove the "Captcha" parameters and see if the request is processed successfully.
- If yes, you can now use this request to perform your brute-force or rate-limiting attempts.
#learn365 Day-30: Common Business Logic Issues (Wrap)
(Cont'd...) 9. Parameter Tampering
- Tamper Payment or Critical Fields to manipulate their values
- Add multiple fields or unexpected fields by abusing HTTP Parameter Pollution & Mass Assignment #bugbountytips#appsec
(1/n)
(2/n)
- Response Manipulation to bypass certain restrictions such as 2FA Bypass
10. App Implementation Logic Abuse
- If an app accepts JSON data, try changing content type to XML and see if the XML data is being processed, it can be left vulnerable to XXE or XML-based attacks.
(3/n)
- If an application is using the DELETE method to delete a resource but there is no CSRF protection, try converting the method to GET/POST and add an additional parameter like ?method=delete