Category: Security

May 14 2015

Verizon Report Foreshadows Breaches Originating With IoT Devices, Part 4

This post was written with the invaluable assistance of Steve Watson of Intel.

On April 14, Verizon released its 2015 Data Breach Investigations Report (DBIR). Since then, McAfee Labs posted three blogs (here, here, and here) expanding on the DBIR’s Appendix D discussion of the security of the Internet of Things.

In this final blog discussing IoT security, we outline things businesses can do to prepare for the onslaught of IoT devices in their trusted networks.


Classify your networked physical environment

Are you deploying IoT devices to showcase these new technologies, optimize and automate routine tasks, or enable remote monitoring of environments? Compromising a fancy IoT device–controlled lighting display is a low-risk concern, but if the IoT device controls security lights outside a building or a large commercial refrigeration unit, then the risk is much greater.

Businesses should develop risk-based security classifications and considerations that extend beyond data and systems to networked physical environments. Everyone would agree that life-safety systems have a higher consideration than the person counter at the door of the office break room, but what about the lighting controls for the stairwell or the notification of a leak in the boiler room?


Segment (isolate) the IoT network and actively monitor that network

By isolating IoT devices onto a separate network or subnet, you can mitigate the risk of these devices in production networks. In the event of compromise, the entire IoT implementation can be managed rather than hunting for the devices among other end nodes. An important consideration regarding network isolation is that some devices will need to be multihomed across different network protocols. As noted in our second blog, an IoT device can act as a bridge between protocols, so complete isolation extends beyond the segmentation of that device on a TCP/IP network.


Evaluate IoT in light of the “cyber kill chain” principles

Lockheed Martin popularized the concept of a cyber kill chain and it has been widely used by the security community to describe the different stages of cyberattacks. The model defines seven phases of threats that can be applied to IoT devices in a network—much as the model has been applied to traditional servers and endpoints in that network.

Let’s apply the model to an evaluation of an IoT device: What level of intrusion is possible using the device? Today many IoT devices are likely limited to the Reconnaissance phase because they have not been fully dissembled to uncover vulnerabilities. We should anticipate that compromises may be imminent over the air, Internet, and physical access—moving some IoT devices into the Weaponization and Delivery phases. Once vulnerabilities are identified, attackers will seek to weaponize IoT exploits and then determine how they can be delivered.

Consider the simplicity of a backdoor attack on an IoT device running a modified Android version with limited security controls in place. Does the technical team know which operating system the IoT device is running? Will they be able to detect that a different ROM has been uploaded to the IoT device or know that it was different?

A significant unknown in the threat research community is whether compromise can occur from non-TCP/IP networks to the trusted TCP/IP networks. If an IoT device speaks to node devices via Zigbee or Thread and also has a traditional TCP/IP address, will it be possible to exploit the IoT device from the non-TCP/IP side, completely bypassing network monitoring and analysis?

We also don’t know whether an attacker could compromise multihomed IoT devices, thus accessing sensors, relays, or actuators on the other side of isolated IoT networks.

Compromise from IoT nodes to a TCP/IP network moves from right to left in the following diagram. It might be possible for an attacker to send malformed packets on the IoT node mesh network through the IoT device onto the TCP/IP network. It is easy to imagine a distributed denial of service attack on the TCP/IP network originating from a mesh network.

20150514 IoT Simon

Compromise from a TCP/IP network to IoT nodes moves from left to right in the diagram. It is similarly easy to imagine an attacker who has gained access to the TCP/IP network triggering actuators on the IoT network, wreaking all sorts of havoc as a result.

These are new threat vectors introduced with the deployment of IoT devices with insufficient research to understand what is possible.

While businesses should be familiar with network monitoring and normalization on their networks, limited options exist for monitoring non-TCP/IP network implementations. If a network compromise occurs on the alternate wireless protocols, will it be possible to detect the attack?


IoT developers must understand where their devices fit into the network

IoT devices will not exist in a vacuum. These devices will sit alongside computing nodes on complex networks. Consequently, developers of IoT devices should understand and architect secure designs into their products. The OWASP list of attack surfaces referenced in our second blog identifies key security areas and details how IoT device developers can mitigate those security risks.

Developers should also keep a careful eye on emerging IoT security standards. Google, Intel, Qualcomm, GE, and others are working on standards, but this area is far from settled. The key thing is to embrace and support those standards as they emerge.

IoT devices are coming to a network near you, so planning and preparation are essential. Learn more about Intel’s approach to IoT devices and their security here.

The post Verizon Report Foreshadows Breaches Originating With IoT Devices, Part 4 appeared first on McAfee.

May 14 2015

Google extends Chrome malware crackdown to Windows dev channel, OS X

Google is requiring more Windows-based Chrome extensions to be installed from its Web Store and will enforce the same requirement on Mac users in a few months in an attempt to prevent users from inadvertently installing malicious titles.

The move comes a year after Google first required Windows users to download extensions from the Windows Store, a mandate that resulted in a 75-percent drop in user support requests seeking help uninstalling unwanted extensions. The policy wasn't enforced on the Windows developer channel, so developers of malicious extensions have increasingly embraced it as a medium for distributing their wares.

On Wednesday, Google said that all extensions for Windows were required to be hosted on the Google site, and starting in July, the same will apply to all extensions for OS X, Jake Leichtling, Google's extensions platform product manager, wrote in a blog post. Google will continue to allow inline installations, in which a third-party website seamlessly links to an extension that is actually hosted on Google. Google will also continue to permit installations by large organizations through its enterprise policy.

Read 1 remaining paragraphs | Comments

May 14 2015

Apple Watch’s security features protect data but won’t deter theft

When you first set up the Apple Watch, it asks you to assign the device a security passcode to stop just anyone from picking up your watch and looking at all the stuff on it. While that passcode is an effective tool to protect your data, it does nothing to stop someone from lifting your watch, resetting it, and using it themselves or selling it.

As detailed in a post on iDownloadblog, it's dead simple to find the Watch OS reset option without unlocking the device. Long-press the side button to bring up the power menu, then Force Touch that menu to find the "erase all content and settings" button. Once you've done that, pairing the watch to a new phone works exactly the same way as it did when you took the watch out of the box.

There are also ways to erase all the data on an iPhone, iPad, or iPod Touch without bypassing the lock screen, though. All you need to do is put the device in recovery mode and then restore it using iTunes. In this case, though, the Activation Lock feature introduced in iOS 7 still works as a theft deterrent. Even if you wipe the phone, setting it up again requires the Apple ID password of whatever account was signed into iCloud on that phone. Just months after it was introduced, Activation Lock had already significantly curtailed iPhone theft in major cities, and legislation requiring a similar "kill switch" on all smartphones is already on the books in several US states.

Read 1 remaining paragraphs | Comments

May 13 2015

Venom VM bug called “perfect” for NSA, or for stealing Bitcoin and passwords

The just-patched critical vulnerability in widely used virtualization software is an ideal exploitation target for state-sponsored spies and criminals alike fishing for passwords, cryptography keys, or Bitcoin, a researcher who has dissected one of the fixes said.

The bug, which is known to affect the Xen, KVM, and native QEMU virtual machine platforms and appliances, makes it possible for attackers to break out of protected guest environments and take full control of the operating system hosting them, security researchers warned Wednesday. In the hours following Wednesday morning's disclosure of the vulnerability, many security professionals have publicly said its severity is being exaggerated. The critics have rightly pointed out that it can't be remotely exploited and can't be exploited on large numbers of machines in a single stroke, as is the case with most serious security bugs.

Rob Graham, CEO of security firm Errata Security, has indicated that the bug is still worth taking seriously. For one thing, he suspects it will be easy for attackers to exploit the flaw. For another, he said exploits could yield highly valuable assets on vulnerable machines, particularly on virtual private servers, which use virtualization to segregate different customers' data on the same physical machine. In a blog post published a few hours after the vulnerability came to light, Graham wrote:

Read 1 remaining paragraphs | Comments