IoT Security Fail

So I am not a huge fan of the whole Internet of Things movement that is going on right now, mostly due to the recent lack of any real security or thought of security being placed into these IoT devices. A more accurate name for the IoT would be the Internet of Insecure Things (IoIT). Recent (or not so recent) news of consumer home wireless access points and routers being compromised and used for various botnets are one example of this concern, and this is just one small example. Home routers, thermostats, IP cameras, VOIP phones, DVRs, smart TVs, etc, all things that can contain embedded firmware of now outdated or obsolete libraries that are exploitable. And if they are not exploitable, great, there is probably just some hard coded admin user and password in the device or another debugging backdoor that was forgotten to be disabled.

'Junk Hacking' is a term I like that is used to describe people finding exploits in these devices, it seems every week there is some new little embedded device that has a vulnerability. Stop. When these stories break, everyone always seems to be surprised that there is a backdoor or other exploit on IoT device N. Really?! Of course there was a vulnerability on it! I would have only been surprised if there wasn't! I go by the opinion that every device is vulnerable. Proving me correct is not difficult, proving me wrong on the other hand would actually be impressive.

Now sure, most of these devices (with exception to the router itself) will live on a home private network and all have private ip's assigned by the routers DHCP server, so risk to them should be very minimal even if they are vulnerable in some way or another, although wireless devices are an exception. Some vulnerabilities require physical access to the device as well, which imo is not really a vulnerability (anyone can re-flash devices if it's physically in your hands ). That said, it is amazing how many of these devices end up being publicly accessible on the internet, either on public ips themselves or port forwarded to private ips. Not excluding commercial and industrial devices as well, they are also exposed everywhere. Everything is just hanging out waiting to be poked at. Having convenience over security seems to be the norm.

Favoring backwards compatibility is another issue that needs to be overcome. 'Well, it needs to work on IE6!' No, actually it doesn't, and it definitely shouldn't. This mentality needs to go away. Software goes obsolete for a reason, and that is because it's usually broken. This rule needs to be enforced by all.

The wireless side of things is the same story. Wireless ISM band mesh devices are the new hotness with everything communicating over ZigBee, Z-Wave, or other protocols. You don't need to look hard or far to find known vulnerabilities in these protocols or tools to sniff these networks. While sure, newer devices will have updated firmware with possibly better encryption and security, what about all of the existing devices in the wild?

While manufacturer of devices intentions may be good to keep devices secure and up to date, the real result of these devices is that none of them actually are. The OpenSSL vulnerabilities that occurred last year and recently are an example of these concerns. How many of these devices are still running an old version of OpenSSL? Probably most, unless of course you have updated your firmware, which I know usually never actually happens. This is assuming new firmware is even available.

This issue of updating these home devices to keep them up to date ends up being your (the consumers) responsibility. Manufactures are more than capable of having their devices auto update when new firmware comes available, but the risk and cost would be too high in doing so. The day that the device auto updates and becomes a brick because of a mistake is just too high, especially if it happens to thousands of devices. Manufacturers could of course design in fail-safes to prevent this, things like dual flash memories for running and updated configs allowing a rollback option, but this would of course increase costs. Plus manufactures don't want to have to support their own devices, that is just additional cost.

So the result is it is your responsibility as the consumer to make sure your device stays up to date. I'm not okay with this, but you have no choice. The alternative is to not use the device, if it isn't on, it is not vulnerable. The real issue falls onto the larger portion of the population that doesn't really know or understand, or care to know or understand security, networking, or recent CVE listed identifiers that come out, not to mention understand the actual details of the vulnerability. It is this group of the population that results in everything being at risk, but I don't believe they should be held responsible. Maybe manufacturers should be responsible for the security and patching of their own devices. Maybe they should not be designed so insecure in the first place.

So what is the solution? Should manufacturers be more security minded and allow automatic updates to all IoT based devices? Sure, that would be a good start. Putting any actual thought and time into security in the first place would be another great idea. Having anyone who actually knows anything about security audit your product before production would probably catch a lot of the really stupid mistakes. Another thought would be to not make every device IoT enabled if it doesn't half to be in the first place. Just because something could be internet enabled doesn't mean it should be. I'm pretty sure I have been hearing news of internet enabled refrigerators for over 10 years now, even seen one or two in some stores. Everyone thinks its neat and cool and somehow it will be useful as it solves a problem that doesn't exist. I just know it will be end up being another vulnerable device.

XBee Repeater

I am finally ready to perform some long-range XBee testing using the Digi XBee-Pro XSC modules. I put together a few simple Xbee repeaters utilizing an Xbee-Pro XSC 900Mhz module, a simple rs232 interface, and power supply. Power come from a pair of 18650 lithium batteries.

I made two of the devices above as they are useful for any project that needs portable XBee communication. Simply hook any two laptops or mobile embedded devices up to the pair via rs232 and you have instant point to point mobile serial communication. To enable the device as a repeater, I made a loopback device that plugs into the serial port echoing anything that arrives on the serial rx line back over tx.

The simple 900mhz antenna hooked up to it works well for testing, but I have a pair of high gain 900Mhz ISM band yagis I plan to use for long range testing.


These yagis connected to the Xbee PROs with good lmr-200 cable should make for some very long range communication. The biggest issue is finding a good line-of-site location to test. I have been studying some topographical maps around the Ann Arbor area trying to find two good points of high ground, or a point from a tall structure to high ground. So far I have some good tests at about 6 to 7 miles (which doesn't seem like much, but when trying to see from your point on the ground is a very long distance away). Standing at ground level (if at sea level and looking out), from your eye level (say six feet up) you can only see about 3 miles to the visible horizon. Increasing your distance above the earth to 100 feet only increases the visible horizon to about 12 miles. So I will need to find some tall structures or high ground to test the full 15 mile range that the Xbee datasheet states for the maximum range.

Long Range XBee PRO XSC testing, Part 2

It has been awhile since my original post about seeing how large of a distance I can get two XBee PROs to communicate, but since coming across two nice 902 - 928Mhz ISM band 9 element yagi antennas I figured it was time to give it a try.


My plan is to mount two XBee PRO XSCs each to one of the yagis mounted on tripods. A small ttl to serial interface will be needed at each end which will allow interfacing to laptops. These setups will need to be as portable as possible. With each setup I will be able to set them up easily at any location (the tripod / antenna / XBee and interface, along with a laptop will be the only items needed) and test signal strength and communication using the XBee X-CTU application.

I finished the first ttl to serial converter tonight, only one more to make:

The final step will be to find two locations that are line of sight and up to 15 miles apart using topographical data. 15 miles is a long way, so I will be starting with a five mile distance. As soon as it warms up I will be giving the range test a try. I'm hoping to reach the 15 mile range Digi states that these modules are capable of, but even further would be better. :D

Long Range XBee PRO

Digi recently released a new series of XBee wireless long range transmitters which I have been very excited to play with. The XBee-PRO 900 series has up to a 6 mile range using a high gain antenna! Some other features from the XBee site:

• Fast 156 Kbps RF data rate
• Point-to-multipoint networking ideal for low-latency applications
• Support for large, dense networks
• 128-bit AES encryption

Jim cam over this past weekend to help me perform some basic ranging tests with these modules to see what type of distance can be achieved in an urban area. The plan was to set up a base station and send messages out to a mobile XBee PRO as a repeater and see how far away we can get without dropping any packets.

The base station is simply an XBee PRO linked to my bench machine through it's serial port via a MAX232.



The mobile module is simply an XBee PRO with it's TX and RX lines wired together forming a basic echo repeater. Lithium polymer batteries are being used through a 3.3v regulator. This is simply in basic mode as well, no API mode.



Using Digis' useful X-CTU application for range testing, we were able to get some impressive results. We were not able to get anywhere near a 6 mile range, but with the fact that we were using only the on board whip antenna on these modules instead of a high gain antenna, it was expected. Our testing environment significantly limited the range as well because of the amount of concrete structures in the area. With all of this we were still able to reach a range of several thousand feet before packet loss. A standard XBee would never reach this range.


Range was very limited to line-of-sight. If there was a building in between the source XBee and repeater XBee, packet loss would occur in a very predictable manner. This was all happening from the source transmitter being on my bench inside my home, so there was already an initial structure blocking it's signal path.

Our next tests will occur in a more open area which will allow more line-of-sight testing. I am confident that we will reach several miles in this scenario and will report our findings.