Dutch DigiNotar Servers Were Fully Hacked

← Back to Stories (view on slashdot.org)

Dutch DigiNotar Servers Were Fully Hacked

Posted by Soulskill on Wednesday October 31, 2012 @08:33AM from the they-don't-fool-around dept.

ChristW writes "The final report that was handed to the Dutch government today indicates that all 8 certificate servers of the Dutch company DigiNotar were fully hacked. (Report PDF in English.) Because the access log files were stored on the same servers, they cannot be used to find any evidence for or against intrusion. In fact, blatant falsification has been found in those log files. A series of so-far unused certificates has also been found. It is unknown if and where these certificates have been used."

41 of 83 comments (clear)

Min score:

Reason:

Sort:

Falsified Logs! by Beardydog · 2012-10-31 08:44 · Score: 2

Color me impressed. Log_Modifier may not fill many gigaquads, but it sure ain't free.
1. Re:Falsified Logs! by rwa2 · 2012-10-31 09:51 · Score: 3, Interesting
  
  In other news, it sounds like someone is going to be setting up an authlog blackhole in the near future...
  Did they check their .bash_history ? The silly script kiddie that got into my RH4 box back in the 90s forgot to clean his traces there. I mean, he bothered to run "history -c " , but it didn't actually stop his session from dumping everything there again after he logged out.
2. Re:Falsified Logs! by X0563511 · 2012-10-31 15:46 · Score: 1
  
  quick and dirty: cron jobs that wipe the history file every minute.
  I thought of that in about 5 seconds.
  
  --
  For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
3. Re:Falsified Logs! by rve · 2012-10-31 18:52 · Score: 3, Informative
  
  quick and dirty: cron jobs that wipe the history file every minute.
  I thought of that in about 5 seconds.
  The more canonical solution is rm ~/.bash_history && ln -s /dev/null ~/.bash_history
4. Re:Falsified Logs! by Sadsfae · 2012-11-01 02:13 · Score: 1
  
  FTA, looks like it was a Microsoft Windows infrastructure, all the vectors were Windows servers.
  
  --
  Have a squat over at the hobo house.
5. Re:Falsified Logs! by X0563511 · 2012-11-01 02:24 · Score: 1
  
  Oooh now that is dirty.
  
  --
  For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Define "blatant falsification" by TWX · 2012-10-31 08:44 · Score: 1

Were the Hex strings loaded with DEADBEEF or B00B135 or something?

--
Do not look into laser with remaining eye.
1. Re:Define "blatant falsification" by mfh · 2012-10-31 08:56 · Score: 1
  
  Binary art of someone being blatant, methinks...
  
  --
  The dangers of knowledge trigger emotional distress in human beings.
2. Re:Define "blatant falsification" by TWX · 2012-10-31 09:02 · Score: 1
  
  It's been used a lot. It sticks out obviously when going through a lot of raw data, so it makes for a good catch string on green-bar paper.
  
  Shhhh... Don't let Peta find out about this...
  
  --
  Do not look into laser with remaining eye.
Nothing to see here... by Anonymous Coward · 2012-10-31 08:46 · Score: 3, Funny

This hack never happened.
- Signed: DigiNotar
Who's to blame? (hint) by ntropia · 2012-10-31 08:47 · Score: 2, Insightful

You know, for a server being violated is always a matter of probability, same story about hardware failures ("when", not "if"). Some of the variables in this equation is how "interesting" your server could. And a server releasing certificates is quite "interesting", if you ask me. So if you keep the logs of such an important server on the machine itself, there isn't much to say: the administrators of such a server are incompetent.
1. Re:Who's to blame? (hint) by fluor2 · 2012-10-31 09:36 · Score: 2
  
  it's not fair to blame the administrators. you should blame the people who hired them.
2. Re:Who's to blame? (hint) by rahvin112 · 2012-10-31 10:58 · Score: 2
  
  Yes, because those people are likely the ones that said "We are not buying another machine for log data" or said "we can't afford segregated network segments and secure communication to protect the signing servers". In my experience you can usually trace failures like this back to an unwilligness to spend money, not necessarily blatant incompetence.
  It's just as likely that the management prevented proper security as it is that the IT staff were morons.
3. Re:Who's to blame? (hint) by plover · 2012-10-31 12:07 · Score: 1
  
  I think there's plenty of blame to go around on this one. From the top to the bottom, these guys were thoroughly incompetent. A good admin stepping into the job would have pressed for effective security policies, and balked if they weren't implemented. A competent CISO would have started with them. A competent CEO / CIO should have known they needed a CISO, being a security company after all.
  
  --
  John
4. Re:Who's to blame? (hint) by Opportunist · 2012-10-31 14:46 · Score: 2
  
  No, blame the person writing the specs and requirements. Because the admin can't do JACK if his CISO is a dick.
  Blunders like this ain't an admin's fault. This isn't some config switch set improperly or a port in the firewall left unguarded. It's a fault in the security paradigm and the security strategy of the company. This is NOT an administrator's fault. In companies of a certain size (and I guess DigiNotar would be one) the average admin doesn't even have the information to make a decision like that. A watchful admin might notice it, he might even mention it "upstairs", but he cannot DO anything about it if it doesn't get green lighted from above.
  Don't blame the techs for management errors. And this, bluntly, is one.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
5. Re:Who's to blame? (hint) by dkf · 2012-11-01 00:06 · Score: 1
  
  Blunders like this ain't an admin's fault.
  Wrong. They are the admin's fault, along with the fault of others as well. Blame can be spread, but not absolved. The admin should not have let things get into a state where things could get hacked, whatever his line management said. What's worse, if things were in a management state where the admin had decided to do a private passive-aggressive work-to-rule (I've known a few admins like that; technically competent, but total dicks) then they're absolutely making things worse and are thoroughly to blame.
  Mind you, I'm not absolving management here. It takes two to tango.
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
6. Re:Who's to blame? (hint) by Opportunist · 2012-11-01 21:36 · Score: 1
  
  The question is whether an admin can actually make that decision. Considering how sensitive the whole subject is and how management usually thinks techs don't know about "responsibility", chances are that he could not. The admin could have been well aware that there is a problem, and if he is smart he wrote a mail (and printed it for his own records) to his superior, but it is very unlikely that he could make a decision like that without a blessing from above. What's worse, there most likely even existed an order that he MUST NOT do something like that with the thinly veiled threat that if he does he's being fired on the spot. That has nothing to do with a passive-aggressive work-to-rule attitude, simply with "I want to keep my job so I have to work to THEIR rules".
  A good admin would probably have noticed it, and he probably informed management about it. Whether he did or not we'll probably never know, because such things (hopefully!) don't make it out into the open, at least if this doesn't go to a public court. But it is very likely that he sat there, knowing well that he's guarding a ticking time bomb, but he just didn't get the necessary ok from above to do anything about it.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Bloody n00bs... by fuzzyfuzzyfungus · 2012-10-31 08:48 · Score: 3, Insightful

You would think that a company playing at something mildly important(like, oh being a CA for the Dutch government...) could, at very least, do basic things like store logs on WORM tape... Yes, those are overpriced compared to the normal ones; but they aren't that expensive.
1. Re:Bloody n00bs... by Anonymous Coward · 2012-10-31 08:55 · Score: 3, Insightful
  
  WORMs cost money... so does all security... I'm sure the contract was awarded to the lowest bidder.
2. Re:Bloody n00bs... by tlhIngan · 2012-10-31 09:25 · Score: 1
  
  You would think that a company playing at something mildly important(like, oh being a CA for the Dutch government...) could, at very least, do basic things like store logs on WORM tape... Yes, those are overpriced compared to the normal ones; but they aren't that expensive.
  Welcome to business. The same rules apply everywhere - try to cut as many corners as you can so the company can boast about huge profits and the CEO can pay for this space tourist ticket.
  The only things that change are how far you can take it before you get caught, and what the penalties are. In thie case, it was basically closing up shop. Not the worst (they could've held the execs liable, for example)...
3. Re:Bloody n00bs... by Ryanrule · 2012-10-31 12:36 · Score: 1
  
  You need to insert liability. IE, signing agency is FULLY liable for any losses incurred due to their security failure. This will make signing very expensive. That is ok.
4. Re:Bloody n00bs... by Opportunist · 2012-10-31 14:52 · Score: 3, Insightful
  
  *sigh* Most likely, yeah.
  Security is the stepchild of IT. They don't produce. Ok, so does a lot of IT, but at least with the rest of IT, management can somehow hope that eventually they can fire a couple of people. With ITSEC, no such luck. They don't streamline production (worse, they often bog it down), they don't make people redundant, in fact, they make more people necessary. Plus, those pesky, nosey security geeks keep peeking into every computer and might find out that the boss is surfing on pages containing gay llama porn.
  It's sad but true, if you see two people sitting on a huge table in the crowded cafeteria and nobody wants to join them, and they're not talking with each other either, you know where security and controlling are.
  But unlike controlling, it's pretty hard to make your boss understand the dangers of a security breach in IT.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
5. Re:Bloody n00bs... by Opportunist · 2012-10-31 14:54 · Score: 1
  
  Sadly, it won't increase security. The money will not be used to hire better people and tighten security, it will go into reserves for when (not if) they get to pay for their blunders.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
6. Re:Bloody n00bs... by buglista · 2012-10-31 20:05 · Score: 1
  
  Another syslog server costs peanuts, just has to be a bunch of disk with only port 514/udp listening. Shit, I use to run an internal CA which was more secure than these guys, because it was air-gapped. I know that doesn't scale, but we weren't charging people for certs, just doing it for internal use.
7. Re:Bloody n00bs... by DarkOx · 2012-10-31 22:18 · Score: 1
  
  Man you just described the scene in our cafeteria most days. I happen to be one those guys at the table. What always amazes me is production just does not get it. I really am their best friend. They are always freak out that "our security stuff" might mess up their PLC and someone could get hurt.
  Its like the possibility that a worm could get on their unpatched XP SP1 platforms from one of the endless parade of technician laptops that get plugged into that subnet and someone could get hurt is entirely lost on them. You'd think a bunch of plant engineers would get that its better to test out security controls under somewhat controlled conditions with people aware they might be a problem than to get owned during third shift.
  Codered and welchia were not that long ago, and stuxnet and flame were just in the news but memories are short apparently.
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
8. Re:Bloody n00bs... by DarkOx · 2012-10-31 22:29 · Score: 1
  
  No it won't got to reserves. It will go to insurance premiums and to one of the big audit firms annually to NOT find problems and generate a great deal of glossy print outs to make the insurance firm feel good.
  
  <half kidding>
  The insurance firm will then sell stocks and bonds to a large brokerage, who will aggregate them into a fund or other financial product with more insurance companies suggesting that all risk has been eliminated. The original insurance companies will by these products (essentially their own companies) back from the brokers after paying a hefty commission and list them as assets.
  
  Then brokers will revalue the assets higher based on the now expanded balance sheets, and suggest that more leverage is therefore okay. Eventually some hack of some tiny backwater CA nobody uses will cause a ripple effect bring the entire financial system to knees.
  </half kidding>
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
9. Re:Bloody n00bs... by Opportunist · 2012-11-01 21:26 · Score: 1
  
  Our product managers found out that I'm on their side by now. What I learned is that you have to "sell" it to them, my angle was that I write part of their specs and also verify that they are being kept by the suppliers, thus taking work off their shoulders. Actually, what happens is that I write the sec requirements (which is my job anyway), then adapt them to their project (which is technically their job but that way at least I get what I want instead of them guessing what my specs are actually about and then omitting what really counts...) and review the bids (so I can make sure that my security guidelines are implemented).
  It serves both of us. I get in the hard- and software we buy what our security standards require, and keep them from having to deal with it at least during the bidding stage of the project. Maybe it could work for you too, maybe trying to get into the acquisition/programming procedures for your PLCs would help them get rid of the concerns for "your security stuff" and enable you to get what you need?
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
FULLY hacked? by ilsaloving · 2012-10-31 08:50 · Score: 4, Funny

As opposed to, what, partially hacked?
Isn't that like being almost pregnant?
1. Re:FULLY hacked? by fuzzyfuzzyfungus · 2012-10-31 08:55 · Score: 5, Informative
  
  It's always a dangerous assumption to make; but architecturally the concept of 'partially hacked' isn't terribly nonsensical. Consider the enormous number of web server setups where OS-level credentials and web application authentication are entirely different things. It happens all the time that kiddies will crack the web component and scribble all over your php forum or CMS or whatnot; but without ever gaining access to the OS.
  You really don't want to work on the assumption that 'eh, I'm sure we were only partially hacked, no need to reinstall the OS'; but it may well often be true.
2. Re:FULLY hacked? by dutchwhizzman · 2012-10-31 09:18 · Score: 4, Informative
  
  4 out of 8 CA servers were proven to be tampered with and the hacker got Admin and/or SYSTEM privileges. The only thing he didn't get away with were the actual private keys, since those were stored in hardware that did the actual signing. If Diginotar would have scheduled the signing to a specific time of day and removed the smartcards from the readers for those CAs, he wouldn't even have been able to get his rogue certificates signed. The other 4 servers weren't interesting for the hacker and my interpretation is that he mainly used the CA server that could sign "web site certificates" for MITM purposes. I'd say that qualifies as "fully hacked" as opposed to for instance a single web server where a single web service was not completely secure, so he could manipulate it into signing requests. He got through 3 layers of (obviously lacking) security before he got to the CA servers themselves. Layer 1 was web servers, layer 2 was the office network and layer 3 were the CA servers themselves. He used stacked tunnels to get through firewalls between network segments and used public webservers he already owned as file drop. Out of over 250 investigated machines, he got access on all significant ones in the certificate, web hosting and logging processes, but the actual hardware containing the private keys. In summary, I'd say fully hacked is an accurate description.
  
  --
  I was promised a flying car. Where is my flying car?
3. Re:FULLY hacked? by NinjaTekNeeks · 2012-10-31 09:31 · Score: 1
  
  Agreed. Had the attacker not been able to leverage the access he obtained on the web servers to compromise the SQL Server he may very well have been stopped in his tracks in the DMZ.
4. Re:FULLY hacked? by PolygamousRanchKid+ · 2012-10-31 09:41 · Score: 1
  
  As opposed to, what, partially hacked?
  Well, yes, it's partial differential equations and quantum mechanics . . .
  
  Isn't that like being almost pregnant?
  It's just like Schrödingers cat was pregnant and not prenant at the same time.
  In Abstract Hilbert Space.
  
  --
  Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
Not surprised at all! by tikal808 · 2012-10-31 09:30 · Score: 1

Just look at what their web servers have been running for years! What a joke!! http://uptime.netcraft.com/up/graph?site=www.diginotar.nl
1. Re:Not surprised at all! by Anonymous Coward · 2012-10-31 09:37 · Score: 1
  
  As opposed to the OS and web server running on the kernel.org servers that were compromised by trojans? I wish I wish I could remember their names...
Re:Oh, really? Try this *NIX boy... apk by tikal808 · 2012-10-31 10:26 · Score: 1

You have put together a good compilation of various issues with Linux. Of course in my brief comment, I never even mentioned Linux. I'm looking forward to seeing what kind of issues you have complied regarding Net/Free/Open BSD. Cheers.
For more info by Citral · 2012-10-31 10:26 · Score: 1

The attacker's Pastebin posts can be found here: http://pastebin.com/u/ComodoHacker . The authenticity seems likely to me; in one post he links to a calculator.exe that you can download which is signed by a Diginotar certificate. When you inspect the file properties in Windows, it will indeed state that the file is certified.
8200 PSYOP by Anonymous Coward · 2012-10-31 11:20 · Score: 1

First, very good hack - if the story is true. I would not be surprised to find out in ca 10 years that they had the inside help.
BUT, somebody is trying hard to attribute this to Irangov. They are the bad, evildoers and certainly - war must be brought to their land. This smells like a masterpiece in a huge PSYOP orchestration to inflame public opinion in the West.
Google for "8200" and check who builds the CP firewalls.
1. Re:8200 PSYOP by mvdwege · 2012-11-01 06:23 · Score: 1
  
  Since the attackers came in through an open port, the firewalls are irrelevant. Now, will someone please moderate this antisemitic bullshit down to -infinity?
  
  --
  "I know I will be modded down for this": where's the option '-1, Asking for it'?
Re:is there any connection with stuxnet by plover · 2012-10-31 12:19 · Score: 1

No, the signed keys used in the stuxnet attack were believed to have been stolen by an actual break-it at the factories that made the motor controllers.

--
John
Re:And The Political Angle ? by Opportunist · 2012-10-31 14:59 · Score: 1

Just so I know: Why the heck should I care what he is?

--
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Re:There were only 2 types involved... apk by Desler · 2012-10-31 15:41 · Score: 1

Aight, bitch, show me the linux botnets.
Ok. Happy?