Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Industrial Control System Firms In Dragonfly Attack Identified

Unknown Lamer posted about a month ago | from the they're-in-the-grid dept.

Security 24

chicksdaddy (814965) writes Two of the three industrial control system (ICS) software companies that were victims of the so-called "Dragonfly" malware have been identified. ... Dale Peterson of the firm Digitalbond identified the vendors as MB Connect Line, a German maker of industrial routers and remote access appliances and eWon, a Belgian firm that makes virtual private network (VPN) software that is used to access industrial control devices like programmable logic controllers. Peterson has also identified the third vendor, identified by F-Secure as a Swiss company, but told The Security Ledger that he cannot share the name of that firm.

The three firms, which serve customers in industry, including owners of critical infrastructure, were the subject of a warning from the Department of Homeland Security. DHS's ICS CERT said it was alerted to compromises of the vendors' by researchers at the security firms Symantec and F-Secure. DHS said it is analyzing malware associated with the attacks. The malicious software, dubbed "Havex" was being spread by way of so-called "watering hole" attacks that involved compromises of vendors web sites. According to Symantec, the malware targeted energy grid operators, major electricity generation firms, petroleum pipeline operators, and energy industry industrial equipment providers. Most of the victims were located in the United States, Spain, France, Italy, Germany, Turkey, and Poland.

cancel ×

24 comments

Sorry! There are no comments related to the filter you selected.

Watering Hole Attacks (1)

Guano_Jim (157555) | about a month ago | (#47390645)

I hadda look this one up. [wikipedia.org]

Re:Watering Hole Attacks (0)

Anonymous Coward | about a month ago | (#47391745)

You should not have needed to, the name is self-explanatory. You lie in wait at a location where your target needs to visit, or is likely to visit.

Decentralize the power grid (0)

Anonymous Coward | about a month ago | (#47390653)

The only reason this is an issue is because we have a centralized power grid.
if we could provide energy with energy from our own backyard this wouldn't be an issue,
read more here:
http://insitenrg.com/energetic-bear-malware-targets-us-power-plants/

Re:Decentralize the power grid (2)

Nkwe (604125) | about a month ago | (#47390747)

Doing so is really hard if you need to move power between grids - which you probably do.

Re:Decentralize the power grid (0)

Anonymous Coward | about a month ago | (#47391753)

The only reason this is an issue is because we have a centralized power grid.
if we could provide energy with energy from our own backyard this wouldn't be an issue,

We DON'T have a centralized power grid. There are three large power companies in my State, along with at least 2 or 3 dozen smaller, more localized Co-Ops. Yes, they all tie into the same "grid", but power generation is not centralized and neither is control of "the grid" itself. When something starts fucking up on part of the grid, other parts disconnect from it, through a variety of mechanisms... many of which are physical.
Yes, some parts of the country are in bad shape, but it has less to do with "centralization" or "remote access" and far more to do with not having enough power generation to satisfy load... any major disruption in either the transport or generation causes issues because everything is already running near or at peak capacity.

OLE for Process Control (OPC) (1)

Anonymous Coward | about a month ago | (#47390793)

Good luck with securing that as a protocol. Might as well tape a 'kick me' sign on your back. When you are controling things that can kill people why is ease of use/development even a consideration?

Re: OLE for Process Control (OPC) (0)

Anonymous Coward | about a month ago | (#47391127)

Energy bitcoin!

Why can't the Swiss company be named? (2)

rduke15 (721841) | about a month ago | (#47390795)

So the Belgian and German companies can be named, but not the Swiss one? That seems strange.

Re:Why can't the Swiss company be named? (-1, Redundant)

Anonymous Coward | about a month ago | (#47390879)

We found the Belgian and German companies independently. The name of the Swiss company was shared in confidence, primarily to confirm our contention it was another small company with actually less of an impact than eWON or MB Connect.

We are in the process of getting the name from additional sources without restrictions and will publish it when we can. It should be out as should the ICS and energy sites that were redirecting.

Of course, it still is a mystery why US-CERT/ICS-CERT and the European CERTs don't mention any of the company names. The names would certainly be helpful if they wanted to alert asset owners that they may be compromised.

eWON, to their credit, posted an updated notice on their home page of the website breach. MB Connect and the Swiss vendor sites are still silent on the issue.

Dale Peterson
@digitalbond

Re:Why can't the Swiss company be named? (5, Informative)

Dale Peterson (3733417) | about a month ago | (#47390985)

We found the Belgian and German companies independently. The name of the Swiss company was shared in confidence, primarily to confirm our contention it was another small company with actually less of an impact than eWON or MB Connect. We are in the process of getting the name from additional sources without restrictions and will publish it when we can. It should be out as should the ICS and energy sites that were redirecting. Of course, it still is a mystery why US-CERT/ICS-CERT and the European CERTs don't mention any of the company names. The names would certainly be helpful if they wanted to alert asset owners that they may be compromised. eWON, to their credit, posted an updated notice on their home page of the website breach. MB Connect and the Swiss vendor sites are still silent on the issue. Dale Peterson @digitalbond

Re:Why can't the Swiss company be named? (0)

Anonymous Coward | about a month ago | (#47391567)

For all US ICS entities: get a US-CERT/ICS-CERT Portal and/or ES-ISAC account already to have access to this notices and the detailed information. You'd have been notified as soon as this info was available.

The 3 companies are named in alert ISC-ALERT-14-176-01BP.

As was already aluded to elsewhere, the Swiss company is not really an ICS company.

Re:Why can't the Swiss company be named? (1)

plover (150551) | about a month ago | (#47392907)

I was watching a TV show about Alaska, where some small town had their generator go out and they needed to fly in an engineer. In those tiny villages, the kind where an engineering degree means you can get a job somewhere else that can afford to pay you, remote monitoring and diagnosis is the only option they have. They had one guy in the town who had the keys to the building, knew to keep the fuel tanks filled, and could do some minor mechanical repairs to the system, but that was pretty much the limit of his capabilities.

Nobody in that town would be qualified enough to even understand those notices. Nobody there would likely know what software was being used, let alone visit the home pages of the company providing it. A town like that won't have the money to pay for monitoring services - they're going to be on a repair-only basis. And they're going to be the ideal consumers of a remote solution like the kind these firms are selling.

While this town may be a worst case scenario, it exemplifies the kinds of bad luck circumstances that would lead someone right into this risk, and CERT notices probably won't ever help them much.

Re:Why can't the Swiss company be named? (1)

ThatsNotPudding (1045640) | about three weeks ago | (#47400595)

Of course, it still is a mystery why US-CERT/ICS-CERT and the European CERTs don't mention any of the company names. The names would certainly be helpful if they wanted to alert asset owners that they may be compromised.

It's no mystery at all.

Smells fishy? (0)

Anonymous Coward | about a month ago | (#47390875)

Having only RTFS, this is what I can glean:

1. Three European companies were hit with malware.
2. Two of them are named, the third name 'cannot' be shared.
3. Symantec & F-Secure found the malware, then notify DHS.

Very, very strange sequence of events.

diz gun be gud! (0)

snemarch (1086057) | about a month ago | (#47390893)

Peterson has also identified the third vendor, identified by F-Secure as a Swiss company, but told The Security Ledger that he cannot share the name of that firm.

Well, HELLO there, internets!

It'll be interesting to see why that company could not be named. Banking, perhaps?

Boy (1)

Billly Gates (198444) | about a month ago | (#47391003)

It's a good thing none of these industrial controls require IE 6 with an unsupported OS with updates turned off requiring a live internet connection or anything stupid. For a minute that would imply mass incompetence

Water Treatment Plant (2)

tquasar (1405457) | about a month ago | (#47391037)

My employer had SCADA sent via a telephone line to some engineer at another location Walt had no idea how the plant operated or what the info he could see meant and could have started or stopped some equipment remotely. One of the telemetry techs allowed a contractor to shut down a 9 million gallon/day lake pump, not a good thing. There wasn't even a password.

Some things don't need to be on the Internet (0)

Anonymous Coward | about a month ago | (#47391557)

Some industrial-control systems simply should not be on the Internet at all.

If you need to control them remotely, do so with dedicated networks that never touch the Internet. You know those old copper wires that used to run the phone lines? Well, they still go to the telco's switching office. If you aren't using them for anything else, get with the phone company and have them directly-connected to another pair of wires at your remote-control facility. Then run your own encrypted/authenticated communications on top of that dedicated connection.

Back things up by using a secondary channel to authenticate certain commands. This secondary channel might be something as simple as having two responsible on-site employees turn two physical keys at the same time, with instructions not to turn the key until they are satisfied that the command was ordered by someone with the proper authority, much like they do (or used to do) in nuclear missile silos to prevent an accidental start of World War 3.

Sure, someone could tap into the physical line and try to listen in or inject commands, but "good luck with that" thanks to your encryption. You will still be vulnerable to a denial-of-service attack, but it's hard to stop a fiber, er, I mean copper-wire-seeking backhoe that is obeying Murphy's Law.

Oh, and yes, I'm aware that an "air gap" doesn't stop all attacks (*cough* Iranian centrifuges *cough*) but it makes things much harder on an adversary.

Wow this place is dead now (0)

Anonymous Coward | about a month ago | (#47391609)

14 comments on one of the nerdiest stories this side of Snowden. And what do we have next, a story about how fireworks work with over 100 comments. Pack it all up people, slashdot is officially dead for any sort of intelligent discourse.

ROTFLOL (0)

Anonymous Coward | about a month ago | (#47395513)

You came here for, what....INTELLIGENT DISCOURSE?!
In fairness, it DOES sometimes happen. But, Mack, quit crying. There are humans involved.

Against man's stupidity... (1)

folderol (1965326) | about a month ago | (#47391953)

... the gods themselves, contend in vain. The first time I heard of this, my instant thought was that it was utter stupidity to connect any industrial process to the Internet. Since then, every comment I've heard or seen from every source follows the same idea, so why is anyone still doing it?

The cost argument really doesn't fly. Can you imagine the firestorm of compensation claims when (not if) the first major disaster takes place?

Re:Against man's stupidity... (0)

Anonymous Coward | about a month ago | (#47392319)

The why is easy, Lack of expertise and cost cutting. You have component that need service and troubleshooting and it's a lot less expensive to do it remotely from india. Firmware update and the like does not need a tech on site and you see more and more of these updates that must be performe by manufacturer technicien or they wont support you. Combine that with compagnies that like to hire operators because they cost less and...

Re:Against man's stupidity... (2)

EETech1 (1179269) | about a month ago | (#47393413)

I use the eWon, and MBConnect devices all the time, one or the other goes in to every machine we build. They are VPN gateways with secure login so we can remotely work on a machine instead of having to immediately travel to it to check the slightest thing.

None of our customers leave the internet side of the device plugged in. Unless we are on the phone with them, and they are by the machine, it is unplugged. As an additional level of security, the device has a keyswitch connected to it that must be turned on to allow it to connect to the internet, just in case it gets plugged in.

Most devices are managed through the respective manufacturers applications via the cloud, so we just have to download their application, and log in, and it handles getting the keys, and establishing the secure VPN tunnel. It is possible to manage your own infrastructure, but I don't know of anyone who is large enough, or chooses to do it.

I put the eWon app on my brand new work PC, now I have to check if I got pwned the first day got my new Lappy:( The remote access apps are one of the few things that does not get installed on the VM. Connecting to the VPN, through the VM can really be a pain!

The MBConnect devices are really cool, they can even verify the entire system, and reload anything that does not match what is stored inside itself. Besides providing a huge obstacle for anyone wanting to Stuxnet the system, they allow a customer to replace a PLC with a spare, reboot, and have everything come back to normal, and they allow for easier updating of a whole system by passing the program to the MBConnect device, and having it apply the update locally.

Nothing more scary than flashing a PLC remotely, and rebooting it. If it doesn't come back online, you might have to take your Lappy, and leave on an immediate road trip!

Has anybody noticed... (0)

Anonymous Coward | about a month ago | (#47395499)

The EWON part is O-l-d?
As in January 30? And they have already addressed it?
As EWON users, we have had no trouble with it.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>