The news is spreading that Staminus, a DDoS protection service which theoretically falls under the umbrella of what we could call "security companies", has been hacked. At the time of writing, its homepage is displaying only a message from its CEO about the incident.

So far this looks like a typical hacktivist type attack, the stolen data has been publicly posted to the Internet and the perpetrators are gloating about what they've done. There are a few lessons we can learn from the leaked data.


Most hacktivists attacks are launched against a particular target for a reason and the obvious reason here would be that one of the sites protected by Staminus is the official homepage of the Ku Klux Klan. The Klan has been attracting some press lately as a result of one of their former leaders praising a certain controversial presidential candidate and said candidate's supposed hesitancy to disavow the endorsement. Lending some credence to this theory, the hackers took the effort to call out leaked data belonging to the Klan and associates in their data dump, a step they didn't take for any of Staminus' other affected customers, but the hackers themselves claim that they had no idea that Staminus hosted the KKK.

If Staminus was targeted specifically because they host the Klan's website then they likely would have been breached eventually regardless of how good their security was because, as I pointed out in a post last week, it's almost impossible to keep a determined attacker out (hence the importance of focusing on detection and response capability). In this case, assuming the leaked information is correct, Staminus' security posture was horrible and they were a breach waiting to happen. It is entirely possible that the attackers just stumbled across Staminus' weak network and acted opportunistically, only singling out the Klan once they realized what they had found.

Basic Security Errors

The hackers' post on Hastebin describes a long list of simple security errors made by Staminus including: using one root (administrator) password on all of their systems, falling behind on security patches, keeping unencrypted adminstration protocols (Telnet) enabled, and storing plaintext credit card data. Yet more security issues around application password management can be found by looking through the dumped data itself.

Lets take a look at some of the specific vulnerabilities that we can see in the data dump and see what we can learn:


What can we say about patching, we all know we should do it yet everyone seems to be chronically behind. For critical systems concerns about applying patches causing downtime seem to take precedence over missing patches allowing breaches. For less critical systems patches may just be forgotten as other needs take priority.

I suppose all we can really say is that organizations worried about downtime should invest in a test environment so they can try out patches before deploying them to production and otherwise just make sure to stay on top of them. Breaches like this one are the result if they do not.

I know I would much prefer the chance of a controlled and reversible downtime during a set patching window than the unpredictable downtime resulting from an attack, not to mention the other negative consequences of a breach.

Password Failures

The hackers themselves state that Staminus was using a single root password on all of their systems. Going through the data dump this password appears to have been "St4m|nu5". This is pretty bad: substituting numbers and special characters for letters in a word (leetspeak) is a common enough technique for creating passwords that attackers know to look for it. They also know to check for variations on the company name. The attackers may have been able to capture this password through other means (e.g. eavesdropping on Telnet) but I wouldn't be surprised if they cracked a hash to get it.

The significance of password reuse and cracking is that there are plenty of vulnerabilities that may give an attacker access to one or two hosts on a network (especially with missing patches) but that attacker will likely need access to user accounts and higher level privileges to move around the network and find sensitive data. Cracked passwords can also be used to log in and take action under another user's name. Passwords should be hashed to prevent these types of attacks but proper password hashing tends to be hit or miss and even when it is done right can be defeated by poor password choice.

The right way to protect a password is with a Key Derivation Function that uses a strong algorithm, salts, and enough iterations to slow password cracking down to a crawl. Most Linux systems now have this functionality built in when it comes to the OS passwords but it's hit or miss when it comes to off-the-shelf applications and one-off custom applications tend to be terrible. This is exactly what we see in the Staminus data dump.

I happen to have access to a pretty fast GPU based password cracking system (the same system used for my talk at RSA Conference 2 weeks ago and the whitepaper that we released today) so we can run these leaked hashes through it to see what we can get, the same way an attacker would. Given that the data was leaked on Friday and today is Monday the results are just what I could accomplish over the weekend. Cracking is very much a time based activity and with a full week or more we could likely get many more passwords.

It appears that Staminus was using WordPress for their site which has a fairly strong password hashing system. We were able to crack one password simply because a user chose a very weak password. Still, one password may be all an attacker would need to start messing around with the WordPress site, potentially inserting malware for innocent visitors to download.

Another table labelled "tbladmins" which implies some sort of administrative access, contained a number of email addresses and 2 bcrypt hashes per email address. Proper use of bcrypt with strong passwords makes for very difficult password cracking and we weren't able to make much progress over the weekend.

Yet another table, labelled "tblclients" seems to contain the passwords that Staminus' clients would use to log into the service. These passwords were protected using salted MD5, a very easy hash type to crack, and this is where we had the most success with our cracking system. We were able to crack 72 out of 205 hashes in about 15 hours thanks to some very poor password choices by Staminus' users. Using salted MD5 rather than something stronger, like bcrypt, is a major oversight.

All together we are seeing the same common password mistakes that organizations make: a variety of hashing algorithms are in use, some better than others, but regardless of which hash algorithm a particular system uses the users are still free to choose poor passwords and often do. The result is that it becomes very easy for an attacker to gather credentials and move around inside a network or impersonate users once he has a foothold.

Another concern is that users who would use such simple passwords as the ones we recovered from tblclients would also use these same passwords for other services across the Internet. After all, this is a DDoS protection service which seems like the kind of thing that should have a strong password, considering you would probably only use such a service if you're somebody's target already. If you're not willing to choose a strong and unique password for this type of service I'm willing to bet that you're going to use the same crummy password everywhere else. Hopefully the attackers aren't cracking these same passwords and using them to hijack other accounts as we speak.

Protocol Errors

Using an unencrypted protocol like Telnet has been considered a security vulnerability for decades. It is easy for an attacker who can monitor network traffic to intercept plain text credentials that he can then use himself, completely eliminating the need to crack passwords.

Substitute protocols that utilize encryption, like SSH, should be used instead. SSH is free, open source, and has been available since 1995. There really is no excuse for leaving these protocols enabled, never-mind actually using them. Unfortunately many vendors leave these protocols turned on by default or don't support the encrypted alternatives, especially on appliance type devices like power management units (which is what I'm assuming the hackers meant by "PMU"). When faced with a device that doesn't support encrypted administrative connections I would prefer to choose an alternate vendor but I'm just a security guy, what do I know.

PCI Compliance

To get the obvious out of the way: the PCI DSS rules that everyone who handles payments cards should be following explicitly prohibit storing unencrypted payment card numbers, which is exactly what the hackers are claiming Staminus did.

What is perhaps even more concerning is that the definition for the "credit_card" table contains a column labelled "CVV". CVV numbers are never supposed to be stored after a payment card is authorized and it would be odd if such a column existed in the database for any purpose other than long-term storage of CVV numbers. Storing CVV numbers would be akin to storing the PIN codes for ATM cards, it defeats the whole purpose of having a verification identifier separate from the account number.

Unfortunately the Hastebin dump only contains the table definition and does not contain a sample of the data contained within it which would confirm the presence of unencrypted card numbers and CVV numbers. The dump contains links to hidden Tor services with further SQL dumps and I may post an update if I get time to download those and check to see if they contain any smoking guns.

While we're on this topic it's also worth pointing out that PCI DSS prohibits the use of insecure protocols for administrative access, like the open Telnet services described above. Based on the evidence here it's pretty safe to say that Staminus was likely flouting the PCI DSS rules and they're probably going to be having some difficult conversations with their processor and the card brands over the next few weeks.

Learn to walk before you run

These vulnerabilities demonstrate something that myself and others in the security industry (at least those of us who don't work for product vendors) have been pointing out for a while: all the fancy whizbang technology in the world won't help you if you've failed to implement basic security measures on your network. I am keenly aware of this having just visited RSA Conference 2016 where hundreds of vendors were trying to hawk their "advanced" security wares. I would much rather see the CISOs of the world focus their security spending on finding and fixing their basic security issues before even thinking about anything "advanced". You don't have to take my word for this either: as I pointed out in a post a few weeks ago, the head of the NSA's hacking operations made a similar point at the Enigma 2016 conference.

A penetration test is all it would take to identify the basic security failures described above but, speaking from experience, it's all to common for organizations to conduct a test and continue to ignore the basic security process failures staring them in the face while instead trying to solve their problems with more technology. The result is that when we repeat a test we find the same vulnerabilities month after month and year after year.

Security should be an continuous ongoing process of identifying threats and vulnerabilities and working to address them. It is not a goal that can be checked off of a list and it is not a piece of technology that can be plugged into a network. The sooner we can the security basics in place the sooner we can stop hearing about these easy hacks, especially at a company that really should have known better.