Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

Encourage better product design

Encourage better product design 

Electric skateboards apparently open up new commuting possibilities, presumably when there is no snow on the ground. At least one vendor uses a bluetooth remote control. As Wired magazine explained, “Richo Healey was riding his electric skateboard toward an intersection in Melbourne, Australia, last year when suddenly the board cold-stopped beneath him and tossed him to the street. He couldn’t control the board and couldn’t figure out what was wrong. There was no obvious mechanical defect, so being a computer security engineer, his mind naturally flew to other scenarios: could he have been hacked? It didn’t take long to determine that Bluetooth noise in the neighborhood was the likely culprit.”

Healey subsequently teamed up with Mike Ryan, another security researcher, to develop an exploit they call FacePlant. In summary, they can intercept the unencrypted BlueTooth communication with a laptop, take control of the skateboard, and stop the board or put it into reverse. According to the vendor’s web site, the Boosted skateboard is capable of travelling at up to 32 km/h. It is not difficult to imagine the implications of unanticipated brake application at that speed; FacePlant sounds about right.

In addition to the obvious security mistake — an unencrypted bluetooth connection — it is difficult to understand why a product one balances upon would be programmed to stop abruptly upon losing connectivity. Cars are not designed to activate brakes when the gas pedal is released, or even if the engine is turned off. If removing one’s hands momentarily from a motorcycle handlebar resulted in a high rate of deceleration, riders would die. Somewhere in the transition from mechanical to digital controls the concept of a reasonable response has been lost.

Last month, the United States Food and Drug Administration (FDA) advised health care facilities to discontinue the use of Symbiq drug infusion systems. According to the FDA, the pumps “could be accessed remotely through a hospital’s network. This could allow an unauthorized user to control the device and change the dosage the pump delivers, which could lead to over- or under-infusion of critical patient therapies.” While they are not aware of any “patient adverse events or unauthorized access of a Symbiq Infusion System in a health care setting,” an intrusion could obviously result in serious harm.

According to the ICS-CERT advisory, the product contains several vulnerabilities including giving “unauthenticated users root privileges on Port 23/TELNET by default,” accepting, “drug libraries, firmware updates, pump commands, and unauthorized configuration changes from unauthenticated devices on the host network,” and using hard-coded accounts.

A medical device manufacturer might assume that products will be deployed on a secure closed network, and a skateboard manufacturer might not consider communication security a priority. These devices were certainly not intended to be Internet-connected. But they contain the types of vulnerabilities that will plague the Internet of Things if better approaches and standards are not developed.

It is easy to criticize developers of insecure products and label them as negligent, incompetent, or apathetic toward security. But it wasn’t long ago that mainstream IT products such as routers and switches were configured using telnet instead of ssh. FTP is still commonplace in corporate networks despite sending credentials across the network in the clear. Many products still use unencrypted HTTP to access sensitive administrative functions. And tftp, lacking any security whatsoever, is still commonly used for firmware updates and to configure devices such as VoIP phones. More secure open source alternatives such as SSH, SCP, SFTP, and HTTPS have been freely available for more than a decade, yet protocols with obvious security deficits are still in use.

Outdated insecure protocols have no place in today’s products. Default passwords should not exist. Products must respond gracefully when communication sessions are lost. Instead of criticism after the fact, developers and purchasers both need easily understood security standards to help avoid common security pitfalls and encourage better product design.

Have a security question you’d like answered in a future column? Email

Related posts