Overview
Authentication Bypass Vulnerabilities are common flaws in web applications today, but they are not always easy to find.
With the continuous development of technology and the integration of various platforms, traditional authentication methods are gradually decreasing. The new authentication method not only provides convenience for users but also improves security to a higher level. While old ways of logging in users, such as leveraging single sign-on (SSO), are improvements, these techniques can still contain critical vulnerabilities. Whether it is a business logic error or some other flawed configuration, how can one discover these vulnerabilities?
Misconfiguration of the token refresh terminal
In this case, when a user logs into the application with valid credentials, an authentication token is created for authentication. And this authentication token expires after some time. A valid auth token appears in the return packet by endpoint/refresh/tokenlogin sending a request to the server with parameters just before it expires .username
Wrong SSO Configuration
With the diversity of platforms and the continuous improvement of user needs, in order to facilitate users to log in to multiple applications and websites through one-time user authentication, most platforms use SSO systems. But simply using SSO doesn't automatically secure the system: the SSO configuration must also be secure.
Here, an application authenticates using the Microsoft SSO system. When viewing internal.test.com the URL, the browser is redirected to the single sign-on system:
At first glance, it seems to be safe, but analyzing the backend request shows that the program returns an unusually large content, more than 40000 bytes, regarding the content of the redirection response!
Why do you want to return like this? Can there be some other operations to jump directly into the destination?
You will find out yourself that the content of the server sending the user to the process of redirecting to SSO leaks the internal response to the request. So try tampering with the response.
Change 302 the Find header to 200 OK, and delete the entire Location header. successfully bypassed.
Of course, this process can be automated by Burp Suiteadding Match & Replace rules to delete and automatically change the value directly.
CMS - Case Access Problem
CMSs like WordPress, Drupal, and Hubspot also need to be securely configured to avoid such vulnerabilities.
Here is an example of Liferay, which is also based on a coincidence encounter. The app has a login page that can be accessed without authentication.
Liferay uses a portlet as the sso for the application, which has a parameter in the number id p p id. For portlets, the login portlet can be accessed by changing the parameter to a value of 58. On a normal login page, only the login page is accessible. However, by accessing the portlet directly, it is possible to access Create Account function, which then allows self-registration of the function to access background content without requiring authorization.
Although Liferay has used this workflow before, its latest version uses portlet names instead of numeric ids. However, other portlets can also be accessed by changing the name.
JWT - Error parsing of JWT Token
JWT token or JSON Web Token is widely used on the Web. However, although they have a security mechanism by default, which is the key, it is not certain whether the resolution mechanism of the back-end server is secure enough.
There was a website that was using JWT, and when accessed directly, the application redirected the user to Microsoft SSO the webpage.
However, some JS files can be accessed without authentication. While testing it was found that the application uses JWT tokens which are sent through the system after a secure login Microsoft SSO. In the backend mechanism, there was a security misconfiguration that didn't check if the JWT token was generated for a specific application - instead, it accepted any JWT token with a valid signature. Here's an example using a JWT token from Microsoft's website:
Decode the content:
Access the internal interface and successfully obtain data:
Violent Modification of Authentication
In this case, a base64-encoded XML request is sent to the backend for validation. On the login mechanism, it sends the username and password separately. The value in the Scode parameter is the md5 value of the password... There is another interesting flag in the request: scode has a value of 2.
Tried assigning value to 1, it worked! So try to traverse the Scode. Through traversal, it is found that, except for 0, most of them report errors. To change the way of thinking, the value in the Scode parameter is a password, and the operation on the password is unsuccessful. What about the value of the password?
It turned out that authentication could be bypassed simply by providing a username and an empty password.
References
Conclusion
Complex authentication mechanisms can become a new attack vector, especially in applications that are prone to business logic flaws. Since automated scanners often fail to find these vulnerabilities, they still need to be found manually.
Source:- https://tutorialboy24.blogspot.com/2023/04/an-authentication-bypass.html