From digitec IT Security: The fight against credential stuffing // Update 22.10.2018 14:00
An attack on digitec.ch may not have caused any damage, but it shows that engineers are always fighting against hackers, even without financial loss. Engineer István Flach talks about last week's attack.
"I've never done anything like this before," says István Flach. The young man with Hungarian roots is on the hunt for hackers this week. Last weekend, the digitecs and Galaxus alarm systems sounded the alarm. István is investigating the incident and trying to identify the culprits. Of course he has already investigated breaches or attempted breaches, but he has never been able to follow up an attack this far and for this long. Such an investigation begins with a critical question: How bad did it hit us?
István can quickly breathe a sigh of relief. After just a few hours, he can say with a fair degree of certainty what the attack was intended to achieve. "Our customers' credit card details have not been affected and we have no signs of financial damage or data theft," he says. His eleven-strong team can relax a little and the alert level is downgraded.
Why is István on the case? "I'm very interested in IT security," he says almost casually, but speaks with passion and knowledge about breaches, countermeasures and his search for clues. His personal and professional interest led to him being commissioned by Engineering to investigate the attack. His report of the incident - as the industry calls an attack - is detailed and brief. This is rare, as incident reports are usually several dozen pages long and full of verbiage. István's report says the essentials, serves as much more than a Management Summary and shows what the hackers wanted.
The attack in detail
The logs show that the attack began last Friday, 12 October 2018, at 15:58 local time. It lasted until 10:03 a.m. on Saturday
.
"They always do this. They don't want a lot of people in the office who could discover the attack by chance," he says.
But he wouldn't have noticed the attack at all. They sent 40 requests per second to the pages. When something like this happens, automatic systems kick in and block the login attempts. Of the 2,185,717 login attempts, only 763,564 were checked by digitec's servers. The remaining 1,422,063 attempts were blocked by protective measures in front of the servers. During this time, 2090 incorrect logins were recorded on Galaxus, which roughly corresponds to the normal rate of "Shit, now I've entered my password incorrectly". In the end, our servers told the attackers that 48,267 tried accounts actually existed in our system. However, no passwords were leaked. As far as we know at present, the hackers have not cracked anything. So there is no immediate need for you as a user to take action.
István therefore has seven hundred and sixty thousand data records to analyse. That takes time. It's nerve-wracking. Because what if the data record he is currently looking at is the key? What if it contains the critical clue to the damage, attacker or purpose of the attack?
"We know that something has happened, but not the purpose of the attack," says the engineer in the white polo shirt. He looks thoughtful, as if he is still puzzling over the meaning and purpose of the attack. Because he can't be absolutely sure. But he can say with a certain degree of certainty that it is a problem that is causing a global headache and not just plaguing digitec.
Credential stuffing: the global plague
"Credential stuffing," says István and sighs. When he comes to this realisation, he knows that he has a mountain of work ahead of him. Because it will be difficult to determine the purpose of the attack.
The Open Web Application Security Project (OWASP) defines credential stuffing as the automated scanning of user names and passwords. These go through a database that was stolen in another hack.
An attack can look like this: The hackers have a database from another hack at hand. Let's say they have cracked http://example.org and obtained 13 million data records with user names and passwords in plain text. This data can be capitalised on.
Meanwhile, you used the same password, let's say "LiviaRisottoHasenbaerli", and the same username, "thomas.mueller@mail.tld", for some websites. By the way, the password itself is more secure than a password like "QDXMam9Y"
- QDXMam9Y has an entropy value of 37.3 bits and can be cracked by a brute force attack with medium effort
- LiviaRisottoHasenbaerli has an entropy value of 104.4 and is complex enough to secure financial data
"No matter how secure your password is, if you use it for multiple sites, you're taking a risk," says István. He therefore strongly recommends that you use a different password on each site.
There are hardly any countermeasures against credential stuffing, as the attackers use exactly the same mechanisms as legitimate users. Nevertheless, engineers at the digitec offices on Hardturmstrasse are working on this, as are thousands of other engineers around the world. The problem is that logging in still needs to be convenient, but also as secure as possible.
István discovers the purpose of the attack. One week after the attack and the realisation that there is no acute danger to you as a customer or digitec as a company, he has two theories.
Theory #1: Attack by gamers
The attack is a theft. The hackers want to get hold of download codes for games and software and then sell them on the black market of the darknet.
This works globally. So the hackers don't have to be based in Switzerland and play Swiss games in Switzerland. You can redeem a code on the game manufacturer's website and download the game for free and apparently legally. This is because the manufacturer rarely validates the voucher codes as they are randomly generated. In the end, digitec and one customer per code would have the loss and someone somewhere would be playing a game at your expense.
The engineer can, however, say with certainty that the attack failed if that was the purpose of the attack.
Theory #2: Data validation
The second theory is currently the one István believes in the most and the one he is currently pursuing. The hackers didn't want to steal anything, but to validate data. After all, the more valid data records a stolen database contains, the more valuable it is for the hackers who actually want to cause damage.
This is how it works: A gang of hackers stole the database from http://example.org. 13 million data records. Before the database is put on the open market, the hack has to grow a bit. During this time, Example.org users are told to change their password. Some do, some don't. When it comes to selling the database, it's business as usual: "For sale: Database with 10 million valid data records" costs more and is more in demand than "Database with 8 million valid data records". However, the data must be checked for this.
This is why hackers filter their data. They therefore look for a site that is used by many people. In our example, this is https://bispiel.ch, a Swiss site with one million users. The database of example.org is therefore filtered. All data records that have the country "Switzerland" in their address data or whose email address ends in .ch are copied into a separate database and this is then released on bispiel.ch. If thomas.mueller@mail.tld is also registered on bispiel.ch and has also used the password LiviaRisottoHasenbaerli there, the account is sold as valid.
Who are the hackers?
For a full investigation and report to the [Reporting and Analysis Centre for Information Assurance MELANI), István pursues one question: Who is behind the attack?
It quickly becomes clear that the hackers are not exactly stupid. Of course, they are using proxies, i.e. servers that conceal the true origin of the attack. To do this, no IP is used more than 14 times during the attack.
"The usual suspects are there, of course," says István with a grin.
His report shows the top three IP ranks:
- Russia
- Estonia
- Lithuania
The trail gets lost there, because these countries are not so strict about IT security at the legal level and Russia, according to pretty much every secret service on the planet - with the exception of the Russian FSB - even operates its own "cyber army" in which state hackers use their skills for political purposes on behalf of the government.
The countermeasures
Countermeasures are part of every good incident response. Although there is no such thing as absolute security, István and the engineers in Zurich can ensure that the attack cannot be repeated in this form. Because the attackers have managed something that is difficult to achieve: they have beaten ReCaptcha. They either managed to solve the puzzle automatically or exploited a weakness in the implementation of the mechanism and bypassed it. The investigation is still ongoing.
"This tells me one thing above all: our current login system has weaknesses," says István.
There are now two possibilities. Either the engineers make the login more complex and more annoying for you as a user, or they overhaul it completely. István already has an initial idea, which has already been accepted: the login will be split. This means that in future - it is not yet clear exactly when - you will have to enter your user name on one page and then your password on another. The engineer digresses briefly: this mechanism should not be confused with two-factor authentication. You can activate this in your profile and thus protect your account even better.
"Think of it like Google," says István.
Planning for this new login begins. At the forefront: István Flach, engineer from Hungary.
Update 22/10/2018 14:00 - What the hackers can and know
István's team has not completed its investigation into the attack. An update is therefore already due. Investigations over the weekend and on Monday morning revealed the following:
- The attackers did not defeat ReCaptcha. ReCaptcha worked perfectly.
- The data validation with our site also failed. Our servers only sent the message "Incorrect username or password" to the attackers. In other words, the attackers did not receive any useful data. That makes us happy.
- Even if you are one of the 48,267 users whose accounts were directly attacked, you can breathe a sigh of relief. "Incorrect username or password" was issued there too.
The investigation will continue for some time, but is drawing to a close. The current, and probably final, status is that there was an attempted attack, but nothing happened. <p
Journalist. Author. Hacker. A storyteller searching for boundaries, secrets and taboos – putting the world to paper. Not because I can but because I can’t not.