2011
11.08

In the last couple of weeks we’ve heard quite a bit about the alleged “Stuxnet” variant called Duqu.  This Trojan uses a zero-day vulnerability that exploits the TrueType font parsing engine.  The Trojan replicates itself, does whatever it does (still not entirely clear), and removes itself after 36 days to avoid detection.  That last bit is sneaky; it could steal passwords or certs, high-tail it before the heat arrives, and you’d never know to reset anything that was stolen.  Very clever!

While Microsoft are working on a hotfix, they have issued an advisory that contains a workaround to prevent infection.  The actions depend on your operating system, but revolve around changing the permissions of t2embed.dll.

I’ve become very hesitant of these workarounds.  A few months ago I worked on a site that had no choice but to deploy such a workaround for Conficker.

I was installing a ConfigMgr 2007 R3 site server.  I installed ConfigMgr and checked the health of the system (it’s easy to miss a pre-req and get some sort of error).  Then I got the strangest error that I had never seen before; the management point role would not install.  What normally happens is the site server is installed (not far from next-next-next), and then a number of default roles install automatically.  The management point is usually painless.  I googled, binged, you name it, and had no joy.  A day later and 2 things gave me the solution:

  1. I had been told of the Conficker infection and clean up job that was done
  2. I found an obscure post with a similar error that pointed to a system registry key permissions issue.

1 + 1 and I verified this key was a part of the Microsoft Conficker workaround advisory.  Now, I needed to find how this was deployed.  GPMC made it easy to find a GPO that was responsible.  Permission changes via GPO are tattooed so I reversed the edits (AV was up to date).  I forced the policy refresh on the site server, reran the ConfigMgr install and the Management Point installed.  Luckily the customer had used GPO and made this workaround very easy deploy for them, and ID/reverse for me.

By the way, part of the change was changing permissions of scheduled tasks.  It turns out that backup jobs hadn’t been running correctly for a while.

So the lesson is:

  • When there is a zero-day exploit, Microsoft can issue workarounds to prevent infection.
  • Sometimes treatment for an illness can do quite a lot of damage to the patient.  Understand what you are doing and document/communicate it.
  • If at all possible, do what my customer did.  Use a GPO because it is (a) fast to deploy and (b) fast to reverse once the long term defences (patch/AV) are deployed.  And that means impacted systems can be put back to rights.
Technorati Tags: ,

2 comments so far

Add Your Comment
  1. If this new fix involves changing NTFS permissions on that particular DLL GPO won’t be too much help as I’m pretty sure NTFS permissions edited by GPO are not reversed when the GPO is removed.

    • And that’s why I said this in my post: “changes via GPO are tattooed so I reversed the edits”.

Get Adobe Flash player