Yesterday the Iranian CERT made an announcement about a new piece of wiper-like malware. We detect these files as Trojan.Win32.Maya.a.
This is an extremely simplistic attack. In essence, the attacker wrote some BAT files and then used a BAT2EXE tool to turn them into Windows PE files. The author seems to have used (a variant of) this particular BAT2EXE tool.
There's no connection to any of the previous wiper-like attacks we've seen. We also don't have any reports of this malware from the wild.
BlackHat USA may have been wrapped up for the year but DEFCON is in full swing. I didn't stay around for DEFCON though, which means I finally have some time to reflect on BlackHat.
This year featured the first time Apple presented at BlackHat, about iOS security. While the presentation lacked the details usually seen in BH talks it definitely showed Apple is trying to open up. Being (more) communicative is vital to doing security response right.
This is of particular importance for Apple as there were quite a few talks focusing on Apple's security. Ranging from attacks on iOS to Mac-oriented EFI rootkits.
At the recent SOURCE Boston conference, one presentation that caught my attention was called SexyDefense - Maximizing the home-field advantage.
This was quite a thought-provoking presentation that was based on the old concept that offense is always the best defense.
Today is the last day of CanSecWest - a security conference taking place in Vancouver, Canada. On Wednesday I filled in for Costin Raiu and talked about our forensics work into Duqu's C&C servers.
As I'm writing this, Google Chrome just got popped. Again. The general feeling is that $60k, even with a sandbox escape, isn't a whole lot of money for a Chrome zero-day. So, to see multiple zero-days against Chrome is quite the surprise, especially when considering the browser's Pwn2Own track record.
Separately, I found the Q&A session following Facebook's Alex Rice’s presentation immensely intriguing.
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)