An Easy Way for Hackers to Remotely Burn Industrial Motors

Wired posted a interesting article on another car hack. This relates back to the concern of  securing the internet of things meaning protecting anything with a IP address. Using https://www.shodan.io/ and searching for sensitive systems that should not be accessible online shows us that this is still not the case. The original post can be found HERE.

HACKS THAT CAUSE physical destruction are so rare they can be counted on one hand. The infamous Stuxnet worm was the first, causing physical destruction of nuclear centrifuges in Iran in 2009. In 2014, Germany reported the second known case of physical destruction involving a furnace at a steel mill. Both of these attacks required extensive knowledge to pull off. But now a researcher has found an easy way for low-skilled hackers to cause physical damage remotely with a single action—and some of the devices his hack targets are readily accessible over the Internet.

The hack focuses on variable-frequency drives that control motors operating fans and pumps in water plants, mining operations and in heating and air conditioning systems. The drives are digital devices used to set and maintain the electrical frequency fed to the motors to control their speed. These motors in turn control things like water pumps, rock-crushing systems and air-compression equipment.

Reid Wightman, a security researcher with Digital Bond Labs, found that at least four makers of variable-frequency drives all have the same vulnerability: they have both read and write capability and don’t require authentication to prevent unauthorized parties from easily writing to the devices to re-set the speed of a motor. What’s more, the variable drives announce the top speed at which motors connected to them should safely operate, allowing hackers to determine the necessary frequency to send the device into a danger zone.

“All of the drives have a protection setting which says, ‘This is a dangerous speed to run the motor.’ They call it the ‘critical speed,’” he says, “the speed at which the motor’s shaft begins to vibrate.”

Wightman, who is presenting his findings today at the S4 conference in Miami, Florida, says vendors include this setting intentionally in the device’s registry so operators will always know the top speed-limit for motors. But he says the devices reveal this critical speed to anyone who queries them. They use the Modbus protocol to communicate, and a hacker can send a simple query to the drive’s control board to obtain this critical information then use it against the device.

“I would ask why they need to make this setting writeable over a network protocol. Why would an operator ever need to change this setting? That’s not something you would be changing while the device is running,” Wightman says. “It’s something you might change when you swap out the motor but not when it’s operating. Somebody thought it was a good idea.”

Causing a motor to run at or above critical speed can do considerable damage. The vibrations could destroy bearings and the motor shaft. “It’s an easy thing to attack, but it would be hard to figure out what went wrong with the motor, if it was a manufacturing defect or bad luck that caused the motor to fail,” Wightman added.

It might be possible to determine what went wrong if a facility maintained logs that record speed settings and changes; but critical infrastructure and industrial facilities seldom maintain extensive logs, according to a study of industrial control systems done by an academic at Washington University in St. Louis.

Wightman looked at motor drives made by four companies: Schneider-Electric, Allen-Bradley, ABB, and Vacon.

“All four vendors have the same exact problem where they have this critical speed variable that can be read and written to, so the drive can be changed to turn at critical speed,” he says. Ironically, Vacon, a Finnish company, is the same one that manufactured frequency converters used at a uranium enrichment plant in Iran that Stuxnet targeted. Those particular devices, however, operate at a much higher frequency than the ones Wightman examined; they also have export controls on them because they can be used in nuclear facilities.

Wightman purchased a consumer-grade Schneider-Electric Altivar 12-variable-frequency drive to test in his lab. He didn’t conduct physical tests on the other brands but examined their user manuals to see that they have the same write capability and vulnerability. He examined Allen-Bradley’s PowerFlex 7000 series, ABB’s ACS 500 drives, and Vacon’s X4 models.

He said he did not disclose the issue to any of the vendors.

“What are they going to do about it? They designed it to work this way; they purposely went out of their way to make this critical speed readable and writeable with no authentication. They know what they’re doing,” he told WIRED.

None of the vendors responded to a query from WIRED before publication.

Vendors wouldn’t be able to fix the problem with a simple patch. Instead they would have to re-architect the systems to add authentication capability, which would also mean writing a new protocol for them to communicate. Doing so, however, would eliminate backwards compatibility with devices already in the field. “You would have to update the devices and all the software,” he notes.

“We’ve been pushing on this for a long time in the control system world. We need to get away from these insecure protocols. Everyone is like, ‘Well, yeah, the protocols are insecure, but you need a lot of knowledge to do something [to exploit them]. And this is one that doesn’t require a lot of knowledge.”

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.