Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Security Network

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

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.
This discussion has been archived. No new comments can be posted.

Hackers Completely Shut Down DDoS Protection Firm Staminus

Comments Filter:
  • by JcMorin ( 930466 ) on Friday March 11, 2016 @01:43PM (#51678951)
    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.
    • by TWX ( 665546 ) on Friday March 11, 2016 @01:49PM (#51679009)
      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.
      • by redmid17 ( 1217076 ) on Friday March 11, 2016 @02:00PM (#51679107)
        Both people who use Bitcoin are very glad they weren't targeted.
      • by JcMorin ( 930466 )
        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 s
    • Even funnier is having telnet running. But then again telnet has had way fewer security issues than ssh and ssl lately.

      • Re:Telnet (Score:5, Insightful)

        by barc0001 ( 173002 ) on Friday March 11, 2016 @02:16PM (#51679255)

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

      • 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.
        • by Bert64 ( 520050 )

          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 servi

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

        • by KGIII ( 973947 )

          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?

      • by Bert64 ( 520050 )

        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

    • by bluefoxlucid ( 723572 ) on Friday March 11, 2016 @02:10PM (#51679213) Journal

      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.

      • by ScentCone ( 795499 ) on Friday March 11, 2016 @02:18PM (#51679279)
        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.
        • 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.

      • by JustAnotherOldGuy ( 4145623 ) on Friday March 11, 2016 @02:44PM (#51679543)

        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.

        • 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 authenticate

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

      • by 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

      • by Bert64 ( 520050 )

        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.

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

    • by taustin ( 171655 )

      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.

    • 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 w

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

  • by wjcofkc ( 964165 ) on Friday March 11, 2016 @02:01PM (#51679117)

    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.

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

  • by SeaFox ( 739806 ) on Friday March 11, 2016 @02:05PM (#51679157)

    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.

  • That is all.
  • by DaMattster ( 977781 ) on Friday March 11, 2016 @02:09PM (#51679203)
    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.
    • 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.

      • by johanw ( 1001493 )

        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? (Score:4, Funny)

    by JustAnotherOldGuy ( 4145623 ) on Friday March 11, 2016 @02:15PM (#51679241)

    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.

  • by ledow ( 319597 ) on Friday March 11, 2016 @02:40PM (#51679517) Homepage

    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.

  • by zenlessyank ( 748553 ) on Friday March 11, 2016 @03:03PM (#51679713)
    Changes root password and calls it a day.
    • 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).

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

The key elements in human thinking are not numbers but labels of fuzzy sets. -- L. Zadeh

Working...