Watch for Authentication Bypass Vulnerabilities

By Paul Rubens | Dec 8, 2010 | Print this Page

Imagine the front door to your house is equipped with heavy duty locks and bolts, but has a giant cat flap big enough for a man to crawl through fitted at the bottom of it. Why would a thief bother picking the locks when he could bypass them all by entering your home though the cat flap?

A vulnerability like this in your home is pretty unlikely, but believe it or not there are many network devices and Web applications that suffer from something analogous: authentication bypass vulnerabilities. These let hackers into networks and Web applications by allowing them to skip the authentication stage which is supposed to keep them out. They are a real treat for hackers because exploiting them is often far easier and less time consuming than other hacking techniques like trying to brute-force passwords.

Authentication bypass vulnerabilities, like buffer overflows, are generally caused by programmers assuming that users will behave in a certain way and failing to foresee the consequences of users doing the unexpected. The Metasploit penetration testing framework includes a number of authentication bypass modules which use techniques such as exploiting buffer overflows in the authentication mechanism, but there are simpler methods that hackers can use as well:

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 remotemanagement.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:

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

Session prediction/Firesheep

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.