Dutch DigiNotar Servers Were Fully Hacked 83
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."
Falsified Logs! (Score:3)
Re:Falsified Logs! (Score:4, 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.
Re: (Score:2)
quick and dirty: cron jobs that wipe the history file every minute.
I thought of that in about 5 seconds.
Re:Falsified Logs! (Score:4, 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
Re: (Score:2)
Oooh now that is dirty.
Re: (Score:1)
FTA, looks like it was a Microsoft Windows infrastructure, all the vectors were Windows servers.
Define "blatant falsification" (Score:2)
Re: (Score:1)
Binary art of someone being blatant, methinks...
Re: (Score:2)
Shhhh... Don't let Peta find out about this...
Nothing to see here... (Score:3, Funny)
This hack never happened.
- Signed: DigiNotar
Re: (Score:1)
By all means, help yourself.
Giving out the links is kinda dumb when you could have the registration link and one year support and upgrades for free as well.
http://flock.codeweavers.com/ [codeweavers.com]
Who's to blame? (hint) (Score:2, Insightful)
Re: (Score:3)
it's not fair to blame the administrators. you should blame the people who hired them.
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:3)
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 w
Re: (Score:2)
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.
Min
Re: (Score:2)
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
Bloody n00bs... (Score:4, 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.
Re: (Score:3, Insightful)
WORMs cost money... so does all security... I'm sure the contract was awarded to the lowest bidder.
Re:Bloody n00bs... (Score:4, 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.
Re: (Score:2)
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 ent
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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 tak
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:1)
<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 wi
FULLY hacked? (Score:5, Funny)
As opposed to, what, partially hacked?
Isn't that like being almost pregnant?
Re:FULLY hacked? (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.
Re: (Score:2)
Re:FULLY hacked? (Score:5, Informative)
Re: (Score:2)
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.
Re: (Score:2)
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.
Not surprised at all! (Score:1)
Re: (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: (Score:1)
Re: (Score:1)
Aight, bitch, show me the linux botnets.
Ok [theregister.co.uk]. Happy?
For more info (Score:1)
Re: (Score:2)
Just so I know: Why the heck should I care what he is?
8200 PSYOP (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.
Re: (Score:2)
Since the attackers came in through an open port, the firewalls are irrelevant. Now, will someone please moderate this antisemitic bullshit down to -infinity?