Son of Stuxnet

Discussion in 'malware problems & news' started by CJsDad, Oct 18, 2011.

Thread Status:
Not open for further replies.
  1. Rmus

    Rmus Exploit Analyst

    From the article:

    It does display the embedded font on my Windows XP SP3 with IE 8.

    Neither did my Opera browser.

    Note, however:

    Last edited: Nov 14, 2011
  2. Rmus

    Rmus Exploit Analyst

    I contacted Faronics and sent them the Symantec and Securelist analyses of the Duqu exploit. They responded saying that based on that information, their product, Anti-Executable, will block the exploit with DLL protection enabled.

    Last edited: Nov 14, 2011
  3. CloneRanger

    CloneRanger Registered Member

    Tested both my XP/SP2 with NO updates :p on FF & IE with hawki's link from post # 75 :thumb:

    Not sure why with FF it was HTTPS & with IE it was only HTTP ? Anyway ...

    FF = :)


    IE6 not allowing Fonts = Same as FF = :)


    IE6 allowing Fonts = :(

  4. hawki

    hawki Registered Member

    Kaspersky Lab protects against duqu-originated zero-day vulnerability in windows

    Published November 13th, 2011 - 09:01 GMT
    Press Release

    Kaspersky Lab, a leading developer of secure content and threat management solutions, announces that its security solutions are now detecting the vulnerability that was used for distributing all known versions of the infamous Duqu Trojan. Kaspersky Lab’s experts have successfully implemented protection against Trojan.Win32.Duqu.a as well as other malicious programs exploiting the CVE-2011-3402 vulnerability.
  5. trismegistos

    trismegistos Registered Member

    I prefer a much permanent workaround by unregistering or removing the buggy T2embed.dll file.
    Good for Faronics! Though I still have doubts but I guess they know their stuff well.
    The reason for some doubts was because I remember a few months ago, katio said that a kernel exploit such as the one involving this embedded true type font vulnerability would bypass any AE-like protection/HIPS/LUA/Applocker/Sandboxie. i.e, if this single exploit has both the privilege escalation and remote code execution. Tzuk mentioned or rather implied also that before about the possibility of an EOT vulnerability kernel exploit or any kernel exploit with remote code execution breaking out of Sandboxie... and

    Such exploit should be rare but I guess not anymore.

    To harden Sandboxie, users can do this as presented by Nicks...
    Last edited: Nov 17, 2011
  6. MrBrian

    MrBrian Registered Member

  7. mirimir

    mirimir Registered Member

    "There was a lot of speculation when Duqu first emerged about whether the attack was the work of the same group--still unknown--that had created Stuxnet and unleashed it on Iran's nuclear facilities last year."

    Is it not clear that the United States and Israel are responsible for Stuxnet?
  8. trismegistos

    trismegistos Registered Member

    That's why tzuk implied that Sandboxie can be bypassed by such kernel exploit, a privilege escalation with remote code execution - . In a way it differs from the original Stuxnet, whose first exploit (LNK vulnerability) would first trigger the arbitrary code execution to load the malicious dll before it passes on to another exploit(privilege escalation) and so Sandboxie and HIPS/Applocker/AE with dll control can put a stop on Stuxnet's malicious dll.

    So, my understanding of a kernel exploit of the embedded true type font vulnerability is that it can bypass SRP/Applocker/AE/HIPS/Sandboxie as the kernel exploit tries to load the driver on kernel mode. Hoping, I'm wrong. Only testing with the actual kernel exploit will be able to confirm such speculation. Still, there's a greater urgency or a greater need for a patch or at least people should at least apply the workaround on the buggy T2embed.dll file (Fix It program from Microsoft).
    Last edited: Nov 17, 2011
  9. ichito

    ichito Registered Member

    Next "son"? ;)
  10. Searching_ _ _

    Searching_ _ _ Registered Member

    After reading Ichito's post I wanted to see what the MalCon conference was about and who would be presenting about Stuxnet 3.0. When I went to Malcon I saw this:

    Strange coincidence?
    Realizing the mistake I found the right site ;) :
  11. trismegistos

    trismegistos Registered Member

    Attached Files:

    Last edited: Nov 29, 2011
  12. MrBrian

    MrBrian Registered Member

  13. trismegistos

    trismegistos Registered Member

    So it looks like, the dropper of Duqu can bypass all security protections(almost).

    Exploit -> kernel -> driver in kernel -> loader dll in services.exe -> big pnf in services.exe -> big pnf installing from lsass or AV process.


    [ from ]

    The exploit is on the "Vulnerability in TrueType font parsing" which could allow elevation of privileges and arbitrary code execution. In this case, the shellcode executed goes into the kernelmode, win32k.sys, gaining Ring Zero or kernel or the highest privileges bypassing most security, AVs, LUA-SRP, Applocker, probably AE and possibly even Sandboxie and some classical HIPS, once the recipient/victim of a corporation targetted for e.g. opens a seemingly benign Microsoft document file.

    This is what is HD Moore is warning, a kernel exploit that doesn't require an initial remote or local arbitrary code execution unlike the usual local kernel exploits(EoP) requiring an initial exploit of those types to gain local access. Mostly, local kernel exploits would be pushed by a dropper executable(obfuscated exe's or dlls) to elevate privileges. Most AVs, and such protections like SRP, Applocker, AE would easily detect those payloads.

    I am not sure how most classical HIPS would fare in this case of stopping the loading of the malicious driver depending on how deep down to the kernel it guards.

    This is one rare case, AE would probably not block as the payload is not an ordinary executable but a kernel driver in kernel space and the initial dropper is the exploit's shellcode itself before loading the main dropper, the malicious dll.

    SRP even with the grainier dll control would fail to catch the malicious dll, main dropper.

    Sandboxie can be bypassed by these types of kernel exploits as implied by tzuk's statements...

    Not sure how EMET, ASLR, DEP, Sehop, et al will be successful in preventing the exploit of this malwae.

    Only with the actual malware testing with the actual document file containing the kernel exploit, the kernel driver and the malicious dll can we say for certain.

    Fortunately for us, this is easy to mitigate by installing the MS' Fix It program for the meanwhile to block the access to t2embedd.dll as we wait for the patch. T2embedd.dll was the same buggy dll which had been patched before (as in the past EOT vulnerability). I preferred unregistering it permanently which might, however, block some functionalities in certain programs. Some functionalities, which for now I don't really need and have better alternatives.
  14. Joeythedude

    Joeythedude Registered Member

    Q - Would Applocker and Anti-Executable Type Products stop it at the Loader DLL main dropper ?

    I know the kernel is still exploited but if the DLL is stopped from loading then the rest of this version of the exploit would be stopped.

    @trig why wouldn't SRP catch the Loader DLL main dropper ?
  15. Rmus

    Rmus Exploit Analyst

    Please see my Post #77 above.

  16. Dermot7

    Dermot7 Registered Member

    "Stuxnet/Duqu: The Evolution of Drivers" :
    "Stuxnet weapon has at least 4 cousins: researchers" :

  17. trismegistos

    trismegistos Registered Member

    The problem is the dll is dropped by a kernel driver pushed by a kernel exploit(privilege escalation). Even HIPS depending upon the lockdown policy/ruleset will be hardpressed to stop that kernel driver from dropping the dll. How much more SRP, AE or any other security protection.

    The only way to find out is to have Faronics ask a Duqu sample from Kaspersky experts and test that.

    If the dll is loaded/dropped in userspace, SRP will stop that but this is not the case for Duqu.
  18. Dermot7

    Dermot7 Registered Member

  19. Dermot7

    Dermot7 Registered Member

Thread Status:
Not open for further replies.