Son of Stuxnet

[Rmus]

Originally Posted by hawki

A simple test insures the Duqu workaround is working

From the article:

Below is a closer image of the address displayed by Internet Explorer 8 on a vulnerable Windows XP SP3 system.

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

Bryant also pointed out* that "Any browser that relies on the kernel to parse embedded TrueType fonts may be affected by this issue."

Since kernel rendering of TrueType fonts is not something browser vendors frequently discuss, I also tested Firefox 8 and Chrome 15 on vunlerable instances of Windows 7 and XP.

Neither browser rendered the embedded True Type font.

Neither did my Opera browser.

Note, however:

To be clear, this simply means that the system can not be infected viewing a malicious web page in Firefox or Chrome. However, a Windows computer without the workaround, can still be infected by other software, such as a malicous Word document or Powerpoint presentation.

----
rich

[Rmus]

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

[CloneRanger]

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 =

[hawki]

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/...windows-400709

[trismegistos]

Originally Posted by Rmus

Note, however:

I prefer a much permanent workaround by unregistering or removing the buggy T2embed.dll file.

Originally Posted by Rmus

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.

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/viewt...r=asc&start=15

[MrBrian]

Researchers Convinced Duqu Written By Same Group as Stuxnet

[mirimir]

Originally Posted by MrBrian

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?

[trismegistos]

Originally Posted by undertow

From the Microsoft Security Advisory:

"Microsoft is investigating a vulnerability in a Microsoft Windows component, the Win32k TrueType font parsing engine. An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode."

"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 seems any application that renders TrueType fonts can be used to trigger arbitary code execution in kernel mode A drive-by download using this exploit could then pwn a standard user account even with SRP/Applocker. Which explains the lack of detail we have gotten so far. Hopefully the patch comes soon...

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).

[ichito]

Next "son"?

Malware coders and security researchers are increasingly looking at MalCon malware convention to show-off their latest creations and research. We were pretty shocked to see in a twitter update today from MalCon, that one of the research paper submissions shortlisted is on possible features of Stuxnet 3.0.

While this may just be a discussion and not a release, it is interesting to note that the speaker Nima Bagheri presenting the paper is from IRAN.

http://thehackernews.com/2011/11/stu...-released.html

[Searching_ _ _]

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:

Malcon Industrial Controls is a full service systems integrator serving the industrial automation and process control industries. We provide relay, PLC, SCADA, and other control systems, panel fabrication, and related review, integration, and installation services.

http://malcon.com

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

[trismegistos]

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

[MrBrian]

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

[trismegistos]

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/20...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.

[Joeythedude]

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 ?

[Rmus]

Originally Posted by Joeythedude

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

Please see my Post #77 above.

----
rich

[Dermot7]

"Stuxnet/Duqu: The Evolution of Drivers" : http://www.securelist.com/en/analysi...ion_of_Drivers

We have been studying the Duqu Trojan for two months now, exploring how it emerged, where it was distributed and how it operates. Despite the large volume of data obtained (most of which has yet to be published), we still lack the answer to the fundamental question - who is behind Duqu?

In addition, there are other issues, mostly to do with the creation of the Trojan, or rather the platform used to implement Duqu as well as Stuxnet.

"Stuxnet weapon has at least 4 cousins: researchers" : http://www.reuters.com/article/2011/...7BR1EV20111228

(Reuters) - The Stuxnet virus that last year damaged Iran's nuclear program was likely one of at least five cyber weapons developed on a single platform whose roots trace back to 2007, according to new research from Russian computer security firm Kaspersky Lab.

[trismegistos]

Originally Posted by Joeythedude

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 ?

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.

[Dermot7]

While analyzing the components of Duqu, we discovered an interesting anomaly in the main component that is responsible for its business logics, the Payload DLL. We would like to share our findings and ask for help identifying the code.

https://www.securelist.com/en/blog/6...Duqu_Framework

[Dermot7]

By Gregg Keizer: Duqu, the malware that has been compared to 2010's notorious Stuxnet, is back, security researchers said today.

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