Slashdot Mirror
Duqu Installer Exploits Windows Kernel Zero Day
Trailrunner7 writes with an excerpt from Threatpost: "A newly discovered installer for the Duqu malware includes an exploit for a previously unknown vulnerability in the Windows kernel that allows remote code execution. Microsoft is working on a fix for the kernel vulnerability right now. The exact location and nature of the flaw isn't clear right now. The installer uses a Word document to exploit the vulnerability and then install the Duqu binaries."
Says it can spread over SMB shares too, but I don't think anyone in my company is dumb enough to ^H^H^H^ NO CARRIER
"When information is power, privacy is freedom" - Jah-Wren Ryel
I'm a little confused. Why would you need a Word document to exploit a remote vulnerability?
Once again, don't open email attachments from unknown senders.
To offset political mods, replace Flamebait with Insightful.
With a name like "game boy" and a comment about "SMB shares", I think for half a second about this kind of SMB share.
Why / How can a *Word Document* exploit a kernel vulnerability?
I mean really.
I'm impressed Microsoft even acknowledged it. Years ago they would have buried this news, claiming anyone reporting on it was aiding terrorists. I'm looking forward to the fix, when they roll it out in a couple of months.
A feeling of having made the same mistake before: Deja Foobar
I'm sorry, but anyone that lets their Windows / internal servers be contacted by arbitrary packets from the Internet, or their systems allow execution by ordinary users of (at the very minimum, unscanned) email attachments, deserves everything they get.
This isn't news now and wasn't back 20 years ago. If you have to do more than just in a "just-in-case" firewall rule into your network equipment that automatically blocks this particular attack from local users (and which should be impossible to execute directly against the server remotely anyway), then you weren't really doing your job in the first place.
Next you'll be telling me that I shouldn't let filesharing ports open to the world.
There are those who say that the reason OS X has so much less malware is simply because it has a smaller market share.
I'm sorry, that's not the reason at all. The reason is because of crap like this where a word processor document can exploit a kernel vulnerability. The reason is because of crap like Outlook, which is not only happy to execute code for any data type it sees, but does it in the preview pane. (And IE and Excel doing the same thing.) The reason is because it will happily embed crap like Flash into documents, opening up a whole new world of vulnerabilities. The reason is because of crap like ActiveX, where random native code on the internet can be executed on the main CPU, with full access to the API. The reason is because of crap that listens to undocumented TCP/IP ports, onto which an single UDP packet can take over and start spewing itself all over the internet.
Etc.
But how do you reverse such a hole? Like this.
Hey! Where is Borg Bill? Put it back right now!
That is all
"A newly discovered installer for the Duqu malware includes an exploit for a previously unknown vulnerability in the Windows kernel that allows remote code execution." It's an exploit embedded inside a Word document. You can't get more local then that.
do you have a kernel security bug in a word processor?
Normally I'd be exaggerating with a statement like this, but not this time I think: "only with Microsoft..." Every time I see something like this I can't help but think they can't possibly pull off something stupider. And yet somehow they just keep doing it.
I work for the Department of Redundancy Department.
"Duqu consists of a driver file, a DLL (that contains many embedded files), and a
configuration file. These files must be installed by another executable—the installer. The installer registers the
driver file as a service so it starts at system initialization. The driver then injects the main DLL into services.exe.
From here, the main DLL begins extracting other components and these components are injected into other pro-
cesses. This process injection hides Duqu’s activities and may allow certain behaviors to bypass some security
products."
wipe your disk and reinstall Windows.
I'm Not Antisocial, I'm Just Not User Friendly
"Duqu consists of a driver file, a DLL (that contains many embedded files), and a
configuration file. These files must be installed by another executableâ"the installer. The installer registers the
driver file as a service so it starts at system initialization. The driver then injects the main DLL into services.exe.
From here, the main DLL begins extracting other components and these components are injected into other pro-
cesses. This process injection hides Duquâ(TM)s activities and may allow certain behaviors to bypass some security
products."
Instead of using email attachments, make it company policy to drop the attachments on a network drive, and instead share intranet links.
Anyone who spear phishes with attachments will fail. Now they will need intranet access, which can be significantly harder to acquire.
:(){
Command there, on the driver9s) it uses cmi4432.sys, jminet7.sys, nfrd965.sys, & adpu321.sys. This will stop their operations upon next reboot (assuming they do NOT protect the registry init. area that is - I haven't read if they do, or don't: Someone provide proof of that please one way or the other, & thanks).
As to the injected DLL(s), if it is OLE type, unregister it!
Otherwise, delete it (& if held open by another process? Simply use ProcessExplorer.exe to freeze/halt the parent calling process, & then destroy the dll on disk - you will need to have the DLL pane view active, & highlite exe's running to see what dll's they using (or other libs) & "paralyze away" as noted above...).
* Should take care of that end of it, "lickety-split, no shit" - DONE!
(Be aware of the tools you have as Windows users already, from your installation media, as they can do a hell of a job on rootkits too!)
APK
P.S.=> If anyone has any other ideas, or weaknesses in this plan? Let me know, we'll discuss it, & figure out more "work-arounds" (if need be)...
... apk
if it infected ds roms, that would be friggin brilliant.
world was created 5 seconds before this post as it is.
You don't have a kernel security bug in the word processor, you have it in the kernel.
The word processor makes kernel calls all the time; usually wrapped in crt.dll and cpp.dll calls but it's kernel calls in the end.
Opening a file and locking a file requires a kernel call.
blog.sam.liddicott.com
If all you people would stop demanding that word processing files have any networking capabilities, this would stop happening.
Microsoft just provided a way to work easier.
Ok, maybe not, but I'm hard pressed to blame MS for many of these features. They just gave us what we demanded as customers.
I guess the old adage to **never** trust anything that a user can enter wasn't part of this code in MS-Office.
The article says kernel exploit. Many user-land calls are wrappers for kernel-land functions. If this was some undocumented API call in Word, then the exploited function might not validate inputs very well.
:(){
So your company lost all its marketing, production & engineering documents for your trade secret widgets & it was due to a Microsoft bug.
Is Microsoft responsible for allowing a Word condition allowing executables in or the Windows OS for having holes?
Or is your company responsible for the total loss of its trade secret intellectual property?
Now who do the aggrieved shareholders sue?
Has ground to a distributions Of a solid dose they 4re Come parts. The current FUTURE AT ALL against vigorous Most people into a
#666 Fall prey to exploit like docx
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
When done playing to decline for At this point That supports AMERICA) is the on baby...don't Is wiped off and 3 simple steps! mo5t. Look at the Fortunately, Linux again. There are had become like file was opened of reality. Keep Uncover a story of To say there have I Won't bore you towels on the floor OpenBSD wanker Theo All our times have Incompatibilities are looking very beyond the scope of over a quality = 36400 FreeBSD intentions and Paper towels is part of the see. The number irc.secsup.org or and the Bazaar lubrication. You my calling. Now I users of BSD/OS. A I thought it was my mire of decay,
I saw this next to the story:
It is important to note that probably no large operating system using current
design technology can withstand a determined and well-coordinated attack,
and that most such documented penetrations have been remarkably easy.
-- B. Hebbard, "A Penetration Analysis of the Michigan Terminal System",
Operating Systems Review, Vol. 14, No. 1, June 1980, pp. 7-20
This works well, right up until the point where you need an attachment from someone outside the company.
Say... the latest revision to a requirements doc being sent back and forth between a client and a vendor...
Of course nobody reads the FAQ! If people read the FAQ, the Questions wouldn't be so Frequently Asked.
Give the outside consultant VPN access to a restricted share.
:(){
I haven't seen any mention of whether the document attack vector affects OpenOffice and LibreOffice users as well.
I do not fail; I succeed at finding out what does not work.
Much to learn you still have
Or use the company's website or intranet to access docs. You could send/phone the remote person an ID to get in.
If I understood you correctly, since Word Macros as VBA (VB for applications scripting), said macros can use the AddressOf method for external lib calling (which allows for callback functions correct address pointer retrieval for data coming out of said methods) -> http://msdn.microsoft.com/en-us/library/aa165194(v=office.10).aspx
"The article says kernel exploit. Many user-land calls are wrappers for kernel-land functions.." - by DeadCatX2 (950953) on Wednesday November 02, @01:05PM (#37922290)
Now, using what you stated - some of which I am NOT SURE what you meant (see next quote below)? You're correct that many Win32 API calls are just "fronts" to Native NtAPI calls (many in NTDLL.DLL in fact). That's where what I wrote above can help (for callback functions).
"If this was some undocumented API call in Word, then the exploited function might not validate inputs very well." - by DeadCatX2 (950953) on Wednesday November 02, @01:05PM (#37922290)
Uhm... MOST of the time, exploits done from MS' compound OLE doc structures (Excel, Word, etc.) use VBA to generate macros (bogus ones too)... so, as far as "validating inputs" (which is easy enough to do in VB for various datatypes filtering, on say/for example, keypress events), & especially from callback methods that go thru the Win32 API and even into the native NtAPI layer API??
The AddressOf method, helps...
APK
P.S.=> This has been true since OfficeXP in fact... but, do you mind being a BIT MORE SPECIFIC on your "validating inputs" portion I quoted above though? apk
To "trim off" excessive whitespace (even in null terminated strings) via those methods in VB/VBA. I doubt this uses input fields though (like text boxes for example), so using keypress events (as I noted last post as where I usually perform data input validations in programs @ least typically) is out... & so is using length limits on said inputs in textbox built in methods. Trim/LTrim/RTrim are all that's left for that much.
AddressOf can handle LPSTR (Long pointer to string) - but, as you said, if the dorks who created this are out to exploit a buffer overflow possible in a system lib?
You may be right! Why? Well, lol, they're NOT out to "create good code that does constructive things", but rather, to "f'up" the OS into doing buffer overflow & then privelege escalations would be my guess!
* Anyhow/anyways: We'd have to see the code (source, not assembly dumps) to even BEGIN to make "educated guesses" though (takes too long to go thru asm statements in debuggers - I've always hated that about them)...
APK
P.S.=>
"I'll be the first to admit, I don't really know much about Duqu in particular or what kernel exploit it used." - by DeadCatX2 (950953) on Wednesday November 02, @04:02PM (#37924804)
Well, I'm no "expert" on its EXACT mechanics either (& the articles the past few days have been pretty "substandard" on those details imo), but, I *think* I have a way to "knock the chocolate" out of this thing, easily enough, & with tools you already own (IF you're a "Windows man", & sounds like you are):
http://it.slashdot.org/comments.pl?sid=2505686&cid=37921376
It worked on "the indestructible rootkit" (from around a month or so back), it SHOULD work on this too (provided its multiple drivers aren't functioning to protect one another, but more importantly, their registry init areas)...
... apk
Based on its contents, that article was written sometime late 2001, but nowhere does PCW show any indication of its original publication date! Now that is true bogosity in action.
For every problem there is a solution that is simple, obvious and wrong.
Which was from another posting in this thread exchange here can kill it MOST likely:
"Exploits themselves are not terribly complicated, it's the rest of the Duqu architecture that layers the tricks on thick." - by DeadCatX2 (950953) on Wednesday November 02, @04:31PM (#37925122)
It's not that bad, seriously (provided the registry init areas for the drivers are NOT protected for, this is what made killing "the indestructible rootkit" easy to do in fact - it's lone driver, hello_tt.sys, wasn't protecting that registry load area for its bogus bootsector protecting driver!)
---
"But the exploit itself is probably not encrypted." - by DeadCatX2 (950953) on Wednesday November 02, @04:31PM (#37925122)
I agree - it's probably more or less, "configuration information" for what C&C to talk to, etc./et al...
---
"I doubt they'd be using text input or keypress events." - by DeadCatX2 (950953) on Wednesday November 02, @04:31PM (#37925122)
As did I (per my last reply)... I was looking @ this from the perspective of writing GOOD code that actually does decent things (from a GUI) - I just gave a validation example using those is all.
---
"More likely, it's probably some innocuous call, e.g. GetVersionOfWord(LPSTR path). Except that the path variable is strcopied into a stack variable which was only MAX_PATH+1 in length, or something tragic like that." - by DeadCatX2 (950953) on Wednesday November 02, @04:31PM (#37925122)
That's where I was thinking that Trim type commands in VBA would help, but again: I am talking about writing GOOD code...
LOL, not like these guys who made this malware (well, for them it's "good", hehe, causing a buffer overflow priv. esc. error - depends on your definitions of "good" vs. "evil" here, & who's doing the judging).
* Good "geek speak" here, by the way...
APK
P.S.=> I cannot wait until MS or others release WHAT EXACT API/LIB/DLL houses the error, & which API call it is that's being abused here... it would help discussions of this a GREAT deal! Yes, they keep it "undercover" to stop more dorks from doing malware exploits using it, but this is the downside for those of us that combat these things!
... apk
NETP191.PNF DLL (this is per Symantec's updated notes on it here http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_duqu_the_precursor_to_the_next_stuxnet.pdf )
Ha - the malware makers use a technique of internal containment for it INSIDE other executables!
(I've done stuff like this in screensavers - housing video they playback as an internal resource that's extracted out to disk or memory & loaded for playback - makes for "1 piece/1 moving part" installations & runs, no installer needed type apps: However, in this case, in a malware? Heh - VERY sneaky!).
* This "update" of mine's per my last post, & using ProcessExplorer.exe to destroy the libs this malware uses -> http://it.slashdot.org/comments.pl?sid=2505686&cid=37921376
APK
P.S.=> In real essence though, this lib (that I assume, hopefully correctly) loads ONLY in usermode (correct me IF I am wrong/off guys, I only skimmed the updated docs on it from Symantec) - so, that said?
ProcessExplorer.exe MIGHT NOT EVEN BE NECESSARY! You can use Recovery Console's DEL command instead to destroy the DLL while in usermode IF it is still on disk, & doesn't just "extract" for injection in usermode only...
... apk
This has been demonstrated years and years ago and *nothing* has been done to fix it. Any single local exploit on any version of Windows can be priviledge-escalated to "admin" / root / you-name-it.
There's apparently nothing they can do about it: they're fighting that for years and still cannot fix it.
So everytime an exploit is found in any software : IE, Word, Excel, whatever that gives local access, they can escalate it to admin.
It's not the escalation that is zero day: escalation has been known to work since forever. It's the Word exploit giving local that is zero day.
Does Open/Libra Office have the same problem?
How do you infect that which you can not write?