 OK, so hello and welcome to my presentation. My name is Kristina Quest. At daytime, I'm a normal embedded systems developer, but at nighttime or something, I like playing IT security, CTFs, or IT security war games, or go to security conferences to find out how to hack devices. And I felt like talking to my colleagues, many of my colleagues didn't imagine how the attacker thinks, like what the attack vectors are, what the view of an attacker is. And I wanted to bring this to a developer conference, this knowledge. So this is my agenda. In short, I will talk about software and hardware attacks and tell you some example attack stories I've seen in the last years. And let's start with what is IoT? So IoT were traditionally more analog devices like your light bulb or your garage opener or your baby monitor, which are now connected to a network. So often those devices are rather power constrained and memory constrained, and oftentimes less secured because you don't care about security. Well, somebody hacked my IoT light bulb. Why should I care? One of the reasons we saw in 2016, for example, there was this Mirai botnet, which was mainly created out of IoT devices, which now started to attack a distributed denial or service attack on Dundee NAS, so that DNS requests to some major websites like Netflix or Spotify or Airbnb failed. And the thing is those devices are still out there. This botnet still exists, and we don't know how many devices there are. So your device could be one of the one attacking. And the problem is not just you cannot pinpoint, like this manufacturer is to be held responsible because there's a supply chain which is rather large. We have CPCB vendor. Then we have the BSP, the broad support package vendors like Marvel and Broadcom, which create the SDK for you to work on. Then there's the ODM, the original device manufacturer, which puts his own SDK on top of it. Then a retailer, which puts his name on this whole package. And the OM, the original equipment manufacturer. So you have so many steps. You have so many hands touching the code, which introduce bugs as well. And also an embedded device has a large attack surface. It can be connected over a wireless connection. The firmware process can take place over a wireless connection, for example. It can provide a web server or mobile applications. So you have many places where you can actually try to attack. So let's talk about software. So what does the attacker do? First, he does the same that a normal embedded systems developer put us when he gets a device and no documentation. He basically tries to understand how this thing works. He tries to reverse engineer. He inspects the components, the data sheets, looks at the firmware update process, and looks whether he can tamper with that a bit. He looks at the flash content, which is already on the device. So if the firmware is some well-known and well-documented architecture, like ARM or PowerPC or MIPS, is rather an easier task. Then you have ASICs, which are, let's say, average easy. And then the most complicated are FPGAs, because the FPGA is just hardware. So the vendor can have put any program, any bit stream on it. And it's hard to figure out what he actually put on it. And the more PCB layers your device, your board has, the more complicated it gets to analyze. And then the attacker, he would tamper with the firmware update process. He would try to rewrite some parts of the memory. Also use the JTAG channel, for example, or other debug channels to have a feedback and establish a communication channel over serial or JTAG to see what kind of effects his changes have. So if you want to analyze the software running on this board, where do you get this firmware? In most cases, you can dump it from the flash memory, or otherwise you can look around whether you can find the firmware on the FTP server of the manufacturer. There are also FTP index sites where you can search. Some devices come with CDs or DVDs where you can search for the firmware. Or a very good attack vector is looking at ViyaShark. So if the firmware update process takes place over an unencrypted connection without TLS, then you can kind of dump the firmware out of the data which was transmitted. Or if it's not just the blob, you can analyze the firmware and look at the firmware update routine and see how or which part of the binary blob you just dumped is mapped in memory later. Furthermore, in firmware, you sometimes find code or strings. And you can search on the known websites like code.google.com or sourceforge.net or something. But you can recognize some open source software which was just taken from a Chinese manufacturer and put into this box. Then, yeah, you can decompile, you can recompile, you can change some values. You can fast the device, so send random data to it and see whether it crushes. And for example, if the firmware is not stripped, so it has some debug symbols in it or if you find human readable strings in it, it's easier. But once you get the hang of it, if you're really good at reversing, it doesn't keep you from reversing this anyways. So what kind of software do we use? One of them we see on the top right on the slide. This is a screenshot which I took from IDA. So IDA is like more or less the standard, which is used nowadays by reversers. It has a nice GUI and lets you look at the code flow. Then if you are more into open source command line tools, there's Rodara 2, which is being developed. And I heard a new up-and-coming as binary ninja, but I didn't try it out yet. And then for finding bugs in your software, you can use Floorfinder or the Metasploit framework. Metasploit is more, it's like a set or a database of exploits which you can just launch on a target, even if it's remote. And it will automatically perform those attacks. Then there are some tools for firmware analysis, like Firmworker. Firmworker, it uses Spinwork, which will go through a binary blob and it will be searching for headers, for example, which it can recognize. And then it will print you the files which is possibly found in this binary blob and you can extract them. It uses CPU-REC to recognize the architecture the firmware is written for. And it has also the firmware analysis toolkit or a rather academic project, the effects, the firmware analysis and comparison tool. And if your IoT device exposes a web server, you can use the usual tools like SQLMap to find SQL injections or SSLies in order to see whether you configured your server right for SSL or Go Buster. For an extensive list, I recommend you to check out the OWASP website, the Open Web Application Security Project which kind of has more extensive knowledge and put it on their list. And for interfacing with your device, you would use the usual ones, for example, GDB and Open OCD. So in terms of hardware, there are three kinds of attacks. You can have non-invasive attacks, you can have semi-invasive attacks and fully invasive attacks. So for non-invasive attacks, you don't have a direct chip access. You only have the external signals and you try to work with those. For example, you can search for the UART or JTAG and try to interface with your device and get control over it in this manner. Or if the right protection, security fuse is not enabled, you can change the boot loader, you can patch it and let it load your own firmware. You can do hardware fuzzing. Like I would estimate that one out of 10 hardware or the creatures, or do you know what fuzzing is? Fuzzing is you're sending random data to your hardware and see whether it crashes. And I guess like one out of 10 crashes, you can actually, you can create an exploit out of that. And then there are other side channel attacks like timing attacks. For example, if you have a computation, which depends on the value of the secret data. For example, you have your secret and you have the user input and you are comparing the first character and do a break out of your while loop if it's not correct than the second character and so on. So it means like the more characters you have right as an attacker, the more time it will take for the device to respond. And so you can bootforce one character after another in this manner. Also cache miss and cache hit times have a huge timing difference. So which is also used for example, in Spectrum Meta in those cache timing attacks. So you can always find a pattern in those different timing differences. So basically in this kind of attack, you trace instructions, you access register values, you can modify media memory content or extract code and data, but you're not actually physically opening up to chip. Yeah, there are other non-resif attacks like side channel attacks. For example, hardware glitching is when you apply a voltage which is too high or too low or higher or lower than what your chip originally expected. And you hope for funny effects or that your chip calculates any manner which is not expected and makes a mistake and you can use that to hack it or get more information about the secret. There's also glitching attacks where it can alter the clock period during the execution of a program and have a similar effect. Then there's power analysis. If the power consumption of your device depends on the secret data which is computed at that moment, you can get information from that and I will be presenting an attack on that later. There's simple power analysis where you're directly looking at the power traces, but there's also differential power analysis where you kind of correlate the power traces you took and if your correlation criterion is right, you get a peak in your There's also AM radiation, channel attacks or acoustic channels. So all the side effects of a computation you can try to find a pattern and get more information about the secret. Then there are semi-invasive attacks where you actually decap a package and then you can shine infrared light onto this chip and with a certain probability, a gate which switches will emit a photon. In this manner, you can find a location for your attack. For example, in the picture we saw before, here you see emitted photon from your chips and you can assume that the brighter areas are gates which are switching a lot. For example, the brightest spot you see on the left would be the clock or up there, for example, memory address accesses. But the problem with laser glitching is you have an unknown timing. It's more or less trial and error because you're shooting this laser on a big area and you hope that the chip does an error in his calculation. So if semi-invasive attacks didn't work, then you can try fully invasive attacks which require much more effort but you have a 100% success rate. So you can use a focus ion beam to remove or put material on the chip and, for example, create micro probing pads. So basically you can analyze any pad or any signal in your chip you want but obviously it costs much more, it takes more time and knowledge to do that. But fully invasive attacks are mainly used if you have countermeasures put in place in hardware and you want to circumvent it. So mainly for the non-invasive attacks, those are the tools which are used. The oscilloscope for just looking at logic signals or a logic analyzer if you want to analyze UR, for example. Then for JTEC there are good open source alternatives as well. For example, the GoodFed created by Teras Goodspeed or I've heard many good things about the Blackmagic probe. Then for the side channel attacks I mentioned like power glitching and so on. Two years ago you had to make your own set up using an FPGA because that was the only thing which would get the timing right. But nowadays you can take the chip whisperer to do glitching and power loss for you out of the box. You can use the FaceDancer which is based on the GoodFed to do some whole site Python scripting and to fast test your USB device drivers. And if you want to do SDR, software defined radio, there are the HackRF and actually more devices which I didn't list here that you can use. The HackRF is a great Scott Gadget device which can send and receive from one megahertz to six gigahertz. So let's go to some real world attacks. This was theory, now let's go to practice. So there was this nice video which I really recommend to you which is called Hack All Things, 20 devices and 45 minutes where they presented how they, yeah, owned 20 devices really fast in a very entertaining manner. So one of the common attacks was just connecting to UART and often time you just put into a console where you have no password or a password which you can guess easily and you can replace the image device that's running using this console. Sometimes the UART is populated, sometimes it's not, but even if it's not populated, you can easily just put your own connector on it, solder it on the board. What else did it was, for example, change some parameters of the kernel command line. Like if for example, like when you block yourself out of your computer, you boot it up and you put in it equals bin s h into the kernel command line and would directly boot up into a shell. And from here you can, yeah, mount devices, you can replace the image and put your own firmware. Also often bootloaders, they try to execute a preconfigured script and you can just, if you have access to the memory, you can just put a script with the same name instead of that and it will boot up with your firmware. One attack which if those two don't work, you can try to short the pins of the NAND which contains the bootloader and maybe one out of 10 times it will boot up into a corrupted U-boot environment where you have control and you can again replace a firmware. Because the thing for the attackers, you just have to get it right one out of 100 times and you hacked your device. As a defender you actually have to get it right 100 times or your device is corrupted. Sometimes they analyze the firmware and they found out coded or base 64 encoded user names and passwords in the binary. Yeah, base 64 is not encryption, it's just encoding. It's basically easy to decipher. Also brute forcing worked on some devices because many manufacturers would just use brute and manufacturer name as a password so you can easily get in. What else? They had access to an EMC or they wrote a SUID binary on the EMC which uses a similar protocol to whatever an SD card reader is using and afterwards they executed the SUID binary on the device and got root that way. Other devices, they took user input unsanitized and put it into a system function for example. And obviously if you put Zemicolon reboot Zemicolon your device will reboot and you can put any system command or batch command you want in that. Often WEP or Wi-Fi password fields of the configuration page were not sanitized. They would just take whatever you give to it or network folder names who would put any batch commands into a network folder name, right? They are trustworthy. Or URL parameters. Sometimes they could just execute a command by just passing it to an URL. Also if the firmware update takes place over an encrypted channel, for example, just plain HTTP or FTP, it can be intercepted. They can put a man in the middle attack in place so you send your firmware, I modify it and I send it further to the device you want to update and well, I control the device now. Then this one was a rather academic attack. They attacked a PLC, a programmable logic controller which is used a lot in industry and they tried to downgrade to an older firmware version but it didn't work, it didn't let them do that. They searched for JTAG or something similar, they didn't find it on the board. They tried injecting code on the web page of the manufacturer to do a firmware update and put their firmware on this device but it didn't work. They assumed that maybe the firmware was, there was a checksum over the firmware or the firmware was signed so that's why it was not taken. So they ended up actually modifying the board. So the flash chip which contained the first stage boot loader was right protected using a pin and they soldered this pin and could alter any data on this flash chip. Then there was an attack on an electronic safe lock by Plur which was presented at DEF CON 24. So what he had was a metal box and outside of this metal box he would have a keypad, a buzzer and a battery and inside behind steel doors there was a lock and MCU and E-prom and a bolt motor. So between those two inside and outside there was just one hole to pass the wires through. And the good thing was that inside the MCU and the E-prom they were connected by a direct line which was connected to a pull-up. So every time the device would read a zero from the E-prom the voltage drop over the pull-up would be higher so he could record a higher current taken from the battery. So he could look at the power trace directly and say okay this one is a zero, this one is a one. So how can you mitigate this kind of attack? Yeah so he would put any combination of numbers in there. He would read on the power trace the real secrets which was read out from the E-prom and he could put in that real secret afterwards. And you can protect yourself against those kind of attack by for example storing the hash instead of the real secret. So the attacker can just see the hash but he doesn't possibly know how the hash is calculated. And the second attack he did so this easy attack didn't work on this block. So he did timing attack, the one I described before where you have this Y loop where you compare the real secret character to the user input one by one and if there's one mismatch between characters encountered you just break out of the loop. So you see it in the power trace the more characters he got right the more digits he entered were correct the longer it took for the lock to respond. The problem in this case was after five tries he got locked out for 10 minutes. So brute forcing is not so easy if you have to wait 10 minutes between the tries. But he got lucky because normally in the E-prom if you reset it, it would be reset to zero X F F so everything is one. But in this case the E-prom, in this case the E-prom was an STM 8S. So when you reset it, it was reset to zero. So he had this small time window of 500 microseconds after and he counted the number of tries he performed was stored in E-prom as well. So in order to write a new counter value in the E-prom the counter is set to zero before it's initialized with a new value. So he had a 500 microseconds timeframe after the write starts where this counter would be at zero. And if he applied the brownout voltage exactly at this moment in time he would have gained infant amount of tries because the counter would be reset to zero. And how can you mitigate against this attack? You can do constant time comparisons. So basically you check all the values and then you give back whether the key code entered was correct or not or using hash secret. So you actually have to wait for all the inputs from the user, you calculate and then you compare. So another question is how do you protect against that? Well, you can start with protecting against buffer overflows, stack overflows, heap overflows by comparing rigorously the buffer bounds. Don't use the unknown unsafe functions like gets or string compare. Use the saver functions like f, get, s or string and compare which takes into account the buffer size. Then many compilers have secure compiler flex where you can disable or enable the nx bit of the stack. So the stack becomes non executable. You can activate the stack protection and so on. Also build systems like Yocto and build route will have flex for that or you can enable it in your, there are some secure options in the kernel which you can enable via menu config. Then if your device has a web server, you should protect against SQL injections or cross-site scripting. Instead of black listing commands, you should white list your commands because you should never underestimate the creativity of an attacker and never directly take user input and put it in system or something. Always sanitize, always validate input coming from the user. Don't trust user input ever. So if you do firmware updates, always do it over a secure channel. Always do it over a TLS because otherwise, yeah, you can just man the middle of this update. Don't do your own crypto. There are so many libraries which you can use where many eyes have looked over and which are tested by many people. Don't reinvent your crypto reel. Maybe also implement an anti-rollback protection because often older firmwares have known bugs and a hacker could just reinstall an older version and apply the bugs, which were bugs two years ago, five years ago. Don't have hard-coded secrets in your firmware. Always don't put user names and passwords and so on as hard-coded secrets into your firmware or in non-protected storage. Like for example, EEPROM or flash is not a safe storage. You should not put your keys in there. And if your platform has a trusted execution environment like trust on for ARM or SGX for Intel, you should try to use that. Do identity management have different user, have different accounts for web management and for remote console access? Don't put tokens and IDs and cookies into the URL because the attacker can just sniff it and replay it. Especially don't use tokens which can easily be guessed like sequential numbers one, two, three is not a secure token or current time is not a secure token. You can guess that. Use secure passwords for logins for the URL for example. And in the best case, you would have an individual secret for each device to deliver because otherwise one device gets hacked. All your devices are compromised. If you have one password per device, it's only this one. Then how many of us have unused language or shell interpreters in our devices? How many bash and dash and ash and ZSH we have in this devices which we never use or libraries? The more attack surface an attacker has, the more tools he will find to exploit the device. So reducing the attack surface is one of the protections against hacking. Also disable ancient legacy protocols like FTP and Telnet. You would be surprised how many devices are out there which I still use that. Remove debugging interfaces because the hacker can also enter from there. And also manufacturers often have those management interfaces where they can do customer support where they have either and very easily put possible password or no password at all. And oftentimes those interfaces come with a root privilege. Yeah, if possible, tag third party code and SDKs. I don't know whether it's always possible. There are tools you can use for that. Keep your kernel, your framework, your libraries up to date. For example, using a package manager and check whether the tools you use are vulnerable. There are many vulnerability databases and you just enter the version of the tool you're using and see whether it has known vulnerabilities. Or you use one of the tools recommended by OWASP in order to check third party code or components or do some static analysis on it and it will tell you where there might be possible bugs. And do thread modeling. Like get in the shoes of an attacker and think how, through which port can he enter? Like what are the possible vulnerable parts of your device? And once your device gets compromised, how do you treat with it? How do you contain the damage which is done? So if you didn't take in very anything from this lecture, maybe those points. So the main attack vectors for devices are crypto or the web interface or old firmware which still has bugs from 2000 or doing a firmware update process over an unencrypted channel or having the attacks passwords in your binary or storing secrets in an unprotected place. And so maybe it's a good idea to integrate security tests already in your continuous integration or your development cycle instead of in the end after your product is finished and ready to be shipped to find some security vulnerabilities and not have the time to fix it afterwards. And also there's basically not a way of how you can really secure your system 100%. It just makes it harder for the attacker or more so that you would have to invest more cost or more time in order to hack your device but it's never impossible. You just try to get the bar as high as possible so basically that he will attack the other manufacturer not you. So do you have any, thank you for listening to me renting and do you have any questions? So you recommended each device having their own secret for the keys and such and I agree that's a great idea. Do you have any suggestions on tools to help manage like thousands or tens of thousands of keys across out there? I didn't try out anything but maybe mentor since they have tools to do firmware update processes securely maybe they have a solution for that but I don't know, you would have to talk to them. Yeah, I know more of the attacker side than actually how to protect it because it's really hard to protect. Thank you.