University Learns About IoT Insecurity The Hard Way

A sneak peek of Verizon's Data Breach Digest, which is supposed to be published in full in March, revealed that an unidentified university had its own Internet of Things (IoT) devices hacked and turned into a botnet. The university's IT team laid out some of the hard lessons it learned during this whole incident that will help it prevent other botnets from taking over the university's IoT infrastructure again.

What Happened

The affected university used all sorts of IoT devices--smart light bulbs, vending machines, fridges, etc.--to improve convenience and management efficiency. Then, when students complained about their internet connections not working properly, the IT team discovered "over 5,000 discrete systems making hundreds of DNS lookups every 15 minutes." Nearly all of those systems were on the network dedicated to the university's IoT infrastructure.

The IT team realized that the IoT devices used weak, default passwords that were brute-forced as the botnet spread from device to device. Luckily for the IT team (and the university's accounting department) the affected devices didn't have to be thrown out. The attackers used an insecure HTTP connection to update the device's passwords, which allowed the IT team to intercept them and take back control of the compromised IoT gizmos.

Lessons Learned

Following this incident, the IT team learned a few lessons about the mistakes it made, which it hopes not to repeat in the future:

Keep Networks Isolated

One of the university's biggest mistakes was keeping all the insecure devices on a single network. This made them more vulnerable to attack by anyone with access to that network; setting up multiple networks could have made it harder to compromise all of the devices. (Though at least the IoT devices appear to have been kept separate from other networks, which likely mitigated the potential impact the attack could've had on other systems.)

"Don’t keep all your eggs in one basket; create separate network zones for IoT systems; air-gap them from other critical networks where possible," warned the university's IT team.

Not that setting up multiple networks is a magic bullet. Ultimately, it's best to make sure each and every device is secure.

No Direct Internet Connection

Another easily avoided issue was the fact that all these devices had direct internet connections. This isn't a good idea for all IoT devices, especially if an internet connection isn't strictly necessary, because connecting them to the internet at large means exposing them to attack from anywhere in the world. Devices that can be managed locally should be managed locally--this simple maxim could help prevent many potential attacks on IoT products.

"Don’t allow direct ingress or egress connectivity to the internet; don’t forget the importance of an in-line proxy or content-filtering system," said the IT team.

Change Default Credentials

The majority of IoT devices come with default credentials and don’t ask users to set new ones up. This a grave mistake, because it means that even institutions such as universities that have their own IT teams can make the mistake of leaving most of the devices with the default password intact.

"Change default credentials on devices; use strong and unique passwords for device accounts and Wi-Fi networks," recommended the university's IT team.

This is too much of a security responsibility to be given solely to the IoT device customers. One simple user interface change, such as asking the user to change the original password, could solve this. However, the customers themselves do take part of the blame for not changing the credentials as well.

If the IT team of the university had changed the credentials, this botnet takeover would have likely been avoided. The issue still remains that it’s far too easy for too many customers to make this mistake, though, and it falls on the manufacturers to fix this type of vulnerability.

Monitor Events/Disable Insecure Features

Insecure connections such as Universal Plug and Play (UPnP) and Real Time Streaming Protocol (RTSP) should be disabled. The network traffic should be monitored for threats and other vulnerabilities in the system as well.

Always Update

Regular software updates tend to fix the majority of IoT security problems. The university's IT team recommended that administrators should keep an eye on manufacturer websites for new patches. However, it would also be preferable for critical security fixes to automatically install when they're released. It would also help if software updates were released more often--most IoT devices are updated a few times a year, and manufacturers stop supporting them after just a couple years.

Securing IoT Devices Will Become Critical

IoT devices clearly need better security. Less clear is how to convince manufacturers and their customers to care. Perhaps some baseline security regulations, a security rating system, and enforced recalls could help, but those aren't guaranteed solutions. Manufacturers trying to squeeze as much technology for as low a price as possible into their products--and the people buying those products--might still view security as an afterthought.

This problem should be addressed before smart-but-insecure devices become increasingly popular and reach more critical infrastructure. These same vulnerabilities in self-driving vehicles, heart rate monitors, traffic management systems, and others could endanger people's lives instead of merely inconveniencing a university's students and IT staff.

Create a new thread in the News comments forum about this subject
This thread is closed for comments
Comment from the forums
    Your comment
  • Achoo22
    The second bullet point is especially amusing to me: revert Internet of Things devices to just plain Things.
  • 2Be_or_Not2Be
    What I find amusing is that the university probably offers a degree program in IT, possibly even in IT Security. Yet they didn't apply what they were probably teaching.
  • bloodroses
    "The IT team realized that the IoT devices used weak, default passwords that were brute-forced as the botnet spread from device to device."

    #1 rule to security: never use the default password on devices. That part is common sense and should not even need to be taught. If they at least changed the passwords to something much more complex, it would have been much harder for the botnet to brute-force... lol