Authentication Bypass [Via Response Manipulation]
Hi Friends!
This is my 15th blog on web application security penetration testing. In this blog I will explain Authentication Bypass via response manipulation. In my last blog, I have explained about CSV or Formula Injection attack. Hope you people liked it. If you haven’t read it yet please follow along.
Before moving ahead, let me remind you about our Burp Suite proxy tool where we can captured the Request and Responses which goes To & From Web server. If you are very much newbie and don’t know how to capture responses then have a look in below screenshot.
Once, I was performing dynamic penetration testing of the android application. This application was useful for booking flights. I have installed .apk on my android rooted device and already configured to capture traffic of the mobile application into Burp Suite. Below is the step by step POC which I have collected through-out testing.
- Navigate to login screen. Enter credentials (valid Email and invalid Password) and click on login button.
2. · Capture the request in proxy tool. As shown in below screen, email is passed in the GET request to check whether Username is valid or not.
3. Server responds with following response indicating that account is valid.
4. Capture the verify credentials request in proxy tool as shown in below screen.
5. As entered credential(password) is incorrect application server responds with “Invalid Username or Password” error and message flag is set to FALSE as shown in below screen.
6. Alter the message parameter value from false to true to bypass the authentication as shown in below proof of evidence.
7. User successfully logged in with invalid credentials as shown in below screen.
Impact:
Below are the impacts based on above reported vulnerabilities:
Successful exploitation of this vulnerability allows an attacker to bypass the application’s authentication mechanisms and gain unauthorized access to any user account. Without a strong lockout mechanism, the application may be susceptible to brute force attacks. After a successful brute force attack, a malicious user could have access to:
· Confidential information or data: Private sections of application could disclose confidential documents, users’ profile data, financial information, bank details, users’ relationships, etc.
· Administration panels: These sections are used by webmasters to manage (modify, delete, add) application content, manage user provisioning, assign different privileges to the users, etc.
Remediation:
Recommendation for Preventing Authentication Bypass:
· Do not use static response for validating authentication.
· Always place server-side validation on each request and validate users.
· Choose the appropriate token for the level of risk of the transaction.
· Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.
· Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
· Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts.
· Design your system to require a code that must be appended to the reference number displayed on the OTP. The combined longer number is both unique and harder to crack than the OTP value by itself. Along the same lines, configure longer OTP values, in general. An eight-digit reference number is harder to crack than a six-digit one.
· To handle sessions properly, ensure that server creates, maintains, and destroys session tokens properly over the life-cycle of a user’s mobile app session.
References:
Broken Authentication OWASP:
https://www.owasp.org/index.php/Top_10-2017_A2-Broken_Authentication
Authentication Bypass:
https://compsecurityconcepts.wordpress.com/2013/11/02/authentication-bypass/
