While working on the protection of an online store of one of our customers, we several times ran into a curious brute-force attack, which was not so easy to resist. It was based on a simple to graceful decision, which distinguished an attack from the ranks of its ilk. What she represented and how we were still protected from her, read under the cut.
As you know, the “classic” brute-force is an attack using the data brute force method. For example, known accounts are taken, and passwords are selected for them according to some criteria, either generated on the fly or on the basis of stolen dictionaries. This is the basic method of hacking accounts.
And in the case I’m describing, the attackers acted a little differently. First, they used a large botnet distributed among different countries from several hundred infected computers. In the monitoring system, everything looked as if they were completely different computers, or proxy servers, for which real people sat and accessed the site. Such an attack can go unnoticed for a long time.
The second feature of the attack, in addition to a strong geographical distribution, was not over passwords, but logins. Possibly, malefactors used dictionaries of popular passwords and the stolen lists of logins. And at first one login was taken to a known password, then another, a third and so on. It was very similar to the situation when ordinary users connected through one provider cannot login with their passwords. That is, at first glance, nothing criminal. In addition, recourses to the resource were very rare - one or two per minute.
The third feature of the attack was that the botnet had a very "human" behavior: the clients processed JavaScript, accepted cookies.
Because of this complex factor, the attack went unnoticed for quite a long time. When we discovered it, we asked a nontrivial question: how to defend? All botnet computers did not have any particular distinguishing features, except for a certain error in the user agent. But we did not block the attack on the basis of this sign, because in this case we would no longer see the actions of the attacker. It was necessary to isolate some other anomalies. From the point of view of IP addresses, nothing much happened. It is also impossible to block logins that make a large number of unsuccessful attempts to log in, because the frequency is very low, and not a password, but a login. There was only one way - to introduce a captcha. But the customer really did not want to do this, because he believed that captcha could alienate many customers. Meanwhile, the attackers have already managed to find the right combinations for some accounts.
Surely you wonder: why would someone hack into the accounts of online store customers? The fact is that bonus points accumulate in your account, which can be used to get discounts on goods. Probably, someone really wanted to buy or sell bonus points on the Internet.
As a result, we persuaded the client to introduce a captcha using F5: it should appear after a specified number of unsuccessful entries. But first you had to set up the criteria for successful login in the system. This turned out to be a little more complicated than it looked, because in some cases the resource gives the same response code to any login attempts. As a criterion for successful login, we chose to transfer a domain cookie to the client.
The latest version of
F5 ASM has the ability to respond to selection attempts from the point of view of Device ID - a unique browser identifier. A JS code is added to the page, and when an infected machine opens this page, it reports its unique identifier. In the case of our attackers, it turned out that the Device ID of the browser was the same for each IP address. That is, in fact, one browser accessed from the same IP address.
Therefore, you can set the following criterion: if more than 5 unsuccessful login attempts are made within one 15 minutes from one browser, a captcha is shown to this client. If this is really a normal user, he will decide it and calmly log in. In case the browser does not support JavaScript, we have added exceptions. But in order not to weaken the protection, another criterion was used: if more than 20 unsuccessful login attempts are made from the same IP address, a captcha is again offered. Again: for a normal user, this will not create problems.
But today there are already methods for circumventing protection using captcha. For example, botnets send captcha to “outsourcing” - to China or India, where hardworking local people solve captcha for a small fee and return text values. But even in this case, appropriate measures can be taken: even if, with resolved captcha, attempts to enter are unsuccessful, you can block requests from a specific IP or Device ID if a specified number of unsuccessful attempts are exceeded.
The last time an online store attacked in this way, we managed a captcha and it worked. After its introduction, the brute-force attack gradually began to fade and eventually ceased. About a year has passed since then - there has been no relapse.
Andrei Chernykh, expert of the Information Security Center "Jet Infosystems"