Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Microsoft Security News IT

Same Platform Made Stuxnet, Duqu; Others Lurk 89

Posted by timothy
from the what-evil-lurks-in-the-hearts-of-men dept.
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.
This discussion has been archived. No new comments can be posted.

Same Platform Made Stuxnet, Duqu; Others Lurk

Comments Filter:
  • Windows 7 (Score:1, Insightful)

    by Anonymous Coward

    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!

    • by Anonymous Coward

      this year, Microsoft will release a secure operating system.

    • by Baloroth (2370816)

      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)

      by man_of_mr_e (217855) on Sunday January 01, 2012 @01:12AM (#38554400)

      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)

        by Anonymous Coward

        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)

          by man_of_mr_e (217855) on Sunday January 01, 2012 @04:05AM (#38554866)

          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)

            by Runaway1956 (1322357)

            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)

              by Anonymous Coward

              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.

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

                • by 0123456 (636235)

                  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)

              by zAPPzAPP (1207370) on Sunday January 01, 2012 @05:48AM (#38555092)

              Writing new code from scratch will not make that code suddenly bug free.

          • 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

            • by man_of_mr_e (217855) on Sunday January 01, 2012 @01:59PM (#38557510)

              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.

              • "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.

                • by smash (1351)
                  The unix way is slow, sure, but the buffer cache makes the problem go away, whilst still reporting correct results. Windows tries top optimise the algorithm trading off accuracy for speed, which is simply not required if you have a half decent buffer cache.
          • by Ihmhi (1206036)

            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?

            • 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

            • by drinkypoo (153816)

              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.

          • by Mojo66 (1131579) on Sunday January 01, 2012 @01:19PM (#38557212)

            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.

            • 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

  • by RMingin (985478) on Sunday January 01, 2012 @12:56AM (#38554364) Homepage

    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 US hasn't admitted to it, and there's some evidence that points to an Israeli origin. Why jump to conclusions when there's no need to for this article?
    • by heson (915298)
      CIA outsources a lot of its dirty work, primarily for deniability reasons but also since experience is hard to get in some risky fields of operation. I.e it can have been developed with help from experienced contractors, who will bring their own tools and might also steal tools for private use.
    • U.S. involvement doesn't mean the CIA wrote the thing. United States Cyber Command (I know, it totally sounds like something out of a video game, but it really exists) includes branches of the Army, Navy, Air Force, and Marines. And there's one very good reason to think that the CIA wasn't involved in Stuxnet: Stuxnet actually worked. The CIA have a good track record when it comes to overthrowing third world governments... and kinda suck at everything else.
      • by Shavano (2541114)
        Really? You don't know about most of their covert activities. If you know about it, either it has been declassified or security has been broken. You're looking at them through a biased filter.
  • My brother who is a security consultant for a large company that makes routing and network equipment often tells me that there are many many many really good bad things out there. Many of which have not be discovered by others and they don't announce they have discovered them. They just add the security to the equipment and go on their way. Some they even leave active in controlled environments to watch what they are doing over the long term.
  • Yea and ... (Score:5, Interesting)

    by Osgeld (1900440) on Sunday January 01, 2012 @01:42AM (#38554494)

    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

    • by ThatsMyNick (2004126) on Sunday January 01, 2012 @02:13AM (#38554572)

      You missed an important piece of information. Was your printer really on fire or not?

      And yeah I know, its woosh time.

      • by Osgeld (1900440)

        it was indeed not on fire

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

        • by EnsilZah (575600)

          Clearly the problem is not with the software, rather it is with the hardware printer ignition mechanism.

    • Re:Yea and ... (Score:4, Interesting)

      by VortexCortex (1117377) <VortexCortex@@@project-retrograde...com> on Sunday January 01, 2012 @02:30AM (#38554604)

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

      • by Culture20 (968837)
        I believe GP was referring to the need to use dos2unix and unix2dos.
  • Sad, isn't it? (Score:2, Interesting)

    by msobkow (48369)

    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.

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

    by superid (46543) on Sunday January 01, 2012 @07:39AM (#38555420) Homepage

    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.

    • by Type44Q (1233630)

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

    • by Mojo66 (1131579)

      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.

  • by sgt scrub (869860) <saintium.yahoo@com> on Sunday January 01, 2012 @08:18AM (#38555516)

    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: (Score:2, Informative)

      by Anonymous Coward

      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

  • Recommended. You can safely skip the last 20 minutes.

Man will never fly. Space travel is merely a dream. All aspirin is alike.

Working...