Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/608 Thanks!
Today, I'm glad
to have Andrei Kostin here today,
and he studied computer
science in Bucharest and recently
finished his PhD
on security and embedded systems,
and he's done some pretty cool hacks.
Maybe some of you have looked him up
and he's the author of The Toolkit
My Fair Classical Universal Toolkit,
which enables you to crack RFID chips,
basically.
And he will talk about methods
on how to make a large scale security
analysis of embedded devices
possible.
So enjoy it and give a warm welcome
to Andrei.
Hello, everybody, welcome to my talk.
Thank you, Christian, for introducing me
to. My name is Andre Kostin.
I am a recent college graduate from
Eureka in south of France.
And today I'll be presenting you
basically a quick squeeze of
my three years thesis
on security of embedded devices,
film or how to do it fast and furious
of large scale with
some demos.
So a very short film.
I will not go too much, but
in principle I'm interested
in embedded devices
as such, regardless
of the shape we take,
they might take the shape of our RFID
card or a credit card, or they take
shapes of printers or funguses, TV
cameras or even airplanes.
All of these are kind of examples
of embedded devices fit
in different bodies, let's say.
But inside they're embedded devices.
And this is what makes them a little bit
different than normal PCs.
And interesting for me.
So we know that embedded
devices are everywhere, is not something
new. And we are seeing
this where we use them
every day.
We see that embedded with
embedded devices.
We are getting more complex
and smarter because we really want
to do more
useful stuff with them, like writing
a script for them or calling an API
or trying to
TransAm some piece of advanced
software on them, whether it's a smart
home or a smart TV
and of course, embedded devices.
We are also getting on top of that.
They are also getting interconnected in
what's the new buzzword,
Internet of Things Iot and
these layers of complexity, basically
the interconnection of devices
which before are not supposed
to to be connected
combined with new complexity of software
and text and APIs makes a
little bit harder
to actually understand all the security
surfaces.
So it requires a little bit of a
systematic approach.
And all these embedded
devices, they run software
and.
Regardless of their shape, how they look
like their software is
called Fermor because of
historical reasons, so your
smart TV, your smart
meters, your home, rather, and even
your hard drives in your PC
or network cards in your PC
perceiver on these pieces of firmware,
which is kind of a smaller said
software operating system or not
running inside of it.
So there are some observations
that at present that
back in 2014 we've seen,
at least in a part of the Internet,
which is just a small observable part,
but there are hundreds of thousands of
Hilmar packages which we've been able to
to download and partially
to unpack and analyze.
So there might be many more
thousands of FERMA packages, but at
least we know there are hundreds of
thousands of them.
And there's also this interesting
predictions that by 2014,
where there were 14 billion
interconnected objects by
Cisco Internet of Things connection
counter, and the prediction is that
they are well known.
Hype is where by 2020 will
be between 20 and 50 billion of
interconnected devices.
So this basically
brings us to the importance of
embedded devices and their firmware,
because the embedded devices are
ubiquitous, even though they are
invisible, they are essential to
our lives.
Think about pacemaker's think about
using the cars they
can operate for many years, for example,
for smart infrastructure if it's buried
in concrete or is put somewhere
in the out of reach area,
they should operate and they could
operate for years even without getting
no updates or no security updates.
And they have a large or face because
of those devices do not have
normal.
Mouse keyboards, input output
systems like keyboard, mouse
and monitors.
So we need some kind of web interfaces,
networking interfaces and debugging
interfaces so that we are able to
to to operate easily
and is not news that the embedded
devices are insecure.
We've been seeing this trend from, I
guess, 2005 or 2006
when increasingly
more every day there
were examples of embedded devices
being insecure, like a lot
of routers being insecure.
When printers shown to be insecure on
a large scale, then VoIP
phones and VoIP systems used in
offices, cars,
Schoenbeck and even in
present shown to be remotely
hackable and insecure.
Drones, fireworks,
all kinds of p.l.c.
scars are industrial control
systems and the finger can
go on because there's actually no
limit on the type or
application of embedded devices.
And we can go on the blogs
and on their reports and white papers and
see every type of
embedded device have some kind of a flaw.
But what is the observation here is that
most of these white papers or
research was done in
a manual or not
necessarily just in a manual, but it was
like every research research
was done in an individual manner, like
taking a particular device or a
particular embedded Fermor
and analyzing it
heads to end.
And basically it involves a lot of
tedious work, a lot of manual work,
a lot of scripting.
And basically it's it
cannot scale. If you want to understand
what are the security of 50 billions
in security implications of 50 billions
of connected devices or
security flaws in hundreds of thousands
of or images?
We need scalable approaches.
And these approaches where we
do a lot of things manually just
does not scale.
I'll try to give a very quick overview
of how usually very manual
analysis of films
takes place.
And for most of you, maybe it's not
something new and for sure it's not.
But the idea is that there is a
phillimore package, you download
it, you get it on your C.D., you get it
on your USB stick, or you pay hundreds
of euros and get on
a fantastic card.
If it's a card or a system,
you unpack or decrypt.
And if you cannot decrypt is not a
problem, you keep it.
And some day somebody will dump
the key and you will be able to decrypt
it and go back and do the process as if
they're Fillmore's decrypted
unencrypted.
Then there is a very generic
steps like detecting the CPU or the
type of binary Vello
that addresses detecting
and then applying some kind of a static
analysis on the code or the source
code of interpreted files and
dynamic analysis and
then looking for some kinds of
patterns, even in form
of strings or function names or symbols
or just chunks of codes, which people try
to do now with machine learning and
intermediate language.
But that is to try to find this kind of
back doors or debug interfaces or
you are console's or know
obvious wounds.
This can be done statically or usually
can be done also dynamically, but it
requires more effort as will go through.
Then if you didn't have a device, you
have to buy the device.
Some people do it, otherwise they have a
device with no firmware and then
they start as if we started with
FEMA itself.
But in general case, if you want to do
analysis on some devices, you do not want
to buy every device every now and then
just to analyze.
So you want to start as cheap as possible
and start as possible is
getting the feel more free from the
Internet.
And then if you find some indication
that there's vulnerabilities, you will
want to buy the device.
You have to set up the device, meaning
all the cabling, all the network
configurations, all the
drama is right.
And then eventually, if
you need to go even deeper or samples,
abilities might require some physical
intervention, you might need to even go
and disassemble.
So clearly, there are two parts of this
manual analysis process and
we can see what the part of buying
the device, setting up the device and
disassembling it to go to its geotag,
or you are the console or
just hook up on the microprocessors
or flash memory is
is hard to automate because you
don't have so much budget to buy all the
devices. Just go on Amazon and buy at
random devices that you think
might be vulnerable.
And second is not very
easy to to set up all the devices
in uniform unless you have a very smart
robot, maybe in a few years will have
them. And also not very
easy to automatically disassemble the
device and go some robots
to connect to vegetables and you can
find them. There are some steps towards
that direction to automate this with
tabulators and some some movement
moving moving parts
to try to detect these.
You are. But still, it's like a heart
problem is hard to automate.
On our own website, we see
what the first
part is. More or less is automated
because getting the former is
nothing than just going to a download
link that eventually logging
in, if it requires a username and
password, downloading it,
then trying to unpack it.
If it doesn't work with a simple zip,
you can use the brute force method, you
just brute force and I'll show you some
examples and then you just
try to do some juristic.
You detect some things which you might
want to optimize
for your analysis. And when you just do
static and then amik analysis, of course,
there are some caveats for both of
you for all of these steps.
But clearly this as a process,
as a as a vote can be automated,
so.
Going from this point forward, we have
this idea to to have a large
scale automated analysis to better
understand and classify and analyze
film or images without
using the devices. What is very
important, because we don't actually
need these devices, because most of them
can be with more or less effort emulated
if we really need to to confirm something
or not.
So there are some challenges, like
the large number of devices, the large
number of Theama files, these are the
challenges which have to
be overcome.
Also of the things that
the Iot and the embedded devices,
they're using
different kinds of architecture.
Of course, the most well known are
and MEPs and PowerPC maybe.
But there's mirrors of our
microcontrollers and microprocessors,
which you really don't know
what they are and also not necessarily
all of them use Linux.
So you would need to know where to
load that bytecode and so on.
And basically, we also have
a highly unstructured data.
Even though you can go and download all
the files on the Internet, you need to
know what is what, because
otherwise you end up in a very
inefficient,
very inefficient brute forcing process.
And you need to be really focused when
you have a lot of data.
So to overcome with these challenges,
we have some solutions.
We propose solutions
such as for a large number
of devices. The first thing we want to
do, no devices analysis.
So we try to do no devices,
a large number of fumer files.
Basically, we need to analyze a lot of
data, OK? We need to devise
a scalable architectures
because the systems are heterogeneous.
We need to devise techniques which
are generic enough,
which do not depend on particular
CPU architecture or
hardware architecture.
We want to be either on the
intermediate level or
have some some some
specialized techniques, but we can from
which we can pivot
when there's a
focus on web and network
interfaces and APIs, because all of these
devices they expose with network
interfaces and APIs and in particular
we expose the web interface as a means
to remote management or remote
access to the device.
Having highly unstructured data, we
propose that you need to
do a large dataset classification,
meaning that you use machine learning
to classify the Fillmore's and so on.
And we'll show some examples of this.
So first, the
first challenge, like FERMA in device
classification.
Why? Why is that the challenge?
We know that, again, there's hundreds
of thousands of Fermor packages.
And of course, I don't see many
volunteers in the room to manually triage
and classify them.
And we basically propose
machine learning.
And we in particular in our case, we used
Saikat learn
Python package and we
try to evaluate our approach.
That is that if you have Fermor files
and these from our files
usually are specific to devices.
So if a device
evades a device which has a particular
number of
megabytes for Flash,
then the Filmer file, if it's a
full update, will have more or less 16
megabytes. Right.
So there is this kind of fear.
More properties like file size, file
entropy, some strings and so on,
which makes those femur's
particular to that device
or what vendor.
So these are kind of the
properties of the files from
our files, which we use like file size,
entropy value called densities
of the strings inside and unique strings
in each category.
And then we try to use these as features
in machine learning algorithms,
random thoughts and decision trees.
And we did some some sampling
and we found that in our case,
what worked the best was
the random forest.
We've size entropy,
strings and strings, unique features.
And I know it sounds a little bit
too much for this presentation,
but you can find the details in in
the in the papers, which are at the end
of the slides, how these
features were chosen and how they're
generated. But that is what if we,
for example, include another feature
of Fillmore's, which is not very
good when we have the
classification of Fillmore's or detection
of Fillmore's not very
accurate.
So in our case, we've
been able to achieve more than 90 percent
accurate detection of Fermor
by Vandar or by Vandoren product.
So it helps us because we can basically
say from this big number
of Fillmore's, let's
put this in chunks and we have
Fillmore's from vendor or A vendor, B
vendor C and then we can
apply specific unpegging
techniques or specific known exploits
to test the VWs.
Fillmore's are vulnerable or not
because we know it's vendor or B or C.
So this is our local optimum
where I live.
The future is the same as on the
on the slide.
And that is that
I can try to give you
a demo at the end of the presentation.
Uh, so so the next challenge is
the automated static analysis.
So the idea is that.
If you have a large number of
farmers, you want to do more to
do the analysis as quick as possible and
automated as possible, so in
the first instance, what we did, we took
the files, which we crawled the several
hundred thousand farmers.
We put them in a database
and we developed some
processing, unpacking and analysis nodes.
And basically, you can scale it inside
your own
organization or you can scale it to
Amazon Web Services to
whatever number of nodes you need.
And basically these nodes, or they do,
they just receive a few more.
They try to unpack using brainwork
or using binary analysis tool kit.
These are two very awesome tools.
You can combine them or write your own
and then you unpack the files.
You get the file system if you're lucky.
If not, you can write your own compactors
and plug them into brainwork and banner
analysis tool kit and scale
it to many numbers of nodes.
When we do some simple static
analysis like
collecting default
or backdoor passwords or
an unusual password, or
we try to to see very
private certificate's private files
and which are in the film around
should not be there.
Then we also saw this in a film, more
analysis and report database and do some
data management which will come down
later.
So what kinds of static analysis would
perform in the first place?
We do check for Web
server configuration.
We didn't run any static code
analysis because it was our first
experiment. We didn't know what exactly
to expect. What was the percentage of
CPU architecture?
What was the percentage of operating
systems? And it's really hard
to have a full set of tools, especially
if you work open source or
free software to to
tackle all of these challenges.
When we also look for credentials,
weak default or hardcoded the need to see
password, or we look
for basically four strings
in the Fillmore and then we try to
map them to
hash hashes
in each password.
And we found like dozens of them, where
the string string inside
the femur is actually
a password for an
we need to see.
We also use the versions and the
keywords, for example, versions are
useful if you want to, to test
statically or dynamically if a particular
open SSL library shipped in a few
is vulnerable or not.
The thing is that just getting the
Fillmore version is not enough
because you never know whether
the library or the software package
was compiled with a particular
set of options or was
privately purchased by the vendor.
And the vulnerability is not there.
So if you have a severe, it might not
work just because of the simple reason,
because they privately purchased it or
compile it in a way, but it doesn't
trigger. So aversion is just an
indication of what you might be looking
for, but it's not like a definite
hit.
And then we also use some correlation,
which I'll show some examples of them.
We use the strings, we use the fuzzy
hashes and private SSL keys.
The fuzzy hash is interesting
thing basically is a
forensic technique which compares files
by their similarity with do not
compare it one by one as
in crypto hashes.
So it gives you an idea if
there is a common file in different
finnemore packages and there's some
small modification between vendors and it
makes it easy to find cross
bugs, as I'll show in in a
second.
So in one example, we have this Fermor
SD card, wi fi
finnemore. So basically these are SD
card, which have a wi fi chips
in them. And there
was a known vulnerability in it
like common injection
and says
we know that this particular file.
But Fermor is vulnerable when
one we do fuzzy hash
analysis, we see that there's
a few other like Fermor two and
feel more free and more five
and feel more full, which have similar
files. And we try to correlate them by
the hash and we see what some
files are similar by
fuzzy hash. So if this
particular file is vulnerable to excess
or remold code
injection, then the
other two, because of their similarity,
they might be as well.
So this is a very good indication that
you should pivot from Phillimore one to
fewer and fewer morphos and
testing for exactly the same
vulnerabilities or exploit.
And the thing is that sometimes
you you get different vendors hit
by the same bug just because it's a
white label product and
they buy an SDK or a development
kit and they use the very same
vulnerable software packages.
Another example which we found
interesting is that we had
the private we had HTP
as certificate's
in the Fillmore's and they had private
keys along with them, which is a mistake.
But OK, whatever you might think that
maybe be the first, but they regenerate
their SSL certificates.
Oh, we look it up in our
database. We see that this
particular SSL certificate
corresponds to assistive event
or a and we actually found some
vulnerabilities in this vendor wait
out going forward.
We take them up outputs
and they have their
HP Cisco Systems come.
What we do, we try to correlate the same
with the fingerprint of Certificate's
in the IP for
fingerprints.
And we find that actually the same
fingerprint, which is
from the certificate and a few more
files, is found online.
And by random sampling,
we found that some of these
online devices which use the EPA
certificate, they actually
come from a vanderbeek.
And the conclusion is
that most likely these two vendors are
affected by the same vulnerability we
found in the first place by analyzing the
filmer. And you can go and pivot
from vendor A and basically go
and exploit vendor BS
devices which are online.
And one example of this is.
I'll just show you
this is this particular example
so you can see what it is.
A a sentry, it's
a CCTV camera, and you can
see that it's a probably sentry, right.
And what's that particular example
I was talking about?
But when you see the SSL certificate,
it's Brecon, and I'll show your
dynamic analysis of one device
and how we do it.
So there it is.
But if you have these kind of situations
where you have devices
labeled by different vendors but
have vulnerabilities which you don't
know, you will not know if you don't do
it at a large scale, you'll just focus on
the Brixham devices and you'll think only
brick home is, uh,
is vulnerable.
And to give you an idea is that I have
a virtual machine.
Uh, you can see that I
have, uh, the
same IP, but different parts, three zero
eight zero four zero zero and
two zero eight zero.
So I started with a brick home
and you see that embedded virtual
machine. I am running a
simulated fumer, which
I'll explain a little bit later.
But what I want to say is that
once we have a
vendor, a let's say, breckon phillimore,
and we can do dynamic analysis, we can
emulate it and find vulnerabilities
inside, we can easily find
automated exploits and use them against
VanDerBeek and.
We can do admin, admin, and you
can see that this is basically
an automated simulated system
which simulates automatically this Fermor
from this particular system vendor,
and you can do pretty
much in our case, we focused on
the Web interfaces, and I'll go
into details a little bit later.
But I want to show you that
it's possible to do dynamic analysis as
well, not just looking for
SSL certificates and do this in our
automated manner.
And you can see what the Web
interface is pretty responsive.
And you can do.
You can.
Yeah. You see, I mean, this is
really awesome. You find bugs like that,
right? And
but that's the thing that you can
start penetration testing tools like
Arachne, like
W Fresia for your
preferred commercial tool.
And we will easily find the excesses
and remote code injections
and a remote command injections and
Pascual's whatever the interface
might have.
OK, so it was a small
parenthesis.
So in that case of these broken
cameras, we found one certificate.
We one we found one vulnerability
which was important, and we
correlated to two vendors
and correlated to a total of 35000
online devices. And we have at
that time, back in 2014, we had
109 private RSA
keys which were without passphrase.
And we can skim the fingerprints
and go look around on the Internet
using Shodan or Sense's
or whatever your system
is. So as as a first
result from that very simple, not
not very complex technologies
like no called static analysis,
we found 38 new vulnerabilities like
existences. Back doors
are nontrivial default
or hardcoded passwords, which
affect around 700 more images.
And we correlated some of these
vulnerabilities to around 140
online devices using Shodan
and Google Docs.
So the last challenge we had
or we tried to
to tackle is the automated dynamic
analysis, like a sneak peak.
What I have shown you on the Fenmore
emulation of broken cameras.
So the idea is that we have
with Ampex fewer, more sources or
you might have tons of them.
ARMPAC, let's say, when you want to
select some of them to
do dynamic analysis, your
selection criteria might very well.
In our case, we selected the ones which
had clearly a web interface inside
and we could start the Web interface
because usually the Web interface
is the first thing which ends up on
the Internet when you plug your device to
your outer or to your direct connection.
And this is the thing you usually want to
access to manage your device
remotely unless you use
some smartphone application, but which
basically does the same for the cloud and
piggybacks on some connection to
your to your device.
So we selected these we
do some filesystem preparation because
if you did a lot of Fermor unpacking,
you will know how it is,
and especially when you have hundreds of
thousands of files
or very diverse, then automatically
unpacking and extracting, you'll get a
lot of false positives, a lot of junk
data, a lot of
broken files.
Just because vampyre
was brute forcing too much or
maybe just because
they used slightly different settings
of Packer
for their, for example, for affairs
or for Jeffares to
values Biggenden little, then
we with some specific options and then
vampyres the default on peckers do not
work out of a book.
So the system sometimes are broken
and you need some your risks to broker
some links. You need some of your risks
to to find with some files are not
properly there and try to make
them as good
as possible so that your
emulation will be successful.
Then what you do, you also try
to do it scalable,
like the static analysis you want to do
with the name analysis as well.
It's a little bit slower because
it involves both emulation on a much
slower emulator
and then also involves dynamic
analysis tools, basically, which are
phasers or penetration testing tools,
which send a lot of input.
And we perform with dynamic
analysis
using Corrimal.
We collect the results and we use it for
machine learning and for improving the
analysis or analyzing why the particular.
Emulation or failed,
maybe there was a kernel problem or maybe
they're missing a kernel modules, and
this might happen a lot because not all
Fillmore packages are full
Theama packages.
You must know that
most of the films are kind of partial
updates. Most of the vendors, they just
send you a D for the updates
of impacted files.
They do not send you every time the whole
image of the file system.
And that's why sometimes you you
you need to know why the simulation
or analysis is failing.
But that is the challenging
thing, is how how do you scalability
or scalable
emulate heterogeneous architectures
or in general how you automatically
emulate? Because if you do it by hand,
it's funny, but you get tired after half
a day when we
need to choose an emulator.
And there are a lot of options how
to do the simulation or analysis.
So that would be the ideal later.
But the problem, it does not exist.
And when I'm talking about ideally
emulation is very later, which you give
it a file and it will automatically
know the architecture and will
be able to emulate the CPU, will
automatically know the operating system
and will know how to put it and will know
at which addresses basically to load
all these files.
But from what we know publicly,
some such thing is not available
when a generic system immolators
is the chemo
and there are two options to use
it with original
Fillmore and the original kernel or
with original Fermor and generic
kernel. The problem is that not very
many Fermor come with
a kernel update.
Most of them, if you look at them there
on Kernel two point six
to 10 years ago.
So they do not update very often
the kernels and you will not get them
very often in the Fillmore update.
So this means that you will have
to either extracted by Jayton
or use some manual process
which doesn't scale.
And in that case, the generic
kernel approach where you have a generic
general built with all the possible
modules and options would
be a better idea.
And then there are some other options
where you can just take the
application you want to test and you
don't test it in an emulator, but you
load it in a
test environment, which is
different from where you related
environment. And this works very well
for interpreted languages like people
and things like that, basically
where there is a virtualization
environment and you can replicate the
virtualization environment without
putting all that XML
kitchen souper in there.
Again, we had to make some
choices that a perfect
emulator doesn't exist, so we cannot use
it. There are not many farmers
have kernels inside, so we cannot
use it.
And this is all too experimental.
But details about architectural truth are
in the paper.
Not Borio now with this, but you can
look look it up what exactly it is.
So we use VESTO approaches using the
original Fermor we with a generic kernel
and in cases where it applies
to basically strip the whole document
route if it is a pearl
or PSP and put it in a
Eeks 86
test environment and run it there and
there are Apache or like they should be.
Now, the idea is that
you have vacuum chemo,
which runs inside the normal machine,
or it can run inside the van.
In our case, it runs inside the VM.
We we run on top of the
with our technical details, but then we
throw the film inside the chemo
and we see the truth.
The truth is the procedure where
basically you change the root system,
the perceived root system of air
or the environment you are working on.
And you can basically say to where
to remove that from now on,
the root of a few more file is
your root file system and you can
basically use the environment from
the former as if
it was being provided by chemo.
So in this way, you kind of
can easily emulate their
corvids with that.
But it works pretty well for
many Fillmore's.
When you just because
you are insitute environment, you just
bootstrap everything with finitely, NRC
and so on and live it
run. Of course, some of them will fail
because there's no device
attached to chemo because
you need to write some
plugins for chemo in order to
emulate the flash memory
of April memory of a serial port
Ethernet.
Luckily, the networking is pretty
well done in chemo and it works fine.
But for others, you need to basically
write a good set of
plugin libraries, which would be
able to accommodate most of your
devices.
And once you have that, you can
basically overcome those failures
and then you just
fire off a Web server, whether it's
more like the PDA
and so on, or it's a
standalone binary.
And then you just
interested in that part.
In our case, we are interested in Web
server part and then we just plug
the Iranis up w
free A.F.
Penetration testing tools.
We use GCP dump in order to recover
all the communication, to be able to roll
back and find what the input
trigger a particular exploit
or a particular crash or a particular
command injection you
can use and map you can use methods,
Blodget and Nessus, and basically fire
all your arsenal of tools
on the immolators systems, on the ports
you want to to work on.
In our case, we focused on the web
interface, so we we use these tools
and as a result, we
had around
225 high security vulnerabilities,
meaning command injection exercises and
SRF impacting
around 10 percent of the original
dataset. We've been we've started from.
And these vulnerabilities impacted
25 percent of the vendors.
That is that we didn't develop
this framework to find all the
vulnerabilities.
But if you have such a framework and
you can find the low hanging fruit very
fast in one day and and
kill basically or close 10 percent
of your vulnerabilities, if you're a
vendor, then it's a very useful tool.
Or if you are a tester, you want to find
all of these things quickly.
You don't want to spend all your days
just going manually and try to emulate
manually. Just leave it overnight to come
in the morning. You have two hundred
twenty five reports on
200 Pyramus and your job is done for the
day.
Right now.
OK, so I
showed you, like part of this demo.
I mean, this is, uh,
Fabricant camera
where some things you can
play with.
But what I wanted to show you is that,
uh, the process
of starting from the femur and
going to the to the correlation
and then finding the interesting
things. So, for example, if you have
analysis on, uh.
On these
files, for example, you can correlate
buy by string and you can see
what some of the Fillmore's
in particular, HP, for example,
they had some some Fenmore which
they pulled from pulled out from the
Internet for I don't know what reason
which contained V0 or failed to open
a net channel.
I don't know what it means, but.
I think it's very
not very funny.
So if you have this kind of you can
search by keywords and you you will be
amazed how many Fillmore's
actually hit on the key word Back-Door.
Some of them, of course, are with snorter
ideas. Rules which look for
keyword Back-Door and Visa
rules basically give you a hint.
But sometimes you actually find Railsback
doors by searching for the word
Back-Door, right?
Now, I mean, they understood that
this is very obvious, and
if you know the story of Juniper, they
started to use cryptograms.
But I mean, if you have this kind of
cryptograms, you can also start
looking around at this from our files.
And then you look at the few more details
and also the name of the version.
And you can pivot from there.
You can also look for those
dual see keys if
you are present in this film or other
films.
But to give you an example of the
fuzzy hash thing,
as I mentioned, you in the slides
somewhere here.
OK, so this is why I
mentioned the SD cards and correlational
files, and
that is what I can.
I'll keep it shorter.
We know this file is vulnerable
in one of a one of SD
cards.
It was very well known blog post we
can look at by the hash and we can
actually see that this file.
Is presenting these farmers
OK?
Some some of them and is
nothing particular because they're just
incremental versions of
the same device, Fermor
and we can also see what it's 100
percent similarity.
So it means this file didn't change
across versions.
But the interesting thing is that.
You see that ad
for some entries, the vendor change and
you can easily automate
to trigger you an alert or to basically
pivot automatically when you have
a similarity hit
for one file across vendors.
When it goes across vendors, you know
that something is fishy.
It means that the other vendor must
be vulnerable. And you see what the
similarity is.
Not 100 percent is 46,
which is because these
vendors of the cars, they take the white
label or as the case or development
kits and they put their logo on their
copyright text.
So there's some change in the in their
output or in their
files. But that is where the core
functionality stays the same way.
Whenever a core functionality
of a Web server or the kernel, they
just update their copyrights.
And that's why there is not full
similarity. But there is some similarity.
So if you look at this file is
peculiar and
is a version
147, but that is what OK,
once you have this knowledge that
this file is vulnerable
and you have two vendors, you can just
try to emulate
both of them and see whether they are
vulnerable.
And in one case,
you see is the same IP is the same
virtual machine is transend wi
fi as I can
kill it like it is.
But we've have
another part, and this is that you are
having this kind of emulation.
You can also find very
quickly bugs like unauthorized
access. Right. So you see what it asked
me for a password.
But if I.
Go to this page, it's automatic like
that, so you see what you don't need,
like a very sophisticated thing and
you can use these fantastic
tools or plug ins for fantastic tools to
find these kind of vulnerabilities very
easily and basically generate
KVI reports every every minute.
Uh.
OK, we can log
in sometimes where
the thing is where interfaces are
broken, because you see there is no Mac
address, right, because it
tries to call some IOC, T.L.,
which is not supported by Kojima.
And you need to write a blog in in order
to to support all this kind of e-mail.
But that is what you can still find the
vulnerabilities if you go
see your name, Arachne name
is because now the Arachne
is is is testing with
this machine.
OK, so it used to
test this machine, I can
do a very quick thing.
Like that.
So basically, you see that using
ventilatory the need to buy that
expensive 40 50 euro card,
you can find the vulnerability and the
same way you can. It's just a very quick
example. But you can find also we found
the same common injection which took some
time for the guy to find the
right spot automatically is easy to find.
Now we go to court,
which is basically a very peculiar
and we can go to
WiFi set up.
And to
try to.
To do the same, I mean, it's
basically the same the same page in
the back because it's a parallel, but
their output is different.
That's why I told you the similarity is
different, because
if you look at the source.
No, not this one, uh,
frame source.
You see where there is Vizcarra
everywhere, so basically they use race
cards as the caffeine,
um.
And you say that it's basically the same,
that is where you can find exactly the
same vulnerability, exactly the same
philes car that it whatever
it name it is a very simple
by just triggering the tools and
basically the tools will do this for you
because it was for everything, for
exercise, for common injection, for
reversals, for file inclusions and
so on.
So basically
that's that's
the idea.
Well, I guess I'll conclude now
and we'll leave some
minutes for four questions.
But the idea is that I can assure
you that there are plenty of Latin
vulnerabilities in embedded former
Wideman's.
And because we are there, we just way to
be discovered.
And many of the farmers are all this
help or even if they
get updated, we see cases where
they ship in 2014,
2015 Fenmore update
10 year old busy box or
Linux kernel version.
I mean, uh, feel security
analysis is absolutely
necessary is another conclusion, and
we see it by every day because the
everyday that Juniper
Back-Door popped out, everybody
started analyzing the funeral of Junipero
S.. Right. So I
we we we we think and we also
we agree with the former security analyst
is absolutely necessary.
And a broader view on perfumers,
not just the very particular view on this
set of Fillmore's is not just beneficial,
but is necessary because you can see what
you can relate the same vulnerabilities
or different vendors and you can actually
discover the big surface, the big impact.
You never know when we'll
find those dual keys
in other Fillmore's and we will be
surprised if it's actually not just
Junipero OS was
or was affected by the back door or
whatever. It was just an example.
But of course it involves many untrivial
steps and challenges.
We have to overcome them in
some ways. Sometimes we take
shortcuts and we don't get the 100
percent results.
But as long as we get some
vulnerabilities, it's important.
And that we we also
see that for many vendors,
in particular, the white labels, but
not just white labels, it's also the big
corporates who buy the white labels.
But security is
clearly not a priority.
But it's a tradeoff with cost
and time to market. And we prefer not
to invest a lot and actually be first
to market. And they completely
ignore the security.
So vis A
are my references, you
are more welcome to to read them,
share or tweet or cite
them in your papers or studies
or give me
a sign if you need
any question
or any advice or you have an
idea.
I am.
I'll be around or you'll reach me
on my email. I'd like to acknowledge
my colleagues with whom I have done part
of his research and work,
John Arzak, our Lanfranchi Down
the Road and Apostolis US.
And thank you.
If you have any questions, I'm
ready to take them.
Thanks for the great talk and we're
taking questions now for 10 minutes, and
if you absolutely have to leave the room,
please do so as quietly as possible.
Um, OK, so just walk
up to one of the microphones on my left
or on the right, um, and
ask away.
We start with a microphone to my right to
please.
Hey, look, I
thank you for the great talk.
I was wondering if because
because you don't always actually
purchase a device and actually test
exploits directly on a device, if you
have trouble
with vendors
acknowledging or being willing to
receive
vulnerabilities that haven't actually
been tested against the physical device.
OK, so I'll repeat the question whether
the fact that we don't always buy the
devices and we don't test
on actual devices whether the
vendors are willing to take
those reports in and
address those vulnerabilities with.
Yeah, yeah.
So actually when
we talk today, I want I
the plan to to drop some zero days
in some of our routers, but
because the
vendors actually listens or started to
listen, we'll have to delay
some of those.
So the short answer is
yes. Most of the vendors start right
now looking at these reports, even
though they are not tested on real
devices.
They look at these reports and
we provide as much detail as possible
regarding how we found them and what
is very triggering
input or what is very exploitation
methodology.
And if they are not willing to take
it in a responsible disclosure manner,
then it is becoming full disclosure after
the time out then OK,
otherwise I do not say.
But yeah, to confirm is,
is that the
vendors started looking at these
reports, at least in our case,
and is good.
They don't have a zero, they maybe they
have time to fix it.
Great. Thank you.
OK, another question from the microphone
to my father.
Um, congratulations on a great talk.
Thank you, Will.
Did you actually write Kimeu
devices? And if so, will you make them
public?
Oh, that's a very good question.
I'm not very kumu
guy.
Dr. Jonas Other my colleague,
he is a very good kumu
guy who is actually working on
binary dynamic translation and analysis.
And he he actually
writes plug ins to map
both devices.
And I only recommend
to contact him if you have
any questions regarding this thing.
In our methodology, we just used
bare metal chemo, but
that is where once you have a library of
chemo plugins or devices is
just easy breezy to
plug them in and basically broaden
your testing surface.
Thank you.
So we have one question from the
Internet, if I'm correct.
Yes, so joining
us are all the features
you mentioned today, available
information or R.E.
or and also is
the project opensource?
Are readily available for download.
OK, so there
are two questions, whether the.
Films are available to be
downloaded and whether it's open
source first.
Oh, we can we can share
some of the metadata and information
about the finnemore, but we cannot share
the Fillmore's themselves because of a
copyright. I mean, we don't we are not
distributors of software.
And usually these fires back.
If you start putting them on your side
with fires, back with legal claims
that you are distributing illegally
software, which you are not entitled to.
And this is kind of a tricky situation.
But to address this, if anybody
wants to run a specific
test or analysis on the data we
have just dropped by an email, I'll
try to accommodate the Rania's create or
I'll try to to to give you access
on our ARMPAC environment where you can
run it. So this is the first question.
And second, our project
is well, is not intended to
be run as open to be
released as open source is more intended
to be run as a service
where we can give
back to the community as much information
as we can and at
the same time try to
to improve our things, basically
is not rocket science.
What we've implemented is well described
technically in the paper
is just a distribution of jobs and
so on as we sometimes
also contribute.
Comets or bugs
or improvements to some of these tools
like Moonwalker, binary analysis, tool
kit. So in that sense, yes, we contribute
also to the open source community.
OK, we'll take two more questions.
So please, to my left.
Hi, thanks for a great talk,
and actually I have two questions and
for a short question is that how
long does it take usually for
the dynamic analysis on
the farmers?
OK, vulnerabilities.
OK, so so to emulate
it, it takes
OK, we take some some
measure of precautions.
We're having some dead times where we
we do weights or sleeps just
to make sure that all the set up is fine
because you you cannot expect
a consistent or constant time from chemo
running in different virtual machines,
running on different hardware across the
globe. So you don't have a consistent
time, but in general
is to to
start the chemo for a particular
image takes around, I
know, up to five minutes,
depending what it has to load and all
devices it can or cannot find or
all kinds of folds and to
test it, it also depends
on
what kind of dynamic analysis.
In our case, we were on the testing
and we use the excessive SRF and
or always command the injection
models from Arachne and
they may very well take quite some time
to generate around 10000
20000 fuzzing inputs per
each class.
And basically it
takes around half,
half an hour, one hour to to
test.
Can I have one more question?
I think we should take the ones waiting
over there for a long time, so,
OK, first of all, thank you for the
beautiful talk.
I have many questions, but I
have selected one that is most
for me interesting.
How would it go about scaling
the, uh, the firmware
retrieval part?
Because from some of your slides,
I took, um,
thought that your current
sample size is about to two
thousand for very much.
Is that right?
And, uh, actually,
how do you go about loading
and processing all of the
firmware from different
browsers which are not publicly
available? And it seems that
it involves, like manually Googling for
their website to download the
firmware.
And and so this
was the first one and the second one.
What is your current sample size?
OK, so the current sample
size, we have
collected sample size, which you used for
the first study, and it will
it was around one estimate, up to around
170000 Fillmore images.
OK, 170000 fewer more images
which we called using the Google
custom searches or using FTP
spiders and have to be indexing sites.
And we just took a seed of
500 EFTPOS and vendor
sites and start crawling
everything. And then we just filtered out
the web with basically the PDAF
documentation drivers and so on,
and we ended up with one hundred seventy
thousand files.
Now we did the static analysis
on thirty two thousand
unpacked files because academic
deadlines do not usually meet with
our desires. So we had to cut some
lines and do on a shorter
scale of a static analysis and
the dynamic analysis as well, because it
takes much more time to
emulate than pentathletes.
We did it on two thousand
more images. We tried to emulate
and find Web vulnerabilities
in around 2000.
OK, so this is basically a breakdown
of the sample size.
Now, how do we do about the
files we cannot get?
Of course, there will be always files
behind the paywall at registrational
or which are not available.
If you are not registered as a customer
or as a reseller and
so on, which is why we have this service
where people can draw them.
And as we move forward,
we'll try to perform machine learning
as well as to classify them and
also to analyze them and give results
back, not just on the files we have
and from the public interface.
We collected around 2200
files, uh, around 10
gigs of data, so
around 50 megs per file.
But there are some some bogus files as
well. People just drop some movies and be
present.
OK, thank you. Unfortunately, we're out
of time, so we cannot take any more
questions. Thank you for being here this
morning and enjoy the rest of the
Congress.