Last Updated: 2012-06-05 10:29:19 UTC
by Johannes Ullrich (Version: 4)
Microsoft just released an emergency bulletin, and an associated patch, notifying users of Windows that a "unauthorized digital certificates derived from a Microsoft Certificate Authority" was used to sign components of the "Flame" malware.
The update revokes a total of 3 intermediate certificate authorities:
It is not clear from the bulletin, who had access to these intermediate certificates, and if they were abused by an authorized user, or if they were compromised and used by an unauthorized user. Either way: Apply the patch.
The bulletin also doesn't state if this intermediate certificate authority or certificates derived from it could be used to fake the patch. Microsoft Certificates are used to sign patches, and a compromise could lead to a sever break in the trust chain. The use of a "real" Microsoft certificate is surely going to increase the speculations as to the origin of Flame.
========== UPDATE 1 (04 June) ===========
We'll update this story as we learn more
A post today from Microsoft sheds more light on this:
If you are not patched or otherwise mitigated, your workstation will trust code signed with this cert - remember that patch Tuesday is coming up, this could go very bad very quickly !!
The certificates in question are issued by "Microsoft Root Authority" or "Microsoft Root Certificate Authority". "Microsoft Root Authority" is certainly in my browser list trusted for "All issuance policies" and "All application policies".
This lends more weight to the wording in the original SA , which indicated that these certs can be used in MitM (Man in the Middle) attacks on SSL as well as code signing.
We've discussed the potential in the past for pushing malware as a patch, but seeing this as possible in a major platform like Windows is NOT common !
The patch provided by Microsoft removes trust for these, but you can do this yourself in your browser, or by using the CERTUTIL command line method. However, I don't see anything in my list that looks like what's been compromised - and in order to move a CA to the untrusted list it needs to be in your list in the first place. Removing the Microsoft Roots are (of course) not recommended !
========== Update 2 (04 June) ==========
I've had a reader ask - how do I remove these from the Trusted Publishers list without applying a patch that I haven't yet tested?
Simple, you can use certutil. For instance, to remove the first cert ("Microsoft Enforced Licensing Intermediate PCA", with a Thumbprint of "2a 83 e9 02 05 91 a5 5f c6 dd ad 3f b1 02 79 4c 52 b2 4e 70" ), enter the command:
certutil -delstore authroot "2a 83 e9 02 05 91 a5 5f c6 dd ad 3f b1 02 79 4c 52 b2 4e 70"
After you delete the offending items (or apply the patch), you can easily check the status in IE, under "Untrusted Publishers" tab in the "Content" / Publishers section
========== UPDATE 3 (05 June) ===========
Our reader Matthijs correctly points out that in this case you cannot delete what is not there. If you don't have these in your Cert Store in the first place, you cannot delete them with this method. Check his comments (and his link) in the comments section - some great input there, thanks Matthijs !
Last Updated: 2012-06-05 02:20:09 UTC
by Lenny Zeltser (Version: 1)
There are numerous ways of concealing sensitive data and code within malicious files and programs. However, attackers use one particular obfuscation technique very frequently because it is simple to implement and offers protection that's usually sufficient. This approach works like this:
- The attacker picks a 1-byte value to act as the key. The possible key values range from 0 to 255 (in decimal).
- The attacker's code iterates through every byte of the data that needs to be encoded, XOR'ing each byte with the selected key.
To deobfuscate the protected string, the attacker's code repeats step #2, this time XOR'ing each byte in the encoded string with the key value.
For example, consider the malicious Microsoft Word document "World Uyghur Congress Invitation.doc", which was submitted to victims as an email attachment in a targeted attack. (To understand how this exploit works, see my earlier posts How Malicious Code Can Run in Microsoft Office Documents and How to Extract Flash Objects From Malicious MS Office Documents.)
To locate the executable file within the Word document, you can use Frank Boldewin's OfficeMalScanner tool. The "scan" option directs the tool to look for the embedded malicious Office and Windows executable files. The "brute" option tells the tool to look for these artifacts even if they were obfuscated using several common methods, including the XOR technique described above.
In this example, OfficeMalScanner automatically locates and extracts the embedded Windows executable, saving it as the "WUC Invitation Letter Guests__PEFILE__OFFSET=0xfc10__XOR-KEY=0x70.bin". (The tool automatically determined that the attacker used XOR key 0x70 to conceal this file.) According to PEiD (see screenshot below), the extracted file is a Win32 program that is not packed and that was probably compiled using Microsoft Visual C++.
The deobfuscated and extracted Windows executable file can be analyzed using any means, including your favorite disassembler and debugger, as well as using behavioral analysis techniques.
It's quite possible that the extracted malicious executable also contains obfuscated data. Given that everyone, including malware authors, takes shortcuts once in a while, it's possible that this data is protected using the simple XOR algorithm we discussed earlier. Didier Steven's XORSeach tool can scan any file, looking for strings encoded using simple techniques, including this XOR method.
You need to know the clear-text version of the string you'd like XORSearch to locate. One good value to look for is "http", because attackers often wish to conceal URLs within malicious code. Another good string, as suggested by Marfi, might be "This program", because that might identify an embedded and XOR-encoded Windows executable, which typically has the string "This program cannot be run in DOS mode" in the DOS portion of the PE header.
As you can see below, XORSearch locates the string "HTTP/1.1" within the extracted malicious executable; apparently it was encoded using the key 1B. (Sometimes you get a false positive, as seems to be the case with the key 3B.)
When invoking XORSearch with the "-s" parameter, you direct the tool to attempt decoding all strings within the file using the discovered key. In our example, this results in the creation of the "WUC Invitation Letter Guests__PEFILE__OFFSET=0xfc10__XOR-KEY=0x70.bin.XOR.1B" file. If you look at this file using a hex editor, you can locate several decoded strings that you might use as the basis for custom signatures and further code-level analysis.
XOR and related methods are often used by attackers to obfuscate code and data. The tools above help you locate, decode and extract these concealed artifacts. If you have recommendations for other tools that can help with such tasks, please let us know by email or leave a comment below.
-- Lenny Zeltser
Last Updated: 2012-06-04 13:55:17 UTC
by Rob VandenBrink (Version: 1)
We've received a fair number of questions on today's emergency patch from Microsoft ( https://isc.sans.edu/diary/13366 ), and many of them have been simply "Why don't they just put the affected Certs into the CRL (Certificate Revocation List)"? That is, after all, what the CRL is for, and it's part of the SSL protocol for goodness sake!
Simply put, in most cases the browsers do not consult the CRL, or if they do, they time out the lookup and proceed on *very* quickly. Jim wrote on this in Febuary when Chrome enabled this behaviour ( http://http://isc.sans.edu/diary.html?storyid=12556 ). But this behaviour has been in force for some time (to various degrees) in most browsers an platforms. A quick google led me to some excellent articles on this topic:
You'd think after the Diginotar compromise just last year (http://isc.sans.edu/diary.html?storyid=11500 , http://isc.sans.edu/diary.html?storyid=11512 and many others), we'd have learned and changed this behaviour.
Unfortunately, it's truly become a race to the bottom for Browsers where SSL security is concerned. And sadly, it's we, the browser users who insist on "the fastest browser" that have forced them to go there.
Last Updated: 2012-06-04 06:03:56 UTC
by Rob VandenBrink (Version: 1)
This past week (June 1) VMware has posted version 1.0 of it's vSphere 5.0 Hardening Guide. They've changed their approach from previous Hardening Guides, the current version is gridded out an Excel doc, with the benchmarks split out between those that apply to Virtual Machines, ESXi, Network and vCenter.
The thing I really like about this new version of the Hardening Guide is that it further emphasizes script-based assessments of as many of the benchmarks as possible. Examples of how to assess many of the benchmarks are supplied in vCLI, PowerCLI and direct shell scripting within ESXi.
This approach is near-and-dear to my heart, we spend an entire day on script based security assessments of vSphere ESX and ESXi environments in SANS SEC579 ( https://www.sans.org/security-training/virtualization-private-cloud-security-1651-mid )
You can find the vSphere 5.0 Hardening Guide here ==> http://communities.vmware.com/docs/DOC-19605
For assessing vSphere 4.1, the vSphere 4.1 Hardening Guide can be found here ==> http://communities.vmware.com/docs/DOC-15413
Thanks to Charu, his team and all the contributors to this great series of resources!
Please choose a specific diary above to comment