Advanced Methods of Bypassing of Blockings at Web Sites

English Ukrainian

Eugene Dokukin aka MustLive

There are many methods of blockings, which admins of web sites are using to block access to their sites or to the parts of the functionality. Among such methods there are using of captchas and blocking by IP. These methods are used for security purposes, so they must be reliable.

But not all such methods are reliable enough (even there are such stereotypes) and there are ways to bypass them. So web developers and admins of web sites should be aware of it. Last year I’ve published some advanced bypassing methods (developed by me) and in this article I’d describe my methods of bypassing of security mechanisms at web sites.

Bypassing of captchas.

In 2007 in my project Month of Bugs in Captchas (MoBiC) [1] I’ve described a lot of basic and advanced methods of captcha bypassing. And in this article I’m talking about new advanced method, which I’ve described at my site in 2011 - it can be used even against unbypassable captchas (which can’t be bypassed by earlier mentioned methods).

In different forms at web sites, particularly in login form, such protection methods can be used as captcha or temporary blocking. In login form these methods protect against Brute Force attack. But these protection methods can be bypassed at their incorrect implementation, both blocking and captcha (particularly if captcha appears at page not right away, but appears after one or few incorrect login attempts).

First I’ve created this method in 2009, when found vulnerability at one web site, which allowed to block users access to the site at special request. And at deleting of session cookie this blocking can be bypassed. About this attack method I’ve wrote in my article “Using of safety mechanisms for blocking access to the site” [2]. Analogical possibilities of bypassing of blocking I’ve found many times at different sites during 2009-2011.

For example, during of security audit of the site of one my client, I’ve found possibility of using this method for captcha bypass in login form (when captcha appears after first unsuccessful login attempt). I.e. the status of captcha activation is in the session and if to delete session cookie, then captcha will not appear and it’ll be possible to conduct automated Brute Force attack. So if to not receive or delete cookie, then it’ll be possible to bypass the state of protection activation and so to bypass captchas and blockings at web sites.

Such vulnerabilities in protection systems taken place at different web sites and web applications. Let’s examine such attack on an example of MyBB.

In April 2011 I’ve disclosed Brute Force vulnerability in MyBB [3], where it’s was possible to bypass captcha in login form by using of session reusing with constant captcha bypass method (which is described in MoBiC project). The developers ignored to fix this and other vulnerabilities (in released MyBB 1.6.3). As I found in August, developers set by default other protection method in new versions MyBB 1.6.3 and 1.6.4 (which also exists in previous versions of engine and is using at most forums on MyBB). This method uses limit of login attempts instead of captcha, but this protection can be easily bypassed by using of above-mentioned method [4] (similarly to bypassing captcha).

If to not receive cookies (or delete or null cookie “loginattempts”), then the number of login attempts will be unlimited. And any blockings will fail. And if blocking has already worked, then it’s just needed to delete or null this cookie to remove blocking. This situation takes place at most forums on MyBB, but there are forums on such versions of the engine, which has counter of login attempts not in cookie “loginattempts”, but in the session. So for bypassing of protection it’s only needed to remove cookie “sid”.

The next figures show the process of blocking bypass:

Figure 1
In MyBB there is no captcha at login form and blocking is used.

Figure 2
They have set blocking after 3 unsuccessful login attempts.

Figure 3
Delete cookie “loginattempts” and conduct attack infinitely.

Thus such protection mechanisms as captcha and blocking, which hold their state in user supplied data (such as cookies), can by easily bypassed.

Bypassing of blocking by IP.

Now let’s talk about bypassing of more robust protection - blocking by IP. This method I’ve developed in July 2011, when was conducting security audit of one card processing PCI DSS site.

At existence of blocking by IP at web site (on 1 hour, or 24 hours, or even complete blocking), particularly in authentication forms, which triggers after few unsuccessful login attempts, there is a possibility to bypass this blocking. Which will come in handy to Brute Force attacks [5].

I’ll note that this method is designed exactly for bypassing of blocking in such functionality as authentication forms (for bypassing of any blockings by IP in any functionality the proxies should be used), at that single IP address is used. And for using of the method it’s needed to have working account at the target site, i.e. the registration should be available at the site to make working account for yourself.

For conducting of Brute Force attack with bypassing of blocking it’s needed to do the next steps:

1. Create working account at the target site.

2. Find out margin of blocking - after which unsuccessful login attempts the blocking occurs (e.g. 15).

3. Use the bypass method for conducting of Brute Force attack to pickup passwords.

The essence of the method is the next. Usually at blocking by IP the number of unsuccessful login attempts is counting, which is nulled at successful login attempt. So it’s needed periodically, before blocking will trigger, to send requests with correct login and password (for own account) to null this counter. E.g. at blocking after 15 attempts, it is necessary to send certainly correct authentication data after every 5th attempt.

Thus the blocking by IP is bypassing and it’s possible to infinitely bruteforce from single IP.

Conclusion.

Even such protection methods as captcha and blocking by IP can be bypassed, as you can see from above-mentioned. So web developers and admins of web sites should be aware of it and protection mechanisms should be implemented correctly. And security auditors should check web applications and web sites for liability to such attacks, as to basic captcha bypass methods, as to these advanced attack methods. To check reliability of safety mechanisms and also to make sure that they can’t be used for blocking access of the legitimate users to web sites.

References:

1. Month of Bugs in Captchas (http://websecurity.com.ua/category/mobic/).
2. Using of safety mechanisms for blocking access to the site (http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2010-August/007003.html).
3. Multiple vulnerabilities in MyBB (http://lists.grok.org.uk/pipermail/full-disclosure/2011-April/080408.html).
4. Security bypass vulnerability in MyBB (http://lists.grok.org.uk/pipermail/full-disclosure/2011-September/082625.html).
5. Brute Force (http://projects.webappsec.org/Brute-Force).