Same Platform Made Stuxnet, Duqu; Others Lurk 89
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.
Re:Happy new year (Score:5, Funny)
Happy new year~
There's no better way to kick off the new year on Slashdot with a Microsoft article.
Re: (Score:1)
That's ok. You can be modded down!
Re: (Score:2, Insightful)
by Anonymous Coward on 2012-01-01 16:07 (#38554182)
Re: (Score:1)
I think this year I'll stop forgetting to log in when I post.
Windows 7 (Score:1, Insightful)
So, this new super-secure, not-at-all-like-the-previous-versions of Windows is still being infected by the same malware as before.
I'm shocked!
Re: (Score:1)
this year, Microsoft will release a secure operating system.
Re: (Score:2)
I thought this was the year of Linux on the desktop?
Small problem, however: most people buy laptops these days.
Re:Windows 7 (Score:5, Funny)
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.
Re: (Score:2)
Does it cook bacon? Cuz if it don't cook bacon it ain't all that.
There's a PPA for that.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
OS/2, are you back from the grave?
Re: (Score:1)
Other OS's are more secure than Linux, UNIX, and OS X, too.
So what?
Re: (Score:2)
Same development platform != same malware. Not every program made with Visual Studio is identical, for example (an analogy, but you get the idea). Also, the development program supposedly underwent large changes in 2010 (after 7 came out). Not that Windows 7 is super-secure, you just have to make better arguments that it isn't.
Re:Windows 7 (Score:5, Interesting)
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.
Re: (Score:2, Interesting)
What I found interesting is the low code quality of Windows reflected in the exploits.
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
Re:Windows 7 (Score:5, Insightful)
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.
Re: (Score:2, Interesting)
It's that "steadily pruning" that allows malware creators to keep up, or even to keep one step ahead of Microsoft.
They need to make a clean break. The next release of Windows should be that clean break. Microsoft has masters of marketing in their employ. They can tell the world that everything from the old days is out the "Window", and none of it will work on Win8. And, they can hype it up in such a manner that even non-geeks get excited about it.
I'll give grudging credit to Microsoft. Win7 is more sec
Re: (Score:2, Insightful)
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.
Re: (Score:2)
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". They paid for that software however many years ago, they've gotten their use out of it, it's time to move on. Tightwad bastards need to get with the times.
ASSuming that management is intelligent enough to describe what they need to be done, I'm certain that they can find a coder to do whatever it is that needs to be done.
Re: (Score:3)
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.
Re:Windows 7 (Score:5, Insightful)
Writing new code from scratch will not make that code suddenly bug free.
Re: (Score:1)
Mod up!
I am so sick and tired of the MS sucks bal bla, but Unix is infalliable that persists here.
The ones who say Linux never gets viruses always have rootkits on their servers because it is a dangerous assumption. MS is at least trying and has more security features of any operating system. So there are a few vulnerabilities. I am sure Gnome, X, and Linux have similiar ones as well.
Re: (Score:2)
You've been influenced by old new thing. It's well written and I enjoy reading it but after a while it becomes clear there is too much rationalizing of poor design decisions and sloppy implementations. A recent example is the recent entry about NTFS file sizes [msdn.com]. While recognizing that Unix does it the right way very early in the post, the rest of the post goes on to rationalize the confusing, dumb design decision in NTFS influenced by a perceived performance problem that hasn't been relevant for at least a d
Re:Windows 7 (Score:4)
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.
Re: (Score:1)
"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."
That's one way to view it. Another way to view is that Unix designers went for a consistent and predictable design while NTFS designers chose a "surprising" design that continues to surprise developers to this day for a performance benefit that is of dubious value. Surprising designs are typically not good designs.
Re: (Score:1)
Re: (Score:3)
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?
Windows 7/Server 2008 have UAC Virtualization (Score:1)
See subject-line:
1.) UAC Virtualization (via taskmgr.exe) CAN "sandbox" programs into ONLY writing the current user's registry (rather than going "system-wide")... it's a step in the right direction!
2.) Windows also has "Hyper V" natively, so you can "sandbox" an entire virtual machined Operating System & any apps on it you wish to run (many antivirus companies use this technique when analyzing malware in fact).
3.) Then, you've got SANDBOXIE which you noted, & it's 100% free too, + it uses a driver
Re: (Score:2)
They kind of did, it's called Windows 7 64 bit, it deletes the 16 bit environment completely finally, and you're expected to use XP Mode to run your old programs. Unfortunately, XP mode is a piece of shit. Can't even run Civ 2.
Re: (Score:2)
Yes, and that's what I was saying. The person I responded to said that the spooler was writing to another computers system directory. That wasn't the case, it was a remote computers spooler writing to its own system directory (due to impersonation). This was because in certain cases, because of compatibility with older, poorly written printer drivers, this was necessary.
What i said, and what you said are not incompatible, it's just more detail.
Re:Windows 7 (Score:4)
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.
Re: (Score:2)
Please. There's been plenty of backwards compatibility issues in Unix and Linux over the years.
As I said, the LoadLibrary issue is likely because the code was written in the 90's, before LoadLibraryEx existed. The code was never updated. This wasn't a backwards compatibility issue, it was just old code that had been working fine so nobody looked at it.
No, the CRC32 hash was not a backwards compatibility issue, in fact it only worked in Vista and newer because the task scheduler was rewritten. I said it
So Duqu also = CIA project? (Score:4, Interesting)
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?"
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
OLD NEWS ? (Score:2)
Yea and ... (Score:5, Interesting)
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
Re:Yea and ... (Score:5, Funny)
You missed an important piece of information. Was your printer really on fire or not?
And yeah I know, its woosh time.
Re: (Score:2)
it was indeed not on fire
Re: (Score:3)
it was indeed not on fire
Hmmm, must have been a predictive warning message, then. Since computers are never wrong, I'd better bring over some petrol and matches. Where exactly is this printer?
Re: (Score:3)
Clearly the problem is not with the software, rather it is with the hardware printer ignition mechanism.
Re:Yea and ... (Score:4, Interesting)
It wasn't a big deal. I used my BBS.
Protip: Connect two PCs' modems to a single phone line. (Null modem works, but for portability we're going with the lowest common denominator).
Some modems can be told to ignore the "No Carrier" error, so you can connect the PCs directly to each-other, but if yours can't, or the machines are in different rooms just connect the lines directly to the wall outlets to get the carrier...
You can't ring yourself (unless you have two phone lines), so instead you just wait... The booo Dooo BEEEEP "Please Hang Up" (off-hook alert) plays. Then you wait some more for that to stop... Now you have an open phone line to connect two modems via. So all you have to do now is drop to the modem command mode (+++), and issue an ATDT on one PC (Hayes compatible: Attention Dial Tone), but you don't specify a phone number. To the the other PC's modem you issue: ATA (Attention, Answer). The handshake should begin and you can copy / paste ASCII text back and forth once the connection is established. I've used this trick recently with Xmodem, Kermit, etc to transfer Ethernet NIC driver sources, and other files in a pinch.
Maybe transferring ASCII was a headache to you, but it was a breeze to me: even back then digital distribution was miles ahead of sneaker-net & proprietary file system formats...
Re: (Score:2)
Re: (Score:2)
That only covers line endings.
It doesn't even do that! Depending on the platform, you could have CR (Mac) LF (Unix) or CRLF (Windows), and then of course there's Windows with ^Z EOF and Unix with ^D and Macintosh with the ability to know how long a file is...
Sad, isn't it? (Score:2, Interesting)
Some companies are so slow to address reported and known security issues that the malware writers have time to not only create an exploit, but an entire framework for deploying it, and delivering multiple platform enhancements over the years.
All while the vendor can't plug one stinking hole.
Re: (Score:2)
What''s is with all the earlier comments? (Score:2)
Re: (Score:2)
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.
/agree
MS Versus Metasploit (Score:5, Interesting)
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.
Re: (Score:1)
So this tells me that MS does NOT bother to review Metasploit scripts to get a leg up on zero days...
It's far more likely that they do review them and the info finds its way into the hands of a select few (gee, I wonder who that'd be??).
Re: (Score:2)
They do this in order to game the metrics on how reaction time to exploits is measured. They delay patches until a bug is widely exploited and the media reports on it so it looks as if they responded immediately. In their minds, this creates more positive media echo than silently fixing a bug nobody knows about.
Linking DLL's from the net. Nice! (Score:5, Interesting)
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!
Re:Linking DLL's from the net. Nice! (Score:5, Informative)
Re: (Score:2, Informative)
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 fi
The video is pretty cool (Score:2)
Recommended. You can safely skip the last 20 minutes.