>> Securing your embedded devices is very important now that they
are connected and exposed to the public in many ways.
But being able to scan the firmwares
of these devices is really important to be able to secure them.
Terry is here to tell us everything with
his background in security and you'll see it's pretty impressive,
everything you need to know about
scanning and securing your IoT devices firmware.
This is today on the IoT Show.
[MUSIC]
>> Hi, everyone. This is the IOT show.
I'm Olivier your host,
and today we'll talk about
the importance of scanning your device's firmware.
For that, I have Terry with me. Terry, how are you?
>> I'm doing great. How you have you been?
>> I'm fantastic. I'm great back in studios which is fine.
You had the first IoT show back in studios in a long time.
>> Get out of here. Come on.
>> You are.
>> Cool. Do I get an award or something for this?
Some plaque?
>> I'll give you a sticker.
>> Stickers are fine.
>> We like sticker. Hackers like stickers.
>> Terry, before we jump into the topic
of scanning your embedded devices for one.
>> Sure.
>> Who are you? What are you doing at Microsoft.
>> Actually it's an interesting story.
I came from the US National Security Agency;
me and the entire team.
We were doing offensive cyber ops and so we were
wearing different hats and I left the agency,
started a couple of cybersecurity companies
and one of them focused on
firmware and basically taking a compiled firmware image,
reverse engineering it and looking for vulnerabilities.
In 2018, we happened to
be in the RSA Innovation Sandbox where we were on stage,
presented our capabilities which at the time were cutting
edge and somebody from
Microsoft saw us and approached us and said,
"We think Microsoft might be interested in your technology."
>> You're kidding.
>> A couple years later, here we are.
We got acquired by Microsoft,
so now we're part of the Microsoft family.
> Nice. You're here to talk about IoT specifically?
>> Yes, that's been our expertise.
>> IoT devices. Why? Why because traditionally IoT,
before it was called IoT, it was called Embedded.
>> Embedded, exactly.
>> Embedded Development. I was there.
Because these devices were not connected, it was important.
They were secure, but not that important.
Nowadays they are exposed.
They're out there; these devices.
I bet that when you started doing these scanning of firmwares,
you got pretty scared of what you were seeing.
>> Absolutely. Now, you've got to remember, like you said,
these devices usually aren't connected
or initially were not connected,
but now they are, and so security
as in most situations is usually an afterthought; secondary.
But what's even worse than that is
the code quality in these types of devices.
We're talking very simple coding errors
that could be fixed just by knowledge.
For example, buffer overflows
that result because you're using insecure coding functions.
There are secure ways to use the same function and people for
whatever reason are not using these and
these lead to devices that are easily exploitable.
That's just one parameter that we look at.
But it's the one that I think can be most
easily fixed just by pure education.
It doesn't cost money to write a line of secure code
>> Yeah. I remember the times where I was writing real-time code
and these problems had performance impact, not security impact.
But yes, definitely. I mean,
thinking about security at the same level as
performance for these devices definitely becomes paramount here.
The network access is one of the things but
there's also the physical access to the devices.
>> Yes.
>> What about making sure that you
can scan a firmware? Can anyone do it?
>> It depends. The way that we scan firmware
with our technology is you have to have
a copy of the compiled firmware image.
For example, if you went out to
a vendor's website like a Linksys, a NETGEAR,
a Lenovo, an HP,
and you download a printer firmware or a router firmware.
If you take that and put it into our platform,
it will automatically deconstruct
that particular firmware image and not only
look for those insecure lines of code,
but we find other things like
expired SSL certificates and cryptographic keys and
all things that current security products don't look at.
Now, if you have an industrial control system,
maybe something that's built by Siemens
or something that's built by Rockwell Automation,
those firmware images are not publicly available.
You might be able to get them through
your sales representative or
your contractual agreement with those companies,
but you or I
cannot go out and get those and put them into the platform.
>> Got it.
>> That's a limitation of the platform right now is we
can't scan the firmware as it resides on the device.
We physically have to have it right.
>> On site.
>> Exactly. Now there are
techniques where you can extract firmware
from running devices out of memory and put it into the platform.
But in most cases,
that usually destroys the product
because it's a very invasive procedure
>> Yeah. You go get the firmware from
the ROM and usually burn some fuses on the way.
>> Yes, exactly.
>> Which is some way of securing.
That thing is dead.
>> Exactly.
>> We have Azure Defender for IoT which is
a product that allows scanning your network
and detecting problems and and
risks I would say on the network
based on what the devices are doing.
>> Exactly.
>> How is this solution that will be about
the firmware part of it integrating to
the broader IoT security story?
>> Yes. That's one of the reasons
that Microsoft acquired our company ReFirm Labs,
was to add that firmware component to Microsoft Defender for IoT,
because that platform has the ability to scan the network,
looking for IoT devices,
creating an inventory,
and then tracking those devices and then looking for
anomalous traffic and other threat indicators to say,
this device is possibly under attack,
you may want to take some particular action.
In our case, what will have to happen again is that
the end user will have to acquire
the firmware from the manufacturer to put it into the platform.
That's in an enterprise case scenario.
Now, Microsoft understands that we're
accelerating towards the adoption
and creation of more and more IoT devices,
so they want to shift left and start targeting
the developers of these devices
before they even get out to
the marketplace and make them secure before they hit the market.
How this would happen is that if you were willing to
put the Defender for IoT micro agent on your device,
then you will be able to
scan the firmware as you're developing it.
Then if it passes
a certain Microsoft baseline to be determined of security,
then you'll get a particular stamp of approval;
a logo, a certification Defender for IoT certified, for example.
>> I like that.
>> Then you as the consumer and an Azure subscriber,
you buy this IoT device,
you plug it into your network and it immediately start sending
a telemetry up to the Cloud to Azure and to Defender for IoT.
Now, let's say a new vulnerability emerges,
say an open SSL.
That's going to be surfaced as a new CVE in the platform.
Then not only will you as the end user be notified so you
can then take appropriate action
to protect that against the threat,
I as the vendor who created it,
will also get a notification to let me
know that a patch or a new update is warranted.
Then I can take that newly updated firmware,
push it up to Azure device update
and then it would automatically go out to all the customers.
Its a whole device security lifecycle type process.
>> With months of experience when it
comes to dispatching or broadcasting,
let's say, updates for Windows PCs.
Because the Windows update for IoT Hub
is based on the same technology
we're using for updating Windows machine.
>> Yes.
>> We know what we're doing here.
>> The plumbing is there?
>> Plumbing is there, engineering as well.
Let's let's look at how that looks like.
>> Sure. Now, let me let me preface this by saying
what we are looking at is Binwalk Enterprise.
This is the actual commercial product
that ReFirm Labs was selling to customers.
Our customers that we still have today
are actually using what I'm showing you right now.
This is what we're internally calling our
legacy platform because this is going to
go away once our features
are added to defender for IoT, but it's a long way.
>> But we should expect the same features and
experience because the core of the tool.
>> The core results. Yes, exactly.
What we're looking at here is basically
the scan results of a firmware image.
Now, the analysis actually
the time it takes depends on the size of the firmware.
Now, I wouldn't call an entire four gig
distro from a boom to a firmware image, but some people do.
But we can analyze it. It takes hours.
>> In better space they do.
>> That's crazy, but whatever.
Here's one that only took a couple of minutes.
I'm just going to go over some of
the key things that we pull up here.
For example, we have the entire file system that we
can click into and look at your directory tree.
There's nothing special there about that.
The cryptographic material, though,
this is where things get interesting
because if we click on either one of these,
we're going to get some details about
the private keys that are actually embedded into
this particular firmware image and we can
drill down into this to get key specific information.
We got the public keys that are there,
which may or may not be of interest.
But I'll tell you what's really interesting is the certificates.
If we filter out on expiration,
you can see that this firmware is shipping with
a number of expired certificates.
I will tell you, being the gray hat side of things many years ago,
there are sophisticated ways to use
expired certificates to conduct man in the middle attacks.
Why are we shipping IoT devices
out there with expired certificates?
If you're concerned about security, get them out of there.
>> Yeah. Well some people would say the answer
to what you just asked is because
these devices often are built for 10,
20, 30 years, and
until recently they were not meant to be updated.
Don't change something that works right.
Don't fix something that is not broken.
If you don't know it's broken with security problems like that,
so you don't think about fixing them.
>> Going back to the the use case
where this is in an industrial control
setting where you can't take these things
offline or you might not be able to update these things,
a platform like this will at least
make you aware that the problem exists.
Now you can put together
additional defenses to prevent
the exploitation of any of these types of attacks.
This is where we actually build the core
of the program is around the code analysis.
What we try to do is surface
potential zero day vulnerabilities here.
We do it through a multi-stage process,
but to get to the mid of it,
if we actually look at the critical vulnerabilities here,
we see CGI bin has
23 buffer overflows and three command injection attacks.
Then we can drill down into
exactly which lines of code are causing that.
>> You don't have the name of the developer.
Line of code and name of the developer.
>> But you can see how you can drill down into here
and as a black hat this is very
useful because now if I'm trying to actually
weaponize one of these potential
vulnerabilities and create an exploit,
my research time is now cut down significantly.
I can start doing some trial and error
with the stuff that's surfaced right here.
That's the code analysis section.
A big thing that's even come out it's got the backing of
the White House is software bill of materials.
If you are going to be selling IoT devices to
the federal government and the military,
you need to supply them
a software bill of materials of the IoT devices so they're
aware of what open source packages
are used to create this firmware image.
We started doing this many years ago where we can
pull out the actual names of the open source packages,
give you the version numbers,
the license number and a link to it
in the firmware image if you need to pull it out.
Now, I will caveat this by saying we don't look
for every open source package yet.
Hey, we do have a sub list subset here,
that these are some of
the more common components that we find in IoT devices.
We look for the big ones and the way things are going now,
now that we're part of the Microsoft family
and we have a lot more engineers,
what we're going to try and do is actually ask
vendors and people using the platform to possibly upload,
for example, your package manager information.
Because now we have a complete comprehensive list and we
can do that CVE analysis more accurately.
If you don't provide it, then you're stuck with
our canned list of 60 plus things that we think are important.
>> Got it.
>> The other thing, too, that's really interesting,
especially for security pros is looking at the usernames,
the embedded usernames accounts,
we give you the hash, the salt,
the algorithm that was used,
and you can export all this stuff.
If you want to export it and put it into
a password cracker and see how secure the passwords are,
you have that capability.
Obviously the CVE this is no rocket science here.
We take those open source components,
match them up to at this point in this database.
But now that we have the resources of Microsoft Research,
we're going to be able to expand beyond just the next database.
This is nothing but your traditional CVE analysis there.
Security checklist, I'm not even going to go into that because
that's probably going to go away. Binary hardening.
Now, if we're talking to coders and developers,
you know that when you're compiling a firmware image,
you can set certain flags at
compilation time to make it more secure,
so we check on that too.
Obviously this firmware image doesn't
have much in terms of those flags turned on.
But we give you the ability to go through here and filter by which
flags are enabled or disabled
and give you additional information about it.
It's like the Apple fitness score here.
This is obviously not a very healthy piece of
firmware based on the rings there.
>> Still have some steps to go through.
>> That's pretty much the high level analysis that we do.
Again, this is the legacy platform,
people can get access to this for free,
but the same information will eventually make its way into
Defender for IoT and that's where
these results will be manifested.
>> Two points, one reassure people this is freely accessible
but the firmware you
need to acquire it from the manufacturer vendor.
Basically it's not like hackers can go around and say, hey,
I like this device here,
let me grab the firmware and test it and then I find all of that.
People should be reassured that it's not a tool for hackers,
it's a tool for fighting of IoT devices.
The other one is all that makes me
think into talking about giving that information to developers.
Integration of DevOps, I guess is something [inaudible].
>> There is another avenue that
we have yet to explore here now that we're part of Microsoft.
We've had some conversations with
Microsoft Federal whose customers have
expressed interest in this type of
information in their secure DevOps lifecycle.
Yes, there is a need there for that
and we haven't even begin to tap that avenue yet.
>> Yeah. Lots to come, I'm sure.
>> Yes.
>> One last question.
>> Sure.
>> Your technology is about
the compiling binary of the firmware or something like that.
There is a variety of compilers,
hardware architectures out there and so on.
Is there a list of what
supported and not supported, is it extended?
>> Very easy.
It will be extended but if
anybody actually uses this existing platform,
here are the current limitations.
It's got to be a Linux only based from our image.
The architecture supported our MIPS arm
x8664 PowerPC and something called Super H.
>> Super H.
>> Yes, that was for a special customer
so we created that capability.
We do have some very basic crude capabilities
for something called E costs and VX works.
If you want to try that. Azure Atos is coming
all the Atos [inaudible].
>> Its perfect. Love it. I appreciate your time Terry.
If people want to learn more, they can go try out Binwalk today
and looking forward to see
all of that integration to Defender for IoT. Thanks for your time.
>> Hey, thanks for having me on the show, Matt.
I appreciate it. Thanks so much.
Thank you. Everyone if you want to learn more and get to
try what Terry just presented and play around with that,
you can check out the link below here.
Otherwise, looking forward to see you on the IoT show again.
See you, bye.
[MUSIC]