Stuxnet-derived malware found infecting SCADA makers Organizations involved in the making of systems that control oil pipelines and other critical infrastructure have been infected with malware directly derived from the Stuxnet worm that targeted Iran's nuclear program, security researchers said. Parts of newly discovered malware are almost identical to Stuxnet, and were written …
"Duqu .. appears to be on a stealthy reconnaissance mission that sends intelligence data and assets to a server using encrypted and plain-text web protocols"
Who in their right mind connects industrial control machinery to the Internet. Don't bother answering, that's a rethorical question. Lastly lets have a contest of how long someone could talk about malware without mentioning Windows.
"Lastly lets have a contest of how long someone could talk about malware without mentioning Windows."
Let's not. I have personally disinfected a Linux system which had weak SSH passwords successfully guessed using automated software, an instance of which I found in the infected system, which was then used to guess SSH passwords on other random hosts. Compromised Linux servers are, I gather, commonly used as command and control hosts for much larger Botnets, mainly comprising compromised Windows PCs.
Whichever OS you use, securing it is a challenge for the administrator, not helped by sterile "my OS is better than yours" arguments.
Funding various Afghanistan guerrilla groups which turned out to include Osama Bin Laden and the Taliban.
I'd guess various assorted anti Castro Cubans who got into the US drugs trade around Miami.
I've always been impressed how the US has embraced the Moslem philosophy of "My enemies enemy is my friend"
Duqu might mean Duquesne University, a private cathcolic university here in the states (dont know why choose that name) . This looks like Stuxnet's older creepy brother acting like an APT running quietly through the networks. My theory the sucess of Stuxnet has given new form to this badboy to keep a trigger finger and valuable infastructure intel on any other Nation state to give the US and Israel leverage on energy negotiations...just a crazy thought.
...is probably the most likely suspect, donning my tin-foil hat for a moment. They have been caught red-handed operating intelligence operatives in many ostensibly "friendly" countries - ref the passport scandal a few months or a year or so ago whenever it was.
Then there was the Israeli intelligence interference that only came to light in NZ recently.
As for US involvement? Possibly, who knows. The US is so closely involved with Israel that they share the same bloody intestinal flora.
to whoever thought this one up.
It's about time someone sorted out the real Bad Boys and "the industry" started to tie it's own IT laces. We've put up with crap systems for far too long, (Linux penguin brains are you listening and you too MAC funboyz ?), maybe someone not in redmond will design something that works, well, as well as Stuxnet for a f'in start.
Alf
OK, this sounds like a dumb question, but here goes to all of El Reg's readers who actively manage these Windows-based SCADA systems:
Why have these systems:
(A) not been patched to remove the compromised certificates and known vulnerabilities that suntex used?
(B) used on networks where odd traffic to unknown IP address is not throwing up warning bells left right and centre?
A) Not all the time. I know of several systems running old SCADA software.
Some cannot get the latest windows patches as they are not guaranteed by the SCADA manufacturer (I mean the ones who write the executables like GE, Wonderware etc, not the integrators) to work without stopping some part of the SCADA system from working as its an old version of the software. The SCADA software cannot be upgraded as the newer one doesn't link to some third party software which is the only link to some outdated bit of kit that no one supports any more. Some are on very old operating systems too (like Server 2000) which has the same upgrade problems and no windows patches.
And then there are sites where the customer doesn't care about patching the boxes as nothing has changed in their factory unless it wears out and gets the like-for-like treatment.
B) While integrators advise customers that sticking things on a network isn't a good idea and they should be using a decent firewall, they still do. And even if they do take precautions, that nice meaty firewall could be hacked too.
Further to AC's answer -
bear in mind the control systems themselves are not actually windows based PC's, but rather PLC's. These PLC's are programmed using a PC. The virus infects the PC's that are used to program these devices, then modifies the PLC project file stored on that PC so that the PLC does not run as intended and damages the equipment. This incorrect project code is then later downloaded to the PLC by the engineer unknowingly.
The PLC does not need to be connected to the internet, and often will not be (although sadly not often enough). This unfortunately does not stop infection - instead the PC's used to program the device must never be connected to the internet, in fact the project file must never be stored on a PC that is connected to the internet. Short of providing every employee with two machines, one for email/web access and one for programming, and a server kept on a separate closed network for storing the code, this is difficult and costly to achieve. Besides, up until last year there was never thought to be a risk and therefore a need to do just this.
PLCs are probably one of the few things that won't get a virus. However they are usually plugged into PCs, for an HMI, and these days its by Ethernet which can also be used to program it. Gone are the days of a special cable/port for programming. Both a plus and a minus.
The connected HMI is often on the network (always someone wanting collect data on another site).
So keeping the PLCs code on a separate machine would require hacking the integrator as well as the site. Not impossible if you have a specific Target.
Something making it easier is the HMI being on the same network as the PLC programmer back at the integrator (many try to be a DCS by sharing the PLCs database with the HMI tag database). If you catch them back during development.
@GavinC: "up until last year there was never thought to be a risk and therefore a need to do just this".
"Did MS Blaster crash the power grid?, Robert X. Cringely Aug 22 2003"
http://www.infoworld.com/d/security-central/did-ms-blaster-crash-power-grid-696
"Slammer worm crashed Ohio nuke plant net, Kevin Poulsen Aug 2003"
http://www.theregister.co.uk/2003/08/20/slammer_worm_crashed_ohio_nuke/
DuQu and Stuxnet shouldn't necessarily be considered part of the same family; Stuxnet was a very specialized worm with multiple exploits for propagation and an incredibly clever rootkit that attacked a very, very specific model of PLC.
Duqu, on the other hand, is a very well designed trojan with a generic payload that consists of gathering information about the system it is sitting in, however, no one knows how it gets there, so it might be part of a worm-like dropper.
The reason they are related is because Stuxnet and DuQu share certain code; consider it a "core module", if you will. It handles (and consists of) plenty of functions such as decryption of keys, injection, etc.
Duqu is that, very slightly modified, and Stuxnet was that with SCADA modules (quite possibly designed by a different dev team) attached to it.
As for DuQu's attack on industrial controller manufacturers being ridiculous, it's worth pointing out that the US army, in particular a base that was used to pilot Predator drones, was recently hit by a mafiawars-oriented credential stealing trojan. Had that been a worm like stuxnet, except attacking CsLEOS or modifying the software used to control the drones, things would have been problematic.
Airgaps and all the procedures armchair experts are mentioning are great, brilliant in fact, but in theory it is very hard and expensive to set up a so-called secure system, and additionally, it is still going to be vulnerable to certain attacks, anyway.
But then nobody is saying who it is targeting, so maybe that tells them enough to have some confidence in the statement. I certainly think it would be foolish to release it on Iran and then expect the Iranians wouldn't try to turn it back on us.
It isn't using the same certificates as Stuxnet (which were quickly revoked), but is using the same approach as Stuxnet (stolen or rogue taiwanese certificates to sign the driver) to make it 64bit compatible and the installer hasn't been recovered until now so they don't know how the infection propagates yet.
Most of the PLC's run on arm and or risc processors .
The scada software is only a window or human machine interface to the plc software.
The plc software should be hard locked ( ie on the plant processor),and no virus can affect
the process.
For the virus as such ( which is not arm native ,it is windoze) to be effective it has to be able
to modify the operational code ( write to memory) ,or write to an address of a process variable,which usually isnt possible as if physical security is in place.
The scada software in question is retricted by the plc code ,and if written correctly cannot override safety level plc code ,if the safety function has been implemented ,which is a standard requirement in all 1st world countries .
All hype and conjecture ,except where the appropriate standards are not applied.
Because that's not how things like this work. You can't just cut and paste bits of ASM code and modify them that easily.
If you've ever coded in assembly, you'd realize that coding something like reasonably advanced malware would be incredibly difficult to write from scratch.
Additionally, the evidence suggests they were both compiled from C, using the same type of compiler.
We could also bring in the stolen cert from Taiwan, something Stuxnet also did, the same poor CnC communication methods, etc.
If someone else did it, they took extreme care in mimicking Stuxnet and the style of the original authors. It's possible, but why bother?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
