Foundations of Trust Part 4
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:00
Hi, I'm Matthew Clark and this is Lesson 4.4
00:03
Foundations of Trust part for In this lesson, we'll look at the Threat Profile matrix.
00:10
We'll discuss physical security and how to abuse the root of trust and will conclude with the case study.
00:16
So let's get started. Let's start with a quiz question.
00:20
Which of the following are elements of a root of trust
00:24
cryptographic functions,
00:26
secure boot,
00:28
isolated environments
00:30
or in beautiful code?
00:33
Trick question Because they're all elements of a root of trust.
00:36
Can you name the elements that are missing? Secure processor and secure storage? Yeah, absolutely.
00:43
So let's take a look at a threat profile matrix.
00:47
When the OM is designing the architecture, er the sip so will perform. A threat Analysis is part of that risk assessment.
00:55
She will look at the logical and physical vulnerabilities and identifying the local and remote threats, which could exploit those vulnerabilities
01:03
so logical vulnerabilities could be threats in this code. Secure implementation of encryption or weaknesses in the non physical aspect
01:12
and physical vulnerabilities could be things which are going to affect the physical side of the device, and we're going to get into that much Mawr in the next couple of slides.
01:23
Local threats are attacks that target the logical and physical aspects of the device itself, such as proximity attacks,
01:32
tampering attacks like low power fault injection, JPEG tampering,
01:37
trying to expose the encryption keys
01:38
and remote threats Are attacks that target the physical architectures or logical weaknesses like denial of service or buffer overflow.
01:49
The sip so can then use this information to plan controls to bring inherent risk in line with acceptable levels of risk. So let's talk about physical security
01:59
when UH oh am cells and I o T device. They really have no idea where that I o. T. Device is gonna end up or who's gonna be poking around with it.
02:07
I o T devices have to be secured from physical attacks, and those physical attacks generally come in two different types. Invasive and noninvasive.
02:17
Invasive attacks are ones in which the chip surfaces exposed, and non invasive ones have relative proximity to the chip to try to sense electrical characteristics, either to change the behavior or to try to gather sensitive information.
02:35
So let's start with invasive attacks.
02:38
So there's several different types of invasive attacks on more than we're even gonna talk about. But tampering is one of the one of the big ones, and this is a physical tamper or even a damage of the chip, generally using metal probes and that's done to gather sensitive information or try toe alter the circuit behavior
02:57
fall powerful injection. It's another type of of invasive attack where you're trying to tamper with the power supply or change the clock frequency.
03:06
Um, attacker. If they have access to the debug ports, then they'll try to use those
03:12
or physical ports such as USB or cereal.
03:15
Another attack. Invasive attack. His active timing attacks, which required physical access to the timing circuitry.
03:23
So let's talk about non invasive attacks thes air ones that generally have a proximity to the chip.
03:29
There's different types, and let's start with side channel analysis. This one is where the Threat actor attempts to analyze the chips, power signature or radiation, and attempts to extract sensitive information such as secret keys.
03:45
They can try to change the normal operational state either by through temperature, such as changing the operating environment temperature, making it too hot, or making it too cold to see if the at fault can be introduced,
03:58
uh, messing around with the power or performing a clock reset to try to create a fault
04:05
performing power analysis. And that's either through simple power analysis or differential power analysis,
04:12
they could perform an optical attack by trying to create a fault using a laser.
04:18
Also, passive timing attacks these air noninvasive measurements of computation time, and what they're doing is they're trying to determine cryptographic operation.
04:29
So what kind of tools do threat actors use to be ableto perform? Physical attacks?
04:34
Well, generally a screwdriver and pliers and soldering iron is probably some of your more basic and common tools. And then there are plenty of other tools that are out there more than we'll ever have. Slides are time to go through.
04:47
Some of the ones that I'm familiar with are the bus pirate, Um, and the Shericka. Maybe I'm saying that, right? I don't know. There's other ones. JT a goo Laters. Another one that test pin commute combinations. Beagle, bone black. That's an all round test tool.
05:04
It has a development platform where you can set up to perform different test,
05:09
but there's a wide variety of tools that are out there and you can see from these screen shots. You see how it's very physical in nature, their actually attaching to J tags and Andi using probes.
05:20
So let's take a look at a case study. Let's choose one from 2018. They really goes along with the material. In this lesson.
05:28
In this case study, security researchers chose a smart hub that was designed to control sensors and devices installed in the home. It could be used for different purposes, like energy and water management,
05:40
but it could also monitor and perform security services.
05:44
And it was could be configured to alert emergency when our services, if necessary.
05:48
So the device received information from all the devices that were connected to it and communicated out to the customer. Be a phone SMS or email if an alert condition has created so plenty of opportunities for things to go wrong, especially since it had a connection out to emergency services.
06:05
So let's talk about what the firm with what the researchers found. They first started with the firm where they found that the firmware itself could be downloaded from the Internet, really without a subscription,
06:15
and it's hard to protect intellectual property if it is so publicly available.
06:20
They found that the root account password in the shadow file was encrypted, but it was encrypted with D s, which is not a really strong control. To protect passwords from brute force attacks,
06:32
they found that the hub could be controlled either through a mobile application or a Web portal.
06:38
And so the security researchers started zeroing in on that.
06:43
They determined that the device information was stored in a config dot jar file, and then they did also determine that file was being sent. Be a clear text using http.
06:56
The file revealed the devices serial number that that serial number was being used as the device identifier and serial numbers not generally the best divisive identity, especially if there's nothing else to go along with it.
07:10
The security researchers determined that hackers could send the same request to the server with an arbitrary serial number, is the payload and download an archive of that device. If that serial number existed more on this archive in a minute, just remember that you can download other people's archives if you have their serial numbers.
07:30
The process of checking to see if an arbitrary serial number existed or not was pretty straightforward. From attack perspective. To check the serial number, remote Attackers just had to send especially crafted request to the server. And, depending on the service reply, they would receive information if the device was already registered in the system.
07:50
If that device was registered in the system, then they could request that devices archive. So what's in this archive?
07:59
Well, among other personal information, the archive contained the user's password for the mobile app on the Web portal.
08:07
But that's okay. The Ark I was encrypted.
08:09
However, the security researchers determined that that encryption could be easily broken with the help of publicly available tools and hope and source password databases.
08:20
And because users were not required to adhere to certain password complexity requirements during the user registration process, like password link, their requirements of capital number letters or numbers or special characters that made the password extraction a lot more simple.
08:37
So even if they fixed all those issues, they would have still have problems, because the security researchers found that that config dot jar file contained a little something else.
08:48
The config dot jar file that contained the device identity, which was the serial number and was sent in clear text using http, also contained the log in and password details all all of everything that was necessary to access the user's account through the Web interface.
09:05
So no need to crack the archive file it all.
09:09
The file also contained other personal information. They could be used. They could be discovered, such as the phone number for SMS alerts, email addresses, you know, and other things.
09:20
So what can we learn from this?
09:22
Well above everything else, Security absolutely has to be baked in. You can't go back and add security after the fact. Hardly any of these controls would have would benefit from security after the fact.
09:35
Security has to be considered at the earliest stage of the development process,
09:39
and other than that, well, we have the obvious.
09:43
Having firmware so readily available makes it difficult. Makes it easy to reverse engineer and look for bugs or steal the intellectual property and make it is your own
09:52
serial numbers really don't make the best device identifiers, especially if there's nothing else that goes along with it.
09:58
And while encryption is a good way to protect device secrets like root passwords you need to use a modern, secure algorithm
10:07
and the use of nonsense will be helpful
10:11
and require password complexity during users. Sign in and sign up would also be very helpful.
10:16
But one thing to think about is don't bother to use encryption at rest if you're just going to send the password in clear text over the wire. In fact, just don't store the password at all.
10:28
You secure authentication, which is number two on the OAS Top 10,
10:33
and ensure the Web interfaces air not susceptible to other OAS Top 10 the tax either, such as unauthenticated lookups of devices for retrieval of configuration data.
10:45
So hopefully, as we go through these case studies, you can start to understand where and how security should be layered into the I o. T ecosystem.
10:52
And as we as we read about this particular case study, it's entitled I O T Hack. How to Break Into a Smart Home again, and it's published by secure list dot com. I've included a link to it and the references
11:07
Well, that's it for this lesson. What did we learn? Well, we reviewed the threat profile matrix. We looked at physical security and kind of talked about some of the ways that physical security could be addressed. And we explored ways to attack the root of trust. And we take a look at the case study and hopefully can started to learn how to apply some of those lessons of what we're learning.
Up Next
Instructed By
Similar Content
