Tag Archives: Integrators

Revisiting copycats and Stuxnet

Posted on by

As I read Kim Zetter’s “Countdown to Zero Day” I was reminded of the copycat discussions that seemed sparked by Ralph Langner’s warnings (see pp. 182-183).

“Langner suspected it would tie just six months for the first copycat attacks to appear. They wouldn’t be exact replicas of Stuxnet, or as sophisticated in design… but they wouldn’t need to be.”

“[Melissa] Hathaway, the former nationals cuber security coordinator for the White House… told the New York Times, ‘We have about 90 days to fix this before some hacker begins using it’.”

Did we have copycats? Do we have copycats?

Off the top of my head, I can’t think of any I would call a close copy cat. That doesn’t mean there aren’t any, but if there are, they are still virtually unknown.

However, we should recognize that some threat actors seem to have learned what I consider the most valuable lesson from Stuxnet: Engineering firms, ICS integrators and ICS software vendors are high value targets.

Stuxnet attackers apparently went after after the computers at NEDA and other ICS integrators to get access to Natanz. This means the attackers had access to engineering details necessary to create highly-specific and customized attacks. It also means that the attackers had access to the ICS networks themselves (via engineering lap tops at a minimum).

When we think of Stuxnet, we think of Natanz — but broaden your view. What other projects had NEDA and the other targeted ICS integrators worked on? Stuxnet and its cousin code (Duqu etc.) was/is all over Iranian (critical) infrastructure.

Back to the copycats thread. Look at Havex. The parties behind Havex certainly targeted ICS integrators and support providers ( via Trojanized software from eWon and MBConnectLine). So in 2014 we saw a copycat of a key concept. And I would fully expect to see more ICS vendors, integrators, and engineering firms targeted by ICS-seeking malware in the near future.

So, if you operate critical infrastructure, consider the following questions:

  • Who are your ICS integrators?
  • Who is providing maintenance to your ICS?
  • What security policies and procedures are you requiring of those parties?

If the answer to these questions is buried in layers of subcontracts, and all you know is “that your control systems work” chances are there’s not a lot of security oversight going on. Good luck when the next copycats arrive.

Alms for the cyber poor: municipal water industry

Posted on by

The other day I was investigating a presentation by hackers of foreign origin. Their slide deck, which included references to finding Internet-connected SCADA, presented a screen shot of an HMI.

Old Boston City Hall

Close examination showed it belonged to a water treatment facility in the USA. I was concerned that it could mean attackers had gained access the the HMI over the Internet.

I looked up contact info for the water department at the municipality and shot off an email. I didn’t expect to get any response, as previous attempts with other organizations in similar situations had proved fruitless.

I was surprised when I got a call from the municipality’s IT director. Woot! Someone cared!

Most munis, and water in particular, are under-funded and under-staffed. Security is about bottom of the list. Simultaneously confirming, and dismissing my stereotype, the director told me that her very position had previously been a “parking” spot for policemen who needed something to do (AKA couldn’t be fired).

She thought that it might very well be a breach, and promised to look into it. Later that day, I got another call, this time from a plant engineer, who reported that the system integrator had posted numerous HMI screenshots of their plant to the public Internet — including the one in question.

He believed this to possibly be a breach of the NDA under which the work was done.

In some ways it was a relief. In others it was disconcerting.

Lessons learned:

  • There are munis that care
  • There are water people who care
  • Watch out for the integrators
  • Hackers of foreign origin are looking

Zetter and Stuxnet: Why ICS integrators and asset owners should care

Posted on by

It is exciting to see Kim Zetter tell a compelling story of Stuxnet for the masses: Countdown to Zero Day.

I had the opportunity to speak with her at the RSA conference this past Spring. I had just presented some interesting (free and open source!) research on Stuxnet. You can read about my RSA presentation here. While I have yet to read Zetter’s book, she has definitely gone beyond my work in many ways.

Sanctions announcement from U.S. Embassy in Iran

To correspond with her book’s release, I’m posting some interesting, but lesser known points on Stuxnet:

  • A 2004 strategy paper from a senior fellow at The Washington Institute proposed the following U.S. strategy for countering Iran’s nuclear ambitions (his other suggestions are also shockingly accurate):

introduction of destructive viruses into Iranian computer systems controlling the production of components or the operation of facilities;

 

  • Symantec said there were five target companies. Zetter names four (NEDA, Behpajooh, Foolad Technic, Control Gostar Jahed). Symantec must have known their names, but has never divulged them publicly.
  • The U.S. government had been tracking one particular Iranian ICS integrator, NEDA, for literally years as NEDA allegedly obtained embargoed goods through a global procurement network
  • NEDA was public about its Stuxnet infection problem
  • The State Department sanctioned NEDA for its involvement at Natanz after Stuxnet was “over” (sanctions announced in Dec. 2012) — which to me essentially confirmed that NEDA could have been the vector for perhaps both understanding Natanz ICS, and delivering Stuxnet — and its cousin code — to their objectives.

Conclusion: Based on these revelations of how Stuxnet “got in”, if I were a control systems integrator (especially one that supported military installations or capabilities) operating in the West, I would be very concerned about my own internal systems, and the control systems I was building for my customers.