Into the Mind of an IoT Hacker | How to Protect IoT Networks & Devices
- Hello, everyone. I'm very happy to take part in this really great RSA 2021 Virtual Event this year. My name is Itzik Feiglevitch and I'm the Product Manager who leads IOT Cybersecurity Solutions at Check Point. And together with me is Justin Sowder. He's our Security Architecture for IOT and ICS Solutions at Check Point. Now, I'm sure that all of you will agree with me that IOT is one of the biggest trends in the market today.
There's huge buzz around this topic, and I'm sure that many of you are already familiar with the huge numbers of IOT devices that we are expecting to see in the coming years. Now, those IOT devices from one side are really great. And we can talk about increasing the operational efficiency of the business, moving to the digital world and so on. But we also need to take into consideration that all of those IOT devices that are now part of our networks also brings with them lots of security risks into those networks, and actually create a huge attack surface for cyber criminals to come and to hack into those networks.
So in the common presentation, we are going to focus on two topics. The first topic will be what are the risks, What are the risks that those IOT devices brings into those networks? And the second topic is what is the right security solution, the cybersecurity solution to address those risks, to address those challenges in order to protect the IOT devices inside the network and to protect the network from IOT related attacks. Now, at Check Point, we are focusing on four types of customers. The first one at the end customers it can be enterprises, such banks, insurance companies, high-tech companies and they need to deal with all the Smart Building and the Smart Office devices that are connected to the network. We have a healthcare providers. Those are hospitals that we are working with who need to deal with all the connected medical devices.
And we also have industrial customers such as utilities companies, factories and so on. For those types of customers, we offer in a network security solution. The solution that sits inside the network, protecting the IOT devices inside the network and protecting the network from IOT related attacks. The fourth type of customers that we are working with are the IOT manufacturers themselves. We helping them to develop and to provide safe to use IOT devices by integrating nano agents security technology into the IOT devices themselves, protecting them from the inside. One of the first questions I'm always asking when meeting with a new customer is, do you know, do you really know how many IOT devices do you have inside your network today? Those devices are out of your network, those devices are connected to your network.
So how many IOT devices do you have? And the answer is always, no, I don't know. Well, our research department found out that in a typical enterprise or 5,000 employees you will find around 20,000 IOT devices. Now I know that it seems like a huge number, but think about all the IP TVs or the printers or the surveillance cameras or the sensors inside the building, the smart elevators, everything is connected to the enterprise network. In a typical hospital of 500 beds you will find around 10,000 IOT devices. Most of them are connected medical devices.
We have MRI machines, CT devices, infusion pumps, but not only a hospital is like a small city. We have gas systems, water systems, electricity systems, general IOT devices, everything is connected to the hospital network. And in a typical factory of 2000 workers, you will find around 5,000 industrial IOT devices. Different controllers, skater systems, everything is connected to the factory network.
Now we need to ask ourselves, how are all of those devices are connected to the network? For the security manager point of view, those are not trivial devices that sits inside the network. Many of those devices have their own unique characteristics such as the operating system, the device functionality, many of those devices are based on those crazy IOT and OT protocols; BACnet, Skater, Modbus, but probably the most disturbing thing is that many of those devices are unmanaged devices. Meaning that they are connected to our network, but we don't have any way to control those devices, to view them and to define what those devices can do and cannot do inside our network. If we will go and search for those devices in our existing security management system, we will not find those devices. Now, in many cases those devices are also connected to the external internet.
And this is because of many reasons, for an example, we would like to enable the different vendors of the different IOT devices to be able to access them. Maybe we would like to enable access to remote users, specifically during this COVID-19 days, many of us are working from home or maybe we would like to enable access to a third party service provider who managing those devices for us. For an example, a company that monitors the printers inside the facility and in case they will find the printer with an empty tunnel they will automatically send a new one. So in many cases those devices are connected to our network from one side, and on the other side, also to the external internet.
Now the attackers using standard scanning tools can find those devices. They know what to look for. They know what characteristics to look for. What types of protocols. One of those tools is Shodan, I'm sure you're familiar with that.
This is a public website also known as the Google of the IOT hackers. And you can see here two searches that have did, they've find more than 25,000 printers and almost 300,000 cameras that are connected to the internet. And of course we can search for specific model, specific vendors, even for devices in specific location. Now, once we've managed to find those IOT devices, it is quite easy to connect to them. And it is quite easy to hack into those devices. Most of the IOT devices don't even have basic security capabilities.
When those devices were developed, no one thought about that. Many of those devices are based on all the tech software and legacy operating systems. I've personally seen devices that still runs windows 95, many old operating systems, such as windows 2000 with no security patches, with no vulnerabilities that are very easy to hack into. And many of those devices are based on default passwords, one two three four eight eight eight. Someone taking this device out of the box with the default password and connected it to your network.
And now you have hundreds of devices that are based on default passwords that are connected to your network. Now we have limitations that preventing us from going and fixing those issues. We can't go and change the software inside those devices. We can run dedicated security application inside those devices. Limitations such as physical access devices that need to work 24/7, different regulations, certifications and so on. Now, the attackers they know that and they're using those devices, and they're using those devices in two ways.
The first way is hacking into the IOT devices themselves and then manipulating those devices and by doing so damaging the operation of the business. It can be for an example, a medical device in the hospital, manipulating such a device can maybe even, can kill someone. It can be an industrial device in the factory, manipulating such a device, such as Smart Elmo Stat can force the factor to shut down the entire production line or it can be just a simple IOT device, like a surveillance camera. And the attacker can take control, can take over this camera to see what it sees, maybe to turn it into a Botnet attack or maybe use it for crypto mining. The second way the attackers using those devices is backdoor to the network. Because as I said, in many cases those devices are connected to the external internet.
And in many cases in security, because the user don't always have the right knowledge about how to connect those devices. So they're using the wrong protocols, the wrong, unsecure applications so the attackers can find those devices quite easy. Hack into those devices and through those devices to get into the network. I'm sure you're familiar with Mirai attack, back in 2016 targeting hundreds of thousands of IOT devices creating a huge digital setup. Since then every few months we've seen a new variant of Mirai attack. So we have Mukashi and Dark Nexus and Kaiji, and the latest one by the way is Mozied that was identified by IBM a few months ago.
Now it seems that all those latest variants of Mirai attack now targeting specifically Enterprise IOT devices, such as IP phones and printers. And we're also seeing that the new types of attacks are crypto mining attacks. Trying to turn those devices into crypto mining. So each of the IOT devices don't have lots of CPU power but you need to multiply it by hundreds of devices that you have in each of the enterprises networks. So in one attack, you can even hound the several thousands of dollars from this network, from the IOT devices.
ZigBee systems becoming to be very popular within Smart Buildings. In a typical system you will deploy on one side, a ZigBee gateway and on the other side, the large number of smart devices that communicating with this ZigBee gateway, so with the ZigBee wireless network. A very popular ZigBee system is for smart lighting.
Controlling the lights all over the building through this network. Now our research department found out that it is quite easy to hack into the ZigBee gateway. You can simulate a ZigBee device from your laptop, connect to the gateway, manipulated it, make it think that you have a legit ZigBee device and installed inside a malware. Now think about the next scenario. You can sit in the lobby of a large bank. The only thing you need to make sure is that you will be in the range of the ZigBee wireless network.
And now you can hack into the system and for an example, turn off all the lights in the entire building. In case you've missed this case, few months ago this group of ethical hackers managed to find 28,000 printers that are connected to the internet. As you've seen it, it's quite easy to find those printers, just go and search for them in Shodan website. And they managed to connect to those printers and send them a command that caused them to print this page saying "This printer has been hacked, here is a list of things that you need to do in order to secure this printer."
Now, once you've managed to get a connection to a printer it is quite easy to hack into the printer. And in case I'm always saying, there is a hacker that ready to use free exploitation toolkit that you can download from GitHub, PRET Printer Exploitation Toolkit. Just run this application, give it the IP address of the printer. And there's a high probability that this printer is based on a port 9,100 IPP, Internet Printer Protocol. And there it is, you can hack into the printer.
There is a very nice list of, all several things that you can do to this printer. For example, get a copy of everything that is being sent to this printer, or maybe it use this printer for (indistinct), or maybe even cause a physical damage to this printer. This is a smart controller that is being used in BMS, Building Management System.
On one side, the interfaces such as a BACnet, Modbus to the different systems inside the building. You can connect it to HVAC, to smart lighting and so on. On the other side, as you can see there is a web interface, you can connect to this controller and you will get a very nice dashboard, enabling you to control all the devices inside the building. Now, more than a year ago, US department of Homeland security published a higher risk score to this device. Actually it was, it is the highest score, it gave it a score of 10 with a critical risk with a backdoor based on port 22, enable attackers to gain control over this controller and basically to gain control over the complete systems inside the building.
Now of course that the vendor immediately released a software update, called all the customers, "You need to immediately update the software inside device," but I'm interested to know how many of the customers didn't did this upgrade. Think about the Seesaw of a large bank getting this email telling him you need to go and upgrade the software inside your Building Management System. Probably he will not know what you're talking about. He's dealing with users, and account and clouds.
So, he might forgot to do this upgrade. This is a real ultrasound machine that we bought to Check Point Labs in order to try and hack into it. And the thing is that it took us only a few minutes to succeed with that.
And the reason is that this machine is based on windows 2000 with no security patches. Now, this is how it looked once we've managed to hack into this machine. we managed to get access to the medical records that were store inside this ultrasound machine. We also managed to get access to the DICOM protocol that we're going towards the (indistinct) sender.
Now, if you will go to the vendor, in this case it is Phillips and you will ask them what to do. They will tell you, what do you want? This machine is end of life. You need to go and replace this machine. But this is a perfectly working machine and we have budget limitations and operational limitations. And we would like to keep using this machine.
And this is exactly what's going on inside hospitals. They're using legacy machines or machines that are based on legacy operating systems, and those are perfectly working devices that have been used inside hospitals networks. About a year ago, there was a cyber attack attempt against the water system here in Israel.
Now, nothing seriously really happen but of course it was all over the news. Looking into a water system, we will notice that there are many subsystems inside, there are many sub networks and many elements and devices. And part of this system can be far water pumps that might be used even by private users. And in many cases, those water pumps are connected to the internet where controllers that is similar to the controller that you are seeing here, in this case the model is ADAM-6,000, it can be any other controller.
Most of them are based on the same concept for one side there is a serial interface. And on the other side, there is the internet connection. I know we mostly can, for example, open or close this pump. The interesting thing to see is that you can see I found more than 1,800 controllers such as this one that are connected to the internet.
And specifically this controller comes with a default password zero zero zero zero zero zero zero seven. Also a known CVE for this controller. And I can ensure you that most of those controllers are still based on this default password. Think about the farmer who using this controller, and doxing he's going and changing those passwords. So as probably you've guessed it is quite easy to crack this password, and to get control over the water pump. And this bring us to the challenge itself.
The question is, okay, so what done, what should we do? You have a huge number of IOT devices inside your network and those devices are unmanaged and invisible devices. If you will go, when you would search for those devices in your existing security management system you will not find those devices. Those devices are very easy to access as you seen, and those devices are very easy to hack into. So we going to switch now to Justin, who is going to present what should be the right solution in order to address this challenge. - All right, thank you Itzik for that introduction.
Again, my name is Justin Sowder. I'm a Solutions Architect for Check Point for the Americas. A reminder, there's a live Q and A happening now.
I think these stories are all fascinating and interesting, and certainly some of the scenarios that Itzik laid out there are thought provoking for the various different industries. So laying out what Itzik has done here with a bunch of examples of how things can go wrong. I wanted to take this and turn it into a discussion about what we can do from a cybersecurity perspective to help minimize the risk here. And really it breaks down into four different pillars. The first of which is that discovery and risk analysis.
How do we find out what's there? How do we find out how many devices are out there? How much shadow IT is happening through acquisitions? We have non standards in different sites and really just mapping out, what we don't know is the first part and getting as close to possible as we can to an accurate representation of what's in our environment. The second piece of that is the zero trust model, moving into some form of that where we start isolating these devices from the rest of our network and from each other. By doing that we reduce the risk of east-west exploitation. We reduce the risk of some of the things that Itzik talked about in that in his portion.
Aside from just a basic firewall prevention, what we also wanna do is look at what we can do from a threat prevention side. How do we keep these devices functioning in their designed roles while preventing traffic to things like command the control servers or other malicious activity that they might be doing. Crypto mining reporting, things along those lines. It's important to not necessarily take a heavy cybersecurity hand and say we just wanna purely isolate that box that might actually have a bigger impact than letting it continue in that fashion. And that ties directly into the detection and response piece of this, which is now that I know what my devices are, now that I have visibility into 'em, how do I respond to incidents? And how do I detect detect those incidents and get the right people involved to take the right action with those? (Justin clears throat) And that comes down to a fundamental design here, you'll see three basic components. The first of which is the IOT Discovery Engine.
Other, there are some examples here. Those are not meant to be a all inclusive. This might be a tool of your making. This might be some repository where you're doing that first piece, that discovery and analysis of the data that's out there of the devices and things like that. The second piece of that, all that data has to be fed into a system that can take that data, use it in a fashion, extract information and use that to enforce policy later on into the third piece of this, which is that security gateway itself.
And these can be deployed in a couple of different fashions. I'll talk about that in a little bit, but the idea here is that this flow should be completely automated. From a new device being connected or an existing device being discovered to this IOT security management that will extrapolate the data, extrapolate relevant tags to your policy. And then down to an enforcement point, then makes this again, not that heavy handed cybersecurity. We're gonna dictate that we drop everything and all new devices have to have a ticket associated with them. And it's a slow process that encourages your shadow IT, but that this is automated, and that the users don't see an impact to this flow from a new device coming on to it being protected and enforced in the security realm.
And as Itzek laid out there are four different areas that we tend to focus on here. And I wanna go into those in a bit more detail. The first being Smart Office. This has become very important for us, certainly as a lot of us have been working remote over the last year that's actually expanded the footprint into devices that we no longer have control of from a corporate side. Our kids' laptops, anything like that that might be another vector to get in through a corporate machine that's running on a home network.
Smart Building has been emphasized here as well. There's been a major push for energy concerns and things like that with buildings to automate reactions in the building from movement to eight-track to any of these things. And there've been several vulnerabilities that have been exploited in major breaches that have gone in through these systems.
They typically do need to have some kind of remote access and to do maintenance or scheduled work for those. And those can be another vector for threats to infiltrate. Industrial also has its own unique set of challenges from very short downtime windows, maybe once a year, maybe twice a year, to these machines being designed to run an environment for 20 years and with minimal interaction, people that have implemented them have been gone from the company for some period of time, there may be very little documentation other than we just know that this environment works and we don't want to touch it and potentially break our process. And last medical, probably one of the front and foremost over the past year, as we've seen everything happened in the world, these devices have an impact on patient care. Again, back to the point of we wanna monitor everything about a patient we wanna see it live.
We want doctors to be able to pull things up in different environments, immediately or remotely. And these devices are hampered from FTA or other body regulations that say you cannot run antivirus on this, or we have certain versions. As you know, I've also seen some windows 95 machines out there, some very old cryo freezer controllers and things like that. So all of these have their own unique challenge.
And the important part here is that when you're looking at this from your environment perspective to identify which one of these is the most important for you. Which is the most relevant to your business and which is the largest threat factor and the most exposure. It might be a combination of these for instance a hospital certainly is also a Smart Building. So as an industrial maybe has remote office workers now or something like that.
So it doesn't necessarily just fall into one of these. It might be multiple to consider there. As we're getting into device details, and this goes back to kind of that first and second phase of my mapping, it's important to gather as much information as possible about the device. Certainly saying that it's an IP camera for instance, is a good start and we're gonna start building things with that. But we also wanna do some kind of risk scoring here.
We wanna be able to say based on a firmware version or based on anything like that, that this device is more or less vulnerable. And we do that by comparing known CVEs to certain firmwares. A lot of these vendors are getting better about publishing those details and comparing them. And so you know, as you're deploying this IP camera into your network, what the risk is of it based on that firmware version. Other details MAC addresses are pretty fundamental from a starting point, they don't get you much beyond that.
As we're looking through different vendors, there tends to be a lot more deeper protocol analysis and baselining that is very relevant to the devices more so than just the MAC address. But any information that you can pull in is important, it may be its NetFlow data, maybe its integration with a wireless controller, maybe its integration with your NAC solution, whatever the case may be. The more protocol and analysis that you can get on a device to build that profile is gonna help you in developing an accurate policy that is minimally impactful to the environment.
And when we take that data, all that information, we wanna build it into a policy that actually lets us, again get into this dynamic piece where a security administrator is not overburdened with requests but also that provides an important proper layer of security versus just a let's let anything out to the internet and make sure that it does that. So an example would be here. These are some tags that we've inserted into a couple of different pieces, and you can see in that source column, and in a couple of other pieces. We're able to tag that data and use that into policy itself.
And this should be something that should be done via an API with any vendor to be able to build this out and map these components. So you can see an example here of a taken security camera, any security camera we find, we're gonna permit these protocols, but if you'll see you later, if that risk level is critical maybe we've identified that by the firmware version. Maybe we've identified that by some other piece, it will actually prevent that traffic.
And so we're doing some risk management right here in the blue section, the middle blue section, whereas on the top in the red we're actually permitting the proper traffic that we need too for that. And another example that's hugely popular is using manufacturer tags. That's where that MAC address tends to come in a little more. What that does is it gives us the ability to restrict the domain level access to what those devices have access to. You'll see that some of these are very chatty, as you start looking at net flow data with various connections that they're making. A lot of vendors are getting better again on publishing exactly where device should be talking to, what it should be talking to for updates.
If you wanna allow that at all, is another concern that you wanna take into account, but those domains you can restrict and you can be careful about what's going out, and any deviation from that you then choose ultimately as your cleanup. Do I want to still permit this and put it in a detect mode and look for deviations and alert on those? Or do I want to drop traffic that doesn't meet my baseline? That's gonna depend on your comfort level with the policy that you've built above that. That's gonna depend on the potential impact for health care for instance, of drop packets and the implication that that may have or anything along those lines.
So building that policy little easier said than done, and a lot of cases those tags are great to do that, but these are some areas that I'd encourage you to take advantage of as you're looking for this, and this should all be part of an API driven exercise to go through. Profiling the device. There's a lot of tools out there that you can actually take. And some of those I showed earlier, will actually build profiles of devices, mapping out the protocols, mapping out where it's talking to, what's relevant and alerting on that, building that out for you.
And that ties directly into the traffic baseline. I wanna make sure that I capture all traffic that's relevant for that device. Maybe it does one thing for 29 out of 30 days in a month but that 30th day there's a batch that deviates from that. I need to make sure that I account for that and decide in that baseline, how I want to handle that piece. Crowdsourcing another great spot. There's a ton of data out there for various pieces of devices.
And when selecting these IOT devices, you know, that may be a consideration for you. How active is the community on that? What kind of data is out there? How well do they integrate with your other solutions in the security realm and in the rest of the network realm? I said I'll talk a little bit more now we're going to the enforcement piece of this. North-south, that's the traditional starting point for most customers looking at that data that's going out to the internet.
Looking at traffic like Anti-Bot traffic, you know, known CNCs is a very easy way to find and capture devices that have been compromised and doing whatever it is that they're doing there. East-west is kind of the next generation of where we're going out here. What does that look like? And it's a bit more of a challenging task, because traditionally we've just dumped these devices on the VLANS and we've let them go through and do whatever they want to without any mapping of the communication between it.
That's great from a functionality perspective, it really hurts us from the security side as we can get that lateral movement between devices and then potentially exploiting north-south. So, we know there's a lot of different ways to approach this, really again, it's assessing your risk level, you know, what fault domains you wanna have in there. How do you isolate machines in your network and looking at what kind of block choke points that you can put in to your environment at that point to make sure that you've minimized your risk there.
Virtual patching just like has been traditional in the server world for a long time. Also absolutely important in the world of IOT devices as well, understanding again, like in the industrial world you don't, you cannot patch right away. You've gotta wait for a different change window that might happen once a year. Medical's a very similar thing. You've gotta roll devices in when they're not taking care of patients for these things. So being able to use technologies like an IPS to block that in that virtual patching model, hugely important as a first step.
It's not a get out of jail free card to avoid ever touching and upgrading these devices. You absolutely still should. But it's important to think about where you're positioning this IPS device as well to make sure that it is also blocking lateral movement between those devices.
But still permitting that authorized traffic, again, these devices do have a significant number of important functions that may keep people alive or keep the business running. And in that case, it's important to go through and make sure that that authorized traffic is still permitted in those scenarios. (clears throat), excuse me.
On the topic of identifying these devices, Itzik talked about Mirai as well. It's important to look at these pieces of the CNC connection. You see the camera example here as we're going through, and feeding that data in to some kind of solution where you're building that profile up to know that this is a bad connection, whatever that technology looks like there are a lot of good third party threat providers out there that will provide data for you to feed into your systems, to look for this.
You know, there are constantly updated lists of CNCs and various other known bad entities out there in the world that are provided from governments, from private firms, from paid feeds. Any of these things you should be considering these feeds and looking at indicators of compromise in your environment to make sure that the devices in your network are not reaching out to any of those known variables. And that ties me into another interesting piece here that goes into what do we do with the unknown? What do we do with the devices themselves and how do we prevent these from doing anything that we don't want them to? And this is kind of something new and interesting that we're working on as well, as looking at the firmware level of the devices themselves.
Itzik told the story earlier of crypto mining becoming more and more popular. It's very very easy to do in a lot of these devices running a basic Linux kernel to install these especially if they're compromised at that point. And the idea behind that is I don't care if I burn this device out. I want to run every processor, every piece of compute resource on this, as hard as I can, for as long as I can to extract the maximum amount of cryptocurrency from it before it basically melts.
So what we're actually doing in this space and this is a combination of working directly with IOT manufacturers and working with customers who are deploying these devices, is looking at this concept of a nano agent where we'll actually look at the code of the firmware as it's executed to determine if, is it doing anything bad. Is it doing any control flow hijacking? Is it doing, is there any memory corruption taking place on this device? And if so, block that in real time and prevent it from happening. Now, the challenge with that is how do we do that with a very small footprint? A lot of these devices as Itzik said, don't have a lot of compute on them themselves.
They're made very specifically for a very specific task and having a massive security footprint or sticking a firewall of some type in front of every IP camera simply isn't feasible. The way that can be done is at the very very very small light agent, that agent sitting as part of the compiled firmware, phones homes to then get its profile signature of what kind of device it is, and what kind of protections we want to run on it. It is important for this to be tuned to very specific devices. And in such a way, we make sure that there isn't a lot of extra overhead on the device that is not impactful to the device itself and what it does. Again, these are potentially life-saving devices that we do not want to input any other overhead on them to prevent them from performing their function.
So with that, hopefully, Itzik scared you in the beginning with some of the stories, I talked a little bit about some of the solutions and some of the design considerations to have, as we said IOT is coming, it's here and hopefully you're more ready for it now. Thank you again, everyone for attending, it's been our privilege to present in this virtual expo. Look forward to the next time.
Thanks a lot for your time and enjoy the rest of the conference. Thank you.
2021-07-22 11:03
