A billion reasons to enhance your penetration testing

Mike Weber, Vice President, Coalfire Labs

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:

  1. 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.

  2. 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.

  3. 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.

Mike Weber


Mike Weber — Vice President, Coalfire Labs

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS