How Stuxnet was deciphered | Hacker News Reader

How Stuxnet was deciphered

wired.com

267 pointspaulsilver71 comments

"On June 17, 2010, Sergey Ulasen was in his office in Belarus sifting through e-mail when a report caught his eye. A computer belonging to a customer in Iran was caught in a reboot loop — shutting down and restarting repeatedly despite efforts by operators to take control of it. It appeared the machine was infected with a virus."

I am curious as to what in Stuxnet code and/or the client computer caused this. From the rest of the article, Stuxnet went to great lengths to stay undetected. Anyone has clues ?

most worms have an 'installed' marker somewhere on the system. the loader will check the mark and if not present, will install and reboot. my sense is that the marker wasn't being set properly resulting in this bug.

I had the same bug in a worm I wrote. I was storing the marker in the local user part of the registry, which was being loaded from the domain controller, so the bit wasn't being retained.

This is easily the most interesting article i've read in the past 6 years.

I really enjoyed it as well. It provides enough technical detail while still being accessible. Some of the analogies are a bit of a stretch, but you'll have that.

I was disturbed by the implication that the researchers should stop investigating Stuxnet (or refrain from publishing) because of the possibility that it was a US or Israel covert op. There are so many problems with that reasoning, and I'm glad they weren't swayed by it.

Will you still hold that opinion if Iran develops and uses nuclear weapons?

That would moot the point, no?

Not sure if this is a username troll, but at this point many people had the stuxnet code, so all that would have happened if they didn't publish their findings is that it would have increase the risk to our power plants because it made it more accessible to the people that are actually in the position of defending our power plants, whereas enemy clandestine intelligence agencies would have the motivation to analyse the code anyway and re-purpose it for an attack.

Furthermore, even if Iran does make WMDs, they do not pose a serious threat to Israel or the United States. Their delivery systems (missiles/rockets) are very antiquated and can be reliably intercepted and a suitcase nuke has extraordinary low yield. And even if they somehow gain the capability to effectively use their WMDs they would not do so due to MAD.

Mad is the argument against nuclear war when the actors are somewhat reasonable. What happens if you get unreasonable actors that don't really care who dies, their countrymen and themselves included. At that point, we are totally screwed. I would be surprised if these type of people don't exist. Lets hope they never get near a nuclear weapon.

Somehow Kruschev, Stalin, and friends were not crazy enough. It's easy to call someone a nutjob. It's hard to know what it's like to face the sober realization that you could, if you wanted, end human life on earth.

I'm relatively comfortable with corrupt politicians in control of nuclear weapons. Their motivations are clear and predictable.

You cannot say the same of True Religious Believers.

This is incredibly naive. A simple ship sailing into NY harbor could easily deliver a nuclear weapon, even if it was large and unrefined. This is especially the case for a U235 gun-type (ie Little Boy) weapon, which requires relatively little sophistication.

And even if they somehow gain the capability to effectively use their WMDs they would not do so due to MAD.

Nobody would fly airplanes into a buildings because human beings want to live, right?

Yea it was weird that the author kept bringing that up when none of the people in the story had thought about it or seemed to care.

absolutely!!

I agree. This is definitley a good read and kept me want to read it all. I usually skim read most articles but this made me want to read the whole article.

exactly. It is the kind of thing you expect from a Hollywood movie, except it actually happened. And with a Mossad/NSA angle to boot!

As software now sits between pedal and brake and cars are beginning to be increasingly connected should we expect to see more assassinations performed this way?

Google now has a fully-functional driverless car and at least one US state has approved their use on the road.

Who needs polonium when you can send a virus out to seek a car?

The potential to murder with computers has been around for a while already. Governments are just waking up to it. To use the classical example: imagine hacking into a hospital network and changing a patient's blood type...

scary thing (imo) is that computer hacking is (compared to what you would otherwise have to do) so low cost and low risk that now "unknowable" assassinations (i.e. difficult or impossible to tell if the death was an accident or not) are within reach of everyone ...

I disagree.

One, you must have the knowledge of how to hack that specific car's ECU. You must know the make, model, and exact ECU of the car.

Two, you have to actually be familiar with reverse-engineering ECUs to begin with.

Three, you need special equipment to connect to an ECU diagnostically, let alone in a way to reprogram it.

This adds up to a lot of hassle, and greatly limits the number of people who have the skills to pull this off. Who would develop this method but a government with the time/manpower to create and test it? And, if the government wants you assassinated, why would the government allow a real/accurate investigation anyway?

It would be far simpler to create a small microcircuit to play havoc the the ECU, than to hack the ECU. But, even then you'd primarily just lose mileage (and a mechanic would quickly locate it).

That requires physical access to the car.

like script kiddies doesn't learn all that to just deface websites already....

Unlike a website, a car requires access to a physical, proprietary interface to embedded components. You must craft an attack to the interface and ECU.

And there are chips that can have their memory permanently burned into them (I don't know if ECUs use them, however). Patches are impossible, but there's no risk of infection either. Just test it rigorously first.

>Unlike a website, a car requires access to a physical, proprietary interface to embedded components.

That's not necessarily true.

For example, my car's ECU can be reprogrammed using the instrumentation bus. The instrumentation bus can be accessed using the wires that interface with the CD changer. That means that the audio system is on the same network as the ECU -- and if I had a Bluetooth adapter, that'd likely be on the same network as well.

Indeed, researchers can disable electronically controlled brakes via Bluetooth: http://www.technologyreview.com/computing/35094/?ref=rss&...

>Patches are impossible

I've had to take my car in for patches a few times. Where there is software, there will be patches required.

At the end of the day, I doubt we will be seeing assassinations via car hacking. But I wouldn't call it impossible.

exactly. and even more worrisome, on-start shenanigans is tied to all kinds of sensors on your car. and it has a data connection. 24/7.

I can't stand OnStar for those exact reasons, especially the GPS/data-connection.

What I meant about it being impossible to patch the ECU was, if they used one of the single-write chips to store the firmware it couldn't be hacked/patched except by being replaced, or possibly manipulated from the inputs.

> Indeed, researchers can disable electronically controlled brakes via Bluetooth

That I didn't know. That's a major security problem, and another reason I'm glad for my 9 year old car.

A friend of mine worked at a company that made diagnostic computers for cars and he managed to brick a BMW that required an engineer from Germany to fix the issue (an upgrade of the BMW's firmware was interrupted by the power going out, leaving the car's computer in an inconsistent state).

i don't like "you must have the knowledge of how.." based arguments. how expensive is this knowledge? bored undergrads at good to decent schools learn enough to pull this kind of thing off given a few K in bootstrap money.

organized crime has both the will and the funds to do something like this. so could an independent person... you're talking $50-$75k and 6 months of a persons time to figure out how to delete someone without anyone even thinking it was murder?

the advantage of "hacking" the ECU is that by making changes in software you can make changes that can't be detected by a mechanic or by a vigilant pre-drive screen of your car. after i read the autosec.org paper my first thought was "this is dumb, it requires physical access to the car to pull off, i already have that, i can perform hundreds of other types of physical sabotage to make the car crash. nothing new here."

a few weeks later i realized "wait a minute, if i make a change in software, it can theoretically remain undetected forever before i activate it. also, nothing the operator does to find it could work. also, if i die in a wreck on the freeway that looks like i just lost control of my car, will the state police rip apart the wreckage, find the ECU, and verify that it hasn't been tampered with? will they know how to? will they even think to do that? and even then it wouldn't matter because the software could erase itself from permanent storage just-in-time..."

there are a lot of advantages and i think the barrier to entry is a lot lower than you say it is.

Perhaps the barrier is lower.

But understand my position: I am not an advocate of automated cars, or even highly computerized cars. The more computerized the car becomes the more points of failure it gets, whether that be a dropped internet/GPS connection, a hardware glitch, or "cosmic rays" (which got the blame for the Prius brake issues).

It takes significant developmental effort to hack the ECU. And if you don't want the changes to be detectable by mechanics or a prescreen drive test, you need to be especially cautious in your changes. You must disassemble and analyze the ENTIRE codebase of the ECU to determine where you want your changes to reside, then pack it back in.

A simple countermeasure is to let the mechanics look at the ECU version checksum. Standardize the checksum across the model, with subsequent patches being listed as a different version number. Then the mechanic checks with the official manufacturer's guide and you know if there's a problem.

You are sounding paranoid.

Physical security is always the first, and most effective barrier. If the interface were better secured digitally, it wouldn't take a genius to access the ECU's circuitry and wire an extension. But again, it takes significant investment.

If the ECU is modified to accelerate at maximum speed at some random moment, the only thing necessary to defeat it is switching into neutral and pulling off the road! The range of destructiveness the ECU can cause is limited, though it can rack up your repair bills.

Crime syndicates usually buy shares in the local police force. If you meet a mysterious end in a car accident the investigation would be tampered with regardless of the method used to kill you.

Theory is wildly different from reality.

Quite a bit of the knowledge is out there. An enterprising Finn has reverse engineered much of the network that runs my Saab:

http://pikkupossu.1g.fi/tomi/projects/projects.html

And for the special equipment, that's not always the case -- my car's engine controller can be reprogrammed by tapping into a few wires on the CD changer harness in my trunk, and that's likely to go unnoticed by me, my mechanic, the police, you name it.

Interesting.

But again (see my other response to a similar statement), theory is wildly different from reality.

The ECU controls things like fuel-oxygen ratios, how much the throttle is open, etc. Steering, braking, and the transmission are almost strictly physical/mechanical interfaces.

Unless you drive a Prius, or like system where the brakes are digital, you can counter a sudden, massive acceleration with your steering, brakes, and by turning the car off—no matter what the ECU wants.

The applicability of this kind of sabotage for murder/assassination is limited.

>The applicability of this kind of sabotage for murder/assassination is limited.

Possibly. But I'm not sure I'd react all that well if, while driving in the middle of the night, my lights suddenly went out, my stereo started playing music at full volume, and my throttle went wide open.

And that's all a possibility on my 2003 car -- newer cars are moving towards doing much more with software. And where there's software, there will always be viruses.

> And where there's software, there will always be viruses.

Agreed.

I just hope that the car manufacturers will take developments like this into account, and make these systems very robust.

You know, that's the first good reason I've ever heard for me getting a tattoo.

AFAIK a bedside test is always done before a transfusion, simply because the records cannot be trusted even without malicious intervention (and a test is pretty easy to do).

It's a complex attack vector for a simple problem. If you have enough access to tamper with the software, why not just remove the cap from the brake fluid reservoir? It's faster than figuring out how to access the PCM [1] (to tinker with the throttle code) and less likely to fail.

And it would be catastrophically poor planning on the part of car designers to make car firmware remotely modifiable. We're not talking about general purpose computers here.

[1] http://en.wikipedia.org/wiki/Engine_control_unit

Except that the target may discover the leak, and the lack of ability to brake; newer cars will warn when the fluid pressure is low. Switching the car to first gear to slow could get the driver out of immediate danger. I think the emergency brake uses a wire that is directly connected to the brakes.

However, I do presume that the victim is paying attention to their vehicle and not in a sudden emergency condition.

It's a vector, however, that needs no physical access to the car. It can be launched remotely from another country.

Who would have thought a centrifuge could be attacked in this way?

> It's a vector, however, that needs no physical access to the car.

Are you sure about that? I can't imagine they'd put these autonomous driving systems on the network... Didn't Stuxnet itself require at least physical access by proxy in that it was propagated through USB drives being physically used in the victim's systems?

Many cars have Bluetooth support.

All it takes from there is the engineer putting the powertrain bus/ECU on the same network with the Bluetooth adapter.

As I posted below, my Saab's engine control unit can be reprogrammed by splicing a few wires onto the CD harness. That means the audio network can at least access the ECU. I don't have a Bluetooth adapter on my car, but if I did, I'd wager it can access the audio network...

Good point. I'd hope the regulatory system will require that systems that can make the car move be totally isolated from any other systems, but who knows.

...Assuming it works as advertised, there are some handy features, including the ability to remotely lock and unlock the car, fire up the climate control, see how much gas is in the tank, look up in Google Maps where you left you car, and check if the lights are on.

http://www.reghardware.com/2011/07/06/review_cars_volvo_s60_...

Nissan Leaf[1], TomTom Live Traffic, GOOG(maps)...

[1] http://seattlewireless.net/~casey/?p=97

> And it would be catastrophically poor planning on the part of car designers

Why? I'm sure they don't like recalling their cars every couple of months to fix a bug, and customers don't either.

Car firmware developers know the exact hardware, needs, and uses in every case. Think about where most bugs come from: people doing things the developer didn't expect. Cars don't have many inputs, and those few inputs don't have many possible values.

It turns out cars are catastrophically poorly planned then. Check out http://www.computer.org/portal/web/csdl/doi/10.1109/SP.2010.... -- they found they could cause the engine to stop, or the brakes to come on individual wheels by hacking the internal car network (Canbus).

> It's a complex attack vector for a simple problem. If you have enough access to tamper with the software, why not just remove the cap from the brake fluid reservoir?

Actually, depending how integrated are the subsystems in the car, one could just create a specially crafted MP3 and leave a CD or USB stick in the victim's car. This MP3 would work like the JailBrakeMe pdf and essentially put the victim's computer in the hands of the attacker. It's been done by security researchers, but I can't find the reference now.

That's not what bothers me about software being used in important physical systems like the brakes of a car. What bothers me about that is not knowing anything about how that software was developed or tested, the amount of rigor that went into it, etc. All software has bugs but the laws of physics don't.

I always liked this talk by Bruce Dang at 27C3 (December 2010), telling (part of) Microsoft’s side of the whole Stuxnet saga: http://www.youtube.com/watch?v=73HlkCI-GwA

The article made me remember of this virus I've heard about. Supposedly, it was accessing a rotation media (harddisk, floppy disk? I don't remember) in different patterns and monitoring the failure rate for each pattern. Then it would keep accessing it in the pattern that caused most errors which would kill the hardware device - as the errors were supposedly from resonances caused by movements of the reading heads and would cause physical stresses in the device.

Anybody else heard about that?

Commodore 1541 FDD, but it was serviceable.

ps: also similar was setting "unfriendly" scanrates for unprepared CRT-s, Samsung notebook HDD "click of death".

memoryhole:

https://secure.wikimedia.org/wikipedia/en/wiki/Commodore_154...

though my all time favourite is the ping

Wasn't that the sort of thing Tsutomo Shimomura specialized in? I remember it being hyped as part of the danger of Kevin Mitnick's hacking into his systems.

I enjoyed reading along about this on the Langner blog during late last year and early this year.

He was often the first to break news about new understanding in the PLC related code, and at the time was given very little credit for it. Yet without him it would probably have taken a LOT longer to get to the bottom of this.

If you want an example of an interesting post from his blog: http://www.langner.com/en/2011/02/22/intercept-infect-infilt... Here he talks about a nice attack vector, that seems obvious if you have access to bits of the postal infrastructure in Germany...

And: http://www.langner.com/en/2010/11/15/417-attack-code-doing-t... Here he talks about the man in the middle attack, which meant that the PLCs reported back correct frequency/speeds to the operators, whilst doing something nasty underneath.

I'm waiting for a good book to come out that details all of the stuff in this attack. It's pretty stunning work.

The whitepaper: http://www.symantec.com/content/en/us/enterprise/media/secur...

http://vimeo.com/25118844 is a really cool video that helps explain a lot of the same information about the virus. Not as technical, but it is still very interesting.

I saw this video back when it was first uploaded, very interesting video and well done

It's funny that the US is spending so many billions of dollars trying to sabotage Iran's economy and nuclear plant, when the country poses zero threat to the US, and the US faces enormous fiscal challenges.

When I write funny, I mean utterly tragic, wasteful and a result of a relentless propaganda campaign which has resulted in every political candidate falling over themselves to prove how committed they are to facing down the menacing Iranian threat.

The propaganda is mutual. The US finds it convenient to have an enemy while Iranians are cowed into supporting the aytollahs for fear of US invasion. This is a dangerous kind of equilibrium.

Zero threat to US allies too?

Very interesting read. Although I would have preferred if they hadn't said the ending at the beginning of the article.

The difference between stories and technical papers is that stories leave the conclusion for the ending and technical papers put the ending at the beginning. The article seems to share a bit of both.

Have to agree with other posters - Best article I've read on Stuxnet - good job.

This is a particularly well-written article by Wired.

This is an extremely well put article. The series of events and the way that it was written kept me reading it to the end. It was a very interesting article.

I dislike these magazine articles posted online that are some 8 pages long and the entire first page is simply the hook, no real info. Sorry, I am not going to read you, espeically if I came to you not for a feature story, but for a piece of specific news info, e.g. "how stuxnet was deciphered."

Am I the only one who feels this way?

edit: not sure why opinion = downvoted.

Because it's lazy tldr; thinking. It's an extremely well-written article and there's a easily found view-as-one-page button at the bottom.

Dude you are a writer for Wired.com. I'm not surprised that you would bristle at my criticism.

You should look in to Instapaper if you find multi-paged articles distracting. There are other alternatives as well such as using the print page to see all of the text on one page.

multipage articles are annoying due to the multipage. usually there's a print option.

but don't think tl;dr.

next time try this http://www.readability.com/articles/1fyqqx1d

or instapaper. the design sucks indeed, suites paper format, not web.

I just finished reading the article via Instapaper on my Kindle. It's much nicer this way (sans photos).

Reply on news.ycombinator.com