Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security The Internet IT

Another Dutch CA Hacked 152

An anonymous reader writes "After the fiasco involving DigiNotar, another Dutch CA (Gemnet, a daughter of KPN-Telecom) has been hacked and databases were accessed, webwereld.nl reports (Dutch original). The hack was possible because the website was managed using PHP-MyAdmin, and this application allowed database access without a password. The site has been shut down and security checks were ordered."
This discussion has been archived. No new comments can be posted.

Another Dutch CA Hacked

Comments Filter:
  • by Anonymous Coward on Thursday December 08, 2011 @10:19AM (#38302498)
    So a CA, holder of the keys for SSL certs, had an externally facing db admin module with no password... Just wow...
  • jawdrop (Score:5, Interesting)

    by v1 ( 525388 ) on Thursday December 08, 2011 @10:20AM (#38302510) Homepage Journal

    website was managed using PHP-MyAdmin, and this application allowed database access without a password.

    At what point does this become "criminal negligence"?

    And you'd expect there would be some sort of periodic audit process in place for anyone that manages a root certificate? hippa-style something or other? Or will they just set up any idiots with a CA that have good credit?

    • Re:jawdrop (Score:4, Interesting)

      by Afforess ( 1310263 ) <afforess@gmail.com> on Thursday December 08, 2011 @10:56AM (#38302826) Journal
      Actually, you could make the counter claim that the story title is bad.

      After all, it isn't stealing to pick money off the ground, it isn't hacking to visit public web data.
      • by Anonymous Coward

        The title IS misleading. This is incompetence or negligence but 'hacking' in the title gets more eyeballs.

    • by jon3k ( 691256 )
      HIPAA*. It's short for "Health Insurance Portability and Accountability Act". Sorry, pet peeve.
  • by EasyTarget ( 43516 ) on Thursday December 08, 2011 @10:24AM (#38302538) Journal

    this application allowed database access without a password

    Nope, it doesn't.. not unless configured by a really clueless person, or (this being Holland) by someone who really couldn't give a f**k while being mis-managed by someone determined to spend as little as possible, or hopefully less.

    (disclaimer; I'm a sysadmin who runs, amongst many other things, a MySQL server + PHPmyadmin for my company in the Netherlands, I do it properly but that's only because I care, nobody has ever checked..)

    • by johnkoer ( 163434 ) <<moc.oohay> <ta> <reoknhoj>> on Thursday December 08, 2011 @10:38AM (#38302660) Homepage Journal

      not unless configured by a really clueless person

      I think that is what was being implied by the summary. When I read it, I didn't assume that that was how PHPmyadmin came out of the box. They probably should have used better wording like "nd this application was configured to allow database access without a password", to ensure they got the correct point across.

      • Comment removed (Score:5, Interesting)

        by account_deleted ( 4530225 ) on Thursday December 08, 2011 @10:59AM (#38302856)
        Comment removed based on user account deletion
        • by Anonymous Coward

          Atleast to my eye it looks like they're trying to lay blame on PHPMyAdmin.

          I agree completely. Even worse, my experience tells me that this article could very well show up in some IT department's policies as a reason behind a "best practice" of banning PHP itself. I've always thought it "rude" for programs to include the technology they use in their names. The technology gets a bad rap for the program's problems in the eyes of the technically-challenged.

      • Even if it ships without a password out of the box (and I think it does), that shouldn't allow free access to the database, unless their database accepted a connection, from the root user, with no password. Someone there doesn't know how to setup MySQL.

    • Re: (Score:3, Insightful)

      I haven't worked with PHPMyAdmin for years (luckily) but even having it accessible from public IP adresses is a serious oversight, password or not.

    • by arth1 ( 260657 )

      (disclaimer; I'm a sysadmin who runs, amongst many other things, a MySQL server + PHPmyadmin for my company in the Netherlands, I do it properly but that's only because I care, nobody has ever checked..)

      As a long time sysadmin, it has become my opinion that the way to use tools like phpmyadmin "properly" is not at all.

      I once thought that they might be okay for home use, but have changed my mind on that too - it breeds a generation of "sysadmins" who don't know exactly what they're doing, or why, and in some cases don't even give a fuck about their ignorance. They may then expect the tools at work too, because they have made themselves dependent on them.
      When the undigestables meet the stationary propeller,

      • Your line of reasoning is a little off, you could use the same argument against every labor saving invention in the history of mankind (No spears for you caveman! Lest you forget how to properly kill a deer with your bare hands!). phpMyAdmin is very useful for doing a lot DB work quickly. I use it practically every day. It's an invaluable tool for developers, for examples, who are managing their own local databases and a useful tool for support personnel who can be trusted with some database access but a

        • Thank you for saying this so well.

          Plus

          1. phpMyAdmin (at least the way I use it) does not have its own passwords. It uses a MySQL user ids and passwords. If you fail at securing MySQL, it's not phpMyAdmin's fault.
          2. If it's running under Apache httpd you can limit access in a lot of ways (i.e. by IP address and/or Apache login) so there is no problem with it running on an internet facing server.
          3. You can be a CLI guru and still use a GUI to get things done.
          • Yeah pretty much. I know this is /. so we have to quibble about every goddamn thing, but if you're installing something like phpMyAdmin and it doesn't ask you about passwords, or whatever dumbass thing happened here, the problem is that somebody screwed the pooch by just leaving it that way. We gotta make it a little harder than that.

            I think the takeaway from this story is that there are "sysadmins" that don't know what they are doing and occasionally demonstrate this in spectacular ways. There are also V

        • by rev0lt ( 1950662 )
          A developer that would need to use phpMyAdmin should already know enough SQL to use the CLI interface. There are plenty of graphical mysql administration tools that can easily work with a tunneled ssh connection. In the cases that is not feasible, the alternative should never be to upload a 3rd party tool, with a rich history of known vulnerabilities, to a production server.
      • by rev0lt ( 1950662 )
        Last time I checked many (most?) sysadmins don't know exactly what they're doing, and that's why graphical and wizard-based configuration tools are so popular. And no, I'm not talking about windows. There's nothing wrong with that, in most cases. Critical or public facing infrastructure should be the exception, though.
      • So you are blaming the tool for failures of the users ( sysadmins are users in this case ).
        If they don't know how a tool works, the solution is not to stop using the tool. The solution is to learn how it works.

        • It's easy for us to forget the complexity and blame the sysadmin, too. It might be wise to periodically remind the user community that these are machines with billions upon billions of intangible but very real moving parts. The number of utilities and GUI property pages we have to use are many - thousands - and when budgets are trimmed a little too tightly, some of the bits will become misaligned. Knowledge or no, the sysadmin has a fairly huge workload and you have to allow time to get it right before y

  • by Anonymous Coward

    Why blame the tool? It's like blaming the web browser that the people used to access PHPMyAdmin to access the unsecured database. It's the dits who didn't secure the database that are to blame. Put a password on it and PHPMyAdmin won't be able to get in. Unless there's an exploit I'm not aware of, of course.

    • by ggeens ( 53767 )

      Why blame the tool? It's like blaming the web browser that the people used to access PHPMyAdmin to access the unsecured database.

      AFAIK, PHPMyAdmin doesn't have its own security. The user/password is passed to the MySQL server. If they were able to create databases without a password, it would seem that MySQL was installed without a password for the mysql admin user. During installation, MySQL asks to set a root password. A long time ago, this was not the case.

      This would seem that they had a very old MySQL setup and they never changed the password.

      • During installation, MySQL asks to set a root password

        Not on Centos, and I assume Red Hat.

        • by kyrio ( 1091003 )
          It's asked me for a root pass on CentOS, and Debian and others that I've used.
          • Echoing this sentiment. Every package management system I've used to setup MySQL asked to set a root password.

          • It's asked me for a root pass on CentOS,

            Step 1: yum install mysql-server
            Step 2: service mysqld start

            No password required.

            • by kyrio ( 1091003 )
              MySQL would have started itself after installing the package. So, where's the part when you install phpmyadmin and it asks you for passwords?
              • MySQL would have started itself after installing the package

                That (incorrect) statement shows that you are not familiar with Centos.

                So, where's the part when you install phpmyadmin and it asks you for passwords?

                yum install phpmyadmin

                Then you have to configure it. You may choose to protect the phpmyadmin installation with passwords, but (under Centos), nothing forces you to do this. The install defaults to phpmyadmin being allowed only from localhost, so there is a tiny bit of security.

                • by kyrio ( 1091003 )
                  Yeah, I just installed CentOS recently. I do believe you are full of shit as others have backed up what I said.
                  • I have several Centos servers (as well as Gentoo servers and desktops, Ubuntu Desktops, etc.) that I adminster and I just installed Mysql and phpmyadmin the other day. So, I am quite confident in what I write. Perhaps you have a desktop machine that you play with?
                    But, since you are a self-important twit, let me demonstrate that you are wrong:

                    Installing:

                    mysql-server x86_64 5.1.52-1.el6_0.1 updates 8.1 M

                    Transaction Summary

                    ====================

                    Install 1 Package(s)

                    Upgrade 0

                    • by kyrio ( 1091003 )
                      Though I've never used Ubuntu, I would imagine it would do what all other distros do.
  • by Penguinisto ( 415985 ) on Thursday December 08, 2011 @10:26AM (#38302560) Journal

    "The hack was possible because the website was managed using PHP-MyAdmin, and this application allowed database access without a password."

    I honestly don't know what to say. I mean, doing something like this on an internal network would be bone-headed enough, but doing it on an external-facing box? Under conditions where you would think security is paramount? I mean, you have to actually install and set up PHP MyAdmin - that shit isn't on by default.

    But, the fault lies elsewhere as well. After all, who the fuck was supposed to be doing the compliance audits, pen-testing, network security, firewall security? You always hire a reputable outside person/company to do those things.

    I honestly think the corp got what it deserved at this point... though the victim customers certainly don't deserve what they're about to get (a scramble for new certs, integrity checking, etc).

    • by Pieroxy ( 222434 )

      Under conditions where you would think security is paramount?

      And this is why you don't know what to say. Security is not paramount. Net revenue is. And security costs money.

      • Unfortunately, your statement is all too true in far too many cases.

        Well, it is until the company gets bitten by the lack of it, in which case one or more of the following options are open:

        1) fire the admin deemed most responsible for the breach (in this case, it'd be justified anyway)

        2) over-react, spend a mountain of cash on security, and lock everything down to the point where nobody can use it without a lot of headache and heartache.

        3) fire up the PR machine, and minimize as much of the reputation damag

    • But, the fault lies elsewhere as well. After all, who the fuck was supposed to be doing the compliance audits, pen-testing, network security, firewall security? You always hire a reputable outside person/company to do those things.

      I expected to find a bunch of "certified by X" badges on their website [google.com] but it just says, basically, "we're safe. Trust us."

      If they weren't on the government gravy train they probably would have been gone a long time ago.

  • So, any CA can create a cert for any site (or even EVERY site via *.* -- WHO THOUGHT THIS WAS A GOOD IDEA?!). This means EVERY SINGLE CA must remain 100% secure all the time in order for us to be able to trust the CA system.

    Now, this was pointed out from the beginning. "There is not a single point of failure -- No! There are MANY points of failure, any of which means a complete breakdown!"

    A web of trust is the only real competing system, and still here we are, not even trying that out on a large scale. Say what you will, but know that all trust tree hierarchies are doomed to fail.

    Come at me CA apologists. All your certs aren't belong to you.

    • by ledow ( 319597 ) on Thursday December 08, 2011 @10:49AM (#38302770) Homepage

      Personally, I now have more faith in the CA system than before.

      When a rogue CA was spotted, within days it had was revoked AND ALL ITS CERTIFICATES FAILED, including ones running in government departments, in every major web browser (totally independently).

      That's a pretty damn good response, and caused the collapse of the company and a government investigation - because browsers that have NOTHING to do with the CA's or the government unilaterally revoked a CA certificate in their browsers.

      The point of the CA system is trust. At some point you have to trust someone. Web of trust is just trusting the majority of public opinion, statistics or some other automated metric. The CA system is trusting particular institutions and browser makers (who, if you don't trust anyway, you wouldn't be doing business with or using their product).

      One CA abused that trust and they disappeared from the web overnight. But I still trust my CA. It's like saying that because one hosting company had a website vandal, everyone should just stop using website hosts.

      And now it's in the news, every tiny little breach is going to come to light whereas before, unless you followed the OSCP revocations religiously, you'd never have known.

      The CA system did exactly what it was designed to do and it worked much better than I would have ever expected. I don't see the Dutch CA failing as a failure of the system - the system worked and continues to work. It's like the Internet - it just routes around damage and carries on (by revoking the trust - which you can do yourself in any browser - in those who are untrustworthy).

      • by Anonymous Coward

        I'm sorry, but what a load of BS. The fact is that the DigiNotar breach was only quickly dealt with *once it was discovered* long after the breach actually occured, with fraudulent certs already being in the wild and actually used in Iran. Who knows how long it'll take next time before someone notices these fraudulent certificates. Heck, who knows how many CA's have been breached right now, only we don't know about them yet...

      • Having every major browser vendor issue a software update, is far from what i'd consider to be "working". Why don't we have proper CRL's?

        • by ledow ( 319597 )

          Update? That's what CRL's are for, as you point out.

          Opera was never "updated" to remove the Diginotar cert, for instance.

      • "But what's really scary, is that the evidence F-Secure found suggests that DigiNotar was hacked at least two years ago."

        I don't agree that having one's ass hanging in the wind — thinking your SSL connections are secure while they're not — for two years is a system that "works".

        It's astonishing in the current landscape where most everyone appears to be concerned and casting about for solutions to see someone thinking the CA system is fine. The foundation of the CA system involves giving each of

      • Personally, I now have more faith in the CA system than before.

        Personally, I now have more faith in our financial system than before.

        When a rogue CA was spotted, within days it had was revoked [...]

        When Lehman Brothers screwed up, within days they had collapsed [...]

        That's a pretty damn good response, and caused the collapse of the company and a government investigation

        That's a pretty damn good response, and caused the collapse of the company and a government investigation

        The point of the CA system is trust. At some point you have to trust someone [...]

        The point of the financial system is trust. At some point you have to trust someone [...]

    • by AvitarX ( 172628 )

      For a web of trust to work on a global scale, you're going to need super trustables, it will essentially end up like we have now.

      This isn't e-mail where our interactions are pretty much limited to friends.

    • This means EVERY SINGLE CA must remain 100% secure all the time in order for us to be able to trust the CA system.

      You act like this is something that shouldn't be an outright requirement anyway, let alone something that a company entrusted with generating SSL keys should actually be capable of in the first place.

      Frankly I hope their certificates get revoked and they get shutdown due to neglecting their only source of income, our trust in them. Maybe a few more companies going tits up will be a wakeup call.

    • by Skuto ( 171945 )

      or even EVERY site via *.* -- WHO THOUGHT THIS WAS A GOOD IDEA?!

      I think Firefox and Chrome reject such certificates by default (for obvious reasons).

    • by dveditz ( 11090 )

      No browser would accept a *.* certificate. According to the spec '*' can only appear in the leftmost label and can match only within that label. Long ago Netscape originally supported an expressive regexp syntax; modern browsers follow the RFC.

  • by Barefoot Monkey ( 1657313 ) on Thursday December 08, 2011 @10:38AM (#38302662)

    The hack was possible because the website was managed using PHP-MyAdmin, and this application allowed database access without a password.

    That's a bit misleading. From what I gather the hack was possible because the database was configured to allow access without a password. Considering that, whether or not PHPMyAdmin is appropriate is a tiny matter by comparison. The summary makes it sound like PHPMyAdmin is to blame.

  • In response to the news, Gemnet's parent company KPN, has revoked a thousand certificates. Dutch original [webwereld.nl]
  • Once I though that CA where serious business, with the biggest of them hosted in bunkers with complete security for the keys.
    Now I know it's just as secure as everything else on the net: as Lulzsec demonstrated this year, no security whatsoever.

    Now I'm just waiting to learn that nuclear missiles launch consoles are web applications with a "secure" javascript password check to protect them.
    • Once I though that CA where serious business, with the biggest of them hosted in bunkers with complete security for the keys. .

      Happy to hear it since I had the same idealistic vision and in the past was doubtfull of our company solution that uses a non networked machine to sign certs that is in a protected aread but not a bunker or faraday change. Only was to import/export data (requested and certs) is via DLT tape. Afterall it doesn't seem such a lousy solution

  • And here I thought the Dutch would have the national pride not to make their network security like Swiss Cheese.
  • Ca subject name? (Score:4, Interesting)

    by qha ( 23486 ) on Thursday December 08, 2011 @11:30AM (#38303230)

    So the first question I expected t.f.a. to answer:

    What is the subject name of this Ca so I can remove it from my list of "trusted" Cas?

    • by Anonymous Coward

      What is the subject name of this Ca so I can remove it from my list of "trusted" Cas?

      You would have to move to the Netherlands, become a muncipality and get hooked up to their private network to see a GEMNET-certificate. You haven't read TFA, have you?

      • by qha ( 23486 )

        Thanks!

        No, I just scanned through it looking for hints on what the ca subject might be. Now I have however and I have to admit it still isn't clear to me from the article that this is not a common ca or whatever we should call them.

  • by dragonhunter21 ( 1815102 ) on Thursday December 08, 2011 @11:43AM (#38303442) Journal

    I'm kinda getting an Uplink vibe here, with all these "X was hacked" "Another X was hacked, the government is taking it very seriously" on and on and on.

  • The keys are there to protect my communications. And yet I am not the one who is choosing who to use as the vendor for my trust. I am given a list of 3rd parties that I have never heard of instead.
    There should not be 1000+ organizations in charge of the security of my communications. I should choose a vendor I trust, and then that vendor should decide if the website I am trying to reach is legitimate. The system is broken by design.

  • For Verisign to get hacked.

    • I'm just waiting... for Verisign to get hacked.

      Or burgled.
      Or infiltrated by enemy agents.
      Or infiltrated by government agents.
      Or headed up by a clueless CEO who demands single sign-on access to everything and uses a password based on his birthday.
      Or outsourced to Sony.

    • It's not Verisign any more - it's Symantec. And in the near future all those "Verisign Secure" badges on the internet are changing to "Norton Secure".

      So... job done I guess.

  • These stories about Dutch CA's are really clogging up the system.

  • Not sure if it would've helped in this situation, as it seems the DB itself had no password, but since I don't run phpMyAdmin, I use a fail2ban jail which bans any IP trying to access phpMyAdmin since they're obviously up to no good.

    Shameless plug:

    Jails for phpMyAdmin, ssh as root, and, bad robots:
    https://www.maow.net/fail2ban [maow.net]

    And, it's using a self-signed certificate ... seems like the only CA I can trust is myself, and I don't really like the look of that shifty character in the mirror either.

  • According to KPN, the hacked website was not part of the CA's issuing system. Assuming they're being wholly truthful, this article is pure sensationalism: A company has a non-critical website that's hacked: whooptie.

    Of course it's bad PR: it doesn't inspire confidence in their other security matters. However, its just as likely that they're concentrating on their actual business (managing certificates), and the site was an afterthought. In any case (maybe I'm just cynical) it doesn't surprise me that a v

    • Only partially misleading... the configuration provided access via a roundabout route to the admin credentials, which could be used to legitimately mess with the issuing system by escalating access privileges. It's not a case of "they left the issuing system wide open!" but it is a case of "they left an entry point to their management system wide open!" which can eventually result in the same thing... with fewer ways to track monkeying with the issuing system, as the attacker will be using legit creds, and

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Working...