WEBVTT

00:00:00.000 --> 00:00:09.804
<i>preroll music</i>

00:00:09.804 --> 00:00:24.745
Herald: Our next speaker for today is a
computer science PhD student at UC Santa

00:00:24.745 --> 00:00:30.805
Barbara. He is a member of the Shellfish
Hacking Team and he's also the organizer

00:00:30.805 --> 00:00:35.816
of the IECTF Hacking Competition. Please
give a big round of applause to Nilo

00:00:35.816 --> 00:00:36.228
Redini.

00:00:36.228 --> 00:00:39.510
<i>applause</i>

00:00:39.510 --> 00:00:46.671
Nilo: Thanks for the introduction, hello
to everyone. My name is Nilo, and today

00:00:46.671 --> 00:00:52.330
I'm going to present you my work Koronte:
identifying multi-binary vulnerabilities

00:00:52.330 --> 00:00:56.486
in embedded firmware at scale. This work
is a co-joint effort between me and

00:00:56.486 --> 00:01:02.101
several of my colleagues at University of
Santa Barbara and ASU. This talk is going

00:01:02.101 --> 00:01:08.247
to be about IoT devices. So before
starting, let's see an overview about IoT

00:01:08.247 --> 00:01:13.904
devices. IoT devices are everywhere. As
the research suggests, they will reach the

00:01:13.904 --> 00:01:19.762
20 billion units by the end of the next
year. And a recent study conducted this

00:01:19.762 --> 00:01:25.769
year in 2019 on 16 million households
showed that more than 70 percent of homes

00:01:25.769 --> 00:01:31.836
in North America already have an IoT
network connected device. IoT devices make

00:01:31.836 --> 00:01:37.660
everyday life smarter. You can literally
say "Alexa, I'm cold" and Alexa will

00:01:37.660 --> 00:01:43.573
interact with the thermostat and increase
the temperature of your room. Usually the

00:01:43.573 --> 00:01:49.610
way we interact with the IoT devices is
through our smartphone. We send a request

00:01:49.610 --> 00:01:55.164
to the local network, to some device,
router or door lock, or we might send the

00:01:55.164 --> 00:02:01.139
same request through a cloud endpoint,
which is usually managed by the vendor of

00:02:01.139 --> 00:02:07.290
the IoT device. Another way is through the
IoT hubs, smartphone will send the request

00:02:07.290 --> 00:02:13.663
to some IoT hub, which in turn will send
the request to some other IoT devices. As

00:02:13.663 --> 00:02:18.879
you can imagine, IoT devices use and
collect our data and some data is more

00:02:18.879 --> 00:02:23.376
sensitive than other. For instance, think
of all the data that is collected by my

00:02:23.376 --> 00:02:29.731
lightbulb or data that is collected by our
security camera. As such, IoT devices can

00:02:29.731 --> 00:02:37.081
compromise people's safety and privacy.
Things, for example, about the security

00:02:37.081 --> 00:02:44.330
implication of a faulty smartlock or the
brakes of your smart car. So the question

00:02:44.330 --> 00:02:53.126
that we asked is: Are IoT devices secure?
Well, like everything else, they are not.

00:02:53.126 --> 00:03:00.953
OK, in 2016 the Mirai botnet compromised
and leveraged millions of IoT devices to

00:03:00.953 --> 00:03:06.965
disrupt core Internet services such as
Twitter, GitHub and Netflix. And in 2018,

00:03:06.965 --> 00:03:13.294
154 vulnerabilities affecting IoT devices
were published, which represented an

00:03:13.294 --> 00:03:20.915
increment of 15% compared to 2017 and an
increase of 115% compared to 2016. So then

00:03:20.915 --> 00:03:27.710
we wonder: So why is it hard to secure IoT
devices? To answer this question we have

00:03:27.710 --> 00:03:33.635
to look up how IoT devices work and they
are made. Usually when you remove all the

00:03:33.635 --> 00:03:40.415
plastic and peripherals IoT devices look
like this. A board with some chips laying

00:03:40.415 --> 00:03:45.604
on it. Usually you can find the big chip,
the microcontroller which runs the

00:03:45.604 --> 00:03:50.535
firmware and one or more peripheral
controllers which interact with external

00:03:50.535 --> 00:03:57.188
peripherals such as the motor of, your
smart lock or cameras. Though the design

00:03:57.188 --> 00:04:03.445
is generic, implementations are very
diverse. For instance, firmware may run on

00:04:03.445 --> 00:04:08.775
several different architectures such as
ARM, MIPS, x86, PowerPC and so forth. And

00:04:08.775 --> 00:04:14.349
sometimes they are even proprietary, which
means that if a security analyst wants to

00:04:14.349 --> 00:04:20.041
understand what's going on in the
firmware, he'll have a hard time if he

00:04:20.041 --> 00:04:26.060
doesn't have the vendor specifics. Also,
they're operating in environments with

00:04:26.060 --> 00:04:30.563
limited resources, which means that they
run small and optimized code. For

00:04:30.563 --> 00:04:38.041
instance, vendors might implement their
own version of some known algorithm in an

00:04:38.041 --> 00:04:45.265
optimized way. Also, IoT devices manage
external peripherals that often use custom

00:04:45.265 --> 00:04:51.245
code. Again, with peripherals we mean like
cameras, sensors and so forth. The

00:04:51.245 --> 00:04:57.479
firmware of IoT devices can be either
Linux based or a blob firmware, Linux

00:04:57.479 --> 00:05:03.127
based are by far the most common. A study
showed that 86% of firmware are based on

00:05:03.127 --> 00:05:07.900
Linux and on the other hand, blobs
firmware are usually operating systems and

00:05:07.900 --> 00:05:15.010
user applications packaged in a single
binary. In any case, firmware samples are

00:05:15.010 --> 00:05:20.020
usually made of multiple components. For
instance, let's say that you have your

00:05:20.020 --> 00:05:26.410
smart phone and you send a request to your
IoT device. This request will be received

00:05:26.410 --> 00:05:33.190
by a binary which we term as body binary,
which in this example is an webserver. The

00:05:33.190 --> 00:05:37.990
request will be received, parsed, and then
it might be sent to another binary code,

00:05:37.990 --> 00:05:43.150
the handler binary, which will take the
request, work on it, produce an answer,

00:05:43.150 --> 00:05:48.130
send it back to the webserver, which in
turn would produce a response to send to

00:05:48.130 --> 00:05:54.100
the smartphone. So to come back to the
question why is it hard to secure IoT

00:05:54.100 --> 00:06:01.060
devices? Well, the answer is because IoT
devices are in practice very diverse. Of

00:06:01.060 --> 00:06:05.890
course, there have been various work that
have been proposed to analyze and secure

00:06:05.890 --> 00:06:11.500
firmware for IoT devices. Some of them
using static analysis. Others using

00:06:11.500 --> 00:06:15.910
dynamic analysis and several others using
a combination of both. Here I wrote

00:06:15.910 --> 00:06:19.690
several of them. Again at the end of the
presentation there is a bibliography with

00:06:19.690 --> 00:06:28.990
the title of these works. Of course, all
these approaches have some problems. For

00:06:28.990 --> 00:06:33.850
instance, the current dynamic analysis are
hard to apply to scale because of the

00:06:33.850 --> 00:06:39.430
customized environments that IoT devices
work on. Usually when you try to

00:06:39.430 --> 00:06:45.400
dynamically execute a firmware, it's gonna
check if the peripherals are connected and

00:06:45.400 --> 00:06:49.780
are working properly. In a case where you
can't have the peripherals, it's gonna be

00:06:49.780 --> 00:06:55.390
hard to actually run the firmware. Also
current static analysis approaches are

00:06:55.390 --> 00:07:00.580
based on what we call the single binary
approach, which means that binaries from a

00:07:00.580 --> 00:07:05.620
firmware are taken individually and
analysed. This approach might produce many

00:07:05.620 --> 00:07:11.530
false positives. For instance, so let's
say again that we have our two binaries.

00:07:11.530 --> 00:07:17.320
This is actually an example that we found
on one firmware, so the web server will

00:07:17.320 --> 00:07:22.990
take the user request, will parse the
request and produce some data, will set

00:07:22.990 --> 00:07:27.430
this data to an environment variable and
eventually will execute the handle binary.

00:07:27.430 --> 00:07:33.670
Now, if you see the parsing function
contains a string compare which checks if

00:07:33.670 --> 00:07:37.930
some keyword is present in the request.
And if so, it just returns the whole

00:07:37.930 --> 00:07:43.780
request. Otherwise, it will constrain the
size of the request to 128 bytes and

00:07:43.780 --> 00:07:51.790
return it. The handler binary in turn when
spawned will receive the data by doing a

00:07:51.790 --> 00:07:59.380
getenv on the query string, but also will
getenv on another environment variable

00:07:59.380 --> 00:08:04.060
which in this case is not user controlled
and they user cannot influence the content

00:08:04.060 --> 00:08:10.480
of this variable. Then it's gonna call
function process_request. This function

00:08:10.480 --> 00:08:16.690
eventually will do two string copies. One
from the user data, the other one from the

00:08:16.690 --> 00:08:22.930
log path on two different local variables
that are 128 bytes long. Now in the first

00:08:22.930 --> 00:08:28.360
case, as we have seen before, the data can
be greater than 128 bytes and this string

00:08:28.360 --> 00:08:33.460
copy may result in a bug. While in the
second case it will not. Because here we

00:08:33.460 --> 00:08:40.810
assume that the system handles its own
data in a good manner. So throughout this

00:08:40.810 --> 00:08:45.550
work, we're gonna call the first type of
binary, the setter binary, which means

00:08:45.550 --> 00:08:50.530
that it is the binary that takes the data
and set the data for another binary to be

00:08:50.530 --> 00:08:57.700
consumed. And the second type of binary we
called them the getter binary. So the

00:08:57.700 --> 00:09:01.570
current bug finding tools are inadequate
because other bugs are left undiscovered

00:09:01.570 --> 00:09:08.080
if the analysis only consider those
binaries that received network requests or

00:09:08.080 --> 00:09:12.750
they're likely to produce many false
positives if the analysis considers all of

00:09:12.750 --> 00:09:19.410
them individually. So then we wonder how
these different components actually

00:09:19.410 --> 00:09:23.430
communicate. They communicate through what
are called interprocess communication,

00:09:23.430 --> 00:09:28.890
which basically it's a finite set of
paradigms used by binaries to communicate

00:09:28.890 --> 00:09:36.660
such as files, environment variables, MMIO
and so forth. All these pieces are

00:09:36.660 --> 00:09:42.150
represented by data keys, which are file
names, or in the case of the example

00:09:42.150 --> 00:09:49.440
before here on the right, it's the query
string environment variable. Each binary

00:09:49.440 --> 00:09:53.280
that relies on some shared data must know
the endpoint where such data will be

00:09:53.280 --> 00:09:57.540
available, for instance, again, like a
file name or like even a socket endpoint

00:09:58.080 --> 00:10:02.910
or the environment variable. This means
that usually, data keys are coded in the

00:10:02.910 --> 00:10:10.770
program itself, as we saw before. To find
bugs in firmware, in a precise manner, we

00:10:10.770 --> 00:10:14.100
need to track how user data is introduced
and propagated across the different

00:10:14.100 --> 00:10:22.680
binaries. Okay, let's talk about our work.
Before you start talking about Karonte, we

00:10:22.680 --> 00:10:27.930
define our threat model. We hypotesized
that attacker sends arbitrary requests

00:10:27.930 --> 00:10:33.360
over the network, both LAN and WAN
directly to the IoT device. Though we said

00:10:33.360 --> 00:10:38.640
before that sometimes IoT device can
communicate through the clouds, research

00:10:38.640 --> 00:10:42.690
showed that some form of local
communication is usually available, for

00:10:42.690 --> 00:10:50.040
instance, during the setup phase of the
device. Karonte is defined as a static

00:10:50.040 --> 00:10:54.270
analysis tool that tracks data flow across
multiple binaries, to find

00:10:54.270 --> 00:11:00.690
vulnerabilities. Let's see how it works.
So the first step, Karonte find those

00:11:00.690 --> 00:11:04.590
binaries that introduce the user input
into the firmware. We call these border

00:11:04.590 --> 00:11:09.180
binaries, which are the binaries, that
basically interface the device to the

00:11:09.180 --> 00:11:15.570
outside world. Which in the example is our
web server. Then it tracks how a data is

00:11:15.570 --> 00:11:20.760
shared with other binaries within the
firmware sample. Which we'll understand in

00:11:20.760 --> 00:11:25.170
this example, the web server communicates
with the handle binary, and builds what we

00:11:25.170 --> 00:11:30.630
call the BDG. BDG which stands for binary
dependency graph. It's basically a graph

00:11:30.630 --> 00:11:39.720
representation of the data dependencies
among different binaries. Then we detect

00:11:39.720 --> 00:11:45.360
vulnerabilities that arise from the misuse
of the data using the BDG. This is an

00:11:45.360 --> 00:11:52.650
overview of our system. We start by taking
a packed firmware, we unpack it. We find

00:11:52.650 --> 00:11:58.740
the border binaries. Then we build the
binary dependency graph, which relies on a

00:11:58.740 --> 00:12:04.800
set of CPFs, as we will see soon. CPF
stands for Communication Paradigm Finder.

00:12:04.800 --> 00:12:10.320
Then we find the specifics of the
communication, for instance, like the

00:12:10.320 --> 00:12:16.140
constraints applied to the data that is
shared through our module multi-binary

00:12:16.140 --> 00:12:20.550
data-flow analysis. Eventually we run our
insecure interaction detection module,

00:12:20.550 --> 00:12:26.040
which basically takes all the information
and produces alerts. Our system is

00:12:26.040 --> 00:12:32.430
completely static and relies on our static
taint engine. So let's see each one of

00:12:32.430 --> 00:12:37.320
these steps, more in details. The
unpacking procedure is pretty easy, we use

00:12:37.320 --> 00:12:42.600
the off-the-shelf firmware unpacking tool
binwalk. And then we have to find the

00:12:42.600 --> 00:12:47.730
border binaries. Now we see that border
binaries basically are binaries that

00:12:47.730 --> 00:12:54.150
receive data from the network. And we
hypotesize that will contain parsers to

00:12:54.150 --> 00:12:57.930
validate the data that they received. So
in order to find them, we have to find

00:12:57.930 --> 00:13:04.170
parsers which accept data from network and
parse this data. To find parsers we rely

00:13:04.170 --> 00:13:12.900
on related work, which basically uses a
few metrics and define through a number

00:13:12.900 --> 00:13:18.000
the likelihood for a function to contain
parsing capabilities. These metrics that

00:13:18.000 --> 00:13:22.470
we used are number of basic blocks, number
of memory comparison operations and number

00:13:22.470 --> 00:13:29.070
of branches. Now while these define
parsers, we also have to find if a binary

00:13:29.070 --> 00:13:34.110
takes data from the network. As such, we
define two more metrics. The first one, we

00:13:34.110 --> 00:13:39.480
check if binary contains any network
related keywords as SOAP, http and so

00:13:39.480 --> 00:13:45.240
forth. And then we check if there exists a
data flow between read from socket and a

00:13:45.240 --> 00:13:51.660
memory comparison operation. Once for each
function, we got all these metrics, we

00:13:51.660 --> 00:13:56.070
compute what is called a parsing score,
which basically is just a sum of products.

00:13:56.070 --> 00:14:01.710
Once we got a parsing score for each
function in a binary, we represent the

00:14:01.710 --> 00:14:07.680
binary with its highest parsing score.
Once we got that for each binary in the

00:14:07.680 --> 00:14:14.370
firmware we cluster them using the DBSCAN
density based algorithm and consider the

00:14:14.370 --> 00:14:18.240
cluster with the highest parsing score as
containing the set of border binaries.

00:14:18.240 --> 00:14:25.620
After this, we build the binary dependency
graph. Again the binary dependency graph

00:14:25.620 --> 00:14:29.790
represents the data dependency among the
binaries in a firmware sample. For

00:14:29.790 --> 00:14:35.430
instance, this simple graph will tell us
that a binary A communicates with binary C

00:14:35.430 --> 00:14:40.770
using files and the same binary A
communicates with another binary B using

00:14:40.770 --> 00:14:47.310
environment variables. Let's see how this
works. So we start from the identified

00:14:47.310 --> 00:14:53.010
border binaries and then we taint the data
compared against network related keywords

00:14:53.010 --> 00:14:58.320
that we found and run a static analysis,
static taint analysis to detect whether

00:14:58.320 --> 00:15:04.680
the binary relies on any IPC paradigm to
share the data. If we find that it does,

00:15:04.680 --> 00:15:09.360
we establish if the binary is a setter or
a getter, which again means that if the

00:15:09.360 --> 00:15:13.320
binary is setting the data to be consumed
by another binary, or if the binary

00:15:13.320 --> 00:15:20.520
actually gets the data and consumes it.
Then we retrieve the employed data key

00:15:20.520 --> 00:15:25.860
which in the example before was the
keyword QUERY_STRING. And finally we scan

00:15:25.860 --> 00:15:30.450
the firmware sample to find other binaries
that may rely on the same data keys and

00:15:30.450 --> 00:15:35.820
schedule them for further analysis. To
understand whether a binary relies on any

00:15:35.820 --> 00:15:42.510
IPC, we use what we call CPFs, which again
means communication paradigm finder. We

00:15:42.510 --> 00:15:52.290
design a CPF for each IPC. And the CPFs
are also used to find the same data keys

00:15:52.290 --> 00:15:56.280
within the firmware sample. We also
provide Karonte with a generic CPF to

00:15:56.280 --> 00:16:00.390
cover those cases where the IPC is
unknown. Or those cases were the vendor

00:16:00.390 --> 00:16:06.090
implemented their own versions of some
IPC. So for example they don't use the

00:16:06.090 --> 00:16:13.350
setenv. But they implemented their own
setenv. The idea behind this generic CPF

00:16:13.350 --> 00:16:19.740
that we call the semantic CPF is that data
keys has to be used as index to set, or to

00:16:19.740 --> 00:16:27.870
get some data in this simple example. So
let's see how the BDG algorithm works. We

00:16:27.870 --> 00:16:31.890
start from the body binary, which again
will start from the server request and

00:16:31.890 --> 00:16:38.250
will pass the URI and we see that here. it
runs a string comparison against some

00:16:38.250 --> 00:16:44.850
network related keyword. As such, we taint
the variable P. And we see that the

00:16:44.850 --> 00:16:52.800
variable P is returned from the function
to these two different points. As such, we

00:16:52.800 --> 00:16:57.180
continue. And now we see that data gets
tainted and the variable data, it's passed

00:16:57.180 --> 00:17:02.310
to the function setenv. At this point, the
environment CPF will understand that

00:17:02.310 --> 00:17:08.460
tainted data is passed, is set to an
environment variable and will understand

00:17:08.460 --> 00:17:13.680
that this binary is indeed the setter
binary that uses the environment. Then we

00:17:13.680 --> 00:17:18.540
retrieve the data key QUERY_STRING and
we'll search within the firmware sample

00:17:18.540 --> 00:17:28.066
all the other binaries that rely on the
same data key. And it will find that this

00:17:28.066 --> 00:17:29.880
binary relies on the same data key and
will schedule this for further analysis.

00:17:29.880 --> 00:17:37.020
After this algorithm we build the BDG by
creating edges between setters and getters

00:17:37.020 --> 00:17:45.150
for each data key. The multi binary data
flow analysis uses the BDG to find and

00:17:45.150 --> 00:17:51.270
propagate the data constraints from a
setter to a getter. Now, through this we

00:17:51.270 --> 00:17:56.610
apply only the least three constraints,
which means that ideally between two

00:17:56.610 --> 00:18:02.760
program points, there might be an infinite
number of parts and ideally in theory an

00:18:02.760 --> 00:18:06.690
infinite amount of constraints that we can
propagate to the setter binary to the

00:18:06.690 --> 00:18:11.790
getter binary. But since our goal here is
to find bugs, we only propagate the least

00:18:11.790 --> 00:18:17.040
strict set of constraints. Let's see an
example. So again, we have our two

00:18:17.040 --> 00:18:24.060
binaries and we see that the variable that
is passed to the setenv function is data,

00:18:24.060 --> 00:18:29.490
which comes from two different parts from
the parse URI function. In the first case,

00:18:29.490 --> 00:18:35.040
the data that its passed is unconstrained
one in the second case, a line 8 is

00:18:35.040 --> 00:18:40.470
constrained to be at most 128 bytes. As
such, we only propagate the constraints of

00:18:40.470 --> 00:18:49.980
the first guy. In turn, the getter binary
will retrieve this variable from the

00:18:49.980 --> 00:18:55.830
environment and set the variable query.
Oh, sorry. Which in this case will be

00:18:55.830 --> 00:19:03.390
unconstrained. Insecure interaction
detection run a static taint analysis and

00:19:03.390 --> 00:19:07.650
check whether tainted data can reach a
sink in an unsafe way. We consider as

00:19:07.650 --> 00:19:12.660
sinks memcpy like functions which are
functions that implement semantically

00:19:12.660 --> 00:19:19.050
equivalent memcyp, strcpy and so forth. We
raise alert if we see that there is a

00:19:19.050 --> 00:19:23.100
dereference of a tainted variable and if
we see there are comparisons of tainted

00:19:23.100 --> 00:19:31.620
variables in loop conditions to detect
possible DoS vulnerabilities. Let's see an

00:19:31.620 --> 00:19:37.260
example again. So we got here. We know
that our query variable is tainted and

00:19:37.260 --> 00:19:43.770
it's unconstrained. And then we follow the
taint in the function process_request,

00:19:43.770 --> 00:19:52.740
which we see will eventually copy the data
from q to arg. Now we see that arg is 128

00:19:52.740 --> 00:20:01.050
bytes long while q is unconstrained and
therefore we generate an alert here. Our

00:20:01.050 --> 00:20:04.980
static taint engine is based on BootStomp
and is completely based on symbolic

00:20:04.980 --> 00:20:09.750
execution, which means that the taint is
propagated following the program data

00:20:09.750 --> 00:20:14.430
flow. Let's see an example. So assuming
that we have this code, the first

00:20:14.430 --> 00:20:19.620
instruction takes the result from some
seed function that might return for

00:20:19.620 --> 00:20:25.755
instance, some user input. And in a
symbolic world, what we do is we create a

00:20:25.755 --> 00:20:33.630
symbolic variable ty and assign to it a
tainted variable that we call TAINT_ty,

00:20:33.630 --> 00:20:40.290
which is the taint target. The next
destruction X takes the value ty plus 5

00:20:40.290 --> 00:20:46.890
and a symbolic word. We just follow the
data flow and x gets assigned TAINT_ty

00:20:46.890 --> 00:20:54.300
plus 5 which effectively taints also X. If
at some point X is overwritten with some

00:20:54.300 --> 00:21:00.900
constant data, the taint is automatically
removed. In its original design,

00:21:00.900 --> 00:21:07.860
BootStomp, the taint is removed also when
data is constrained. For instance, here we

00:21:07.860 --> 00:21:11.880
can see that the variable n is tainted but
then is constrained between two values 0

00:21:11.880 --> 00:21:19.770
and 255. And therefore, the taint is
removed. In our taint engine we have two

00:21:19.770 --> 00:21:26.610
additions. We added a path prioritization
strategy and we add taint dependencies.

00:21:26.610 --> 00:21:32.430
The path prioritization strategy valorizes
paths that propagate the taint and

00:21:33.030 --> 00:21:39.030
deprioritizes those that remove it. For
instance, say again that some user input

00:21:39.030 --> 00:21:46.110
comes from some function and the variable
user input gets tainted. Gets tainted and

00:21:46.110 --> 00:21:51.180
then is passed to another function called
parse. Here, if you see there are possibly

00:21:51.180 --> 00:21:57.930
an infinite number of symbolic parts in
this while. But only 1 will return tainted

00:21:57.930 --> 00:22:05.490
data. While the others won't. So the path
prioritization strategy valorizes this

00:22:05.490 --> 00:22:09.990
path instead of the others. This has been
implemented by finding basic blocks within

00:22:09.990 --> 00:22:16.140
a function that return a nonconstant data.
And if one is found, we follow its return

00:22:16.140 --> 00:22:21.870
before considering the others. Taint
dependencies allows smart untaint

00:22:21.870 --> 00:22:26.310
strategies. Let's see again the example.
So we know that user input here is

00:22:26.310 --> 00:22:33.900
tainted, is then parsed and then we see
that it's length is checked and stored in

00:22:33.900 --> 00:22:40.755
a variable n. Its size is checked and if
it's higher than 512 bytes, the function

00:22:40.755 --> 00:22:48.210
will return. Otherwise it copies the data.
Now in this case, it might happen that if

00:22:48.210 --> 00:22:53.535
this strlen function is not analyzed
because of some static analysis input

00:22:53.535 --> 00:23:00.780
decisions, the taint tag of cmd might be
different from the taint tag of n and in

00:23:00.780 --> 00:23:07.380
this case, though, and gets untainted, cmd
is not untainted and the strcpy can raise,

00:23:07.380 --> 00:23:15.540
sorry, carries a false positive. So to fix
this problem. Basically we create a

00:23:15.540 --> 00:23:21.360
dependency between the taint tag of n and
the taint tag of cmd. And when n gets

00:23:21.360 --> 00:23:28.410
untainted, cmd gets untainted as well. So
we don't have more false positives. This

00:23:28.410 --> 00:23:33.330
procedure is automatic and we find
functions that implement streamlined

00:23:33.330 --> 00:23:40.140
semantically equivalent code and create
taint tag dependencies. OK. Let's see our

00:23:40.140 --> 00:23:48.240
evaluation. We ran 3 different evaluations
on 2 different data sets. The first one

00:23:48.240 --> 00:23:55.140
composed by 53 latest firmware samples
from seven vendors and a second one 899

00:23:55.140 --> 00:24:02.340
firmware gathered from related work. In
the first case, we can see that the total

00:24:02.340 --> 00:24:09.720
number of binaries considered are 8.5k,
few more than that. And our system

00:24:09.720 --> 00:24:15.900
generated 87 alerts of which 51 were found
to be true positive and 34 of them were

00:24:15.900 --> 00:24:21.960
multibinary vulnerabilities, which means
that the vulnerability was found by

00:24:21.960 --> 00:24:27.990
tracking the data flow from the setter to
the getter binary. We also ran a

00:24:27.990 --> 00:24:32.010
comparative evaluation, which basically we
tried to measure the effort that an

00:24:32.010 --> 00:24:37.260
analyst would go through in analyzing
firmware using different strategies. In

00:24:37.260 --> 00:24:41.280
the first one, we consider each and every
binary in the firmware sample

00:24:41.280 --> 00:24:49.050
independently and run the analysis for up
to seven days for each firmware. The

00:24:49.050 --> 00:24:57.390
system generated almost 21000 alerts.
Considering only almost 2.5k binaries. In

00:24:57.390 --> 00:25:04.020
the second case we found the border
binaries, the parsers and we statically

00:25:04.020 --> 00:25:11.070
analyzed only them, and the system
generated 9.3k alerts. Notice that in this

00:25:11.070 --> 00:25:15.630
case, since we don't know how the user
input is introduced, like in this

00:25:15.630 --> 00:25:21.120
experiment, we consider every IPC that we
find in the binary as a possible source of

00:25:21.120 --> 00:25:28.470
user input. And this is true for all of
them. In the third case we ran the BDG but

00:25:28.470 --> 00:25:33.060
we consider each binaries independently.
Which means that we don't propagate

00:25:33.060 --> 00:25:37.800
constraints and we run a static single
corner analysis on each one of them. And

00:25:37.800 --> 00:25:45.750
the system generated almost 15000 alerts.
Finally, we run Karonte and the generated

00:25:45.750 --> 00:25:55.230
alerts were only 74. We also run a larger
scale analysis on 899 firmware samples.

00:25:55.230 --> 00:26:01.380
And we found that almost 40% of them were
multi binary, which means that the network

00:26:01.380 --> 00:26:08.220
functionalities were carried on by more
than one binary. And the system generated

00:26:08.220 --> 00:26:16.620
1000 alerts. Now, there is a lot going on
in this table, like details are on the

00:26:16.620 --> 00:26:21.660
paper. Here in this presentation I just go
through some as I'll motivate. So we found

00:26:21.660 --> 00:26:27.360
that on average, a firmware contains 4
border binaries. A BDG contains 5 binaries

00:26:27.360 --> 00:26:34.050
and some BDG have more than 10 binaries.
Also, we plot some statistics and we found

00:26:34.050 --> 00:26:39.030
that 80% of the firmware were analysed
within a day, as you can see from the top

00:26:39.030 --> 00:26:46.350
left figure. However, experiments
presented a great variance which we found

00:26:46.350 --> 00:26:51.300
was due to implementation details. For
instance we found that angr would take

00:26:51.300 --> 00:26:56.220
more than seven hours to build some CFGs.
And sometimes they were due to a high

00:26:56.220 --> 00:27:01.650
number of data keys. Also, we found that
the number of paths, as you can see from

00:27:01.650 --> 00:27:09.480
this second picture from the top, the
number of paths do not have an impact on

00:27:09.480 --> 00:27:15.030
the total time. And as you can see from
the bottom two pictures, performance not

00:27:15.870 --> 00:27:23.610
heavily affected by firmware size.
Firmware size here we mean the number of

00:27:23.610 --> 00:27:29.610
binaries in a firmware sample and the
total number of basic blocks. So let's see

00:27:29.610 --> 00:27:35.190
how to run Karonte. The procedure is
pretty straightforward. So first you get a

00:27:35.190 --> 00:27:38.790
firmware sample. You create a
configuration file containing information

00:27:38.790 --> 00:27:45.150
of the firmware sample and then you run
it. So let's see how. So this is an

00:27:45.150 --> 00:27:51.450
example of a configuration file. It
contains the information, but most of them

00:27:51.450 --> 00:27:55.290
are optional. The only ones that are not
are this one: Firmware path, that is the

00:27:55.290 --> 00:28:00.300
path to your firmware. And this too, the
architecture of the firmware and the base

00:28:00.300 --> 00:28:07.170
address if the firmware is a blob, is a
firmware blob. All the other fields are

00:28:07.170 --> 00:28:12.381
optional. And you can set them if you have
some information about the firmware. A

00:28:12.381 --> 00:28:18.330
detailed explanation of all of these
fields are on our GitHub repo. Once you

00:28:18.330 --> 00:28:23.981
set the configuration file, you can run
Karonte. Now we provide a Docker

00:28:23.981 --> 00:28:28.666
container, you can find the link on our
GitHub repo. And I'm gonna run it, but

00:28:28.666 --> 00:28:41.402
it's not gonna finish because it's gonna
take several hours. But all you have to do

00:28:41.402 --> 00:28:53.225
is merely... <i>typing noises</i> just run it
on the configuration file and it's gonna

00:28:53.225 --> 00:28:57.630
do each step that we saw. Eventually I'm
going to stop it because it's going to

00:28:57.630 --> 00:29:02.537
take several hours anyway. Eventually it
will produce a result file that... I ran

00:29:02.537 --> 00:29:07.857
this yesterday so you can see it here.
There is a lot going on here. I'm just

00:29:07.857 --> 00:29:14.780
gonna go through some important like
information. So one thing that you can see

00:29:14.780 --> 00:29:21.923
is that these are the border binaries that
Karonte found. Now, there might be some

00:29:21.923 --> 00:29:26.360
false positives. I'm not sure how many
there are here. But as long as there are

00:29:26.360 --> 00:29:32.131
no false negatives or the number is very
low, it's fine. It's good. In this case,

00:29:32.131 --> 00:29:38.879
wait. Oh, I might have removed something.
All right, here, perfect. In this case,

00:29:38.879 --> 00:29:45.444
this guy httpd is a true positive, which
is the web server that we were talking

00:29:45.444 --> 00:29:52.185
before. Then we have the BDG. In this
case, we can see that Karonte found that

00:29:52.185 --> 00:30:00.252
httpd communicates with two different
binaries, fileaccess.cgi and cgibin. Then

00:30:00.252 --> 00:30:10.799
we have information about the CPFs. For
instance, here we can see that. Sorry. So

00:30:10.799 --> 00:30:19.775
we can see here that httpd has 28 data
keys. And that the semantics CPF found 27

00:30:19.775 --> 00:30:26.823
of them and then there might be one other
here or somewhere that I don't see .

00:30:26.823 --> 00:30:35.835
Anyway. And then we have a list of alerts.
Now, thanks. Now, some of those may be

00:30:35.835 --> 00:30:44.135
duplicates because of loops, so you can go
ahead and inspect all of them manually.

00:30:44.135 --> 00:30:50.982
But I wrote a utility that you can use,
which is basically it's gonna filter out

00:30:50.982 --> 00:31:02.100
all the loops for you. Now to remember how
I called it. This guy? Yeah. And you can

00:31:02.100 --> 00:31:13.368
see that in total it generated, the system
generated 6... 7... 8 alerts. So let's see

00:31:13.368 --> 00:31:20.579
one of them. Oh, and I recently realized
that the path that I'm reporting on the

00:31:20.579 --> 00:31:25.970
log. It's not the path from the setter
binary to the getter binary, to the sink.

00:31:25.970 --> 00:31:31.426
But it's only related to the getter binary
up to the sink. I'm gonna fix this in the

00:31:31.426 --> 00:31:37.552
next days and report the whole paths.
Anyway. So here we can see that the key

00:31:37.552 --> 00:31:43.395
content type contains user input and it's
passed in an unsafe way to the sink

00:31:43.395 --> 00:31:49.688
address at this address. Now. And the
binary in question is called

00:31:49.688 --> 00:32:02.416
fileaccess.cgi. So we can see what happens
there. <i>keyboard noises</i> If you see here,

00:32:02.416 --> 00:32:12.480
we have a string copy that copies the
content of haystack to destination,

00:32:12.480 --> 00:32:20.751
haystack comes basically from this getenv.
And if you see destination comes as

00:32:20.751 --> 00:32:30.001
parameter from this function and return
and these and this by for it's as big as

00:32:30.001 --> 00:32:38.895
0x68 bytes. And this turned out to be
actually a positive. OK. So in summary, we

00:32:38.895 --> 00:32:46.529
presented a strategy to track data flow
across different binaries. We evaluated

00:32:46.529 --> 00:32:52.972
our system on 952 firmware samples and
some takeaways. Analyzing firmware is not

00:32:52.972 --> 00:32:58.156
easy and vulnerabilities persist. We found
out that firmware are made of

00:32:58.156 --> 00:33:02.660
interconnected components and static
analysis can still be used to efficiently

00:33:02.660 --> 00:33:07.730
find vulnerabilities at scale and finding
that communication is key for precision.

00:33:07.730 --> 00:33:12.229
Here's a list of bibliography that I use
throughout the presentation and I'm gonna

00:33:12.229 --> 00:33:12.956
take questions.

00:33:12.956 --> 00:33:18.431
<i>applause</i>

00:33:18.431 --> 00:33:27.366
Herald: So thank you, Nilo, for a very
interesting talk. If you have questions,

00:33:27.366 --> 00:33:32.470
we have three microphones one, two and
three. If you have a question, please go

00:33:32.470 --> 00:33:37.684
head to the microphone and we'll take your
question. Yes. Microphone number two.

00:33:37.684 --> 00:33:41.995
Q: Do you rely on imports from libc or
something like that or do you have some

00:33:41.995 --> 00:33:46.733
issues with like statically linked
binaries, stripped binaries or is it all

00:33:46.733 --> 00:33:51.895
semantic analysis of a function?
Nilo: So. Okay. We use angr. So for

00:33:51.895 --> 00:33:57.277
example, if you have an indirect call, we
use angr to figure out, what's the target?

00:33:57.277 --> 00:34:02.627
And to answer your question like if you
use libc some CPFs do, for instance, then

00:34:02.627 --> 00:34:08.313
environment CPF do any checks, if the
setenv or getenv functions are called. But

00:34:08.313 --> 00:34:12.873
also we use the semantic CPF, which
basically in cases where information are

00:34:12.873 --> 00:34:17.687
missing like there is no such thing as
libc or some vendors reimplemented their

00:34:17.687 --> 00:34:21.977
own functions. We use the CPF to actually
try to understand the semantics of the

00:34:21.977 --> 00:34:25.888
function and understand if it's, for
example, a custom setenv.

00:34:25.888 --> 00:34:29.900
Q: Yeah, thanks.
Herald: Microphone number three.

00:34:29.900 --> 00:34:36.905
Q: In embedded environments you often have
also that the getter might work on a DMA,

00:34:36.905 --> 00:34:43.233
some kind of vendor driver on a DMA. Are
you considering this? And second part of

00:34:43.233 --> 00:34:47.793
the question, how would you then
distinguish this from your generic IPC?

00:34:47.793 --> 00:34:52.502
Because I can imagine that they look very
similar in the actual code.

00:34:52.502 --> 00:34:58.752
Nilo: So if I understand correctly your
question, you mention a case of MMIO where

00:34:58.752 --> 00:35:03.956
some data is retrieved directly from some
address in memory. So what we found is

00:35:03.956 --> 00:35:08.434
that these addresses are usually hardcoded
somewhere. So the vendor knows that, for

00:35:08.434 --> 00:35:13.280
example, from this address A to this
address B if some data is some data from

00:35:13.280 --> 00:35:18.857
this peripheral. So when we find that some
hardcoded address, like we think that this

00:35:18.857 --> 00:35:21.688
is like some read from some interesting
data.

00:35:21.688 --> 00:35:28.073
Q: Okay. And this would be also
distinguishable from your sort of CPF, the

00:35:28.073 --> 00:35:32.180
generic CPF would be distinguishable...
Nilo: Yeah. Yeah, yeah.

00:35:32.180 --> 00:35:35.775
Q: ...from a DMA driver by using this
fixed address assuming.

00:35:35.775 --> 00:35:39.827
Nilo: Yeah. That's what the semantic CPF
does, among the other things.

00:35:39.827 --> 00:35:41.336
Q: Okay. Thank you.
Nilo: Sure.

00:35:41.336 --> 00:35:43.856
Herald: Another question for microphone
number 3.

00:35:43.856 --> 00:35:46.117
Q: What's the license for Karonte?
Nilo: Sorry?

00:35:46.117 --> 00:35:51.130
Q: I checked the software license, I
checked the git repository and there is no

00:35:51.130 --> 00:35:53.440
license like at all.
Nilo: That is a very good question. I

00:35:53.440 --> 00:36:00.610
haven't thought about it yet. I will.
Herald: Any more questions from here or

00:36:00.610 --> 00:36:04.410
from the Internet? Okay. Then a big round
of applause to Nilo again for your talk.

00:36:04.410 --> 00:36:24.820
<i>postroll music</i>

00:36:24.820 --> 00:36:31.630
Subtitles created by many many volunteers and
the c3subtitles.de team. Join us, and help us!

99:59:59.999 --> 99:59:59.999
asdf