Nowadays, a lot of attacks take place by tricking the user in some way, such as to open a file, click on a malicious link, or enter their personal data into a fake website.

But when it comes to the “Internet of Things” (IoT), the methods are a little different. In principle, this is partly because in many cases there is no interface for the user to interact with, but added to that, the devices themselves often present vulnerabilities and poor implementations of security measures.

The big challenge with IoT devices is that they are all different: Each manufacturer has its own firmware, uses different protocols, and designs its own architecture. So, the first step before carrying out any analysis is to understand the architecture, find out what components are involved, and how they interact and communicate among themselves. The ideal thing at this stage is to make a diagram of the device, as precisely as possible, including each component and its interactions, in order to determine what could go wrong with each of the parts involved.

This way, you will be in a better position to define the attack surface and work out the various individual vectors that could be used.

At this first stage, your analysis can be as in-depth as you want, you can even open each device and analyze the internal components from an electronics or communications perspective. Try to identify which components could be useful to you when you come to search for possible vulnerabilities, like serial ports, the UART controller, flash drives, filtering modules, JTAG interfaces, etc.

Now you have your diagram, you have your analysis lab ready, but… what are you actually looking for?

Basically, anything that can be intercepted or manipulated from beyond the usual flow. A good way to start looking for possible vulnerabilities is to try and see how you can interact with the various components beyond the usual flow, for example, hijacking a component or disrupting a controller.

You can start with means of communication, intercepting any type of traffic that enters or exits a device, whether it’s via Bluetooth, radio frequencies, Wi-Fi, or even an infrared controller such as a standard remote control for a TV.

One clear example of this is the vulnerability discovered in 2013 by the researcher Nitesh Dhanjani in the communication between Philips Hue lamps and their hub or controller. These devices communicate among themselves via the Zigbee wireless protocol, and if attackers run a successful sniffer attack on this traffic, they will be able to analyze and understand the communication between the hub and the lights, and even disrupt or change the data packets, so as to switch the lights on and off, regardless of what order is sent by the hub. That means—as Nitesh showed in his research—causing a permanent blackout to a Hue lighting system. Fortunately, this vulnerability in the Zigbee protocol was corrected and so the Philips lights and other affected devices were patched. Still, it is a good example of a vulnerability found by means of a sniffer and man-in-the-middle technique that was adapted to suit the new architecture.

There are many more examples like this out there, including some that are still current, affecting toys, IP cameras, watches, thermostats, household appliances, and almost any other smart device. Many of them present known vulnerabilities in their components or communication, or do not implement sufficiently strong security measures to keep an attacker out.

It is very common for these devices to send plain text information among some of their components, to use insufficient encryption, or even not to request any kind of authentication.

Another example involved a well-known baby monitor which offered an interface operating via the Internet, whereby the parents could not only see the child through a camera, but also talk and send sounds to the baby. Due to the method of authentication and a vulnerability in the platform, an attacker could send sounds and even play music through various monitors. That’s pretty dangerous when you consider the level of access to a family’s privacy that these devices have.

If you have any smart devices in your home, you can start running your own security tests. Start by making a diagram of the architecture, understanding it, and defining the attack surface. Look for possible vulnerabilities by intercepting traffic, analyzing whether the information is encrypted, and seeing how it can be manipulated. The operating system AttfyOS, which we recommended previously, is a good tool to start with.

In future posts, we will be analyzing the different tools it offers and showing you some techniques for analyzing IoT devices.

Editor’s note: contributed blogs like this are part of ChannelBuzz.ca’s annual sponsorship program. Find out more here. This content originally appeared on ESET’s We Live Security blog.)