WEBVTT 99:59:59.999 --> 99:59:59.999 *preroll music* [filler, please remove in amara] 99:59:59.999 --> 99:59:59.999 Herald: Our next speaker for today is a computer science PhD student at UC Santa 99:59:59.999 --> 99:59:59.999 Barbara. He is a member of the Shellfish Hacking Team and he's also the organizer 99:59:59.999 --> 99:59:59.999 of the IECTF Hacking Competition. Please give a big round of applause to Nilo 99:59:59.999 --> 99:59:59.999 Redini. [filler, please remove in amara] 99:59:59.999 --> 99:59:59.999 *applause* [filler, please remove in amara] 99:59:59.999 --> 99:59:59.999 Nilo: Thanks for the introduction, hello to everyone. My name is Nilo, and today 99:59:59.999 --> 99:59:59.999 I'm going to present you my work Koronte: identifying multi-binary vulnerabilities 99:59:59.999 --> 99:59:59.999 in embedded firmware at scale. This work is a co-joint effort between me and 99:59:59.999 --> 99:59:59.999 several of my colleagues at University of Santa Barbara and ASU. This talk is going 99:59:59.999 --> 99:59:59.999 to be about IoT devices. So before starting, let's see an overview about IoT 99:59:59.999 --> 99:59:59.999 devices. IoT devices are everywhere. As the research suggests, they will reach the 99:59:59.999 --> 99:59:59.999 20 billion units by the end of the next year. And a recent study conducted this 99:59:59.999 --> 99:59:59.999 year in 2019 on 16 million households showed that more than 70 percent of homes 99:59:59.999 --> 99:59:59.999 in North America already have an IoT network connected device. IoT devices make 99:59:59.999 --> 99:59:59.999 everyday life smarter. You can literally say "Alexa, I'm cold" and Alexa will 99:59:59.999 --> 99:59:59.999 interact with the thermostat and increase the temperature of your room. Usually the 99:59:59.999 --> 99:59:59.999 way we interact with the IoT devices is through our smartphone. We send a request 99:59:59.999 --> 99:59:59.999 to the local network, to some device, router or door lock, or we might send the 99:59:59.999 --> 99:59:59.999 same request through a cloud endpoint, which is usually managed by the vendor of 99:59:59.999 --> 99:59:59.999 the IoT device. Another way is through the IoT hubs, smartphone will send the request 99:59:59.999 --> 99:59:59.999 to some IoT hub, which in turn will send the request to some other IoT devices. As 99:59:59.999 --> 99:59:59.999 you can imagine, IoT devices use and collect our data and some data is more 99:59:59.999 --> 99:59:59.999 sensitive than other. For instance, think of all the data that is collected by my 99:59:59.999 --> 99:59:59.999 lightbulb or data that is collected by our security camera. As such, IoT devices can 99:59:59.999 --> 99:59:59.999 compromise people's safety and privacy. Things, for example, about the security 99:59:59.999 --> 99:59:59.999 implication of a faulty smartlock or the brakes of your smart car. So the question 99:59:59.999 --> 99:59:59.999 that we asked is: Are IoT devices secure? Well, like everything else, they are not. 99:59:59.999 --> 99:59:59.999 OK, in 2016 the Mirai botnet compromised and leveraged millions of IoT devices to 99:59:59.999 --> 99:59:59.999 disrupt core Internet services such as Twitter, GitHub and Netflix. And in 2018, 99:59:59.999 --> 99:59:59.999 154 vulnerabilities affecting IoT devices were published, which represented an 99:59:59.999 --> 99:59:59.999 increment of 15% compared to 2017 and an increase of 115% compared to 2016. So then 99:59:59.999 --> 99:59:59.999 we wonder: So why is it hard to secure IoT devices? To answer this question we have 99:59:59.999 --> 99:59:59.999 to look up how IoT devices work and they are made. Usually when you remove all the 99:59:59.999 --> 99:59:59.999 plastic and peripherals IoT devices look like this. A board with some chips laying 99:59:59.999 --> 99:59:59.999 on it. Usually you can find the big chip, the microcontroller which runs the 99:59:59.999 --> 99:59:59.999 firmware and one or more peripheral controllers which interact with external 99:59:59.999 --> 99:59:59.999 peripherals such as the motor of, your smart lock or cameras. Though the design 99:59:59.999 --> 99:59:59.999 is generic, implementations are very diverse. For instance, firmware may run on 99:59:59.999 --> 99:59:59.999 several different architectures such as ARM, MIPS, x86, PowerPC and so forth. And 99:59:59.999 --> 99:59:59.999 sometimes they are even proprietary, which means that if a security analyst wants to 99:59:59.999 --> 99:59:59.999 understand what's going on in the firmware, he'll have a hard time if he 99:59:59.999 --> 99:59:59.999 doesn't have the vendor specifics. Also, they're operating in environments with 99:59:59.999 --> 99:59:59.999 limited resources, which means that they run small and optimized code. For 99:59:59.999 --> 99:59:59.999 instance, vendors might implement their own version of some known algorithm in an 99:59:59.999 --> 99:59:59.999 optimized way. Also, IoT devices manage external peripherals that often use custom 99:59:59.999 --> 99:59:59.999 code. Again, with peripherals we mean like cameras, sensors and so forth. The 99:59:59.999 --> 99:59:59.999 firmware of IoT devices can be either Linux based or a blob firmware, Linux 99:59:59.999 --> 99:59:59.999 based are by far the most common. A study showed that 86% of firmware are based on 99:59:59.999 --> 99:59:59.999 Linux and on the other hand, blobs firmware are usually operating systems and 99:59:59.999 --> 99:59:59.999 user applications packaged in a single binary. In any case, firmware samples are 99:59:59.999 --> 99:59:59.999 usually made of multiple components. For instance, let's say that you have your 99:59:59.999 --> 99:59:59.999 smart phone and you send a request to your IoT device. This request will be received 99:59:59.999 --> 99:59:59.999 by a binary which we term as body binary, which in this example is an webserver. The 99:59:59.999 --> 99:59:59.999 request will be received, parsed, and then it might be sent to another binary code, 99:59:59.999 --> 99:59:59.999 the handler binary, which will take the request, work on it, produce an answer, 99:59:59.999 --> 99:59:59.999 send it back to the webserver, which in turn would produce a response to send to 99:59:59.999 --> 99:59:59.999 the smartphone. So to come back to the question why is it hard to secure IoT 99:59:59.999 --> 99:59:59.999 devices? Well, the answer is because IoT devices are in practice very diverse. Of 99:59:59.999 --> 99:59:59.999 course, there have been various work that have been proposed to analyze and secure 99:59:59.999 --> 99:59:59.999 firmware for IoT devices. Some of them using static analysis. Others using 99:59:59.999 --> 99:59:59.999 dynamic analysis and several others using a combination of both. Here I wrote 99:59:59.999 --> 99:59:59.999 several of them. Again at the end of the presentation there is a bibliography with 99:59:59.999 --> 99:59:59.999 the title of these works. Of course, all these approaches have some problems. For 99:59:59.999 --> 99:59:59.999 instance, the current dynamic analysis are hard to apply to scale because of the 99:59:59.999 --> 99:59:59.999 customized environments that IoT devices work on. Usually when you try to 99:59:59.999 --> 99:59:59.999 dynamically execute a firmware, it's gonna check if the peripherals are connected and 99:59:59.999 --> 99:59:59.999 are working properly. In a case where you can't have the peripherals, it's gonna be 99:59:59.999 --> 99:59:59.999 hard to actually run the firmware. Also current static analysis approaches are 99:59:59.999 --> 99:59:59.999 based on what we call the single binary approach, which means that binaries from a 99:59:59.999 --> 99:59:59.999 firmware are taken individually and analysed. This approach might produce many 99:59:59.999 --> 99:59:59.999 false positives. For instance, so let's say again that we have our two binaries. 99:59:59.999 --> 99:59:59.999 This is actually an example that we found on one firmware, so the web server will 99:59:59.999 --> 99:59:59.999 take the user request, will parse the request and produce some data, will set 99:59:59.999 --> 99:59:59.999 this data to an environment variable and eventually will execute the handle binary. 99:59:59.999 --> 99:59:59.999 Now, if you see the parsing function contains a string compare which checks if 99:59:59.999 --> 99:59:59.999 some keyword is present in the request. And if so, it just returns the whole 99:59:59.999 --> 99:59:59.999 request. Otherwise, it will constrain the size of the request to 128 bytes and 99:59:59.999 --> 99:59:59.999 return it. The handler binary in turn when spawned will receive the data by doing a 99:59:59.999 --> 99:59:59.999 getenv on the query string, but also will getenv on another environment variable 99:59:59.999 --> 99:59:59.999 which in this case is not user controlled and they user cannot influence the content 99:59:59.999 --> 99:59:59.999 of this variable. Then it's gonna call function process_request. This function 99:59:59.999 --> 99:59:59.999 eventually will do two string copies. One from the user data, the other one from the 99:59:59.999 --> 99:59:59.999 log path on two different local variables that are 128 bytes long. Now in the first 99:59:59.999 --> 99:59:59.999 case, as we have seen before, the data can be greater than 128 bytes and this string 99:59:59.999 --> 99:59:59.999 copy may result in a bug. While in the second case it will not. Because here we 99:59:59.999 --> 99:59:59.999 assume that the system handles its own data in a good manner. So throughout this 99:59:59.999 --> 99:59:59.999 work, we're gonna call the first type of binary, the setter binary, which means 99:59:59.999 --> 99:59:59.999 that it is the binary that takes the data and set the data for another binary to be 99:59:59.999 --> 99:59:59.999 consumed. And the second type of binary we called them the getter binary. So the 99:59:59.999 --> 99:59:59.999 current bug finding tools are inadequate because other bugs are left undiscovered 99:59:59.999 --> 99:59:59.999 if the analysis only consider those binaries that received network requests or 99:59:59.999 --> 99:59:59.999 they're likely to produce many false positives if the analysis considers all of 99:59:59.999 --> 99:59:59.999 them individually. So then we wonder how these different components actually 99:59:59.999 --> 99:59:59.999 communicate. They communicate through what are called interprocess communication, 99:59:59.999 --> 99:59:59.999 which basically it's a finite set of paradigms used by binaries to communicate 99:59:59.999 --> 99:59:59.999 such as files, environment variables, MMIO and so forth. All these pieces are 99:59:59.999 --> 99:59:59.999 represented by data keys, which are file names, or in the case of the example 99:59:59.999 --> 99:59:59.999 before here on the right, it's the query string environment variable. Each binary 99:59:59.999 --> 99:59:59.999 that relies on some shared data must know the endpoint where such data will be 99:59:59.999 --> 99:59:59.999 available, for instance, again, like a file name or like even a socket endpoint 99:59:59.999 --> 99:59:59.999 or the environment variable. This means that usually, data keys are coded in the 99:59:59.999 --> 99:59:59.999 program itself, as we saw before. To find bugs in firmware, in a precise manner, we 99:59:59.999 --> 99:59:59.999 need to track how user data is introduced and propagated across the different 99:59:59.999 --> 99:59:59.999 binaries. Okay, let's talk about our work. Before you start talking about Karonte, we 99:59:59.999 --> 99:59:59.999 define our threat model. We hypotesized that attacker sends arbitrary requests 99:59:59.999 --> 99:59:59.999 over the network, both LAN and WAN directly to the IoT device. Though we said 99:59:59.999 --> 99:59:59.999 before that sometimes IoT device can communicate through the clouds, research 99:59:59.999 --> 99:59:59.999 showed that some form of local communication is usually available, for 99:59:59.999 --> 99:59:59.999 instance, during the setup phase of the device. Karonte is defined as a static 99:59:59.999 --> 99:59:59.999 analysis tool that tracks data flow across multiple binaries, to find 99:59:59.999 --> 99:59:59.999 vulnerabilities. Let's see how it works. So the first step, Karonte find those 99:59:59.999 --> 99:59:59.999 binaries that introduce the user input into the firmware. We call these border 99:59:59.999 --> 99:59:59.999 binaries, which are the binaries, that basically interface the device to the 99:59:59.999 --> 99:59:59.999 outside world. Which in the example is our web server. Then it tracks how a data is 99:59:59.999 --> 99:59:59.999 shared with other binaries within the firmware sample. Which we'll understand in 99:59:59.999 --> 99:59:59.999 this example, the web server communicates with the handle binary, and builds what we 99:59:59.999 --> 99:59:59.999 call the BDG. BDG which stands for binary dependency graph. It's basically a graph 99:59:59.999 --> 99:59:59.999 representation of the data dependencies among different binaries. Then we detect 99:59:59.999 --> 99:59:59.999 vulnerabilities that arise from the misuse of the data using the BDG. This is an 99:59:59.999 --> 99:59:59.999 overview of our system. We start by taking a packed firmware, we unpack it. We find 99:59:59.999 --> 99:59:59.999 the border binaries. Then we build the binary dependency graph, which relies on a 99:59:59.999 --> 99:59:59.999 set of CPFs, as we will see soon. CPF stands for Communication Paradigm Finder. 99:59:59.999 --> 99:59:59.999 Then we find the specifics of the communication, for instance, like the 99:59:59.999 --> 99:59:59.999 constraints applied to the data that is shared through our module multi-binary 99:59:59.999 --> 99:59:59.999 data-flow analysis. Eventually we run our insecure interaction detection module, 99:59:59.999 --> 99:59:59.999 which basically takes all the information and produces alerts. Our system is 99:59:59.999 --> 99:59:59.999 completely static and relies on our static taint engine. So let's see each one of 99:59:59.999 --> 99:59:59.999 these steps, more in details. The unpacking procedure is pretty easy, we use 99:59:59.999 --> 99:59:59.999 the off-the-shelf firmware unpacking tool binwalk. And then we have to find the 99:59:59.999 --> 99:59:59.999 border binaries. Now we see that border binaries basically are binaries that 99:59:59.999 --> 99:59:59.999 receive data from the network. And we hypotesize that will contain parsers to 99:59:59.999 --> 99:59:59.999 validate the data that they received. So in order to find them, we have to find 99:59:59.999 --> 99:59:59.999 parsers which accept data from network and parse this data. To find parsers we rely 99:59:59.999 --> 99:59:59.999 on related work, which basically uses a few metrics and define through a number 99:59:59.999 --> 99:59:59.999 the likelihood for a function to contain parsing capabilities. These metrics that 99:59:59.999 --> 99:59:59.999 we used are number of basic blocks, number of memory comparison operations and number 99:59:59.999 --> 99:59:59.999 of branches. Now while these define parsers, we also have to find if a binary 99:59:59.999 --> 99:59:59.999 takes data from the network. As such, we define two more metrics. The first one, we 99:59:59.999 --> 99:59:59.999 check if binary contains any network related keywords as SOAP, http and so 99:59:59.999 --> 99:59:59.999 forth. And then we check if there exists a data flow between read from socket and a 99:59:59.999 --> 99:59:59.999 memory comparison operation. Once for each function, we got all these metrics, we 99:59:59.999 --> 99:59:59.999 compute what is called a parsing score, which basically is just a sum of products. 99:59:59.999 --> 99:59:59.999 Once we got a parsing score for each function in a binary, we represent the 99:59:59.999 --> 99:59:59.999 binary with its highest parsing score. Once we got that for each binary in the 99:59:59.999 --> 99:59:59.999 firmware we cluster them using the DBSCAN density based algorithm and consider the 99:59:59.999 --> 99:59:59.999 cluster with the highest parsing score as containing the set of border binaries. 99:59:59.999 --> 99:59:59.999 After this, we build the binary dependency graph. Again the binary dependency graph 99:59:59.999 --> 99:59:59.999 represents the data dependency among the binaries in a firmware sample. For 99:59:59.999 --> 99:59:59.999 instance, this simple graph will tell us that a binary A communicates with binary C 99:59:59.999 --> 99:59:59.999 using files and the same binary A communicates with another binary B using 99:59:59.999 --> 99:59:59.999 environment variables. Let's see how this works. So we start from the identified 99:59:59.999 --> 99:59:59.999 border binaries and then we taint the data compared against network related keywords 99:59:59.999 --> 99:59:59.999 that we found and run a static analysis, static taint analysis to detect whether 99:59:59.999 --> 99:59:59.999 the binary relies on any IPC paradigm to share the data. If we find that it does, 99:59:59.999 --> 99:59:59.999 we establish if the binary is a setter or a getter, which again means that if the 99:59:59.999 --> 99:59:59.999 binary is setting the data to be consumed by another binary, or if the binary 99:59:59.999 --> 99:59:59.999 actually gets the data and consumes it. Then we retrieve the employed data key 99:59:59.999 --> 99:59:59.999 which in the example before was the keyword QUERY_STRING. And finally we scan 99:59:59.999 --> 99:59:59.999 the firmware sample to find other binaries that may rely on the same data keys and 99:59:59.999 --> 99:59:59.999 schedule them for further analysis. To understand whether a binary relies on any 99:59:59.999 --> 99:59:59.999 IPC, we use what we call CPFs, which again means communication paradigm finder. We 99:59:59.999 --> 99:59:59.999 design a CPF for each IPC. And the CPFs are also used to find the same data keys 99:59:59.999 --> 99:59:59.999 within the firmware sample. We also provide Karonte with a generic CPF to 99:59:59.999 --> 99:59:59.999 cover those cases where the IPC is unknown. Or those cases were the vendor 99:59:59.999 --> 99:59:59.999 implemented their own versions of some IPC. So for example they don't use the 99:59:59.999 --> 99:59:59.999 setenv. But they implemented their own setenv. The idea behind this generic CPF 99:59:59.999 --> 99:59:59.999 that we call the semantic CPF is that data keys has to be used as index to set, or to 99:59:59.999 --> 99:59:59.999 get some data in this simple example. So let's see how the BDG algorithm works. We 99:59:59.999 --> 99:59:59.999 start from the body binary, which again will start from the server request and 99:59:59.999 --> 99:59:59.999 will pass the URI and we see that here. it runs a string comparison against some 99:59:59.999 --> 99:59:59.999 network related keyword. As such, we taint the variable P. And we see that the 99:59:59.999 --> 99:59:59.999 variable P is returned from the function to these two different points. As such, we 99:59:59.999 --> 99:59:59.999 continue. And now we see that data gets tainted and the variable data, it's passed 99:59:59.999 --> 99:59:59.999 to the function setenv. At this point, the environment CPF will understand that 99:59:59.999 --> 99:59:59.999 tainted data is passed, is set to an environment variable and will understand 99:59:59.999 --> 99:59:59.999 that this binary is indeed the setter binary that uses the environment. Then we 99:59:59.999 --> 99:59:59.999 retrieve the data key QUERY_STRING and we'll search within the firmware sample 99:59:59.999 --> 99:59:59.999 all the other binaries that rely on the same data key. And it will find that this 99:59:59.999 --> 99:59:59.999 binary relies on the same data key and will schedule this for further analysis. 99:59:59.999 --> 99:59:59.999 After this algorithm we build the BDG by creating edges between setters and getters 99:59:59.999 --> 99:59:59.999 for each data key. The multi binary data flow analysis uses the BDG to find and 99:59:59.999 --> 99:59:59.999 propagate the data constraints from a setter to a getter. Now, through this we 99:59:59.999 --> 99:59:59.999 apply only the least three constraints, which means that ideally between two 99:59:59.999 --> 99:59:59.999 program points, there might be an infinite number of parts and ideally in theory an 99:59:59.999 --> 99:59:59.999 infinite amount of constraints that we can propagate to the setter binary to the 99:59:59.999 --> 99:59:59.999 getter binary. But since our goal here is to find bugs, we only propagate the least 99:59:59.999 --> 99:59:59.999 strict set of constraints. Let's see an example. So again, we have our two 99:59:59.999 --> 99:59:59.999 binaries and we see that the variable that is passed to the setenv function is data, 99:59:59.999 --> 99:59:59.999 which comes from two different parts from the parse URI function. In the first case, 99:59:59.999 --> 99:59:59.999 the data that its passed is unconstrained one in the second case, a line 8 is 99:59:59.999 --> 99:59:59.999 constrained to be at most 128 bytes. As such, we only propagate the constraints of 99:59:59.999 --> 99:59:59.999 the first guy. In turn, the getter binary will retrieve this variable from the 99:59:59.999 --> 99:59:59.999 environment and set the variable query. Oh, sorry. Which in this case will be 99:59:59.999 --> 99:59:59.999 unconstrained. Insecure interaction detection run a static taint analysis and 99:59:59.999 --> 99:59:59.999 check whether tainted data can reach a sink in an unsafe way. We consider as 99:59:59.999 --> 99:59:59.999 sinks memcpy like functions which are functions that implement semantically 99:59:59.999 --> 99:59:59.999 equivalent memcyp, strcpy and so forth. We raise alert if we see that there is a 99:59:59.999 --> 99:59:59.999 dereference of a tainted variable and if we see there are comparisons of tainted 99:59:59.999 --> 99:59:59.999 variables in loop conditions to detect possible DoS vulnerabilities. Let's see an 99:59:59.999 --> 99:59:59.999 example again. So we got here. We know that our query variable is tainted and 99:59:59.999 --> 99:59:59.999 it's unconstrained. And then we follow the taint in the function process_request, 99:59:59.999 --> 99:59:59.999 which we see will eventually copy the data from q to arg. Now we see that arg is 128 99:59:59.999 --> 99:59:59.999 bytes long while q is unconstrained and therefore we generate an alert here. Our 99:59:59.999 --> 99:59:59.999 static taint engine is based on BootStomp and is completely based on symbolic 99:59:59.999 --> 99:59:59.999 execution, which means that the taint is propagated following the program data 99:59:59.999 --> 99:59:59.999 flow. Let's see an example. So assuming that we have this code, the first 99:59:59.999 --> 99:59:59.999 instruction takes the result from some seed function that might return for 99:59:59.999 --> 99:59:59.999 instance, some user input. And in a symbolic world, what we do is we create a 99:59:59.999 --> 99:59:59.999 symbolic variable ty and assign to it a tainted variable that we call TAINT_ty, 99:59:59.999 --> 99:59:59.999 which is the taint target. The next destruction X takes the value ty plus 5 99:59:59.999 --> 99:59:59.999 and a symbolic word. We just follow the data flow and x gets assigned TAINT_ty 99:59:59.999 --> 99:59:59.999 plus 5 which effectively taints also X. If at some point X is overwritten with some 99:59:59.999 --> 99:59:59.999 constant data, the taint is automatically removed. In its original design, 99:59:59.999 --> 99:59:59.999 BootStomp, the taint is removed also when data is constrained. For instance, here we 99:59:59.999 --> 99:59:59.999 can see that the variable n is tainted but then is constrained between two values 0 99:59:59.999 --> 99:59:59.999 and 255. And therefore, the taint is removed. In our taint engine we have two 99:59:59.999 --> 99:59:59.999 additions. We added a path prioritization strategy and we add taint dependencies. 99:59:59.999 --> 99:59:59.999 The path prioritization strategy valorizes paths that propagate the taint and 99:59:59.999 --> 99:59:59.999 deprioritizes those that remove it. For instance, say again that some user input 99:59:59.999 --> 99:59:59.999 comes from some function and the variable user input gets tainted. Gets tainted and 99:59:59.999 --> 99:59:59.999 then is passed to another function called parse. Here, if you see there are possibly 99:59:59.999 --> 99:59:59.999 an infinite number of symbolic parts in this while. But only 1 will return tainted 99:59:59.999 --> 99:59:59.999 data. While the others won't. So the path prioritization strategy valorizes this 99:59:59.999 --> 99:59:59.999 path instead of the others. This has been implemented by finding basic blocks within 99:59:59.999 --> 99:59:59.999 a function that return a nonconstant data. And if one is found, we follow its return 99:59:59.999 --> 99:59:59.999 before considering the others. Taint dependencies allows smart untaint 99:59:59.999 --> 99:59:59.999 strategies. Let's see again the example. So we know that user input here is 99:59:59.999 --> 99:59:59.999 tainted, is then parsed and then we see that it's length is checked and stored in 99:59:59.999 --> 99:59:59.999 a variable n. Its size is checked and if it's higher than 512 bytes, the function 99:59:59.999 --> 99:59:59.999 will return. Otherwise it copies the data. Now in this case, it might happen that if 99:59:59.999 --> 99:59:59.999 this strlen function is not analyzed because of some static analysis input 99:59:59.999 --> 99:59:59.999 decisions, the taint tag of cmd might be different from the taint tag of n and in 99:59:59.999 --> 99:59:59.999 this case, though, and gets untainted, cmd is not untainted and the strcpy can raise, 99:59:59.999 --> 99:59:59.999 sorry, carries a false positive. So to fix this problem. Basically we create a 99:59:59.999 --> 99:59:59.999 dependency between the taint tag of n and the taint tag of cmd. And when n gets 99:59:59.999 --> 99:59:59.999 untainted, cmd gets untainted as well. So we don't have more false positives. This 99:59:59.999 --> 99:59:59.999 procedure is automatic and we find functions that implement streamlined 99:59:59.999 --> 99:59:59.999 semantically equivalent code and create taint tag dependencies. OK. Let's see our 99:59:59.999 --> 99:59:59.999 evaluation. We ran 3 different evaluations on 2 different data sets. The first one 99:59:59.999 --> 99:59:59.999 composed by 53 latest firmware samples from seven vendors and a second one 899 99:59:59.999 --> 99:59:59.999 firmware gathered from related work. In the first case, we can see that the total 99:59:59.999 --> 99:59:59.999 number of binaries considered are 8.5k, few more than that. And our system 99:59:59.999 --> 99:59:59.999 generated 87 alerts of which 51 were found to be true positive and 34 of them were 99:59:59.999 --> 99:59:59.999 multibinary vulnerabilities, which means that the vulnerability was found by 99:59:59.999 --> 99:59:59.999 tracking the data flow from the setter to the getter binary. We also ran a 99:59:59.999 --> 99:59:59.999 comparative evaluation, which basically we tried to measure the effort that an 99:59:59.999 --> 99:59:59.999 analyst would go through in analyzing firmware using different strategies. In 99:59:59.999 --> 99:59:59.999 the first one, we consider each and every binary in the firmware sample 99:59:59.999 --> 99:59:59.999 independently and run the analysis for up to seven days for each firmware. The 99:59:59.999 --> 99:59:59.999 system generated almost 21000 alerts. Considering only almost 2.5k binaries. In 99:59:59.999 --> 99:59:59.999 the second case we found the border binaries, the parsers and we statically 99:59:59.999 --> 99:59:59.999 analyzed only them, and the system generated 9.3k alerts. Notice that in this 99:59:59.999 --> 99:59:59.999 case, since we don't know how the user input is introduced, like in this 99:59:59.999 --> 99:59:59.999 experiment, we consider every IPC that we find in the binary as a possible source of 99:59:59.999 --> 99:59:59.999 user input. And this is true for all of them. In the third case we ran the BDG but 99:59:59.999 --> 99:59:59.999 we consider each binaries independently. Which means that we don't propagate 99:59:59.999 --> 99:59:59.999 constraints and we run a static single corner analysis on each one of them. And 99:59:59.999 --> 99:59:59.999 the system generated almost 15000 alerts. Finally, we run Karonte and the generated 99:59:59.999 --> 99:59:59.999 alerts were only 74. We also run a larger scale analysis on 899 firmware samples. 99:59:59.999 --> 99:59:59.999 And we found that almost 40% of them were multi binary, which means that the network 99:59:59.999 --> 99:59:59.999 functionalities were carried on by more than one binary. And the system generated 99:59:59.999 --> 99:59:59.999 1000 alerts. Now, there is a lot going on in this table, like details are on the 99:59:59.999 --> 99:59:59.999 paper. Here in this presentation I just go through some as I'll motivate. So we found 99:59:59.999 --> 99:59:59.999 that on average, a firmware contains 4 border binaries. A BDG contains 5 binaries 99:59:59.999 --> 99:59:59.999 and some BDG have more than 10 binaries. Also, we plot some statistics and we found 99:59:59.999 --> 99:59:59.999 that 80% of the firmware were analysed within a day, as you can see from the top 99:59:59.999 --> 99:59:59.999 left figure. However, experiments presented a great variance which we found 99:59:59.999 --> 99:59:59.999 was due to implementation details. For instance we found that angr would take 99:59:59.999 --> 99:59:59.999 more than seven hours to build some CFGs. And sometimes they were due to a high 99:59:59.999 --> 99:59:59.999 number of data keys. Also, we found that the number of paths, as you can see from 99:59:59.999 --> 99:59:59.999 this second picture from the top, the number of paths do not have an impact on 99:59:59.999 --> 99:59:59.999 the total time. And as you can see from the bottom two pictures, performance not 99:59:59.999 --> 99:59:59.999 heavily affected by firmware size. Firmware size here we mean the number of 99:59:59.999 --> 99:59:59.999 binaries in a firmware sample and the total number of basic blocks. So let's see 99:59:59.999 --> 99:59:59.999 how to run Karonte. The procedure is pretty straightforward. So first you get a 99:59:59.999 --> 99:59:59.999 firmware sample. You create a configuration file containing information 99:59:59.999 --> 99:59:59.999 of the firmware sample and then you run it. So let's see how. So this is an 99:59:59.999 --> 99:59:59.999 example of a configuration file. It contains the information, but most of them 99:59:59.999 --> 99:59:59.999 are optional. The only ones that are not are this one: Firmware path, that is the 99:59:59.999 --> 99:59:59.999 path to your firmware. And this too, the architecture of the firmware and the base 99:59:59.999 --> 99:59:59.999 address if the firmware is a blob, is a firmware blob. All the other fields are 99:59:59.999 --> 99:59:59.999 optional. And you can set them if you have some information about the firmware. A 99:59:59.999 --> 99:59:59.999 detailed explanation of all of these fields are on our GitHub repo. Once you 99:59:59.999 --> 99:59:59.999 set the configuration file, you can run Karonte. Now we provide a Docker 99:59:59.999 --> 99:59:59.999 container, you can find the link on our GitHub repo. And I'm gonna run it, but 99:59:59.999 --> 99:59:59.999 it's not gonna finish because it's gonna take several hours. But all you have to do 99:59:59.999 --> 99:59:59.999 is merely... *typing noises* just run it on the configuration file and it's gonna 99:59:59.999 --> 99:59:59.999 do each step that we saw. Eventually I'm going to stop it because it's going to 99:59:59.999 --> 99:59:59.999 take several hours anyway. Eventually it will produce a result file that... I ran 99:59:59.999 --> 99:59:59.999 this yesterday so you can see it here. There is a lot going on here. I'm just 99:59:59.999 --> 99:59:59.999 gonna go through some important like information. So one thing that you can see 99:59:59.999 --> 99:59:59.999 is that these are the border binaries that Karonte found. Now, there might be some 99:59:59.999 --> 99:59:59.999 false positives. I'm not sure how many there are here. But as long as there are 99:59:59.999 --> 99:59:59.999 no false negatives or the number is very low, it's fine. It's good. In this case, 99:59:59.999 --> 99:59:59.999 wait. Oh, I might have removed something. All right, here, perfect. In this case, 99:59:59.999 --> 99:59:59.999 this guy httpd is a true positive, which is the web server that we were talking 99:59:59.999 --> 99:59:59.999 before. Then we have the BDG. In this case, we can see that Karonte found that 99:59:59.999 --> 99:59:59.999 httpd communicates with two different binaries, fileaccess.cgi and cgibin. Then 99:59:59.999 --> 99:59:59.999 we have information about the CPFs. For instance, here we can see that. Sorry. So 99:59:59.999 --> 99:59:59.999 we can see here that httpd has 28 data keys. And that the semantics CPF found 27 99:59:59.999 --> 99:59:59.999 of them and then there might be one other here or somewhere that I don't see . 99:59:59.999 --> 99:59:59.999 Anyway. And then we have a list of alerts. Now, thanks. Now, some of those may be 99:59:59.999 --> 99:59:59.999 duplicates because of loops, so you can go ahead and inspect all of them manually. 99:59:59.999 --> 99:59:59.999 But I wrote a utility that you can use, which is basically it's gonna filter out 99:59:59.999 --> 99:59:59.999 all the loops for you. Now to remember how I called it. This guy? Yeah. And you can 99:59:59.999 --> 99:59:59.999 see that in total it generated, the system generated 6... 7... 8 alerts. So let's see 99:59:59.999 --> 99:59:59.999 one of them. Oh, and I recently realized that the path that I'm reporting on the 99:59:59.999 --> 99:59:59.999 log. It's not the path from the setter binary to the getter binary, to the sink. 99:59:59.999 --> 99:59:59.999 But it's only related to the getter binary up to the sink. I'm gonna fix this in the 99:59:59.999 --> 99:59:59.999 next days and report the whole paths. Anyway. So here we can see that the key 99:59:59.999 --> 99:59:59.999 content type contains user input and it's passed in an unsafe way to the sink 99:59:59.999 --> 99:59:59.999 address at this address. Now. And the binary in question is called 99:59:59.999 --> 99:59:59.999 fileaccess.cgi. So we can see what happens there. *keyboard noises* If you see here, 99:59:59.999 --> 99:59:59.999 we have a string copy that copies the content of haystack to destination, 99:59:59.999 --> 99:59:59.999 haystack comes basically from this getenv. And if you see destination comes as 99:59:59.999 --> 99:59:59.999 parameter from this function and return and these and this by for it's as big as 99:59:59.999 --> 99:59:59.999 0x68 bytes. And this turned out to be actually a positive. OK. So in summary, we 99:59:59.999 --> 99:59:59.999 presented a strategy to track data flow across different binaries. We evaluated 99:59:59.999 --> 99:59:59.999 our system on 952 firmware samples and some takeaways. Analyzing firmware is not 99:59:59.999 --> 99:59:59.999 easy and vulnerabilities persist. We found out that firmware are made of 99:59:59.999 --> 99:59:59.999 interconnected components and static analysis can still be used to efficiently 99:59:59.999 --> 99:59:59.999 find vulnerabilities at scale and finding that communication is key for precision. 99:59:59.999 --> 99:59:59.999 Here's a list of bibliography that I use throughout the presentation and I'm gonna 99:59:59.999 --> 99:59:59.999 take questions. [filler, please remove in amara] 99:59:59.999 --> 99:59:59.999 *applause* [filler, please remove in amara] 99:59:59.999 --> 99:59:59.999 Herald: So thank you, Nilo, for a very interesting talk. If you have questions, 99:59:59.999 --> 99:59:59.999 we have three microphones one, two and three. If you have a question, please go 99:59:59.999 --> 99:59:59.999 head to the microphone and we'll take your question. Yes. Microphone number two. 99:59:59.999 --> 99:59:59.999 Q: Do you rely on imports from libc or something like that or do you have some 99:59:59.999 --> 99:59:59.999 issues with like statically linked binaries, stripped binaries or is it all 99:59:59.999 --> 99:59:59.999 semantic analysis of a function? Nilo: So. Okay. We use angr. So for 99:59:59.999 --> 99:59:59.999 example, if you have an indirect call, we use angr to figure out, what's the target? 99:59:59.999 --> 99:59:59.999 And to answer your question like if you use libc some CPFs do, for instance, then 99:59:59.999 --> 99:59:59.999 environment CPF do any checks, if the setenv or getenv functions are called. But 99:59:59.999 --> 99:59:59.999 also we use the semantic CPF, which basically in cases where information are 99:59:59.999 --> 99:59:59.999 missing like there is no such thing as libc or some vendors reimplemented their 99:59:59.999 --> 99:59:59.999 own functions. We use the CPF to actually try to understand the semantics of the 99:59:59.999 --> 99:59:59.999 function and understand if it's, for example, a custom setenv. 99:59:59.999 --> 99:59:59.999 Q: Yeah, thanks. Herald: Microphone number three. 99:59:59.999 --> 99:59:59.999 Q: In embedded environments you often have also that the getter might work on a DMA, 99:59:59.999 --> 99:59:59.999 some kind of vendor driver on a DMA. Are you considering this? And second part of 99:59:59.999 --> 99:59:59.999 the question, how would you then distinguish this from your generic IPC? 99:59:59.999 --> 99:59:59.999 Because I can imagine that they look very similar in the actual code. 99:59:59.999 --> 99:59:59.999 Nilo: So if I understand correctly your question, you mention a case of MMIO where 99:59:59.999 --> 99:59:59.999 some data is retrieved directly from some address in memory. So what we found is 99:59:59.999 --> 99:59:59.999 that these addresses are usually hardcoded somewhere. So the vendor knows that, for 99:59:59.999 --> 99:59:59.999 example, from this address A to this address B if some data is some data from 99:59:59.999 --> 99:59:59.999 this peripheral. So when we find that some hardcoded address, like we think that this 99:59:59.999 --> 99:59:59.999 is like some read from some interesting data. 99:59:59.999 --> 99:59:59.999 Q: Okay. And this would be also distinguishable from your sort of CPF, the 99:59:59.999 --> 99:59:59.999 generic CPF would be distinguishable... Nilo: Yeah. Yeah, yeah. 99:59:59.999 --> 99:59:59.999 Q: ...from a DMA driver by using this fixed address assuming. 99:59:59.999 --> 99:59:59.999 Nilo: Yeah. That's what the semantic CPF does, among the other things. 99:59:59.999 --> 99:59:59.999 Q: Okay. Thank you. Nilo: Sure. 99:59:59.999 --> 99:59:59.999 Herald: Another question for microphone number 3. 99:59:59.999 --> 99:59:59.999 Q: What's the license for Karonte? Nilo: Sorry? 99:59:59.999 --> 99:59:59.999 Q: I checked the software license, I checked the git repository and there is no 99:59:59.999 --> 99:59:59.999 license like at all. Nilo: That is a very good question. I 99:59:59.999 --> 99:59:59.999 haven't thought about it yet. I will. Herald: Any more questions from here or 99:59:59.999 --> 99:59:59.999 from the Internet? Okay. Then a big round of applause to Nilo again for your talk. 99:59:59.999 --> 99:59:59.999 *postroll music* [filler, please remove in amara] 99:59:59.999 --> 99:59:59.999 Subtitles created by many many volunteers and the c3subtitles.de team. Join us, and help us!