Week 14

Article 1:

Researchers show that IoT devices are not designed with security in mind

The research was performed by a team from application security firm Veracode for six up-to-date devices acquired in December and found serious issues in five of them. The tested devices were the Chamberlain MyQ Garage, the Chamberlain MyQ Internet Gateway, the SmartThings Hub, the Ubi from Unified Computer Intelligence Corporation, the Wink Hub and the Wink Relay.

All of these devices enable remote control and monitoring over the Internet of various home automation devices and sensors, including door locks, interior switches and power outlets. Most of them connect to cloud-based services and users can interact with them through Web portals or smartphone applications.

The Veracode team didn’t look for vulnerabilities in the firmware of the tested devices, but instead analyzed the implementation and security of the communication protocols they use.

The researchers looked at the front-end connections, those between users and the cloud services, as well the back-end ones—those between the devices themselves and the cloud services.

For front-end connections, they found that with the exception of SmartThings Hub, none of the devices enforced strong passwords. In addition, the Ubi did not enforce encryption for user connections, exposing them to possible man-in-the-middle (MitM) attacks.

For back-end connections the situation was even worse. The Ubi and MyQ Garage did not employ encryption, did not offer adequate protection against man-in-the-middle attacks and did not protect against replay attacks, which enable man-in-the-middle (MitM) attackers to capture traffic and then play it back, potentially triggering unauthorized actions. In addition, the Ubi did not properly secure sensitive data.

MitM protection was lacking across all devices with the exception of the SmartThings Hub, either because TLS (Transport Layer Security) encryption was not used at all or because it was implemented without proper certificate validation.

This suggests that those who designed these IoT devices assumed that the local area networks they’ll be installed on were secure. That’s an error, because research over the past several years have showed that if there’s anything worse than the security of IoT devices, it’s the security of consumer routers. Security researchers find serious vulnerabilities in routers on a routine basis, most of which enable hackers to perform man-in-the-middle attacks, and those flaws have resulted in millions of routers being compromised in large-scale attacks over the past few years.

The misguided trust of IoT manufacturers in the security of home networks is also reflected by the debugging interfaces and other services their devices expose to such networks.

The Veracode researchers found that the Wink Hub runs an unauthenticated HTTP service on port 80 that is used to configure the wireless network settings, the Wink Relay runs a network-accessible ADB (Android Debug Bridge) service, the Ubi runs both an ADB and a VNC (remote desktop) service with no password, the SmartThings Hub runs a password-protected telnet server and the MyQ Garage runs an HTTPS service that exposes basic connectivity information.

In the case of the Wink Relay and the Ubi, the exposed ADB interface can provide attackers with root access and can allow them to execute arbitrary code and commands on the devices.

While they didn’t directly analyze the security of the vendors’ cloud services, the Veracode researchers considered several scenarios, like what would happen if attackers compromised user accounts, intercepted connections somewhere close to the service—for example by compromising an upstream provider—or fully breach the cloud service. They concluded that the impact of such breaches could range from attackers gaining access to sensitive data to taking control of a device and executing commands.

The reliance of these devices on cloud services is not always clearly explained to users and they should be, because not everyone realizes that when they talk to their device through a mobile app, they don’t do so directly and the traffic actually passes through a service run by someone else, said Brandon Creighton, a member of the Veracode research team.

This also means that manufacturers should have security processes in place not only for the hardware devices themselves, but also for their Web services, Creighton said. “These services can be vulnerable as any other application running on the Internet—Web service or network service—so it’s important to get those tested and reviewed as well.”

Based on the results of their analysis, the Veracode team concluded that the designers of the tested devices “weren’t focused enough on security and privacy, as a priority, putting consumers at risk for an attack or physical intrusion.”

For example, information gathered from an Ubi device could enable criminals to know when a user is home or not based on ambient noise or light, the team said in their report. Furthermore, by exploiting vulnerabilities in the Ubi or Wink Relay devices, attackers could turn on their microphones and listen to conversations. “Using vulnerabilities found in the Chamberlain MyQ system, thieves could be notified when the garage door is opened / closed, indicating a window of opportunity to burgle the house, and then remotely open the door.”

Creighton stopped short of saying that the issues they found on some of the tested devices were a universal problem in the IoT world, but he doesn’t think they were anomalies either.

“I think these are common problems that would probably be shared across a lot of different embedded devices,” he said.

The good news is that unlike routers for example, many of these IoT devices come with automatic update capabilities, so whenever an issue is found, the vendors can more easily distribute a fix. Veracode has already contacted the affected vendors and at least one of them, Wink, has already issued patches.

http://www.pcworld.com/article/2906952/researchers-show-that-iot-devices-are-not-designed-with-security-in-mind.html


Article 2:

Over 100,000 devices can be used to amplify DDoS attacks via multicast DNS

The multicast Domain Name System (mDNS) is a protocol that allows devices on a local network to discover each other and their services. It is used both by PCs and embedded devices like network attached storage (NAS) systems, printers and others.

The mDNS protocol allows queries to be sent to a specific machine using its unicast address. However, the official specification recommends that when receiving such queries, the mDNS service should check before responding that the address that made the request is located in the same local subnet. If it’s not, the request should be ignored.

A security researcher named Chad Seaman discovered that some mDNS implementations don’t follow this recommendation and will respond to mDNS queries received from the Internet. The problem with this behavior is twofold.

First, depending on the type of query, mDNS responses can leak sensitive details about the device and its services, including its model, serial number, host name, physical MAC address, network configuration and more. This information could potentially help hackers better plan their attacks.

The second implication is even more serious. Because mDNS responses can be considerably larger than the queries triggering them and because the source IP address can be spoofed, devices that accept mDNS queries from the Internet can be abused to reflect and amplify DDoS attacks.

DDoS reflection helps attackers hide the source of their malicious traffic. Instead of flooding a target with packets directly, attackers can send mDNS queries with a spoofed source address to vulnerable devices causing them to send unsolicited responses to the victim’s IP address.

DDoS amplification implies reflection, but also increases the amount of rogue traffic attackers can generate. That’s because the size of the mDNS responses sent by vulnerable devices to the victim will be larger than the queries made by the attackers.

In tests, some of the vulnerable mDNS services amplified the traffic by as much as 975 percent, Seaman said in a write-up on GitHub. “The true amplification rate is hard to predict since the replies vary a lot based on server configuration and the size of the query packet itself, which changes based on the service being queried, but a safe estimate would be over 130 percent amplification on average.”

Amplification techniques have been used in some of the largest DDoS attacks seen in recent years. There are several protocols that can be abused for this purpose if configured improperly, including DNS (Domain Name System), SNMP (Simple Network Management Protocol) and NTP (Network Time Protocol).

Seaman found over 100,000 devices that respond to mDNS queries over the Internet and can potentially be used by attackers for DDoS amplification.

“These devices include several NAS boxes and printers as well as Windows and Linux machines,” he said. “Some of these machines were located on larger networks such as corporations and universities, and appeared to be poorly secured, if secured at all.”

The researcher notified the CERT Coordination Center (CERT/CC), which issued an advisory about the issue Tuesday.

“If such mDNS behavior is not a requirement for your organization, consider blocking the mDNS UDP port 5353 from entering or leaving your local link network,” the organization said.

Some devices from Canon, Hewlett-Packard, IBM and Synology were found to respond to Internet-based mDNS queries in their default configurations. However, it’s not clear which software running on them actually responds to the queries, CERT/CC said.

Avahi, a Linux software package for zero-configuration networking, was also found to be vulnerable.

http://www.pcworld.com/article/2904972/over-100000-devices-can-be-used-to-amplify-ddos-attacks-via-multicast-dns.html

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s