Watch for Authentication Bypass Vulnerabilities

Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.

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?

For example, imagine a restricted Web page:


What if a hacker were to append an extra “/” at the end of this URL:


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 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.
  • Be aware of the sorts of vulnerabilities outlined in this article.
  • As ever, ensure that your applications are patched and up to date, and your network hardware is running the latest firmware.
Paul Rubens
Paul Rubens
Paul Rubens is a technology journalist specializing in enterprise networking, security, storage, and virtualization. He has worked for international publications including The Financial Times, BBC, and The Economist, and is now based near Oxford, U.K. When not writing about technology Paul can usually be found playing or restoring pinball machines.

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends, and analysis.

Latest Articles

Follow Us On Social Media

Explore More