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."
Web Admin of the Year (Score:5, Insightful)
Re:Web Admin of the Year (Score:5, Informative)
Ignoring that - they had internal documents that were accessible from their web/database server. Everything else defies belief too but really wouldn't have mattered that much if it had been ONLY their web db that was accessed.
Re: (Score:1)
Re: (Score:3)
Re:Web Admin of the Year (Score:4, Insightful)
How do you know it did?
Re: (Score:2)
The hacked machine seems unrelated to the actual CA business, though - it's just a website, not a CA management tool or whatever. Source: http://forum.kpn.com/t5/News-stream/UPDATE-11-30-KPN-sluit-tijdelijk-website-Gemnet/ba-p/8477 [kpn.com]
Re: (Score:2)
Given the number of exploits for phpMyAdmin, whether it's passworded or not is practically irrelevant if it's exposed to the internet.
But, since browser manufacturers don't audit CAs (I've never heard either way whether they audit or not, but even if one of them claimed to do so, given the track record I'd have to call bullshit), this hardly matters anyway--it's just going to happen again and again, and it's already happened a number of times that we have no idea about.
jawdrop (Score:5, Interesting)
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)
After all, it isn't stealing to pick money off the ground, it isn't hacking to visit public web data.
Re: (Score:1)
The title IS misleading. This is incompetence or negligence but 'hacking' in the title gets more eyeballs.
Re: (Score:3)
Re: (Score:1)
The irony here is that your parent was literally spelling out his point. And you still failed to understand it, recognize your failure to understand it, and felt compelled to reply. And then made the same mistake GP was correcting.
Lets play 'Pass The Blame!....' (Score:5, Informative)
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..)
Re:Lets play 'Pass The Blame!....' (Score:4, Informative)
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)
Re: (Score:1)
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.
Re: (Score:2)
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.
Re: (Score:1)
Re: (Score:2)
There is difference between being able to access the database directly, and accessing the database through phpmyadmin :
- On any website i have used , by default direct access to the database is only possible for localhost .
- phpmyadmin is publiciy accessible for everyone, allowing you to administer the database, from any place.
- to get to phpmyadmin, you are required to authenticate.
If phpmyadmin doesn't have a password, the password on database isn't going to matter much , as you can change your password
Re: (Score:2)
There is difference between being able to access the database directly, and accessing the database through phpmyadmin :
- On any website i have used , by default direct access to the database is only possible for localhost .
- phpmyadmin is publiciy accessible for everyone, allowing you to administer the database, from any place.
- to get to phpmyadmin, you are required to authenticate.
If phpmyadmin doesn't have a password, the password on database isn't going to matter much , as you can change your password through phpmyadmin anyway.
One point - I've set up a couple of XAMPP installations, but I can't remember whether it allows multiple login fails without an air-gap. If it doesn't have a form of interrupt here, it's susceptible to a simple odometer attack. Can anyone remember?
Re: (Score:2)
Re: (Score:3)
(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,
Re: (Score:3)
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
Re: (Score:1)
Thank you for saying this so well.
Plus
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Well, I think "bug-ridden" is more than a little bit of exaggeration, I can't remember the last time I ran into a bug in phpMyAdmin. However, if you have multiple people who need access to the database on an infrequent basis, it's easier to run one internal web application that has a tunnel configured to the database servers than to maintain and support the client application on a dozen different machines.
Re: (Score:2)
Re: (Score:2)
Secunia says the phpMyAdmin 3.x branch has had 20 advisories spread over 4 years (2008-2011), 95% of which have been patched (5% have a vendor workaround), 10% of the issues were rated "highly critical", 5% were rated "moderately critical", 70% were rated "less critical" and 15% rated "not critical". No issues fell into the highest category "extremely critical". Half of the issues were cross-site scripting issues, and the two "highly critical" issues seem to require that someone already have logged into p
Re: (Score:2)
Re: (Score:2)
Woosh.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
Nothing wrong with PHPMyAdmin (Score:2, Insightful)
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.
Re: (Score:3)
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.
Re: (Score:2)
Not on Centos, and I assume Red Hat.
Re: (Score:2)
Re: (Score:2)
Echoing this sentiment. Every package management system I've used to setup MySQL asked to set a root password.
Re: (Score:2)
Step 1: yum install mysql-server
Step 2: service mysqld start
No password required.
Re: (Score:2)
Re: (Score:2)
That (incorrect) statement shows that you are not familiar with Centos.
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
Err, wow - just wow. (Score:3)
"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).
Re: (Score:3)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
CA System - Has Never Worked As Intended. (Score:4, Funny)
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.
Re:CA System - Has Never Worked As Intended. (Score:5, Insightful)
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).
Re: (Score:1)
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...
Re: (Score:2)
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?
Re: (Score:2)
Update? That's what CRL's are for, as you point out.
Opera was never "updated" to remove the Diginotar cert, for instance.
CA System, "works" as intended; inherently broken (Score:2)
"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
Re: (Score:2)
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 [...]
Re: (Score:1)
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.
Re: (Score:2)
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.
Re: (Score:2)
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).
Re: (Score:2)
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.
Summary is misleading (Score:5, Informative)
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.
Re: (Score:2)
And replace it with... what?
CAs are a lot like democracy. They both suck, but they tend to suck less than all other forms that have been tried up to now.
KPN revokes certificates (Score:2, Informative)
Re: (Score:3)
FFS, if you're depending on phpMyAdmin for your database security, you're doing it wrong. If phpMyAdmin, out of the box, can access your MySQL server, it means you haven't given a password to the root user on MySQL. Which means anyone that can connect to your MySQL server at all has full access.
Unless setup in a very specific way, all phpMyAdmin does is pass along your authentication information to MySQL.
Re: (Score:2)
Someone please mod parent up.
TFA describes a complete failure not only of the company's security setup, but of its specific architecture and design. Even if you have to use phpMyAdmin that frickin' badly? Unless you're a web hosting provider running the damned thing in a sandbox, you deny visibility to it from the outside network for starters. Then there's still the matter of the default password-less state of the DB.
I mean, damn... what high school kid did they get to set this thing up? It's not 2001 anymo
Flabbergasted (Score:2)
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.
Re: (Score:2)
Well played, sir!
Re: (Score:1)
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
Damn (Score:2)
Re: (Score:2)
Maybe that little Dutch boy can plug this security dike.
Ca subject name? (Score:4, Interesting)
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?
Re: (Score:2)
Ok, so this Ca is already not included in Debian?
I can't find anything about it in the changelog for the ca-certificates package.
Re: (Score:1)
Just asked a collegue to check his windows machine for any ca certificates named anything with Gemnet or KPN, no matches there either.
Re: (Score:1)
I can't find any certificate that looks like this on Centos 6 either.
Re: (Score:1)
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?
Re: (Score:1)
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.
Starting to feel like Uplink... (Score:3)
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 choice of trust is poorly designed (Score:2)
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.
I'm just waiting... (Score:2)
For Verisign to get hacked.
Re: (Score:2)
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.
Re: (Score:2)
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.
Enough is Enough (Score:2)
These stories about Dutch CA's are really clogging up the system.
Re: (Score:2)
Fail2ban jail for phpMyAdmin (Score:2)
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.
Misleadling article (Score:2)
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
Re: (Score:1)
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