Weekly Edition
Return to the Security pageRecent Features
| |||||||||||||
Schneier on Stuxnet
Here's a fairly
comprehensive look at what's known about the Stuxnet worm by Bruce
Schneier. "Stuxnet was expensive to create. Estimates are that it
took 8 to 10 people six months to write. There's also the lab setup--surely
any organization that goes to all this trouble would test the thing before
releasing it--and the intelligence gathering to know exactly how to target
it. Additionally, zero-day exploits are valuable. They're hard to find, and
they can only be used once. Whoever wrote Stuxnet was willing to spend a
lot of money to ensure that whatever job it was intended to do would be
done."
(Log in to post comments)
Schneier on Stuxnet Posted Oct 7, 2010 19:22 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
If this was a targeted stealth attack I'm a bit surprised that they used such a visible vector as a virus which ended up on a goodly number of the world's computers.
Schneier on Stuxnet Posted Oct 7, 2010 20:24 UTC (Thu) by NightMonkey (subscriber, #23051) [Link]
It only had to be stealthy for a limited time. Plus, the advantage of using insecure PCs to do the work of finding a way in rather than some kind of focused, managed effort, was probably pretty compelling.
It is a pity how Windows makes it so easy to do such nefarious work. It's a pity that so many use it in places it just doesn't belong.
Schneier on Stuxnet Posted Oct 7, 2010 21:40 UTC (Thu) by TeDiouS (guest, #67602) [Link]
"[...]It's a pity that so many use it in places it just doesn't belong."
+1
Schneier on Stuxnet Posted Oct 7, 2010 22:55 UTC (Thu) by lutchann (subscriber, #8872) [Link]
Although I'm normally an advocate of avoiding Windows for security reasons, I suspect it would have presented little additional challenge to the organization responsible for Stuxnet if all these Siemens PLCs were programmed from a Linux PC instead of Windows. These people seem to be incredibly skilled at what they do.
Schneier on Stuxnet Posted Oct 8, 2010 0:06 UTC (Fri) by vonbrand (subscriber, #4458) [Link] But getting to those Linux PCs to subvert them in the first place would have been much harder.
Schneier on Stuxnet Posted Oct 8, 2010 2:01 UTC (Fri) by nlucas (subscriber, #33793) [Link]
If they all used the same Linux distribution not that much (assuming they would also know about some linux zero-day exploits).
The diverse Linux ecosystem is one of our best defenses against this.
Schneier on Stuxnet Posted Oct 8, 2010 2:30 UTC (Fri) by Viddy (subscriber, #33288) [Link]
<quote>The diverse Linux ecosystem is one of our best defenses against this.</quote>
See, I'm not so sure thats right - most GNU/Linux distributions are essentially copies of the same original source trees, with a few patches applied here and there. Having a look at this page: http://lwn.net/Alerts/ and looking at the package name and the date cluster would seem to suggest that this is the case.
CVE-2010-3433 was a postgresql security issue that has caused debian, ubuntu, redhat (and therefore centos) and mandriva to release new versions of their packages.
Alternatively, if you statement was "The diverse Unix ecosystem is one of our best defenses against this." then that might be more correct, but even then, I understand that there is some cross platform code/library re-use, which I suspect would lead to cross-platform vulnerabilities.
Schneier on Stuxnet Posted Oct 8, 2010 6:53 UTC (Fri) by nlucas (subscriber, #33793) [Link]
Different systems have different default compiler options, compiler versions, different libc patches, different library versions, different kernel versions, different file-systems (very important for root-kits), have or not selinux enabled, and I'm only talking of the low-level stuff.
Add to this different user ways of re-configuring the system, without a single unique API for this.
For example, you can use ioctls to enable promiscuous mode on a network card, but there is no single way to do the same across linux distributions modifying a configuration file so that the change can be preserved across reboots.
The same for making your malware code to be automatically run on start. How to do it? cron? anacron? upstart? sysvinit? inittab? directly modify grub/lilo to run it on start? and what if it is grub2?
Schneier on Stuxnet Posted Oct 8, 2010 9:42 UTC (Fri) by eru (subscriber, #2753) [Link] There is more that one method different distributions use, sure, but not an unlimited number of them. For those hypothetical "weapons-grade" malware writers behind Stuxnet, it would be no problem to prepare for the 4 or 5 most common ways of doing things. (For instance, "supporting" the last two versions of both RHEL and SLES would probably cover most corporate Linux installations). They might also have obtained intelligence that would permit limiting their target to just one Linux distribution, and a particular version of it.
Schneier on Stuxnet Posted Oct 8, 2010 11:11 UTC (Fri) by nlucas (subscriber, #33793) [Link]
Right. But still an order of magnitude more complex than just 2 or 3 window versions, with much more compatibility between them, with maybe the exception for 32- and 64-bit window versions, if they use kernel exploits.
Now if they really are of the "state-sponsored" black hats type, off course everything can be done with more or less difficulty. Including the possibility of the forged SSL certificates validating fake popular sites.
Schneier on Stuxnet Posted Oct 8, 2010 11:52 UTC (Fri) by nix (subscriber, #2304) [Link]
Given that stuxnet used multiple forged certificates to do its job, and that when one was invalidated it was replaced with a new one the next *day*, yes, I'd say forged certificates are well within the reach of the stuxnet authors.
Schneier on Stuxnet Posted Oct 8, 2010 12:07 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
forged certificates or stolen certificates (there is a _big_ difference between the two)
Schneier on Stuxnet Posted Oct 8, 2010 20:01 UTC (Fri) by foom (subscriber, #14868) [Link]
Well, they used stolen certs.
But, since it seems highly likely to have been written by a government, I fully expect the authors also have the ability to create new valid certs. They probably just a) didn't want to be identified by using a properly issued CA-certificate, or b) didn't want to get their stolen CA certificate revoked, when they could just use some other random low-value certs they stole.
Schneier on Stuxnet Posted Oct 8, 2010 21:03 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
if they were using fake certs it would point pretty directly at a small subset of organizations that would have the capability to create such fake certs.
stolen certs on the other hand could be stolen by anyone, and with the number of infected windows machines out there, there's no real reason to think that a government has any more ability to steal such certs than any botnet worm organizer.
Schneier on Stuxnet Posted Oct 8, 2010 12:54 UTC (Fri) by adren (guest, #20906) [Link]
The Unix biodiversity vs Microsoft monoculture is one element that gives an advantage of Linux over Windows but it's by far not the only one.
This is even one key argument to debunk Linux as being superior in terms of security to say that if it would have 90% market share, then it would be the target from viruses and other malware.
Here is a short list of why Linux is more secure than Windows:
- The peer review aspect gives not only the capacity to look and find bugs, but also one doesn't have to wait until an editor delivers a patch (much better reactivity -> see the ping-o-death example). This also means that there is no "security through obscurity")
- A complete and integrated installation/update facility with the package manager that covers most if not all software needs also means that corrections are pushed directly and much more rapidly to the users
- Usually, one doesn't have to carry on a huge list of unnecessary software (usually related to the graphical interface), especially for servers or embedded platforms (and this is even more so with SCADA environment)
- The "security through diversity" issue doesn't only mean that Linux distributions provide a different ways to integrate software while they often share the same base.
Last but not least: security is a process, so when I have the choice of one OS that was built from the ground up with the security in mind (including most applications) and another that was built for single user purposes with appealing features and userfriendlyness (usually in direct contradiction with security), then I would choose the former especially for an embedded/SCADA system.
Schneier on Stuxnet Posted Oct 8, 2010 13:28 UTC (Fri) by halfpast (guest, #70519) [Link]
I don't think comparing Linux to Windows is appropriate in this instance. The attack was a targeted one, with (allegedly) a lot of manpower behind it, not some dude in the Netherlands portscanning networks all day.
The lesson to be learned here is that, ultimately, security is about risk management. One can only react to 0-days. Resources (in the most general sense of the word) can be expended to improve one's security, but security is never guaranteed. In a battle of attrition, the side with the most resources will eventually win.
Schneier on Stuxnet Posted Oct 8, 2010 19:30 UTC (Fri) by cmccabe (guest, #60281) [Link]
> <snip discussion of apt-get>
A lot of the systems that were infected by this attack were not connected to the Internet, and therefore, not receiving updates at all. The administrators didn't think it was necessary because the software wasn't on the network, and it was doing what they wanted it to do.
> Last but not least: security is a process, so when I have the choice of
OpenBSD is probably the only mainstream OS out there that was built from the ground up with security in mind. Linux can be reasonably secure, but only if the system administrator knows what he's doing and applies security updates regularly. We definitely do need better ways of sandboxing processes-- in this regard, systems like Android are actually ahead of Linux on the desktop.
Schneier on Stuxnet Posted Oct 9, 2010 23:18 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
OpenBSD? Are you joking? It's insecure as hell and is quite badly engineered.
If you are searching for real secure OS then try QNX in its minimalistic form. It's pretty much impenetrable (mostly because it's very modular and basic modules are audited to hell and back).
Symbian also has a good security model, though it's largely irrelevant.
If we move from the realm of mainstream OSes, then we also have KeyKOS, AS/400, and so on.
Schneier on Stuxnet Posted Oct 10, 2010 1:32 UTC (Sun) by RCL (guest, #63264) [Link]
What is the basis for the statement that "OpenBSD is insecure as hell"? It maintains quite good security record.
Schneier on Stuxnet Posted Oct 10, 2010 1:33 UTC (Sun) by mfedyk (guest, #55303) [Link]
"OpenBSD? Are you joking? It's insecure as hell and is quite badly engineered."
Can you be more specific and provide links? everything I hear about openbsd is that it is a very security focused organization. many times to the detriment of other considerations like scalability.
Schneier on Stuxnet Posted Oct 17, 2010 10:02 UTC (Sun) by jzbiciak (✭ supporter ✭, #5246) [Link]
Whoever wrote Stuxnet was targeting a particular PLC setup, which implies they had some good intelligence about the site. I imagine finding out what distro a site's using (should they be using Linux) wouldn't be too difficult on top of that.
Schneier on Stuxnet Posted Oct 8, 2010 9:55 UTC (Fri) by epa (subscriber, #39769) [Link]
The article notes that "It primarily spreads via USB sticks". Has any Linux distribution ever been vulnerable to USB-stick worms? Auto-running programs from an inserted disk or USB stick seems like the kind of moronic practice that Windows is so good at and Linux usually avoids.
Schneier on Stuxnet Posted Oct 8, 2010 10:03 UTC (Fri) by niner (subscriber, #26151) [Link]
Autorun is not the only way to spread a virus via USB stick. Pretty much the same can be achived by putting a prepared image file on the stick that targets some vulnerability in one of the image processing libraries. Common desktop environments would probably be infected by simply opening the folder the USB stick got mounted to because they would try to show some thumbnail. Once infected, it would write similar image files to any connected stick.
Schneier on Stuxnet Posted Oct 8, 2010 16:09 UTC (Fri) by blackwood (subscriber, #44174) [Link]
You could go one level below and craft a corrupted filesystem that attacks the kernel filesystem driver. Autodetection/automount then take care of running your exploit as soon as the usb drive is plugged in. There's a reason why the paranoid check their fs-drivers with images that are randomly changed in a few spots ...
Schneier on Stuxnet Posted Oct 9, 2010 20:42 UTC (Sat) by error27 (subscriber, #8346) [Link]
My linux distribution asks "Do you want to run the autorun file?" That's what windows vista does too. It makes me laugh that people actually thought adding a prompt would slow down the spread of viruses.
I live in Africa. All the computers here are infected with USB viruses. One of the things that the viruses do is create .exe files that match every directory on the USB disk. You can easily click on them by mistake. It would be better if USB disks were mounted with noexec.
I saw another USB virus that used over ten exploit vectors. It created .mp3, .pdf and avi files and a bunch of others. And if you click on any of them then you'll be infected. And people *do* click on them all the time.
Even if you secured all the above, you could still infect people through filesystem bugs as others have mentioned. A lot of the bugs found in the "Month of Kernel Bugs" were filesystem bugs.
Really the main thing that Linux has going for it in terms of viruses is it's smaller market share. It's possible to secure a Linux system but it's sort of complicated. For example type: "mount | grep home | grep nosuid" If you didn't see any output then your computer is probably vulnerable to attacks from local users.
Schneier on Stuxnet Posted Oct 10, 2010 0:38 UTC (Sun) by bgmarete (subscriber, #47484) [Link]
I agree. So, shall we say that security is a FAIL all round?
How hard is this problem really? This is quite interesting. When lwn publishes newly announced vulnerabilities in Linux everyday, one can't help but wonder how many more an operation like the one that produced stuxnet don't bother to reveal.
Is there any coherent theory of security within Computer Science that at least theoretically deals with these problems?
Its quite intolerable, this situation. As long as it persists, there surely can be nothing like Software `Engineering'.
Schneier on Stuxnet Posted Oct 10, 2010 1:40 UTC (Sun) by RCL (guest, #63264) [Link]
I don't think that security should be treated THAT seriously. For me, sacrificing usability to gain more security is just paranoid.
The ultimate security is just denying the user any freedom - limiting them to whatever operations the device was designed for (think consoles and/or ATMs).
I don't want the same on general purpose computers (they are general purpose for a reason).
Schneier on Stuxnet Posted Oct 10, 2010 12:42 UTC (Sun) by Wol (guest, #4433) [Link]
You're confusing maths with science.
It's "trivial" to prove a system is secure (I use the word trivial in its mathematical meaning).
Only snag is, there is NO WAY you can prove that the maths matches the real world - in other words any proof of security is worthless. And unfortunately, THAT statement is an absolute ... (that's why we have engineers - their job is to get the maths and technology as close to agreement as possible).
And anyway, even if you're trying to do that "trivial" mathematical proof, you rapidly hit what kills nearly all attempts - it's called "the exponential explosion" - any proof would probably take longer than the universe has been around to actually do the calculation.
Cheers,
Schneier on Stuxnet Posted Oct 14, 2010 9:50 UTC (Thu) by dgm (subscriber, #49227) [Link]
There's certain truth in what you say, but it is not very well expressed.
One of the things mathematicians do best is stating all the conditions needed for some mathematical contruction to be true. That's why mathematics can be, and are, useful: because we now exactly what conditions have to be met. We use mathematics successfully in physics, chemistry, etc, all very real world disciplines. If you have proof that some software is secure, it's very useful indeed. The wit is that such proof is only good as long as the required conditions are met. In a world where conditions are out of control, any proof about the software is of little use. Fortunately that's often not the case (yes, processors can malfunction and bits can flip espontanously in RAM, but such things can be usually detected, and often corrected, to the point where probability is insignificant).
And by the way, the exponential explossion only applies to mechanical verification, not the one done by hand, thanks to our hability to abstract.
Schneier on Stuxnet Posted Oct 10, 2010 19:07 UTC (Sun) by error27 (subscriber, #8346) [Link]
(I audit kernel code, but I'm not really a security guy so probably this post is nonsense).
If you run a uranium enrichment plant then you should just hire an expert
People have developed a bunch of new exploit fighting tech. Address space randomization, non-executable stacks and fortify source all make exploiting buffer overflow more difficult.
I liked David Wheeler's idea of not allowing control characters in filenames. It makes writing exploits a tiny bit harder and so it's a step in the right direction. I don't think there is a single complete solution, but maybe once we've implemented a partial solution we'll think of the rest later.
Every programming language has a standard way of handling SQL so that you don't get SQL injenction bugs. Why isn't there something like that for calls to the shell?
One thing is that Linux needs better sandboxing tech. The google guys have implemented sandboxing for Chromium on Windows but on Linux the distributions all handle security in non-standard ways. It seems like sandboxing will be important in the future.
Also there is a hardened version of Gentoo, but I'd like to see a hardened spin of something more mainstream.
Schneier on Stuxnet Posted Oct 14, 2010 8:11 UTC (Thu) by nhippi (subscriber, #34640) [Link]
Considering the current linux kernel track record (most recent: CVE-2010-3301), it is implausible to believe that the even the upto-date current kernel wouldn't have unknown vulnerabilities.
Stuxnet team exploited 0-day holes on windows, so likely they would have managed to do the same on linux.
And most industrial systems do not have upto date kernels.
Schneier on Stuxnet Posted Oct 8, 2010 6:39 UTC (Fri) by BackSeat (subscriber, #1886) [Link] Getting nefarious code onto the target system would be hard to do without leaving some trace. However, if you wanted to have control over the compromised system for longer, I'd suggest putting a sacrificial "virus" on it. The virus is found, removed, analysed, and its effects unwound. Everyone's happy: the compromised system owner crosses "fix virus" off his todo list, and the attacker crosses "explore sending two viruses, one much better hidden than the other" off her todo list.
Schneier on Stuxnet Posted Oct 8, 2010 8:46 UTC (Fri) by Lennie (subscriber, #49641) [Link]
Zero-day exploits can be used more than ones, they can be used over and over again until someone actually does an analysis and publishes it (or discloses it to the vendor) and the vendor actually releases a fix.
If something breaks and people suspect a subsystem was exploited and do a clean install, they might disable the subsystem. That doesn't mean someone was notified and actually took the time to analyse it all.
After that it is as useful as a normal exploit, you can only use it for systems which did not get an update (or had a quickfix/workaround applied).
And trust me, not everything is up to date out there.
|
|||||||||||||