Articles

IoT Security Concerns

When looking at IoT implementations, the topic of security always comes up. Many people remember October 21, 2016 as the day IoT devices broke the internet. After the investigation event was complete, it turns out the that it the outtages were not exactly caused by IoT devices. A majority of the denial of service attacks came from things like home routers, which most people would not classify as an IoT devices. When looking at all of the different ways that IoT devices can be modified to do bad things a few different ideas come to mind in terms of risk. How easy is it for a non-authorized user to gain access to a given device and what kind of device is it? If the device is a network router, that is a big problem. If the device is a water sensor and you need a lot of networking equipment to modify it, then the risk can be classified as a low risk. How an IoT device is modified is also a problem. If the IoT device is hacked in such a way that it becomes unusable, because the code ran out the the battery power that is a bigger deal than an IoT device which can be fixed by power cyling the device, which returns it to the factory configuration. Many times the code used to take over the device prevents any remote control access. This means a person needs to physically go power cycle the infected device. This can be a problem as some of these devices are inaccessible and are designed to be replaced not maintained. Power cycling stops the immediate problem but it does not prevent the same exploitation from happening again. New firmware or patches need to be applied to prevent the problem, requiring maintenance of the device again.

Knowing something about the people involved and the process used to gain access can help assessing risk. Unfortunately a number of devices have been released which have no security as they leave ports open which can be readily hacked, instead of say implementing SSL. Telnet, HTTP, DNS, Port 80, Port 22, and RDP all of these are ready targets for attack. There are also broadly speaking three classifications of users who work on accessing things which they don’t have access. Knowing about these three kinds of users and how they go about the process of gaining access.

Terminology changes over time, and to understand the risk, one needs to understand the language used by the people who access networks outside of the way the software was designed. For starters, the word Hacker is not used much. The word is overused and has come to mean people who have ill-intent, instead of the original version of people who were looking for flaws, not exploiting them. The people who access networks are known as Penetration testers, which is commonly abbreviated as pen testers. They not only figure out how things are broken but more importantly how to fix problems which they have found before someone takes advantage of the flaw.

Nation State Attacks

Many governments employ legions of developers to access or destroy. With nearly unlimited resources at their disposal, they are very successful when they want to target software for attack, as was seen when the Iranian centrifuges exploded. They also have the ability to completely mask where the unauthorized code came from, as that is standard operating procedure. If code is ascribed to be from the area near I-95 exit 41, you can pretty much guarantee that it came from somewhere else. It is virtually impossible to trace the origins of Nation State attacks as they ensure nothing is ever what it seems. If there are clues as to the origins of the software, they are added as intentional misdirection to throw people off the trail or to affix blame someone else. They have dedicated hardware designed to break access codes in a matter of seconds. There is no stopping this type of attack. They have little interest in most things so the risk is fortunately low.

White Hats

These penetration testers generally make their living hacking by permission. Firms hire them to see how vulnerable their networks or IoT Devices are. It is likely that white hats would advise these firms on incorporating effective security solutions (such as Mobile security in Intune) in order to prevent office networks from getting hacked. The white hats contact the vendors and provide warnings about things like the ability to access all of the memory on a single VM server if one knows how to overload a specific buffer, which is getting to be more common as servers are virtualized both on-site and in the cloud, which is after all someone else’s server. These people are trying to help make the code better. Of course, all pen testers are not all white hats, there are grey and black hats too. These people know enough to cause or prevent real damage.

scriptKiddieScript Kiddies

Like everything else there are varying levels of skills involved in pen testing. The lowest skill level is known as a Script Kiddies. People who penetrate networks are not the evil geniuses portrayed in Hollywood, they just know where to download Kali Linux which comes with a tool called Metaspolit. This tool contains a database of libraries which can be run against networks. Knowing how to run a program is not a great skill but then again given how poorly so much of the software is written, you don’t have to be an evil genius to say spy on a TrendNet webcam, as they did not fix their software until the FTC made them do it. The IoT hack that broke the internet? That capability was readily available as a canned exploit. Fortunately these common types of unauthorized access are the easiest to defeat. IoT systems need to be designed to avoid simple and well known intrusions, which is something that I will be talking about in my presentation for 24 Hours of Pass. Hopefully you will get a chance to attend live or watch the upcoming recording.

Yours Always

Ginger Grant

Data aficionado et SQL Raconteur

Event Hub Troubleshooting

When creating an Azure Event Hub, chances are there will be no errors. This is not always a good thing, as it may mean that the errors exist but do not appear. Maybe the event hub is sending data, but the data cannot be read by a stream analytics job. Maybe the event hub really is working, but nothing appears in the dashboard. If any of these problems sound familiar, this post should help.

Testing the Event Hub

If you don’t have a source of data, like a raspberry pi or a sensor sending data, you can use this guide to create a C# program to send data to your event hub. Chances are though, this code is going to have to be modified even more than the instructions indicate, because the data sent is not in JSON. While it is not a requirement that data sent to the event hub be in JSON, if you want to read it with stream analytics that is one of the acceptable formats needed. If you are using the code provided and you want to insert a record into a database field input01, the message needs to be changed to the following to add the double-quotes and brackets required by JSON.
var message = "{'input01':\"" + Guid.NewGuid().ToString()   + "\"}";

Validating the Event Hubs Receive Messages

To ensure that the event hub is actually receiving data, validation can only be done in the old Azure portal. The service bus icon is two down from the HDInsight elephant. Double-clicking on the service bus namespace will bring up the a list of event hubs. Double-clicking on that will show this screen. This screen picture was taken roughly at 7:10. How many messages are there at 7:00? None.

eventhubbefore

This screen print was taken at 7:17. Notice anything different about the message count at 7:00?

eventhubafter

Oh look, there are 144 Messages which came in between 7:00 and 7:05. This means that everything really was working, I just needed to wait to see them appear. The wait time tends to vary from 10-20 minutes. Perhaps nothing is wrong. Lucky if this is you as you can stop reading

Stream Analytics with Event Hubs

If you are using an event hub to pass data to a stream analytics job, step one, make sure the stream analytics job is started. Created does not mean started as it should say Running as shown in the clip below.

The input for this stream is set to an event hub which has a standard subscription. The basic subscription, which is of course cheaper, has one default consumer group. With a standard subscription multiple consumer groups can be created and more importantly named. When setting up the inputs there is a blank for the name of the consumer group. If you have a basic subscription this will be empty. If it is empty, then the event hub won’t pass data to the stream analytics job. Perhaps there is a way to get a basic event hub to work with a stream analytics job, but I couldn’t make it happen. When I created an event hub with a standard subscription and created a consumer group and added that name to the input of a streaming analytics job, it worked.

If you have found these troubleshooting tips helpful, please subscribe to my blog, as I will be passing along more tips in my next post which will detail the steps of how to get data from the event hub to a Azure Database.

 

Yours Always

Ginger Grant

Data aficionado et SQL Raconteur