Dutch Certificate Authority KPN/Getronics has announced the suspension of the issuance of digital certificates.
The reason for this is that a breach has been discovered on a KPN web server related to PKI. The attack dates back no less than four years.
KPN, best known for its telecom business, acquired Getronics four years ago. Former Getronics has a certificate authority similar to Diginotar. Like Diginotar, KPN is allowed to issue 'special' certificates for the Dutch government and public services. In fact, many organizations affected by the Diginotar incident switched to KPN certificates.
In an almost unprecedented event the Dutch minister of internal affairs gave a press conference at 1:15 AM Friday to Saturday night. He announced the Dutch government was revoking trust in Diginotar.
Diginotar basically consisted of two seperates branches. One branch was a certificate authority which dealt with regular businesses. The other branch was focused on government and called "PKIoverheid". The audit conducted on Diginotar's systems showed the integrity of the PKIoverheid authority couldn't be guaranteed. It should be presumed the integrity is broken.
At the beginning of last week the Dutch government had vouched for the integrity of the PKIoverheid CA. This caused the browser makers to only blacklist the non-goverment CA from Diginotar. Next time around browser makers won't be quite as trusting.
The attack on Diginotar doesn't rival Stuxnet in terms of sophistication or coordination. However, the consequences of the attack on Diginotar will far outweigh those of Stuxnet. The attack on Diginotar will put cyberwar on or near the top of the political agenda of Western governments.
Here's a break down of most of the important takeaways from this incident:
Earlier this week DigiNotar said another audit would be performed and the results of this audit would be made public.
One of the big questions is whether the government CA branch - called DigiNotar PKIoverheid - has also been compromised.
In seeming preparation of these results, the Dutch government has sent out an email to users who've been issued a certificate via the DigiNotar PKIoverheid CA. All these companies/services are tied to the government or public services. Pending the results of this audit the Dutch government is asking PKIoverheid certificate owners to do the following:
- List the PKIoverheid certificates in the organisation.
- List the processes for which these certificates are being used.
- List the consequences in case the PKIoverheid certificates can no longer be trusted.
I think it would be wise at this point for the affected browser makers to start preparing an update which will also blacklist DigiNotar's PKIoverheid CA. Pending the outcome of the audit, of course.
A lot of Dutch government sites and services are going to be affected by the revocation. Clean up is going to be painful.
The Dutch government has used DigiNotar as an intermediary CA in quite a lot of cases. The Dutch government actually has a root CA of their own. It could be leveraged to quickly produce new certificates for affected services.
I hope it's truly clear now that the Dutch government needs to distance itself from DigiNotar.
In the Netherlands news just broke involving more details with regards to the DigiNotar compromise. According to this the following were included in the targeted domains: Yahoo.com, mozilla.org, torproject.org, wordpress.org and Iranian blogging platform Baladin.
So far, I haven't been able to verify these myself. It would be great if any of the browser makers or DigiNotar could confirm these were amongst the targeted domains.
Assuming these domains were indeed targeted the most plausible explanation is that a specific government is behind this attack.
What's worrisome in this saga is DigiNotar's claim a "few dozen" rogue certificates were generated. This is a particularly suspicious claim because at the same time Google has blocked over 200 rogue certificates. Something doesn't quite add up.
It gets worse though. According to DigiNotar they're not able to track which rogue certificates were generated. So more of these rogue certificates may be out there. How is this possible? Either DigiNotar performs no logging of the certificates they create or their logs got cleaned out during the attack.
Either answer is bad and neither of them is worthy of the trust we necessarily have to put into certificate authorities.
DigiNotar's response to this whole debacle has only made me more worried about how deep this attack may have run. To me, it seems that DigiNotar has not realized certificate authorities need to sell trust above anything else.
The browser makers have responded by exiling DigiNotar from the PKI chain. Now we're waiting for the Dutch government to do the same.
Today we saw the discovery of another rogue SSL certificate - this time for *.google.com. The certificate itself was issued five weeks ago. This will allow an attacker to sniff the traffic to virtually all of Google's services even with HTTPS enabled.
Right now, there's an unconfirmed report this attack is happening in Iran. Frankly, I'm not sure it's really relevant.
Given the number of companies that sell government equipment that enables them to inject certificates onto the wire, this is not restricted to any particular part of the world. However, those countries without their own CA will always be forced to take the route of compromising a Certificate Authority.
The bigger issue here is the Certificate Authority that got compromised. DigiNotar is a Dutch company which was acquired by Vasco earlier this year. Vasco - which amongst other things delivers services similar to RSA's SecurID - is a very big player on the financial market. Meanwhile DigiNotar is especially strong with governments.
Yesterday, I blogged about the older version of Adobe Flash Player on my recently purchased Google Chromebook. On Tuesday, the day before, I'd sent out a note to Adobe's PSIRT asking if they knew what was up with this earlier version.
Today, Adobe got back to me today saying that Flash Player version 10.2.158.27 is the latest version of Flash for Chromebooks. This patch was pushed out yesterday after my blog post went live. (You may notice my screenshot shows 10.2.158.26)
This week my Samsung Chromebook finally arrived. My interest in this platform had been especially piqued after my colleague Costin Raiu's excellent analysis following the Chromebook's introduction.
Google claims Chromebooks are so secure they don't need anti-malware. Such a statement obviously got me interested in the system's defenses.
Imagine my surprise when I was confronted with the following:
After last month's mega patch Tuesday this month's can only be described as very quiet. A total of three vulnerabilities are getting patched in two bulletins, MS011-035 and MS011-036.
MS011-035 deals with a remote unauthenticated vulnerability in the WINS service which can lead to code execution running with SYSTEM privileges. This vulnerability affects the Microsoft Server products. Though consistent exploit code seems unlikely it looks rather easy to DoS the service.MS011-036 deals with two vulnerabilities in Powerpoint. CVE-2011-1269 will likely see consistent exploit code, while Microsoft believes there won't be functioning exploit code for CVE-2011-1270. As pointed out by Kurt Baumgartner here Microsoft is introducing a new exploitability index this month.
This month, Microsoft is releasing 17 bulletins to address 63 security vulnerabilities across a wide range of Windows products. Out of these vulnerabilities, 12 are rated critical and 51 important.
About half of these vulnerabilities are being patched with the MS11-034 bulletin. They all involve Elevation of Privilege vulnerabilities in the Windows kernel.
Elevation of privilege vulnerabilities have gained a lot in popularity as Windows 7 and the use of sandboxes have been gaining traction. These vulnerabilities could be used for instance to circumvent UAC and immediately give a program full admin privileges without warning.
With Microsoft's newer products there's been somewhat of a trend where the number of EoP vulnerabilities outweigh the number of Remote Code Execution vulnerabilities. This trend is likely to persist over the coming months.
Microsoft will also be releasing two advisories this month. One for Windows and one for Office.
Almost exactly one month ago we warned about a zero-day in Flash which was being exploited in targeted attacks. Back then, malicious SWF files were embedded inside Microsoft Excel files. Excel was used strictly as a delivery vehicle.
This month, it's Microsoft Word's turn. The malicious .doc referenced by Brian Krebs shares a lot of commonalities with the malicious Excel sheet from last month. So if they aren't the same gang as before the attackers were at least inspired by this previous incident.