Feeds

back to article Stuxnet worm slithers into China, heralds alien invasion

The infamous Stuxnet worm has reportedly begun spreading in China. The worm, which targets supervisory control and data acquisition (SCADA) systems, has infected "millions of computers" across the country, AFP reports. Local anti-virus outfit Rising International told the official Xinhua news agency that six million individuals …

COMMENTS

This topic is closed for new posts.
Thumb Up

And I shall

in the future explain everything technical by popping a balloon.

2
0
Grenade

As good as Prof Feinman's O-Ring failure demo for the Shuttle Booster...

Short, sweet and to the point.

A pump that should run only three seconds per the PLC programming proceeds to run continuously because of a Stuxnet simulant infection of the PLC.

0
0
Gates Horns

ZX81

I recall Sir Clive Sinclair's comment that you could run a nuclear power station on a ZX81 (Timex for our colonial friends).

If only the industrial giants of the world had stuck with that instead of bloody Windows.

8
0
Happy

He was quite right

You can control a nuclear power station using the processing power of your average digital alarm clock. :-)

0
0

Yeah...

You also used to be able to fly a passenger jet with no computers at all, I prefer to fly on the fully computerised modern ones. In the same way that I like my power stations to have modern monitoring and control systems that put data into databases rather than graph plotting paper rolls. etc. You can't do this with a z80!

1
1
Anonymous Coward

"processing power of your average digital alarm clock."

But definitely not Windows !

2
0

Nay...

I would rather fly in a plane powered by ZX81 rather then one powered by Windows.

But that's only me, I guess.

1
0
Silver badge
Headmaster

Personally...

I like the ones with jet engines. How do you *power* an aircraft with computers - throw them out the back for the reaction?!?

1
0

The title is required, and must contain Pirates and/or Ninjas.

Throwing computers out of the back of an aircraft is likely to get a reaction from the chap/chapette responsible for cleaning the runway.

Not sure their reaction would be helpful in this case!

0
0

cant do that with a z80?

Actually, you probably could, but you would need a few of them.

z80's go all the way up to 50Mhz these days, and if you put in a ASIC, you could probably get much higher than that.

0
0

plane.

Just make sure you dont land hard enough to wobble the ram pack!

0
0

windows worm

lots of newspaper articles mention that siemens machinery is targeted, but neglect to mention it is a windows worm. and....

Q: And these have been patched by Microsoft?

A: The two Privilege escalations have not yet been patched.

5
0
Silver badge
Thumb Up

Boom & Bust

Pricking a balloon pops the bubble.

1
0

re:Boom and Bust. Please clarify.

Does this mean that the 'big swinging dicks' of Wall Street are no longer Masters of the Universe and are, in fact, nothing but a useless bunch of pricks?

0
0
Silver badge
Grenade

Chyrstal Clarity and NEUKlearer Transparency to Boom and Busted

"Does this mean that the 'big swinging dicks' of Wall Street are no longer Masters of the Universe and are, in fact, nothing but a useless bunch of pricks?" .... Jimmy 1 Posted Sunday 3rd October 2010 08:40 GMT

Yes, Jimmy 1, but they can be put to Good Beta and Better Virtualised Use as Remote Controlled Proxy Slave Units to AIReProgrammed SCADA Server Core Architecture. ....... which you might like to consider IS, and is Running as a NeuReal and SurReal Universal World Order Program ....... and IMPertinent Civil CyberSpace Project which Programs the Modernisation of Interceptions too ....... http://wiki.openrightsgroup.org/wiki/Intercept_Modernisation

I trust that is not ambiguous nor confusing.

And No, there is no opt in or out choice .........so everyone is blessed with ITs Powers of Control and Benevolence. And all who would feel Cursed by IT would immediately need to review their decidedly dodgy position and self-centred and selfish mental state.

0
1
Silver badge
Thumb Up

Best. FAQ. Ever

The F-Secure FAQ really is a good read. Some choice excerpts:

"Q: Which factory is it looking for?

A: We don't know.

Q: Has it found the factory it's looking for?

A: We don't know."

...

"Q: Has the stolen certificate been revoked?

A: Yes. Verisign revoked it on 16th of July. A modified variant signed with a certificate stolen from JMicron Technology Corporation was found on 17th of July."

...

But my favorites have to be:

"Q: How is that possible?

A: Good question."

...

"Q: Was Stuxnet written by a government?

A: That's what it would look like, yes.

Q: How could governments get something so complex right?

A: Trick question. Nice. Next question."

and, the clear winner:

"Q: Oh.

A: Yeah."

6
0
Bronze badge

My computer is infected

The virus is called "Windows 7".

1
0
Anonymous Coward

Could be worse...

Might have been Ubuntu...then you'd never get anything useful done.

1
2
Silver badge

Muddying the Waters ..... for Streaking ahead in and into a Beautiful Confusion

"This paper also introduces ".Net-Sploit" - a new tool for building MSIL rootkits that will enable the user to inject preloaded/custom payload to the Framework core DLL." ..... http://www.blackhat.com/presentations/bh-usa-09/METULA/BHUSA09-Metula-ManagedCodeRootkits-PAPER.pdf

Methinks MS.MIL is a more probable Covert Virtual Utility for SMART Machine Programmers and Operating Systems Analysts ...... Crack Hack Lode Code Teamsters.

Although one is never going to get anywhere, either far or important, down that path, for Pretty Good Privacy and Internetional Security Reasons ...... unless Teamster AIgents and Dark Matter Stars with Need to Know would need to know what one would know.

Israel though is a novel Red Herring See for US?

"In other words, changing the Framework requires administrator level privileges." .... And/or above administrator levels knowledge ..... Enriching Intelligence.

All Real Networks belong to Virtually SMART Remote Terminal Units ..... Polyamoral Intelligently Designed Entities.

1
2
Happy

Roof top garden.

I miss these comments from amanfrommars.

If you pick every second letter from the above, you get a smashing recipe for lentil soup.

1
0
Gold badge
Boffin

A Z80 is good enough for a civilian jet engine FADEC

As I was interviewed by one of the companies that tests them.

Their hiring test seemed to spend a lot of time asking forth type questions as well.

Deep embedded people into real time control have different priorities. The want *stability* and *known* bugs (with workarounds)

BTW the update cycle on the engines for the Saturn rockets was roughly 50 updates a second. Engine control on a civilian engine is perfectly doable on a Z80. Its the throttle response on military engines that needs multiprocessors.

As for nuclear reactors their response time to load changes is measured in *days*. Anyone thinking that pulling a few control rods out is enough to goose the output is *very* mistaken.

1
1
Pint

*Most* of the f-secure FAQ is a good read

(c) 2010. Submitted 3:30 pm ish, Saturday.

*Most* of the f-secure FAQ is a good read.

Their ignorance of the field of process automation shows, however, when they fail to spot the real significance of myrtus.

Any insider with a clue would know that this almost certainly originated as a reference to "my RTUs", where an RTU is a "Remote Terminal Unit", which in this context is a remote device which the PLC program uses for IO which isn't directly attached to the PLC itself.

Now it may of course be that there is a play on words going on here, and that the significance is *both* the biblical one and the industrial automation one. But for a self-proclaimed expert (and a recently arrived one at that) on the subject to not spot the industrial automation connection just makes them look ever so slightly silly. In their defence, obviously f-secure are not the only ones that have failed to spot this, and the rest of their FAQ gets a good mark for effort.

Symantec's writeups on the subject are quite good too (that's not a sentence I *ever* expected to be saying).

But the best I've seen to date comes from Herr Langner, in particular the level of detail in the entry at Oct 1st, 11:00, shows Herr Langner's team (unlike f-secure and many others) has some credibility wrt process control.

http://www.langner.com/en/

F-secure, if you choose to update your FAQ after reading this, please do it nicely.

1
0
Black Helicopters

The one who decided to control

nuclear facility with any Windows based system, deserve to be shot.

1
1

Control?

The Windows systems are not used for control. According to F-Secure, there just used to program the controllers.

0
0
Alert

It seems...

that we don't take Linux seriously in the process control industry as an OS to run PLC programming and data acquisition programs. Care to list out Linux software that does this?

1
0
Silver badge
Go

"A centrifuge in a uranium processing plant"

But what would happen? That centrifuge is just throwing UF6 around (UF6? UFOs? Hmmm.. a possible link here?). Could the system make it rev up? Slow down? More action could be had by connecting the Siemens Control Machine to a mixer filled with frogs.

"Centerum Censeo" that Iran is fully within the rights granted to it by the NPT to build and run an Uranium enrichment plant for civilian purposes. Said purposes being verified by the IAEA which continually fails to find any diversion of nuclear material for military purposes etc. etc. etc.

0
0
Gold badge
Coat

@Destroy All Monsters

"But what would happen? That centrifuge is just throwing UF6 around (UF6? UFOs? Hmmm.. a possible link here?). Could the system make it rev up? Slow down?"

Enrichment centrifuges are *not* like the sort of thing you might imagine in a biology lab.

Their design spec is to run at constant speed for *decades* with the UF6 being injected in one part and the stratified flow (enriched and depleted UF6) are collected by different collection pipes.

Spinning the rotors up/down (either individually at random or worse yet *all* at once) wold likely cause bearing failure. What happens next depends on the rotor tech. If light weight and frangible they shatter inside the stainless steel outer casing. If not the casing gets battered and and one or more holes get punched in it release the UF6, resulting in the release of a heavy metal containing gas (never a good thing to inhale) which will release hydrofluoric acid when it hits water, including the water vapor in people's lungs.

All told such a release can cause quite a lot of mischief.

0
0

Infections vs target(s)

The distribution of infected PCs in various countries may only reflect the means by which the code has been distributed and does not necessarily correlate with the ultimate target(s). AFAIK, Siemens stated that they have not licensed any copies of their Simatic WinCC software for use in Iran and have not traded there for 30 years. Maybe Iranians all get their copies of Simatic WinCC from Bittorrent. That might also explain the infection rates in India and China.

2
0
Pint

Hmmm

It seems that the general consensus is "we dont know"

SO a hypothosise (sp)

Q: Will Stuxnet spread forever?

A: The current versions have a "kill date" of June 24, 2012. It will stop spreading on this date.

Now as the doomsday sayers nostradamus fans and the fact that the Mayan calender sops sometime in 2012 as well so maybe thats the date it yes stops Spreading right after sending all systems critical <<BOOM>>

1
0
Coat

@Z80 for FADEC (and what OS is in an S7 PLC)

TLDR fans, stop reading now.

Thank you once again for your input Mr Smith 19. However, on this occasion one particular bit of your reply deserves further comment. The comment about nuclear reactor timescales is afaik valid, and the comment about deep embedded people *should* be valid but, remarkably, some PHBs in positions of authority see different. However...

There is a *lot* more in a modern full authority digital engine control (FADEC) for an aircraft than a Z80 (or even a credible number of co-operating Z80s) could cope with, especially if you try to develop using the trendier languages for these applications (Ada or to lesser extent C++).

For a start, the chances of fitting a worthwhile amount of the currently required code and data in a 16bit/64kbyte address space are vanishingly small, and bank switching and similar techniques necessary to bodge extensions to the address space bring their own challenges.

Multi-precision integer and single precision floating point are required from time to time these days, and in the typical ~20ms cycle time the combination of essential input validation and actual control calculations required for the control loops would not be practical. The size of the data tables required is also surprising; high resolution lookup tables are required for all kinds of things (pressure, temperature, you name it) and these tables consequently are not small.

Part of the reason for this is that, driven by the need for best "mpg", modern jet engines have very little tolerance between the normal safe operating zone and the "whoops" zone (hence best to ignore the idiots Branson and O'Leary and their comments a little while ago re the safety of flying through volcanic ash clouds). This very limited margin for error makes accurate and timely calculations even more important.

It's only a couple of decades since analogue systems based on operational amplifiers and the like were considered adequate for engine control (usually in conjunction with a beatifully engineered hydromechanical system fundamentally based on springs and clockwork), and doubtless a Z80 could have replaced one of those controllers, but the economics of affordable flight mean those days are long gone.

Add the need for a language such as Ada (or, believe it or not, C++), and the whole thing just doesn't fit into a 16bit address space, although the full 32bits is far more than is necessary.

"Forth type questions"? Are you sure these are not related to Lucas Aerospace's legacy [= "stuff that works"] 1980s translated (not interpreted, not compiled) threaded-code language, which iirc was called LUCOL, and was eventually used on various chips from Texas 9900 (16bit) to M68K, including the first UK civil FADEC systems? It enabled extremely simple extremely compact control programs which were trivially simple (that word again) to design, document, code, verify, and test (in this business, simplicity should usually be an advantage). It's so old (and, sadly, obscure) that there's little evidence of its existence, though if you have access to SpringerLink (I don't) there is a paper whose abstract looks promising. It's flying lots of Rolls Royce civil engines from RB211 onwards, and a few others, but currently out of fashion in comparison with Ada, even though flying Ada requires either full trust in the compiler (yeah right) or far more testing using the compiler and chip in question than the PHBs like to pay for.

If FADEC really was doable on a Z80 it would be being done, as Z80s are well known, well understood, and well supported, not to mention its biggest attraction to the PHBs, cheap to implement. Other readers may not be aware that Z80s didn't die in the same era when the S100 bus died, Z80s simply moved elsewhere e.g. into ASICs into cellphone handsets, which meant that at one time not too long ago, Z80s were the world's most widely used microprocessor. Obviously handsets are a market now rightly dominated by ARM.

The same basic SoC ASIC techniques as are used in a handset are also used in an engine controller although obviously the engine-mount environment calls for rather different silicon fabrication techniques; you can't buy these chips at Maplin.

When the 16bit address space became a limitation (back in the 1980s) the replacement processors of choice were typically from the 68000 family. Some unlucky folks (others would say foolish folks) chose the short-lived Z8002.

Since then, PowerPCs have generally been a preferred target for quite a while, in large part because of performance per watt factors. Obviously other options are available.

Anyone starting from a clean sheet today (unlikely, cost of entry is too high) would do well to look at licensing an ARM design; one of the many reasons ARM do well in addition to performance per watt is that courtesy of predication (and the Thumb subset) they get excellent code density (less memory for a given application, or a more complex application for a given amount of memory).

http://www.springerlink.com/content/t5u58euk56dh89kx/

See also: Dolman, W.C., Parkes, J.P. "An Approach to Software for High Integrity Applications." The American Society of Mechanical Engineers. 82-GT-251 (1982)

(credit to heater @ http://forums.parallax.com/archive/index.php/t-109610.html for the ASME reference)

Now returning you to routine Stuxnet coverage...

If anybody knows what processor and OS are inside a Siemens S7 PLC I'd be interested to hear it. I have a vague recollection that the usual S5 models used iRMX as the core OS, which means they were using a mainstream Intel processor. But the iRMX may only have been the comms cards. Either way, contrary to what some folk seem to have been thinking, the PLCs themselves don't run Windows, but the PCs to which they are connected generally do run Windows, and that is the heart of the problem.

My coat is the anti-static one, smelling gently of aviation fuel.

[submitted Sun 19:05 BST]

1
0
Gold badge
Happy

AC@09:48

TL:DR was tempting.

"There is a *lot* more in a modern full authority digital engine control (FADEC) for an aircraft than a Z80 (or even a credible number of co-operating Z80s) could cope with,"

Well I was aware that more modern engines seem to use active clearance control and it was my impression that military engines have to handle a much wider and regular change in power levels.

especially if you try to develop using the trendier languages for these applications (Ada or to lesser extent C++).

"For a start, the chances of fitting a worthwhile amount of the currently required code and data in a 16bit/64kbyte address space are vanishingly small, and bank switching and similar techniques necessary to bodge extensions to the address space bring their own challenges."

I can say that Pratt & Witney have done quite a bit of work using the USAF 1750A architecture. This is a 16 bitter with a 64K address range (but the optional MMU gives you a whole 1MB to play with). It runs the whole Atlas V launch vehicle.

Multi-precision integer and single precision floating point are required from time to time these days, and in the typical ~20ms cycle time the combination of essential input validation and actual control calculations required for the control loops would not be practical. The size of the data tables required is also surprising; high resolution lookup tables are required for all kinds of things (pressure, temperature, you name it) and these tables consequently are not small.

In the case of the S

When the computer hardware is *so* coupled to the system other options become possible. Off hand the only one I can think of which would routinely exceed 16 bits would be pressures measured in Pa

If table look-up is a key part of your architecture then hardware support for table look-up would be a distinct option.

Part of the reason for this is that, driven by the need for best "mpg", modern jet engines have very little tolerance between the normal safe operating zone and the "whoops" zone (hence best to ignore the idiots Branson and O'Leary and their comments a little while ago re the safety of flying through volcanic ash clouds). This very limited margin for error makes accurate and timely calculations even more important.

A little unfair as engine mfgs preferred *no* exposure to dust clouds. The original exposure limits came form Chernobyl in the mid 80s. The improved efficiency you say FADEC systems gives would also mean they are better capable to actively compensate for performance loss (and report such) to the aircraft.

It's only a couple of decades since analogue systems based on operational amplifiers and the like were considered adequate for engine control (usually in conjunction with a beatifully engineered hydromechanical system fundamentally based on springs and clockwork), and doubtless a Z80 could have replaced one of those controllers, but the economics of affordable flight mean those days are long gone.

Add the need for a language such as Ada (or, believe it or not, C++), and the whole thing just doesn't fit into a 16bit address space, although the full 32bits is far more than is necessary.

Depends what you are using that address space for. The last generation Shuttle Main Engine controller was a Motorola 68000 using 128KB of code programmed in C. The SSME destroyed a number of propellant pumps and 200 atm combustion chambers during its development and during its start cycle requires valve opening measurement to the nearest degree (an encoder was misaligned by this amount. The chamber blew up). Its unmodified throttle range is 65%-109%

If you don't have to host the compiler on the target hardware you can use a pretty aggressive (read large, slow, architecture tuned and expensive) compiler to crunch the source.

""Forth type questions"? Are you sure these are not related to Lucas Aerospace's legacy [= "stuff that works"] 1980s translated (not interpreted, not compiled) threaded-code language, "

The usual term is "threaded interpreted" languages.

which iirc was called LUCOL, and was eventually used on various chips from Texas 9900 "

(16bit) to M68K, including the first UK civil FADEC systems? It enabled extremely simple extremely compact control programs which were trivially simple (that word again) to design, document, code, verify, and test (in this business, simplicity should usually be an advantage).

Echos CAR Hoare's comment about a language too simple for bugs to hide in.

It's so old (and, sadly, obscure) that there's little evidence of its existence, though if you have access to SpringerLink (I don't) there is a paper whose abstract looks promising.

Rockewll Collins seems to have gone a similar way. They developed an actual hardware stack computer architecture but not sure if they went with Forth or some in house design.

"It's flying lots of Rolls Royce civil engines from RB211 onwards, and a few others, "

which suggests it pre-dates even the 16 bit processors of the late 80's. The Z80 has been a popular forth target for some time.

but currently out of fashion in comparison with Ada, even though flying Ada requires either full trust in the compiler (yeah right) or far more testing using the compiler and chip in question than the PHBs like to pay for.

"If FADEC really was doable on a Z80 it would be being done, as Z80s are well known, well understood, and well supported,"

Sort of my point.

" not to mention its biggest attraction to the PHBs, cheap to implement. Other readers may not be aware that Z80s didn't die in the same era when the S100 bus died, Z80s simply moved elsewhere e.g. into ASICs into cellphone handsets, which meant that at one time not too long ago, Z80s were the world's most widely used microprocessor. Obviously handsets are a market now rightly dominated by ARM."

Zilog seemed to have licensed their IP fairly widely. They never seemed to have got a really *successful* 16 (or 32) bit design abter the z80 (but did better than the folk behind the 6502, whose performance did inspire the ARM approach)

The same basic SoC ASIC techniques as are used in a handset are also used in an engine controller although obviously the engine-mount environment calls for rather different silicon fabrication techniques; you can't buy these chips at Maplin.

Well the SSME controller needed both M68k's to be on the same *die* due to cross checking timing constraints. Definitely *not* getting that from Maplin.

When the 16bit address space became a limitation (back in the 1980s) the replacement processors of choice were typically from the 68000 family. Some unlucky folks (others would say foolish folks) chose the short-lived Z8002.

Since then, PowerPCs have generally been a preferred target for quite a while, in large part because of performance per watt factors. Obviously other options are available.

Anyone starting from a clean sheet today (unlikely, cost of entry is too high) would do well to look at licensing an ARM design; one of the many reasons ARM do well in addition to performance per watt is that courtesy of predication (and the Thumb subset) they get excellent code density (less memory for a given application, or a more complex application for a given amount of memory).

ARM would be a good idea and Thumb gives good code density.

0
0

anybody else remember ?

Back in the 80's or early 90's there were reports in the trade press about booby trapped printers, that were aimed at Vax minis. Supposed target was Saddam's electromagnetic enrichment plant.

0
0
Gold badge
Boffin

@Herbert Meyer

"Back in the 80's or early 90's there were reports in the trade press about booby trapped printers, that were aimed at Vax minis. Supposed target was Saddam's electromagnetic enrichment plant."

IIRC (It was a *long* time ago) the claim was that some printers firmware had been hacked to mis-print in a *very* specific way generating a highly distinctive pattern of EMI which (supposedly) could be detected by some US ELINT satellites to pinpoint the site.

Not impossible as an *idea*. Were US ELINT sat *that* sensitive back then? Could the mishap generate a code pattern *so* distinctive it could be picked up by a fast moving (lowish altitude) sat? Someone with a *much* better grasp of physics will have to answer that question. Obviously those who *know* the answer won't be telling.

0
0
Thumb Down

Cyber Super-weapons

Is that it? A weapon of mass mild inconvenience? The authors used up a top quality Windows zero-day for this?

They would have done better to bribe a cleaner in the target plants.

1
0
PPW

Not just one...

...they used FOUR Windows zero-days for this, according to the F-Secure FAQ...

2
0
Silver badge

Mary Celeste MetaDataBase Morph

“We were able to reverse engineer the [Stuxnet] code and monitor how it works,” McGurk says. “There have been individuals speculating on attribution and intent…. Our main focus has been on understanding the malware and putting mitigation in place – how to prevent the spread and how to protect the physical infrastructure.” ....... http://www.csmonitor.com/USA/2010/1003/Stuxnet-worm-Private-security-experts-want-US-to-tell-them-more/%28page%29/2

I very much doubt that any of that is true, such is the Stealth Defense System of an Incredibly SMART Programming and AIdDynamic Utility and Absolutely Fabulous, Fabless Facility.

And the Moral of the Magical Mystery Turing Tale .... If in Ignorant Range and Arrogant Fields, Prepare for Reign Clouds with AIMassive Powers of Colossal Crowd Control.

0
1

@ D.M.

Unfortunately Siemens only produce Windows based software. The PLCs themselves run their own OS but you have to create the software with Windows PCs and then use Windows PCs as the operator interfaces to the plant.

Security then depends on what operations are permitted to the logged-in user.

Maybe now Siemens may have a change of heart.

1
0
Joke

Hang on a minute...

They're running nuclear power plants and oil refineries on Windows?

Oh s41t oh s41t oh s41t !

Mine is the lead coat hanging from the entrance to a nuclear bunker.

0
0
Anonymous Coward

"Security then depends on ..."

"Security then depends on what operations are permitted to the logged-in user."

Unless you've been invisibly Stuxnetted, in which case there is no meaningful security?

1
0
Linux

Run Windows, get infected

Its still and ActiveX exploit and, I might add, regular users having the ability to install software. That really good windows security.

1
1
This topic is closed for new posts.