Duqu Mitigation

Published: 2011-11-04
Last Updated: 2011-11-04 09:48:14 UTC
by Guy Bruneau (Version: 1)
9 comment(s)

There has been a lot of information published on Duqu over the past few days and it is likely exploiting a vulnerability in a Microsoft Windows component, the Win32k TrueType font parsing engine. Until a patch as been release to fix this vulnerability, the vulnerability cannot be exploited automatically via email unless the user open an attachment sent in an email message. The Microsoft advisory is posted here. US-CERT also posted a critical alert here and Symantec a whitepaper on the subject here.

[1] http://technet.microsoft.com/en-us/security/advisory/2639658
[2] http://www.us-cert.gov/control_systems/pdf/ICS-ALERT-11-291-01E.pdf
[3] http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_duqu_the_precursor_to_the_next_stuxnet.pdf


Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Keywords: Duqu Malware TrueType
9 comment(s)


Microsoft have released an automated workaround to mitigate the threat until a patch is released. It's at http://support.microsoft.com/kb/2639658

However, "applications that rely on embedded font technology will fail to display properly."
I think Microsoft is glossing over the more dangerous attack. If this can be exploited by simply viewing a web page then it would either come from just clicking a link in an email or, the nasty possibility, just from viewing an HTML email.
You can replace "If" with "Since". From the Microsoft bulletin:

How could an attacker exploit the vulnerability?
There are multiple means that could allow an attacker to exploit this vulnerability, including providing documents or convincing users to visit a Web page that embeds TrueType. The specially crafted TrueType font could then exploit the vulnerability.

So it looks to me like embedded TrueType in webpages is a distinct vector. I've checked both IE 7 and IE 9 and they both default to "Enabled" for Font Download for the Internet security zone. See http://msdn.microsoft.com/en-us/library/ms533034(v=vs.85).aspx for a discussion of Font Embedding in Internet Explorer, including various test pages you can use to verify the behavior (and probably also verify the workaround - I haven't gotten quite that far yet).
I disabled Font download in Firefox.
I am really disappointed in MS as I suspect the poster above is correct.
They said there were multiple vectors in the notice. Are you guys similarly surprised or disappointed when there are bugs in commerical software? I'd suggest you visit securityfocus.com to see how common this type of thing is. Get yourselfs an IPS and patch as soon as one becomes availalbe. Remember - layers......
We applied MS Fix it 50792 MSI installer to find various issues. On Domain Controllers the installer fails due to script error: there is a Windows installer specific issue. Install Execute hangs.
Removing the partial patch by MS Fix it 50793 same issue:
A script to complete the installation could not be processed. Contact your supportpersonal or supplier of the paket. Userdefined action: RUN_32_SETACL Scripterror -2147023170, : line62, column 5,
on W2K3 and XP we saw 2 former WSUS patches offered again after Fix it 50792 looping - no way to install KB972270 and 982132 that as well modified the t2embedd.dll long time ago. Installing the patches automatically or manual does not remove the looping that requests to install again and again after Fix it applied.
Looks Microsoft has to review and fix the Fix it and/or provide WSUS patch that works under all these scenarios.
The deny access to EVERYONE on t2embedd.dll triggers the WSUS to offer patches KB972270 and KB982132 - but install even successful does not stop the updates to be offered agagin and again.
I'm seeing the same behavior with SMS 2003 DSUW with respect to the t2embedd.dll patches and the workaround. The deny on Everyone means that the SYSTEM account can no longer check the file version on the file, so the various Microsoft patch scanning systems no longer see the patch as installed.

As long as all users on the machine are in the Users group (either directly or indirectly), you can adjust the deny to affect the BUILTIN\Users group instead of NT AUTHORITY\Everyone. If you do that, then SYSTEM can still do scans (since it's a de facto member of the Administrators group, but not the Users group). I'm pivoting to that as a workaround. I'm not worrying about servers - one shouldn't be opening random files or websurfing from servers!

Diary Archives