Langner says it isn't a bug, so don't expect vendor patches-- details on Stuxnet research #cyber #stuxnet #langnercommunications

From Ralph this morning: (bolding by your humble editor)

Press release – for immediate release


Langner Communications sees increased threat level as Stuxnet analysis progresses.


Ralph Langner, who successfully analyzed that Stuxnet is a directed attack against industrial control systems sees an increased threat level as the analysis of Stuxnet progresses. Langner points out that not only security researchers will analyse Stuxnet but also the underground.

The analysis that Langner has conducted shows that it is not technically difficult to inject rogue ladder logic into PLC programs.

It is important to understand that this vulnerability cannot be considered a bug, either technically or legally, so it should not be expected that vendors would be able to release a “patch”. Langner expects that exploit code for this vulnerability within several months in the known frameworks such as Metasploit.  

While Langner does not assume to see an attack as sophisticated as Stuxnet soon, he points out that the Stuxnet story will raise a lot of attention in the hacker community where people may now start to try using the attack vector for much less trivial motivations than we must assume for the Stuxnet writers. Langner suggests equipment vendors, asset owners and integrators start developing strategies to cope with this scenario quickly.


Langner Communications GmbH

Fossredder 12, D-22359 Hamburg, Germany

~~~ 1988-2008: 20 Years Langner Communications ~~~



Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • <p> OK, let's keep this in perspective: What STUXNET did was to attack the STEP 7 development environment and to insert some new library routines.  In the office software world that would be like looking for a Microsoft Studio development environment and modifying some key program libraries. </p> <p> Then, when the developers or integrators downloaded a new version of the software, the rogue code was inserted in to the PLC program. The numbered function programs referenced by this rogue code are not known, though Ralph has made some intelligent speculation about it. I completely agree with him that this had to be a very precisely targeted attack. </p> <p> Back to reality, there are many Integrated Development Environment (IDE) packages for many platforms.  Authenticating the code in the foundation libraries is something that I have heard of only among the most paranoid installations. Almost nobody does it. People authenticate entire installation programs, but past that, I've never heard of anyone authenticating a working IDE or an HMI.   </p> <p> Yes, this measure is possible. But is it practical? How far should our paranoia go for protecting our infrastructure?   </p>


  • <p>on this at the <a href="">ThreatSTOP blog</a>.</p> <p>The thing that worries me is that now the techniques are (relatively) public which means that it isn't just national cyberwarfare teams that can exploit this but also cyber criminals - and they are likely to be far less cautious about accidental side-effects.</p>


RSS feed for comments on this page | RSS feed for all comments