Son of Stuxnet

From the article:

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

Neither did my Opera browser.

Note, however:

----
rich

 

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.


----
rich

 

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

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 =

 

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.

http://www.albawaba.com/business/pr...ginated-zero-day-vulnerability-windows-400709

 

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... http://www.sandboxie.com/phpbb/viewtopic.php?p=43628 and http://www.sandboxie.com/phpbb/viewtopic.php?p=53719

Such exploit should be rare but I guess not anymore.

------------
To harden Sandboxie, users can do this as presented by Nicks... http://www.sandboxie.com/phpbb/viewtopic.php?t=6616&postdays=0&postorder=asc&start=15

 

Researchers Convinced Duqu Written By Same Group as Stuxnet

 

"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?

 

That's why tzuk implied that Sandboxie can be bypassed by such kernel exploit, a privilege escalation with remote code execution - http://www.sandboxie.com/phpbb/viewtopic.php?p=53719 . 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).

 

Next "son"?

http://thehackernews.com/2011/11/stuxnet-30-to-be-possibility-released.html

 

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:

http://malcon.com

Strange coincidence?
Realizing the mistake I found the right site : http://malcon.org

 

The Duqu Saga Continues: Enter Mr. B. Jason and TV’s Dexter

 

The Mystery of Duqu: Part Five
The Mystery of Duqu: Part Six (The Command and Control servers)

 

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 http://www.securelist.com/en/blog/208193243/The_Duqu_Saga_Continues_Enter_Mr_B_Jason_and_TVs_Dexter ]


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... http://www.sandboxie.com/phpbb/viewtopic.php?p=53719

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.

 

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 ?

 

Please see my Post #77 above.

----
rich

 

"Stuxnet/Duqu: The Evolution of Drivers" : http://www.securelist.com/en/analysis/204792208/Stuxnet_Duqu_The_Evolution_of_Drivers

"Stuxnet weapon has at least 4 cousins: researchers" : http://www.reuters.com/article/2011/12/28/us-cybersecurity-stuxnet-idUSTRE7BR1EV20111228

 

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.

 

https://www.securelist.com/en/blog/667/The_Mystery_of_the_Duqu_Framework

 

https://www.computerworld.com/s/art...rfaces_after_four_month_holiday?taxonomyId=17