Slashdot Mirror
Same Platform Made Stuxnet, Duqu; Others Lurk
wiredmikey writes "New research from Kaspersky Labs has revealed that the platform dubbed 'tilded' (~d), which was used to develop Stuxnet and Duqu, has been around for years. The researchers say that same platform has been used to create similar Trojans which have yet to be discovered. Alexander Gostev and Igor Sumenkov have put together some interesting research, the key point being that the person(s) behind what the world knows as Stuxnet and Duqu have actually been using the same development platform for several years." An anonymous reader adds a link to this "surprisingly entertaining presentation" (video) by a Microsoft engineer, in which "he tells the story of how he and others analysed the exploits used by Stuxnet. Also surprising are the simplicity of the exploits which were still present in Win7." See also the report at Secureist from which the SecurityWeek story draws.
Happy new year~
There's no better way to kick off the new year on Slashdot with a Microsoft article.
Maybe you're both right: Microsoft will release a Linux distro. It will be both wildly successful and record-breakingly secure. It will also cure cancer, balance the US federal budget, and bring about world peace.
Correct me if I'm wrong, but didn't the CIA totally deny not knowing who made Stuxnet, and that they were sure they totally weren't excluding themselves, and various other CIA double-negativisms that all but said "We did that?" Can't we just say "Duqu written by CIA, just like Stuxnet, on the same dev platform?"
The preceding comment is my own, and in no way construes an opinon of the Emperor of Mankind.
Actually, if you watched the video, stuxnet was interesting because it used different 0-day exploits depending on which version of the OS was used. Only one of the exploits (the foothold exploit that allows the code to work in userland in the first place) worked on all versions of windows.
So, what it really showed was that out of 5 exploits, only one worked across the whole platform, and that one only allowed userland access.
If you need web hosting, you could do worse than here
I saw "printer on fire" the other day on my linux power pc (after installing a pci parallel port card) ...
the thing is unless you want to fuck over X decades of the way shit was done your going to have old things pop up, like it or not that is the beat of the drum or else you end up with a trillion incompatible systems reminiscent of the early 1980's cheap home computer syndrome.
Which if your not old enough to remember ... just the simple ability to transfer ascii text files from platform to another was a headache
What I found interesting is the low code quality of Windows reflected in the exploits. ... was this code written by interns?
Calling LoadLibrary (rather than LoadLibraryEx with LOAD_LIBRARY_AS_DATAFILE) if all you want to do is extract an icon?
Using CRC32 to guard what is essentially trusted login information?
Not range checking an index into a list of function pointers when you read it in?
The print spooler can write arbitrary files? In the system directory of another computer? And it impersonates local system when acting on behalf of a guest?
O_O
Saw the link, watch the talk, pretty awesome. Language can be colorful at time, i don't know if it's typical in this setting. Really liked the structure of his talk, and fact that it even goes into his state of mind when he worked on it really made the story telling much more interesting.
This Sig is removed due to factual inaccuracy
Windows is still hobbled by backwards compatibility. They have been steadily pruning the system of such compatibility issues over the years, but they still remain.
The print spooler was a compatibility issue, and it wasn't writing files to the system directory of another computer. It was the remote print spooler that was writing to its own system directory.
The shell icon extraction code was probably written for Windows 95, and the LoadLibraryEx was not added until Windows 2000. This is why it was the only exploit that worked on all systems.
The CRC32 bit was definitely not well thought out, but it was most likely not considered to be an attack vector, and only there to prevent file corruption... for which CRC32 is fine.
There are going to be bugs in any non-trivial code, and Windows has a lot of code. Just like Linux has lots of code, and MacOS has lots of code.. you can find these kinds of issues in any OS.
If you need web hosting, you could do worse than here
Whats the point of using Windows if it cant run the CFOs IE 6 app? Or productions 16 year old Win95 app? Businesses use Windows to run software and a clean break doesnt make financial sense. This software cant be rewritten and needs to remain compatible.
Writing new code from scratch will not make that code suddenly bug free.
The video is very interesting, but one thing really does annoy me. He talks about discovering the initial vuln and how they were able to understand it literally within minutes (around slide 15/16) and they realized how serious it was (100% successful loading of a DLL from a WebDAV path via LoadLib because control panel icons are handled in a different (broken) way).
Hey says that the vuln existed for years and that a 7 year old could exploit it because it was included in Metasploit (slide 16). He clearly indicated that Metasploit knew about this before MS and that they were tipped off by 1 or 2 other 3rd party malware researchers who sent in "just another LNK exploit" that they happened to bother to look at. He even said "it's a good thing we did [look at it]".
So this tells me that MS does NOT bother to review Metasploit scripts to get a leg up on zero days..... that surprised and annoys me.
In the video at 11:16'ish he says, "it is loading the dll from the net". Essentially Windows allows an attacker to build executables from library sources, disguised as icon containers, located anywhere on the net. Priceless!
Having to work for a living is the root of all evil.
Reminds me of this hack; 133 byte PE executable with remote code loading.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
In the video at 11:16'ish he says, "it is loading the dll from the net". Essentially Windows allows an attacker to build executables from library sources, disguised as icon containers, located anywhere on the net. Priceless!
What exactly is that second sentence trying to say? I can't parse that. Libraries always contained executable code, hell: rundll32.exe mydll.dll,SomeFunctionInTheDll will cause the DLL to be loaded and run SomeFunctionInTheDll as the int main().
What he said is that Control Panel Applets have a feature called "Dynamic Icons", that is, the icon can change or even be entirely drawn by code instead of stored in the program (So the icon for the Windows Firewall can change so the brick wall disappears when the firewall is disabled or something like that) but to do that requires actually running native machine code outside of a sandbox (which is frickin' stupid). He then went on to say that Windows didn't give a crap about the path where the CPL was stored, it could be C:\applet.cpl, A:\applet.cpl, \\someothercomputer\someshare\applet.cpl or a WebDAV folder on a website (which is only slightly worse than the fact that it already worked with network shares anyway).
Windows XP fixed the DLL which contains icons causing code to run problem in XP/2000 when they added LoadLibraryEx with the DONT_RESOLVE_DLL_REFERENCES and LOAD_LIBRARY_AS_DATAFILE flags. The problem is limited to CPLs which (Dynamic Icons) physically can't be loaded that way.
How is it stuff like Sandboxie can exist but Microsoft can't, you know, just start from scratch with a new OS and just run previous editions in a VM?
Random Thoughts From A Diseased Mind (Not For Dummies)
Businesses can update the code, or get new applications, or hire someone to create the applications they need. No, it does not "needs to remain compatible"
If Windows won't run their apps, why would the company stick with Windows?
Microsoft's biggest fear is that if they break WhizzyWriter '93 then companies who are no longer tied to Windows by crappy old software might look at other operating systems instead.
Man I can't understand why your reply has been modded 'Insightful' when it is just a piece of PR guy rationalising poor design decisions, while the parent is at score 2 right now. Too bad I spent my last mod point yesterday.
At least, that allows me to comment on you.
Firstly, you can't explain why LoadLibraryEx wasn't used in XP and later when it was already available in Win 2000. Backwards compatibility would mean that applications were relying on the fact that code was executed when an icon was loaded? Bull crap, Mister.
Secondly, the CRC32 problem wasn't the root cause, but the fact that the XML file where the Task Scheduler stores its data in, is world writeable and contains the user name that it should run the task as. I mean how stupid is that? Following your argument that this was kept for the sake of backwards compatibility, this would mean that applications were expecting to write into the XML file and would then adapt the CRC32 hash? Bull crap, too.
Lastly, if I understood this correctly, the print spooler vuln works like this: due to the lack of a guest user on the target system, the print spooler assigns system privileges to a printing job coming in from an external 'guest' and stores the file under sytem32\spool. Another thread is constantly monitoring this directory and, assuming that only the system user can write there, executes code in some MOF file - whatever that is - with system privileges. This is wrong in so many aspects that not even the best PR person in the world can argue that this has been kept for the sake of backwards compatibility.
I don't know what Microsoft fanboys have modded you Insightful, but these are all bad design decisions and in no way justified by a need for backwards compatibility. Also the fact that the solution they came up with to fix the CRC32 issues was to use SHA256 and not fix the world writeable file issue, is telling the true story. I'm not saying that any UNIX is free of bugs, but this kind of security design does not exist in any UNIX flavour I know. Microsoft engineers or management seem to lack the fundamental security motivation all UNIX programmers have.
Umm.. no. The article you mention doesn't "recognize that Unix does it the right way". It says that doing it that way is slow, which I completely agree. Anyone that's worked with a lot of files knows how slow scanning directories is. Linux these days hacks this by trying to keep inodes as close together as possible.
The inode solution has many many many problems, from slow directory scans to file fragility. If something happens to the inode, the file is very hard to recover (one of the reasons that a hard power loss on a Linux machine can be so devastating). Journaling helps, but can't completely solve that problem.
NTFS is a very stable and secure filesystem. Some people don't like the fact that you can't overwrite in-use files like you can with an inode system, but there are reasons for that as well.
Don't confuse design limitations with implementation bugs. NTFS was deliberately designed to be that way, most security vulnerabilities are implementation bugs.
The bugs stuxnet took advantage of were a combination of old code that had not been updated to more secure API's, failure to check the bounds of a function pointer table, hacks to provide backwards compatibility to poorly written legacy code, and in one case a tool that did not consider that it's files could be used to elevate privs.
All of those have been found in various versions of Linux and it's software. DNS vulnerabilites going back over a decade, sudo vulnerabilities, buffer overflows, etc.. it happens. you write a million lines of code, some of it will have bugs, and some of it will have bugs that expose a vulnerability.
If you need web hosting, you could do worse than here