BYPASS Authentication

While most applications require authentication for gaining access to private information or to execute tasks, not every authentication method is able to provide adequate security.
Negligence, ignorance, or simple understatement of security threats often result in authentication schemes that can be bypassed by simply skipping the login page and directly calling an internal page that is supposed to be accessed only after authentication has been performed.
In addition to this, it is often possible to bypass authentication measures by tampering with requests and tricking the application into thinking that we're already authenticated. This can be accomplished either by modifying the given URL parameter or by manipulating the form or by counterfeiting sessions.
Authentication plays a critical role in the security of web applications. When a user provides his login name and password to authenticate and prove his identity, the application assigns the user specific privileges to the system, based on the identity established by the supplied credentials.
HTTP can embed several different types of authentication protocols. These include:

• Basic - Cleartext username/password, Base-64 encode (trivially decoded)
• Digest - Like Basic, but passwords are scrambled
• Form-based - A custom form is used to input username/password (or other credentials) and is processed using custom logic on the backend.
• NTLM - Microsoft's proprietary authentication protocol, implemented within HTTP request/response headers.
• Negotiate - A new protocol from Microsoft that allows any type of authentication specified above to be dynamically agreed upon by the client and server. Also adds Kerberos for clients using Microsoft's IE v5+.
• Client-side Certificates - Although rarely used, SSL/TLS provides an option that checks the authenticity of a digital certificate present by the Web client, essentially making it an authentication token.
• Microsoft Passport - A single-sign-in (SSI) service run by Microsoft Corporation that allows web sites (called "Passport Partners") to authenticate users based on their membership in the Passport service. The mechanism uses a key shared between Microsoft and the Partner site to create a cookie that uniquely identifies the user.

These authentication protocols operate right over HTTP (or SSL/TSL), with credentials embedded right in the request/response traffic.
This kind of attack is not a technological security hole in the Operating System or server software. It depends rather on how securely stored and complex the passwords are and on how easy it is for the attacker to reach the server (network security).

Description of the Issue 

Problems related to Authentication Schema could be found at different stages of the software development life cycle (SDLC), like design, development, and deployment phase.
Examples of design errors include a wrong definition of application parts to be protected, the choice of not applying strong encryption protocols for securing authentication data exchange, and many more. Problems in the development phase are, for example, the incorrect implementation of input validation functionalities, or not following the security best practices for the specific language.
In addition, there may be issues during the application setup (installation and configuration activities), due to a lack in required technical skills, or due to poor documentation available.

Basic Authentication Bypass

For example, a very basic error that a surprising number of developers make when coding an authentication mechanism for Web applications or network hardware is simply to ask for a user name and password at a login page, and then to allow authorized users unrestricted access to other Web pages without any further checks. The problem with this is that it assumes that the only way to get to the configuration pages is through the login page, but what if users can go directly to the configuration pages, bypassing authentication.
Essentially the router would be relying on security by obscurity, but in practice it is probably not hard for a hacker to find out the exact URLs of the configuration pages. There are a number of ways that this could be done, including:

• Buying or otherwise getting authorized access to a similar piece of hardware and establishing the configuration page URLs
• Finding them out from an online manual or a Web forum
• Sniffing network traffic
• Educated guessing (perhaps remote.html)

To prevent this type of simple bypass it is essential that checks are made that the user has been authenticated on every single page, rather than assuming that if a user has reached a given page they must have been previously authenticated.

Changing Fixed Parameters

When an application or device checks that the user has previously been authenticated, it's important that this check is effective. Authentication bypass vulnerabilities will occur if this is not the case. A simple example of this is when a simple parameter is appended to the end of a URL.
For example, imagine a system that uses a parameter "auth" to signify if a user has been authenticated, and prompts for the log in procedure if auth=0, switching it to auth=1 once a successful login has taken place. As long as auth=1, the user remains authenticated and able to access restricted pages.
Trying to get to a restricted page, a user's browser might submit:
http://www.example.com/remotemanagement.asp?auth=0

Bypassing this authentication might then be as simple as changing auth=0 to auth=1.

Session Prediction

A more sophisticated way of authenticating a user on every page, or "keeping a user logged in", is to send the user a session ID, usually in a cookie, which contains a unique number or string that allows the server to recognize the user as one who has been recently authenticated and entitled to view restricted pages.
Session IDs should be random, making them impossible to predict, and this is often achieved by passing some more predictable value through a hashing function to produce a session ID that is entirely unrelated to the previous ones that have been generated. A mistake that some Web developers make is to use session IDs that are predictable - perhaps by incrementing them sequentially - or to randomise only a part of session IDs, making the short random part susceptible to a brute force attack. If a hacker can get access to a valid session ID then they can carry out authentication bypassing by doing a session hijack attack - essentially providing the server with the session ID of someone who has already been authenticated, thereby impersonating them.
Session IDs can be strengthened by linking them to the IP address of the user who originally authenticated, but this is ineffective when the user is connecting from a public Internet spot where everyone, including hackers, have the same public IP address.
The weakness of session IDs in some circumstances was highlighted recently with the release of a Firefox browser add-on called Firesheep. This exploits the fact that many Web applications such as Facebook carry out initial authentication using a secure SSL connection, but then allow the user to carry on using the application on an unencrypted channel. That means that a user connecting to the application at a public WiFi hotspot sends their session ID over the air in the clear, and Firesheep simply captures it. Armed with a captured valid session ID, Firesheep then makes it trivial to carry out a session hijack by connecting to the application and submitting it, allowing the hacker to bypass authentication completely. In a corporate context, Firesheep highlights a potential weakness with using session Ids on your network if they can be intercepted by a hacker to use for authentication bypass purposes.

Obscuring restricted URLs

Some Web applications or devices maintain a list of URLs that are restricted and prompt the user for authentication credentials before allowing the user to access these URLS. The question that hackers ask is whether there are alternative URLs, which are not on the "restricted list", which point to the same restricted pages? or example, imagine a restricted
Web page: http://www.example.com/admin/configuration/
What if a hacker were to append an extra "/" at the end of this URL:
http://www.example.com/admin/configuration//
or add some other character like "?" or "%" or "~"? In some cases these URLs are effectively equivalent, even though they look different. If the authentication mechanism only checks for the original URL but not the variations then it can easily be bypassed.

SQL injection

SQL injection can be used to bypass authentication by fooling a login page into evaluating an expression that is always true instead of checking that a login name and password is valid. So, for example, the authentication mechanism might involve an expression like: (authorise a user) WHERE Password='$password'

Using a Web interface, when prompted for his password, a malicious user might enter:
ABC' or '1' = '1

resulting in the query:
(authorize a user) WHERE Password='ABC' OR '1' = '1'

The hacker has effectively injected a whole OR condition into the authentication process. Worse, the condition '1' = '1' is always true, so this SQL query will always result in the authentication process being bypassed.

Preventing Authentication Bypass Vulnerabilities

Authentication bypass vulnerabilities can have so many different root causes that it is impossible to give a comprehensive list of measures to take to prevent them. But steps you can take include:
Use the Metasploit penetration testing framework http://www.metasploit.com/ to check for known authentication vulnerabilities in your IT infrastructure.
If you are developing your own authentication code, be alert for possible buffer overflow errors or SQL injection vulnerabilities.
As ever, ensure that your applications are patched and up to date, and your network hardware is running the latest firmware.

Like it ? Share it.