There are so many questions regarding those leaked Russian passwords. Is this for real? What sites are on that list? How can you tell if your site’s users are in the “Russian Billion”? Isn’t this just a matter of changing user passwords?
Bottom line: As a company with websites that have user accounts, what should you do?
First, a bit of backstory. A Russian gang known for monetizing spam delivery changes tactics by using a botnet for something completed different. Whenever a user would visit a web site and log in using a system that is part of the botnet, the system would record the site address and the username and password used. Then the system would surreptitiously test the website for SQL injection under the context of the logged in user. If the site was found vulnerable, the system would note that and send the site address, username, password, and whether the site was vulnerable back to the command and control systems.
The “gang” allegedly leveraged that information to log in as the user, then dumped the database via sql injection – either through automated or manual efforts. Pretty soon they had hundreds of thousands of databases replete with usernames and passwords.
This announcement was all about the usernames and passwords. But if hackers got the usernames and passwords by “dumping the database,” then what about all that data that probably went along with it? I’m sure more will come to light on that front soon – and I’d agree that there’s probably something more catastrophic coming with all that info – but all we know for sure right now is that there are a billion unique credentials in a “list” somewhere.
Let’s say your company has a website that has some public content and a load of features available to logged-in users. Those users might include “members,” or “employees,” or “customers.” Your company happens to have regularly scheduled vulnerability scanning and even has periodic penetration testing to boot. Every report is clean as a whistle – no signs of SQL injection anywhere. You’re in the clear, right?
Not so fast.
While people say a “site” is vulnerable (or not) to SQL injection, that’s not a very accurate phrase. Sites, per se, aren’t vulnerable – they’re simply at risk. It’s the parameters and variables that are sent to the server that can have SQL injected into them. The functions that call the database statements are what then would be vulnerable. These parameters and variables that can be manipulated to find vulnerable database statements are sent to the server when features of the website user interface are used (i.e., a user “clicks” on something).
There’s a critically important item in this story: the botnet allegedly leveraged in the attack would test each site under the context of the logged-in user. The vast majority of companies test their sites only from the perspective of an anonymous attacker. That’s an attack that doesn’t use any credentials to your site – a “black box” test, some call it. Without logging in, some sites may have only a login page and a “forgot password” page – not a whole lot of features. Once logged in, though, these sites could be incredibly feature rich, with features and functionality and whiz-bang whistles and bells. All of which are NOT tested by that un-credentialed, black box test.
An un-credentialed test isn’t entirely without merit. It’s a good way to understand the threat posed by an unsophisticated attacker over the Internet. For the most part, that test emulates the “script kiddie” threat.
Companies have historically taken the approach that their users are “trusted.” Why spend the money testing features of the site that can only be accessed by these trusted users? Well, this latest breach proves why. Without two-factor authentication, your company has no real control over what your users do with their passwords. You’ve made these websites available to the Internet-at-large and a user is welcome to log in from anywhere. That “anywhere” includes their home computer, which could be part of a botnet. Or it may be the public library or in a coffee shop via some unsecured connection. In general, your “trusted” user accounts represent your greatest threat.
Only a credentialed test emulates this “compromised account” threat.
So what are site owners to do in light of this recent news? Three things:
First, it’s a great time to change administrative credentials. While it could be too late – your site’s data may already be compromised – you might as well just do it. Whenever there’s a significant breach, I change my passwords, just like changing my smoke detector batteries on the daylight savings time change.
Next, have your site evaluated to determine what the greatest threats are and have a penetration test done – specifically emulating these threats in a real-world attack scenario.
Finally, if it turns out your site could be compromised under this attack scenario, immediately force a password change. If you can’t do that programmatically, maybe it’s time to consider some secure code training for your development team.