IoT from an Attacker's Perspective

Hello everyone. For our next talk, we have Vinkant with us and he will be talking about IoT from a hacker's perspective. Vinkant is a security researcher. Hi Vinkant. Hey, hello. Hi, and I'd like to just speak a little bit more about yourself and then we can just begin the talk. All right. Yeah, perfect. So, thank you. All right. Yeah. Today's talk is about from an attacker's perspective. And so a quick introduction about myself. I am a security researcher at one of the largest semiconductor manufacturing company. And I have been performing security assessments in different geolocations for the past seven odd years. And I have been contributing to

UC Council as a scheme committee, as well as a review board member. And I have also given talks and a bunch of conferences and forums. And yeah, this is what I have been doing on a daily basis, a range of pen tests. And in the recent past, I have started working on Linux kernels, container technology, as well as connected technology.

So moving on to our presentation today. So the agenda is to understand what is IoT and what are the components that go into building an IoT solution. And we'd also be looking at the attack surface and what new attack surface is introduced in IoT as compared to a typical web application or a mobile application solution, right? So yeah, we'd also be looking at each component or rather each attack surface from an attacker's perspective to see how each of it can be compromised and hence exploiting those vulnerabilities to take over the IoT solution.

So a quick disclaimer, so the content of this talk is purely based on my opinions and I do not represent my employer, right? And we would also be talking a lot about, I mean, certain tools and some hardware components. I mean, I do not endorse them, but yeah, there are other options that, I mean, that you could choose this is just here for illustration or as an example so moving on to an iot i mean to have a quick look at an iot foothold so we have internet of things or connected technology and a variety of industries now So we have it in retail space, transportation, infrastructure, home automation, healthcare, etc. So

today we'll be looking at the IoT security posture. with references to home automation because that is something that we can easily relate to in terms of understanding the security concepts of an IoT solution.

So moving on, so this is just to give you a quick idea of what kind of kinetic technology we have in each vertical So, I mean, as a home consumer, I mean, there are a bunch of things that are connected to internet now, I mean, including light bulbs, security cameras, even our coffee machines these days are connected to internet, right? So, yeah, when in the past few years, there is a,

There is a boom, I would say, in terms of the devices that are being connected to the internet and

enabling us to control them remotely over the internet. So, I mean, the same is applicable to transportation as well as our healthcare. So transportation, we already have a bunch of autonomous driving vehicles, including cars and I mean, certain aid as being introduced in consumer cars, right? So

we would be looking, I mean, we'd be diving deep uh on the home automation side of things in the upcoming slides and this is a quick uh description or a definition of internet of things as in wikipedia so uh internet of things is nothing but uh i mean like internet is a network of networks so internet of things comprises multiple devices in we'll be talking about those devices in the upcoming slides and so what i what an iod solution does is bring all these connected connected devices together and provides provides a user to automate certain routines as well as control those devices from a remote location So that is the whole agenda of an IoT solution. Basically to

automate mundane tasks from a home automation perspective. So this is a quick overview of Samsung's SmartThings architecture. so we can see that there is a smartphone application here that in turn connects to the home internet router and that in turn talks to the smart things hub and the hub is connected to multiple devices so the the hub essentially needs to speak the same language as the devices that we are trying to connect to the solution. In this scenario, we can see that there is a Z-Wave device as well as a ZigBee device. So what that means is the hub essentially should, I mean, should be able to speak the same language or should be able

to communicate using these two protocols, right? And so as IoT matures, we today have a bunch of protocols

which which do not necessarily need a hub separately but i mean basically we are seeing a solution which combines our home router as well as the hub so that is still a work in progress but uh yeah maybe in the near future that is something that can be i mean that would be found pretty uh that should be pretty common uh side and so the the data that the devices collect uh is sent to the cloud service i mean given the size and compute capability of the end devices uh i mean majority of computation happens in the back end on the cloud servers and that is what uh the SmartThings cloud services node represents. And the red lines connect to

Alexa and the green connects to Google. So what this represents is third party integration. So this is how a user is able to control a Samsung device using Google Assistant or Amazon Alexa. So this gives us a quick overview of typical IoT architecture. Let us go, let us do a little dive, a little deeper into the solution, right? So this is a quick, this is a look at the app registration flow of an appliance. In this case, we are looking at registering a refrigerator. So, What this shows is once we plug the device, right, and there is a request that goes to the AWS API Gateway, which triggers the routine to register the appliance and the data,

I mean, in this case, the user that it is registered to, as well as the appliance ID and so on and so forth are stored. the database and this date this data is further used to identify the device and transfer i mean data back and forth so uh the same so this is this gives us a quick uh i mean this gives us an overall idea of how how the registration flow happens and uh This also shows us like majority of the computation happens in the backend services.

So these are a few, I mean, these are certain bare minimum components that an IoT solution typically requires. So I mean, each IoT solution would have some kind of a device, sensor or an actuator. and there would be an operating system. So when you say operating system, this usually is RTOS, real-time operating system, which is pretty small and with a lot of limitations as compared to a full-fledged operating system like an Ubuntu or a Windows operating system. And

there usually is a mobile application or web application that provides the user with an interface to connect or interact with the solution and control the devices and we also talked about how briefly in the previous slides so the hub acts as a data aggregator so the hub is what collects the data from the end devices and transfers that data to our backend cloud infrastructure. So the communication happens via internet. However, the communication between the hub and devices may happen over Bluetooth or other protocols that we will be looking at the upcoming slides. So from a security standpoint,

the CIA triad holds true for IoT solution as well, where the

three pillars of security remains the same, right? Confidentiality, integrity, and availability. So when we say confidentiality, that means the state of being secret, meaning the data that is collected by the devices or provided by the user or generated over a period of time needs to be secure. And integrity means that the same data is not, I mean, it should not be modifiable by unauthorized entities uh for example the data of user a should not be available to or should be provided to a user b for instance as well as availability is something that so when we say availability the data should always be available i mean if there is a loss of data then the then there is a high probability

or it obviously means that there is a service disruption that can occur. So these three pillars are something that we would have to take care in an IoT solution. And moving on to attack vectors, we have three attack vectors in IoT solution. They are physical, local network and remote. So when we say physical, it means an attacker having access to the end device. In our scenario, this can be a light bulb, it can be a hub that is connected to a home network. And local network is nothing but the local area network, which can be connected a home wi-fi network and remote is the broader internet so if if there is a an exploit that can be leveraged from a different geolocation

then that would be categorized as a remote attack and yeah these are uh basically the attack surfaces uh often for for any given IoT solution. And so this includes our device hardware, firmware, memory, local storage, operating system, software update mechanism, network communication, web interface, mobile application, cloud infrastructure, as well as third party interaction. So arguably the device hardware firmware are some of the newly added attack surface for IoT, which are not that prevalent in a typical web or mobile application scenario, right? So we would be looking at it a little in depth. And so what is a device or what is a thing in IoT, Internet of Things, right? So a thing is nothing but an embedded device. so

here we take an example of a bulb so a typical bulb would just have a filament or an ld or an led that lights up when we turn on the switch so in this case we have we have a logic board that is connected to the led so this enables us to control it

remotely so this is how we are able to send a bunch of commands to delight to turn on or flicker or do a bunch of i mean like change the color of it and so on and so forth so this is an example of a thing and moving on to device hardware so talking about device hardware uh since i mean an iot solution would have a huge number of connected devices right so each and not all devices are physically secure in terms of i mean there may be a few devices that are a position uh in your backyard which is not as secure as compared to something that is placed uh within uh I mean, inside our house,

right? So this opens up a lot of attack, I mean, possibilities for an attacker to be able to compromise the network leveraging these hardware, I mean, physical devices. So we'd be looking at a few common scenarios here. And so each logic board, I mean,

typically has either of these debug ports. So, okay, so these days we do not, I mean, there is a requirement that say, I mean, as a security best practice, none of the debug ports should be present in a production ready device, but not all manufacturers follow this pretty strictly. And even though the port is, physically removed those connections are still in place, which I mean an attacker could easily solder pins onto those connectors and regain those debug functionalities. So yeah, so a bunch of debug ports such as JTAG, UART, SPI or I2C can be leveraged to connect to the device. And so here in the photo, we can see that there is a JTAG which is available on the device's logic board. And

so what this enables us to do is, for instance, this is the, so the device that we see on the right hand image is a logic analyzer by Saley. So what it does is it connects using a bunch of probes to any given logic board. and we would be able to connect uh to our laptop via a usb port and so we'll be able to monitor the communication and also look at uh i mean eavesdrop on the uh serial channel communication so so the left image shows how uh the logic analyzer is connected to the board and the right uh image shows uh the logic analyzer itself and how it connects back to our laptop or computer.

So this image shows a typical serial communication. So for instance, let us say there is a UART code and basically we connect the VCC ground and our TXRX. back to our laptop and once the device is enabled once we turn it on we would be able to look at the communication that is happening over that that particular serial channel so we can see a bunch of channels over here and this is the data that is being transmitted back and forth and

this is a cap this is a uh packet capture uh that um that i did on one of the smart bulbs that i was looking at earlier and we can see that uh i mean the uh this is basically an mqtt packet and we can see the username being transmitted uh in clear text over here so i mean we could also this particular uh image i don't think it has the password but yeah typically we could also capture the password of the MQTT connection. So moving on, so another way, the another thing is, so an attacker or rather, so if the shell, I mean if the UART shell or the UART shell is not properly protected, right? So, if the UART

shell you could directly gain root privileges on the shell and what this enables you to do is you could you could leverage this device I mean majority of devices come with some kind of SSH servers or In some devices you also have a full-fledged busybox which would help you use this device to connect to the home network and eavesdrop on other devices connected to the home router. So this is another elaborate attack that could be performed by leveraging insufficiently secure hardware. and yeah as we uh talked earlier so uh device root shell is something that an attacker uh i mean uh typically looks for so what what this does is uh either you capture the credentials uh using one of

the earlier methods or you could also connect uh connect using a jtaculator for instance to uh directly jump onto a root shell of the device which would essentially allow us it would basically give us a terminal that we could use to eavesdrop on other devices and also also place a backdoor that would give a connection back to an attacker's machine which can be leveraged at a later point of time to connect back to the home network and again spy on the other uh devices not necessarily not necessarily an iot device but it could also be a laptop connected to the home network and uh device uh firmware uh uh since the uh onboard memory is pretty uh

limited on on a typical iod device a firmware tends to have uh all your applications and services required to run on the device and enable a bunch of features. So since it is all packaged together into a single firmware, there is a high possibility for residual debug functionalities and there may be a bunch of services that are not used anymore, but they are still present in the firmware, which can be enabled pretty easily. and uh a firmware could also be a i mean it could also hold a bunch of sensitive information like credentials there could also be a backdoor that was created for debug functionalities but it it ended up in the production device so these are some

of the things that an attacker would be looking at in a firmware So to actually get the firmware, you could dump the firmware directly from a device. You could also capture the firmware during an over the year update or by, for instance, let us say there is a device that updates its firmware over wifi and if an attacker is already placed in a man in the middle situation he could eavesdrop and he could capture that firmware so that is another way the other way is to download firmware updates from update repositories there are when some OEMs provide have a repository that is accessible by public to download their firmwares and capsule updates which can uh be

downloaded by attacker uh for i mean usually an older device uh does not tend to get uh firmware updates so uh an attacker could leverage an older firmware and um come up with an exploit which can be used on those devices that are still in use. And so these are a few tools that one attacker can use to extract the firmware and dissect it. For instance, bin work is a pretty common tool that is used to extract file systems from firmware and analyze it. Same goes, I mean, even the from where modkit could be used for similar purposes. And so the first image shows us, I mean, it's the photo of a JTAGulator. So JTAGulator is something that we talked about in terms of connecting to, I mean,

this could be used to connect to the JTAG port on the device. And so this, The JTAG later works as kind of a plug and play, right? So it comes with its own application that can be installed on our laptops and it, so all you need to do is connect the VCC and you should connect the JTAG later to the appropriate JTAG port on the device. And you, all you need to do is enter the appropriate board rate and if the device does not have sufficient security mitigations in terms of having us I mean there are a bunch of devices that don't even ask for a password before letting you into a shell. So in those scenarios, as soon as you plug in, you would

directly be provided with UR shell with root privileges, which you could abuse, right? And yeah, the second image was a bus pirate. So in case you do not have an update firmware repository or you're not able to get the firmware via OTA, then this is another, uh way to extract firmware from the device so this typically connects to your debug ports and you could leverage it to download the firmware from the device itself so these are some of the ways how you could interact with the device itself and yeah what to do once you get your hands on a firmware is to look for encryption algorithms and the cryptographic secrets like i mean there are they have been scenarios where the

firmware has the private key or it exposes too much about the encryption algorithms and it also tends to hold the hard credit credentials and the backdoor accounts uh backdoor services and also may have some endpoints that are API endpoints that are not typically exposed to the user, but they are in place for debug purposes. And

these are some things that can be extracted from a firmware and later leverage to compromise the solution. Moving on to device memory and local storage. So as we do for, I mean, typical Windows application, so,

volatile memory is something that still plays a vital role here in terms of holding,

like, sensitive information. I mean, you could, there are, so there are a bunch of devices that also rely on external storage like an sd card because i mean provided because of the

i mean limited uh onboard storage right so usually the firmware uh is first downloaded on downloaded onto an sd card which is later loaded onto the flash memory and there is a lot of application data that is offloaded to an SD card. And so this is something that we can look at. So the application data stored in SD card could hold again, sensitive information like your credentials or other application data like tokens, authorization tokens, et cetera, et cetera. So these are something that can pay way for an exploit. And yeah, moving on. So we have been talking a lot about the hardware security, but

security of an IoT solution does not just it's not limited to hardware security but we'd also have to look at a bunch of other things starting with the operating system as we i mean we discussed this briefly earlier the operating system so again the onboard memory is pretty limited when it comes to a iot device and this meaning the operating system that is uh that runs on the device also is pretty limited and it doesn't have essentially all the security mitigations or security features that more mature operating system like ubuntu or windows have right so for instance we do not have address based layout randomization or we do not have depth we do not have ach all those security features are

not available in a typical artist that is run on an IoT device. So this means that we would have to, I mean, the developers and the validation team would have to take extra efforts to avoid buffer overflows and also make an extra effort to look at the memory handling because Since we do not have these mitigations in place, I mean, if there is a buffer overflow condition, then it is easier for an attacker to exploit that while compared to other mature operating systems. So these are some things that have to be taken into account before releasing the product to the wider consumer base. and we would also have to look for misconfigured or vulnerable services again because because we do not because

the operating system is pretty small in size and lacks a lot of security features we would have to the developers would have to take extra efforts to

look for vulnerable services and also look at any any unused syscall system calls that have to be removed and so on and so forth so moving on to software update mechanism a typical software update mechanism includes a smartphone

which usually downloads the firmware onto its local storage and later is pushed on to the device via Bluetooth.

So there is a bunch of things that can go wrong here, right? So an attacker could position themselves as an MITM and could tamper with the firmware before it is actually sent to the device. and uh this is just an example right so the way to uh mitigate this is to have proper uh signature checks in place uh so uh the device should not uh directly trust uh the incoming firmware and uh flash it onto the uh onto the device but it should have a proper signature verification process which uh which validates the origin of the firmware and then go ahead and flash it. So there is another way this can be used, right? So usually the devices they come with

rollback mechanism. So when an incoming firmware is not validated properly or if it doesn't match, I mean, if it doesn't pass the signature verification, then there is a backup firmware that is again, that is installed as a part of the rollback mechanism. Oftentimes the the firmware that is in the uh flash memory uh as a backup is not uh is directly is trusted and is uh installed directly without any uh signature verification so that is something that uh also should be taken care of uh because an attacker could uh replace that particular firmware and uh he could trigger an update with uh invalid firmware and trigger i mean and figure the rollback mechanism which would uh install the malicious firmware onto the device

and moving on to network communication so yeah there is a bunch of protocols that are used in an iot solution so usually the devices talk to the hub using uh MQTT, ANMC, ZigBee, and C-Wave. And they have in turn connects to the backend services over Wi-Fi and cellular. And there are a few home, I mean, connected devices at home that directly connect to the router and communicate over Wi-Fi. And so there are a few tools that can be used to capture this communication uh to capture these packets and analyze them for uh unencrypted data and also capture certain requests which can be replayed at a later point of time to trigger the same action that was performed earlier and

so a hacker of one is a pretty common tool that is uh used by attackers to capture uh packets uh uh sent over a bunch of i mean this this also has the capability to capture your cellular communication so this is a pretty robust tool and overtooth one is exclusively used to capture uh your bluetooth packets and uh so if the bluetooth communication is not secure it does not adequately secure this could help us in terms of capturing uh bluetooth packets and also let us replay certain packets to achieve i mean to perform a unauthorized action in for instance turn on the light if I mean, we could send the command to turn on the light by

just replaying the exact request because that already holds your authorization token and et cetera. So from the software side of things, we could use Wireshark to, let's say we are able to connect to the home network and Wireshark is a good tool from a software standpoint to capture the traffic and also analyze the capture packets. We would be looking at one of the packets in the upcoming slides. So this is how a wiretruck GUI looks like. And again, this is an MQTT packet that I captured the, uh, with one of the smart bulb communication. So here we can see that the username as well as the password is being sent over clear text and anyone connected to the network could easily capture this request and they could

authenticate themselves the next time around they want to connect to that particular device. So I mean, yeah, this is an inherent issue with an MQTT connect and which which usually uh sends out both username as well as the password and clear text so and so we we also need to look at the web as well as mobile applications and we have been i mean attackers have been looking at these applications for a long time now relatively longer time while compared to the hardware devices that have been introduced by IoT solutions, right? So the

typical things that can go wrong here is, as we discussed earlier, there could be certain API endpoints that are not that were not developed for end users usage but for certain debug functionalities or for as a service api so those could be exposed to to the use to the attacker which can be later abused for performing malicious activities like performing unauthorized

actions in terms of again, switching on or switching off bulb in the home network. So this is a quick look at Shodan. So Shodan is something that shows you, that gives you an idea of all the connected devices globally. So let us say there is a there is an exploit of one particular baby monitor web application right so you could use easily use uh shodan to uh get a list of all uh all the uh web uis that are connected uh to the internet uh and you could directly uh replicate that exploit on all those devices globally and essentially what would this would give you with uh access to a bunch of network uh and i mean you could you could again uh compromise

the whole uh home networks this way by sitting in a different uh geolocation altogether

and so this for so we just looked at mqtt earlier right so you you could just uh filter all the devices uh by uh the mqtt port which is 1883 here and this gives you all the devices that are connected uh and communicating over this particular port which is essentially mqtt communication

So moving on to cloud infrastructure. So cloud infrastructure is pretty pivotal in an IoT solution because this is where all the data is offloaded. And because we have a lot of devices connected globally, so the data is constantly being pushed to the backend services. and it is constantly being stored in the cloud infrared. So this information is extremely sensitive and I mean in the wrong hands this could easily be abused by malicious actors. So cloud, when it comes to securing a cloud infrastructure, the user accounts should be properly configured and the security patches should be up to date as well as

if a single server is being used for in a multi-tenant kind of a situation then the data isolation should be appropriate and the key rotation should be appropriate and the typical cloud security checklist or items should be, I mean, taken care of when it comes to any given IoT solution. So usually where this goes wrong is when a certain company goes with IoT less reputed cloud provider, which may not have adequate physical security or appropriate key rotations and security patch updation as compared to someone like AWS, right? So this is something that needs to be given an extra attention while going with a less reputed cloud provider. And third party interaction is something that we talked earlier. For instance, there is a

alliance called Matter, which brings together a bunch of companies, right? Which interact with each other. And when we say third party interaction, this is what allows a user to control a Samsung device as we discussed in our initial slide where Google Home, Google Assistant or Amazon Selects can be used to control Samsung device. So this is made possible by third party interactions. And so if the, so each company opens up their API, right? So each of the API endpoints should be adequately secure and also

uh should have appropriate uh authorization tokens and uh i'm sorry yeah the so these things have to be uh taken into account and the primary uh things that would go wrong here is uh the uh disclosure of uh pii and excess of shedding of device data and unintentional data leaks. So these are some things that have to be given. I mean, this requires an extra effort to validate each of the end point that is exposed to third parties. And source code review, and this has always been the best way to best place to identify any security gaps and the same applies here as well. And appropriate code analysis have to be performed prior production release. And the primary things to look at here are for hard-coded

credentials and any back doors that may be present, I mean, which who would have been introduced for debug functionalities and providing service and also look for insecure functions as well as look for appropriate input validations. And yeah, I would like to conclude this talk by saying that, I mean, every trading that security is not a step but a process. There are new security vulnerabilities that are identified and reported each day, right? So we need to keep a track of all the identified vulnerabilities and keep pushing mitigations or updates with appropriate security patches as and when new vulnerabilities are identified. And thank you all for very little bit. Thank you for attending this talk. And if

you have any questions, please feel free to post them on Discord. Thank you.