Hackers Completely Shut Down DDoS Protection Firm Staminus (softpedia.com)

An anonymous reader writes: Hackers have breached DDoS protection firm Staminus, a US-based company that offers protection against a range of network security attacks including, well, DDoS. The fraudsters have also reportedly stolen sensitive data from Staminus' database and dumped it online. Apparently the company was using the same root password for all its servers, and had stored credit card details in plain text. The alleged security nightmare doesn't end there, unfortunately. Hackers managed to expose crucial services via external Telnet, and reset all of Staminus' routers to factory settings, causing a network and services downtime. Staminus acknowledged network and services issues, which apparently last for more than 20 hours, on Thursday, and later assured that its global services have been restored.

Comments

credit card details in plain text?

[JcMorin]

I'm surprise a security firm go away with that... best time to plug the fact that it's time to user payment like PayPal or even better bitcoin so you can get your money stolen if a service you use get hacked.

Re:credit card details in plain text?

[TWX]

Credit cards can be cancelled and transactions reverted, at least to an extent.

They steal your bitcoin wallet information and transfer it, it's gone.

Re:credit card details in plain text?

[Anonymous Coward]

It's not all that surprising, really. There's something of an industry panic over security, for very obvious reasons (e.g. if the government can't protect it's own secrets being leaked, it probably can't protect yours)...

Re:credit card details in plain text?

[redmid17]

Both people who use Bitcoin are very glad they weren't targeted.

Re:credit card details in plain text?

[bluefoxlucid]

It's hard to not store credit card details in plain text. Even the fabled encryption relies on an automated system accessing it by decryption, meaning somewhere the key is accessible. You can hit the database application and say, "Please give me credit cards," and it decrypts them; or it at least can access the key and use that, so you get that too; or it's whole-disk encryption, so it's useless.

You store CCNs so you can re-bill people when you get hacked. We haven't advanced to the point of billing contracts in the financial system yet, so we won't send a vendor-signed billing contract up to the bank saying "I can bill with this frequency and this maximum charge per period". If we did, we could hit the bank and say "Contract #3876492 Bill=$42.79" and the bank would determine if the message was signed by the correct vendor, valid for the contract, and within correct billing limits, as well as what account it affects. No need to store CCNs.

Re:credit card details in plain text?

[ScentCone]

The solution for that is TOKENS. Your web app collects the CC info over an SSL-encrypted session, and presents it to an API at the bank (also talked-to over a secure pipe). The bank records the CC info and returns a token CC account - essentially, a fake CC that you CAN store in plain text because it's completely useless outside of the context in which you and the bank have arranged to later use it. Then, when you go to run the transaction (say, when you're about to ship some goods, or renew services, etc) - which might be half a second later, or a year later - you've got something you can work with, and no need for fragile/complex crypto locally. The bank, which already in theory DOES that in a big way for a living, has that part covered.

The token/fake CC number, BTW, can contain the same last four card number digits as the real card, which makes it very easy to combine those four digits with a scrap or two of customer info in order to look up account history, etc., locally without having to interact with the bank again later.

Re:credit card details in plain text?

[bluefoxlucid]

Using the same last 4 digits would add a lot of work, considering computers can just look up a token (a number) against a table indexed by token that labels the relationship {Token,FK=CCN}.

The system I described was more robust--using a Contract ID with a merchant, rather than an abstract "token"--and includes authentication of the merchant, authorization of the merchant's billing activities, and exclusion of all personally-identifiable information in the billing action.

Re:credit card details in plain text?

[JustAnotherOldGuy]

You store CCNs so you can re-bill people when you get hacked.

The best strategy is simply not to store them, ever. Let the card gateway store them (Authorize.net, PayPal, Amazon, etc) so if anything happens, it's not on your shoulders. I've run sites that accept credit cards for ~15 years, but I never, EVER store the numbers on my servers.

Re:credit card details in plain text?

[bluefoxlucid]

Amazon still stores them somewhere. Risk transfer is a good strategy; but somewhere down the line, someone faces these problems. People who claim things like encryption as a strategy for every data breach are under some weird belief that an automated computer system can both prevent a hacker compromising authentication from compromising authorization (i.e. it lets you access the data because it believes you're an authorized user, but the data is magically unreadable) and internally allow the authenticated user with correct authorization to access the data. They're the same kinds of people who think DRM should work because encrypting the data prevents the user from copying it.

Re:credit card details in plain text?

[JcMorin]

you could say the same for you cash or gold or anything you can hold. The problem with credit card transaction is the global cast. All those millions transactions reverted do charge fees to users, banks and merchants... that's why you have an almost 3% fees to accept it. With new payment solution like Apple Pay it get even worst. Bitcoin is far for perfect, but at least the concept that nobody can pull money from you and you have to push it is the right direction. You can setup you money to have 2 or more signature, for instance your computer, your cell, a website or a even a physical device. Having both steal make it much more unlikely.

Re:credit card details in plain text?

[Anonymous Coward]

Amazon still stores them somewhere. Risk transfer is a good strategy; but somewhere down the line, someone faces these problems.

Ideally someone with deeper pockets and a large enough incentive to apply their resources to the problem.

Auth.net, Paypal, Amazon are good enough.

Re:credit card details in plain text?

[taustin]

If they were storing credit card info in plain text, they weren't PCI compliant, and are 100% responsible for all costs relating to the investigation (average cost: $100,000) and remediation ($4-5 per card to replace, plus all fraud and related fees).

And they likely won't be allowed to take credit cards much longer.

Re:credit card details in plain text?

[Anonymous Coward]

You store CCNs so you can re-bill people when you get hacked. We haven't advanced to the point of billing contracts in the financial system yet, so we won't send a vendor-signed billing contract up to the bank saying "I can bill with this frequency and this maximum charge per period". If we did, we could hit the bank and say "Contract #3876492 Bill=$42.79" and the bank would determine if the message was signed by the correct vendor, valid for the contract, and within correct billing limits, as well as what account it affects. No need to store CCNs.

The last time I worked with any payment processing code, it was an interface to Authorize.net, and they had exactly this functionality baked in back then. (It was about 6 years ago.)

You would process the card with a "recurring payment" flag set, and their API would hand you a transaction key that you were supposed to keep on file. Then, you could send new commands to either "run" or "refund" against that transaction key. It was good for a period of time specified when you requested the transaction key. You couldn't change the "run" amount, but you could then "refund" a partial amount against it if you needed to. It was tied to your merchant account, so the transaction key wouldn't work for anyone else. And there was absolutely no need to store any card details at all. Not the number, not the cardholder's name, nothing. Just the transaction key and the fixed amount and expiration date you requested for it.

INGDRS. (It's Not God-Damned Rocket Science!)

Re:credit card details in plain text?

[Anonymous Coward]

We haven't advanced to the point of billing contracts in the financial system yet

Well, here in the Netherlands (or whole EU?), where the banking/legal system is more sane, we do have something like that.
It is very common to give companies authorization to withdraw from your bank account, especially for recurring payments of power/tv/phone/insurance/yogaclass etc.

There is however not much detail in the "contract", it only says "this company can take my money".
And it places trust in companies to do the right thing, the bank just assumes a company tells the truth if it claims it's authorized and doesn't check with you. Which has the convenience you can also authorize a company just by checking a box on some account creation form on their website.
In practice that works fine, it is rarely deliberately abused, and you can cancel such a transaction for 2 months afterwards.

But I assume this doesn't work for credit cards (which are barely used here).

Re:credit card details in plain text?

[Anonymous Coward]

So now i have to sign something to allow Netflix to charge my account every month, then netflix has to submit it to my credit/debit card company, then the card company has to approve it, send it back to netflix, and now that 45 days have passed, my impulse purchase of a netflix subscription is finally activated? Otherwise, it's still subject to the same issues.

Re:credit card details in plain text?

[Anonymous Coward]

An easy solution is to a combination of AES 256 Encryption, and an RSA public key for the user. The user's Private key should only be available at runtime with a user passphrase while the user is logged in. For example the user password and some salt.

Re:credit card details in plain text?

[Bert64]

You take the card details and encrypt them using your processor's public key... That way you can re-bill the customer but you aren't storing the card number in a way that would be usable by anyone who hacked you.
Problem is that a lot of payment processors don't bother with this, and often require you to submit the plain text card number.

Re:credit card details in plain text?

[Bert64]

That entire processor could happen almost instantly, why would it need to take 45 days?

Re:credit card details in plain text?

[Anonymous Coward]

[Host A ] contains the database with billing details
[Host B ] stores the key to decrypt

[Host A] ----- Stateful firewall and other network crap ---- [ Host B ]

The firewall has rules which allow Host B to connect to the database port of Host A, however no rules which will allow Host A to connect to Host B. Since the firewall is stateful, return traffic from Host A to Host B isn't a problem, even if there are no rules allowing inbound traffic from Host A to Host B.

Allow me to admit, I've never had to design/implement a billing system of any sort however I do believe what I'm describing above is probably close to how it works. Seems pretty common sense to me. Why in the hell would anyone ever store a decryption key on the same system where the encrypted data resides? With what I've described above, Host B is the server which makes the connection to the payment processor and whenver it's time to bill, host B initiates a connection to host A, grabs the needed data and stores in memory, disconnects from host A, then processes the billing.

Please, someone who's actually done this say something. I might not be even close to how it works but again, I just can't imagine leaving the encryption keys on the same server where the database hosting the data is common practice.

- Be dedicated to the billing task
- Have as few services as possible running on it

Re:credit card details in plain text?

[Anonymous Coward]

Yeah ...
Nothing like comparing apples and oranges. A better comparison is:
If thieves steal your cash, it's gone. If thieves steal your
Bitcoin, it's gone!

Having a bank guarantee transactions based on consumer credit and take the financial hit for fraudulent transactions is completely different than Bitcoin.

A business model similar to credit cards could be built that uses Bitcoin as its technical backend and still employ the same consumer protection features.

Re:credit card details in plain text?

[JustAnotherOldGuy]

Amazon still stores them somewhere. Risk transfer is a good strategy; but somewhere down the line, someone faces these problems.

That's right, but it sure as shit ain't gonna be me. :)

Amazon probably has enough money and enough clever people (hopefully) to do a good job of securing credit card details, but I'm smart enough to know that I don't.

I'm not smarter and better funded than a million hackers, and I fucking know it. That's why I let someone who's better at doing it do it for me.

Re:credit card details in plain text?

[Anonymous Coward]

The proposal is specialization: Let someone whose *job* is keeping that shit secure store it, because keeping up to date on how to keep it secure is a full-time job.

It's why people have crappyblog.wordpress.com rather than mycrappysite.com these days: Let wordpress worry about enterprise-scale deployment, hardware maintenance and security.

Re:credit card details in plain text?

[RogerWilco]

That exists where I live (The Nethelands) but it requires a signed paper form from the account owner as part of the billing contract.
Not something easily done over the internet.
It gets generally used for utility companies and subscriptions to magazines, cable and such.
I can even view all the active billing contracts on my bank's website and cancel them from there.

Re:credit card details in plain text?

[easyTree]

Because banks?

Mischief

[Anonymous Coward]

Talk sh*t, get hit. That's what is tough about touting your security powers of protection, you will be targeted . . .and just one big "boom" . . .all credibility lost!

Re:Mischief

[TWX]

Sounds like the biggest problem was that they didn't practice security for themselves. One should assume that being in the security business that one automatically will be a more visible target, and one's security should be set up to meet that head-on.

These guys sound like an old-west movie set. A bunch of authentic-looking fascades held-up by timbers bracing them, no actual building behind the face.

Re:Mischief

[bluefoxlucid]

Well yeah. If you get into the security business, you need to go big or go home; you're automatically an enormous target.

Re:Mischief

[Anonymous Coward]

Security by Blazing Saddles!

Re:Mischief

[Anonymous Coward]

You would think that after HB Gary, companies like this would be a little smarter.

Folks, pay attention. If you have a network with servers and a dedicated Internet connection, you should have the experts in house, NOT 3rd party, and you should NEVER need a 3rd party securty company to protect you, or use a 3rd party for a "cloud" because you have everything to establish your own; I'm an individual and I have my own "cloud" running on my own server at home with my own Internet connection.

Anybody using a 3rd party service in this way is simply broadcasting the fact that you don't have good security people to begin with. You are better off just keeping your mouth shut.

Re:Mischief

[Anonymous Coward]

If you have a network with servers and a dedicated Internet connection, you should have the experts in house

This isn't about experts.
They are a DDoS protection service, and the way such companies work is that traffic to/from your network routes through their systems first. They purchase HUGE amounts of bandwidth, from multiple Tier1 backbone providers, and will often route traffic through a variety of extremely expensive mitigation appliances. Few companies can afford to pay for enough bandwidth and hardware to soak up a 500gig DDoS, let alone the hardware which will let you intelligently filter and allow legit traffic to keep flowing.
We're talking hundreds of millions of dollars of equipment and bandwidth here.

Re:Mischief

[The-Ixian]

Yeah, especially if you use the "cobbler's children" model to run your business.

Re:Mischief

[TWX]

Pretty much. The backlots at the Hollywood studios and at Old Tucson immediately came to mind.

Telnet

[ArchieBunker]

Even funnier is having telnet running. But then again telnet has had way fewer security issues than ssh and ssl lately.

Re:Telnet

[barc0001]

Fewer NEW ones yes. There's still the inherent one that won't go away ever.

Re:Telnet

[Anonymous Coward]

And I lost fewer Olympic events than Anyone who competed in Sochi.

Re:Telnet

[Locke2005]

Yeah, while I was working at Oracle, I managed to snag the network administrator password that would grant admin privilege on every Sun box at Oracle... just by filtering telnet traffic in promiscuous mode on my workstation and catching a network admin logging in remotely via telnet to another computer on my subnet. There's a reason why any sane person uses ssh instead.

Re:Telnet

[Ksevio]

That's why I always run telnet over an SSH tunnel!

Re:Telnet

[Anonymous Coward]

Even funnier is having telnet running.

I'm not sure if they had it running, or if the attackers turned it on and opened it up externally.

Re:Telnet

[The-Ixian]

You made my day!

Re:Telnet

[Bert64]

There are many reasons why telnet is still around...

Some older devices support nothing else.
Some vendors charge you extra for SSH support (or for anything supporting encryption at all).
Windows only comes with a telnet client by default (although they are finally planning to change that).
Telnet isn't necessarily a problem if you control/trust the entire network path, for instance i have some switches i use for testing and i connect to them using telnet over a direct cable from my laptop to the switch itself so theres very little scope for a mitm attack...
Telnet is much simpler to implement, requires far less code and far less processing resources.
Because its simpler, it's also less likely to have vulnerabilities in the code itself so the risks of using telnet are better understood and easier to understand.

Re:Telnet

[Bert64]

Well if they used the same root password on every box they had bigger problems than telnet... All it takes is one box to be compromised and you have a pretty good chance of obtaining the password...
You can crack the hash, on windows boxes you can even pass the hash without cracking it, if you cant crack the hash then you can backdoor the services to capture passwords and wait for someone to log in, and unless the box is completely unused you can probably entice an admin to log in by crashing whatever service the box is supposed to be running... A crashing service doesn't even raise suspicion these days, people are used to software being unreliable and will just restart it or even reboot the whole box.

Re:Telnet

[Tharkkun]

Well if they used the same root password on every box they had bigger problems than telnet... All it takes is one box to be compromised and you have a pretty good chance of obtaining the password... You can crack the hash, on windows boxes you can even pass the hash without cracking it, if you cant crack the hash then you can backdoor the services to capture passwords and wait for someone to log in, and unless the box is completely unused you can probably entice an admin to log in by crashing whatever service the box is supposed to be running... A crashing service doesn't even raise suspicion these days, people are used to software being unreliable and will just restart it or even reboot the whole box.

They haven't allowed anything other than SSH for 5+ years. He probably also sniffed it from the development environment. Everyone had sudo root access on on 100k+ hosts.

Re:Telnet

[KGIII]

while I was working at Oracle

I'm not sure if I should think you're still okay in my book because it's past-tence or if you're no longer okay in my good book because you worked there.

You didn't work in sales, did you? Or legal?

Protection firm?

[wjcofkc]

Apparently the company was using the same root password for all its servers, and had stored credit card details in plain text.

Hackers managed to expose crucial services via external Telnet

I would like to say mind = blown, but we see too much of this shit from so called "security companies". Anyone here want to start a real security company with me? Most of the people that will be posting in this thread are already more qualified than these "security companies" we keep reading about.

As soon as I finish this sentence, I am changing my voicemail message to: I will be unavailable the rest of the day as I commit myself to breaking the world record on the single longest series of facepalms.

Re:Protection firm?

[RogerWilco]

If you do your security "properly" you will be more expensive than the competition and you will go out of business.
Capitalism is fun sometimes.

Not quite what you wanted to say?

[SeaFox]

Hackers have breached DDoS protection firm Staminus, a US-based company that offers protection against a range of network security attacks including, well, DDoS.

Well... wouldn't it make sense that a DDoS protection firm would offer protection against DDoS?
Unless the story here is the hackers took them down with a DDoS this sentence doesn't say as much as the author was hoping.
So far it looks like a plain network intrusion case.

Re:Not quite what you wanted to say?

[Anonymous Coward]

Yo dog, I got a....

nvr mind, I'll just stop right there.

wow

[Anonymous Coward]

cleartext credit card data, just wow staminus, you should have known better

Myth Busted

[idbeholda]

That is all.

Funny

[DaMattster]

It would seem that Staminus did not have the 'stamina' to live up to it's own marketing campaign. Happily some hackers exposed the truth.

Re:Funny

[ScentCone]

Happily some hackers exposed the truth.

If that was their agenda, they could have done so in a far less destructive way. Quite making excuses for griefers.

Re:Funny

[johanw]

Those ways usually get you on the receiving end of very expensive lawsuits. They made sure there won't be any money left for that.

Seriously?

[JustAnotherOldGuy]

Apparently the company was using the same root password for all its servers, and had stored credit card details in plain text.

What a brilliant strategy- standardizing on server passwords!

Storing credit card details in plain text is a super-duper PCI compliance no-no, however, and I'm truly amazed they had the balls to do this when they MUST have known better. This is one of the most serious violations when storing credit card data, and to have a security-industry company doing it is kind of mind-boggling.

INEPT INC.

[Anonymous Coward]

Welcome to INEPT INC. Where nobody can guess our passwords because our GEEC computer system doesn't have a password. You can access your accounts and data from anyplace at any time with out ANY hassle via Telnet or any other service.

Hands up who's surprised?

[ledow]

I've heard of backup companies who don't take proper backups. The servers go, they lose all their customer's data, no returns.

This isn't a shock. Quite often the very people who you "have to consult" in order to appease your boss are the very snakeoil salesman that have no clue about what they're doing beyond talking themselves up.

I had a guy tell my boss that our website "was insecure, expired certificates, etc.". Turns out he was plugging our domain.com into some online checker but didn't notice that our website is actually www.domain.com. Our bare domain, therefore, of course wasn't encrypted or any such nonsense and had no need to be - it was just a landing page that HTTP redirected you to the proper domain (and, to be honest, 99% of the website has no need for a secure certificate either, as none of it is private or confidential - it's a website - and the CMS for it is accessed an entirely different way).

And the expired cert? Actually a fallback "localhost" cert returned by Apache if you specifically request a non-existent https subdomain like "https://domain.com" (which doesn't exist as a website, and only gets a response because it resolves to the same IP as www.domain.com which has the secure port open).

But he plugged it into the checker, so everyone must be able to get into our systems right?! What are we going to do about it?!

The very people who run these services HAVE NO CLUE what they are doing. Like the people that my employer keeps trying to get me to take training courses from, or the apprenticeship company that one of my colleagues has to spend 9 weeks training at.

He said last time he went that their "network" was a bunch of unlicensed workstations ("Just ignore that notice"), with no security, all the same passwords (so he was able to remote into the instructor's PC, etc.), admin-level accounts, all clients connected direct to the Internet with no filter or firewall, and that they thought he was "hacking" because he was remoted into his own home server after finishing their coursework and doing some research of his own. Another told him off for upgrading the version of server because his remote session was to a more modern version.

These were the people TEACHING HIM (supposedly) how to set up domains, manage a network, implement group policy, etc. etc. etc. And they'd not heard of virtualisation, proper imaging techniques (they have "rollback" on their clients but pretty much they are just used by class after class and rebuilt when necessary, hence why they are unlicensed as there's no KMS server, or even a proper image). And they were teaching him on Server 2008... his home server has 2016, and we're using 2012R2 in the workplace.

Basically, he's going there to tick a box to say that "someone other than my boss" thinks he can do the basics, not to actually learn anything. Unfortunately that "someone other" are obviously bog-useless at what they do, or they wouldn't be working at such a company - they'd have got themselves a job managing real servers somewhere.

That's pretty much what's happened here. Get a consultant in to audit things and say you're up-to-scratch. But who audits the auditor? No-one? Pointless then. And they can't even apply the principles that they are judging YOU on to their own internal systems.

I hope they lose every customer they had.

Re:Hands up who's surprised?

[Anonymous Coward]

who's to say they weren't eating their own dogfood. what if they were? what if what they were selling was a sham in the first place and they, too, bought into it?

either way, after this, the company has to fold, period. there's no bouncing back from the loss of credibility of this magnitude.

Re:Hands up who's surprised?

[Anonymous Coward]

You seem bitter.

Anonymous

[Anonymous Coward]

Anonymous didn't even take any credit. The stupidity behind Staminus is so extreme that any script kiddie could have done that.

Anybody would be very VERY foolish to ever trust Staminus again.

DDoS protection is for LUDDITES.

[Anonymous Coward]

Modern app appers use appy app apps to prevent LUDDITES from apping their apps, NOT LUDDITE DDoS protection!

Apps!

Renames Company To Stupidus.

[zenlessyank]

Changes root password and calls it a day.

Re:Renames Company To Stupidus.

[RogerWilco]

Changes root password and calls it a day.

Ah, but you would have to change the root password from St4m|nu5 to Stup|du5

(St4m|nu5 was apparently the root password they used, according to the hackers, so it might not be true).

Customer lawsuits and PR damage ...

[davidwr]

... will shut this company down for good, even if it does survive the technical damage.

Why store CC info online at all?

[davidwr]

Er, why store ALL of it where hackers can get to it at all?

I see the day when companies store sensitive customer-provided info in a "near-line" data warehouse which has a small, carefully-controlled, carefully monitored data-pipe to their other systems.

When one of their main systems needs data for a specific customer, it asks for it and in most cases, it will get it, use it, then purge it.

But if too much data is being "pulled" from the "near-line" data store in too short a time, or if data is being pulled with unusual patterns, then alarms will go off and people trained in security will get involved.

---

I also see the day where data from "inactive" customers - those who aren't likely to order anytime soon - have their data in offline storage which requires manual action to retrieve - basically, the modern-day version of a locked file cabinet.

DDoS != DoS

[ls671]

Maybe they aren't a security firm?

DDoS != DoS
DDoS != security

Strictly speaking, a DDoS is different than typical security like typical DoS prevention firewall rules because there isn't much you can do about it once the packets reach you. These guys prevent the packets from reaching you while still letting legitimate traffic trough as much as possible during the DDoS attack.

Maybe these guys are specialized in DDoS and they know little about security and how to protect their network.