DEF CON 29 - Mickey Shkatov, Jesse Michael - High Stakes Updates: BIOS RCE OMG WTF BBQ

00:09 - We are Jesse and Mickey. I am Mickey. - [Jesse] I’m Jessie.

00:13 - - [Mickey] Here are our pictures. So you can someday find us and harass us face to face.

00:18 - We both work at a startup named Eclypsium, who has generously funded this research.

00:23 - And down below are our Twitter handles where you can heckle us and ask us questions at any time.

00:31 - And this talk will give you some background as to how it all started.

00:35 - What we call the background story. Before we talk about what we found and how we found it.

00:41 - Once we are all on the same page, we’ll dig in a little deeper into the exploitation of these issues and finish up with discussing the practicality of large scale exploitation of these issues.

00:56 - In the last five years, we’ve seen almost an explosion in the amount of firmware related vulnerabilities.

01:02 - We’ve seen more and more publications about silicon side channel attacks and more attention is put on lower level components from the Intel IME to AMD PSP, to PCI bridges, (indistinct) controllers, and even more components in the server world.

01:19 - Since the term firmware is very broad these days, in this context, we’ll use it to describe BIOS or UEFI firmware.

01:27 - Now in my eyes, threats and vulnerabilities are not the same.

01:32 - Threats are manifested using vulnerabilities.

01:35 - For example, there is no threat without a vulnerability of some kind.

01:38 - So in response to this growing problem of increased threats, more and more solutions are popping up.

01:45 - The easiest and most known solution to talk about is Microsoft Secured Core PC.

01:51 - The marketing material for this solution has been putting emphasis on how large scale the firmware problem is and how we’re all oblivious to it.

01:59 - The way this is done is by utilizing a range of hardware and firmware security features to work in unison and provide a sort of umbrella coverage to protect us all.

02:10 - But not everyone can get a new computer with all the top security bells and whistles and not all computers are going to have them either.

02:17 - So for normal users, the problem remains, and it’s simple to explain.

02:22 - There are more issues to patch in firmware and patching or updating firmware has never been a very user friendly process.

02:29 - In fact, many knowledgeable users still fear it because of a mishap they might’ve had in the past themselves, or have heard of a friend breaking their computer during a firmware update.

02:41 - There are some ways the user experience, or UX, problem is being attempted to be solved with minimal user interaction or by using classic OEM tools or update packages, or by manually going into the BIOS menu and flashing through their.

02:56 - LVFS for example, is the RedHat open source way of providing firmware updates in an automated way for Linux users.

03:04 - Windows update is another process of doing this on supportive machines.

03:08 - The easiest example is Microsoft’s Surface lineup.

03:12 - Since they control the whole vertical from firmware to software and manufacturing of the computer, they can have the OS do the update process for them without worrying about any third party not doing proper validation and breaking their system.

03:27 - By the way, this does not mean that bricking is not a real possibility.

03:30 - For example, there are always these unfortunate souls who’s experienced that one bizarre power outage, right smack in the middle of a BIOS update.

03:40 - HTTPS Boot, which is also used to recover an OS But we listed here because it’s a part of the recovery “umbrella”, which can also apply updates as a new version of OS installed over an older one that’s not working anymore.

03:55 - All these methods of updates and recovery need to be done in a secure and safe way.

04:01 - Especially if they involve using a network connection at any point.

04:06 - We’ve had some experience dealing with remote code execution in the past.

04:10 - Back in 2018, we’ve discovered vulnerabilities in Asrock and ASUS update process through BIOS.

04:19 - You can watch our Black Hat and DefCon talks from that year if you want to learn more.

04:25 - Looking at some of the big names in the enterprise computer hardware world, we did some attack surface scoping.

04:31 - We started with HP and looked at their PXE Boot and HTTPS Boot features and we couldn’t find anything that stuck out there.

04:38 - We also took a look at Lenovo’s capabilities.

04:41 - They’re very similar to HPs, but with less fancy user interface.

04:46 - Nothing stuck up there either. We then moved to Dell and then we noticed that they had more options and more fancy UI.

04:57 - We noticed two new options coming in from Dell.

05:00 - One is to make it easier to update the BIOS without an OS.

05:04 - And the other is to recover the OS from an unrecoverable state.

05:09 - Now don’t get me wrong. Both are very useful features that I wish I had these many times during my career using computers.

05:16 - So please don’t take this talk as a discouragement against using these in general.

05:22 - Both of these new features appear to be a part of what’s called Dell Support Assist.

05:27 - Which is an umbrella definition. I’d say umbrella because the same term covers software utilities in the OS level, as well as the firmware features.

05:38 - Some of you might call it bloatware. That’s the stuff where it comes installed by default on most Dell systems.

05:44 - There’s some ways that the Windows side of Support Assist can interact with the firmware side.

05:50 - Those are well documented. We’re not going to go into them right now.

05:53 - If you want to go explore these, you can Google them and you will find plenty of documentation covering this.

06:01 - But for the contents of this talk, anything referring to Support Assistant will be in the context of firmware.

06:08 - Let’s say a regular user gets into the boot options menu.

06:10 - After either something bad happened to their system, or they need to do a BIOS update.

06:16 - This is the screen that they would see. This is the boot option menu or something similar in any other platform.

06:23 - This is the example of what we’re seeing on our Dell Latitude 5320.

06:30 - If their system will not boot to an OS and it needs to go through recovery, then they will have the recovery option.

06:39 - If they need to do a BIOS update, but not use Windows, they can use the BIOS firmware update remote option.

06:49 - The BIOS setup, the diagnostics, the BIOS update, and the device configuration are usually out of reach for normal usage scenarios for common users.

07:02 - For more technical users it is something that most of us are probably familiar with.

07:10 - In case some of you missed that. That was a BIOS flash update over the air.

07:16 - Not just the BIOS update, the OS recovery is done over the internet.

07:22 - What could possibly go wrong? So let’s take a look at how these features work.

07:29 - We need to set up a machine in the middle environment.

07:33 - We start with using the community edition of pfsense running on an old desktop we had lying around.

07:39 - And once we had all of that working, we set up a sniffer and sniffed the traffic.

07:47 - Looking at the initial packet capture, we can immediately see a ping going out to 8. 8. 8. 8, which is Google’s DNS server IP address, and a DNS query asking for the IP of downloads. dell. com.

08:01 - After that we see the handshake process starting and then failing.

08:06 - Looks like we need a cert. Well, what kind of cert do we need? We need a valid SSL cert.

08:11 - So we can use with our malicious server to do a proper handshake and sniff the traffic.

08:15 - So let’s look at the firmware image. We pop it open and we get this string.

08:21 - Now, if you look at it closely, you might recognize it.

08:24 - This is the text header of the Mozilla CA root certificate bundle.

08:29 - Now, this is just the first few lines. This file is very, very long.

08:33 - It contains the common CAs used by Mozilla.

08:39 - So let’s get a cert. First, we tried to get one from ZeroSSL.

08:45 - That’s a free service that gives you three months free cert for a domain that you own.

08:51 - You can play with it and try whatever you want.

08:54 - We got the SSL cert, we loaded it up in the server.

08:58 - Everything looked fine when we tested it independently.

09:02 - But when we went ahead and did the machine in the middle attack, it didn’t work.

09:06 - Turns out the CA that ZeroSSL is using. It’s not one of the ones that is listed in the Mozilla list.

09:14 - So we moved on. We tried, Let’s Encrypt.

09:17 - Took about three minutes before we realized that that’s going to be a hassle.

09:21 - It’s not going to be a point and click way to go to their website, like ZeroSSL, click a few buttons and get a certificate.

09:27 - So moving on. It turns out that you can buy a wildcard SSL certificate for about €70.

09:33 - Which is about $95 to $100. So after a few minutes Googling on the internet, finding the cheapest solution, we ended up buying a certificate from Certum, I hope that’s pronounced like that, and we’re set.

09:49 - And holy crap, it worked. We got a full capture of all the traffic decrypted between our laptop and our malicious server.

10:02 - Let’s take a closer look at those green lines in the capture.

10:06 - We see that the laptop is reaching out to downloads. dell. com and is trying to, first make sure that there’s a connection, and then retrieves a CatalogBc. XML file.

10:20 - Let’s take a step back and look at how this works in high level.

10:23 - We have our laptop reaching out to Dell servers over SSL and getting a catalog file with an XML format.

10:29 - In this catalog, according to what we chose in the laptop, with what option we selected, either firmware update, which we will reference as F-O-T-A or FOTA, or OS recovery that we will mention as C-S-O-S or CSOS.

10:44 - According to that selection, these will point the communications to the corresponding EFI file that will be downloaded from the server.

10:52 - Normally, modifying these would be out of reach because the traffic would be covered over the SSL.

10:59 - But since we bypass that barrier, we are able to play around and mess with the files and the process and see what we can mess with and fuzz.

11:08 - As a result of all this, we have found four CVEs.

11:12 - The first one was the TLS issue. Where the verification of the certificate was not done properly.

11:19 - In which the URL was not compared to the certificate.

11:23 - So as long as you would provide a valid certificate from a trusted CA you could impersonate Dell servers.

11:32 - The second, third, and fourth vulnerabilities are the ones we’re going to discuss deeper in this talk.

11:39 - - [Jesse] Okay. So now let’s take a closer look at some of the vulnerabilities themselves, and what’s actually happening here.

11:47 - This is some of the contents of that CatalogBc. xml file.

11:52 - It includes things like the baseLocation tag with downloads. dell. com.

11:58 - There’s a lot of model specific information in this file.

12:02 - But there’s also some of these software component tags that include things like the path to DellFOTALauncher. efi.

12:12 - There’s another one for DellCSOSLauncher. efi and both the firmware over the air update and the support assist OS recovery, depending on which path you choose, will pick a different software component to download and run from downloads. dell. com.

12:35 - If security is turned off, that’s an easy way to get arbitrary code execution during the pre-boot process.

12:42 - If secure boot is turned on, you do need to have a executable that’s signed by a key that’s allowed by EUFI Secure Boot, which would mean that it’s in the BBD database.

12:55 - In our investigation, we discovered that this base location tag has a buffer overflow.

13:01 - And this is a heat based buffer overflow that is in the UEFI firmware itself.

13:08 - So just the code that’s running before it even downloads and runs this DellFOTALauncher for when it’s parsing this XML file in a component that’s in the SPI, in your UEFI firmware, that’s flashed to the motherboard.

13:24 - That’s where this component, where this vulnerability lives.

13:27 - So there is this overflow in the baseLocation tag, and that was kind of fun.

13:31 - But there’s some more vulnerabilities we’ll look at as well.

13:35 - Starting the support assist OS recovery path or CSOS.

13:39 - One of the things that this does is it downloads a JSON file from from Dell as well.

13:47 - This is part of that JSON file. There are multiple sections that have a URL, size, and then a sha256.

13:56 - It turns out that this URL field has a stack buffer overflow.

14:02 - And also the sha256 field also has a stack buffer overflow.

14:07 - Let’s take a closer look at the sha256 overflow.

14:13 - The verification function to check and see if the file that was downloaded from the server actually matches that sha256 that was provided, has some bugs in it.

14:25 - So this is a simplified decompilation of that function, where it is taking the ASCII hex string, converting that to binary, and then comparing that against the hash that was calculated from the file that was downloaded.

14:45 - But this hex conversion that it’s doing, they are writing the converted values into a buffer on the stack without properly verifying that it’s only the length of a sha256 hash that they’re converting.

15:01 - If you take a look here, they will read up to 20,000 bytes from the hex string, but they can only write 344 bytes before they run into the same return address on the stack.

15:15 - This is a great thing for attackers because it’s a stack buffer overflow at a fixed address, and you don’t have to worry about embedded nulls, other bad characters, because you can just give it a hex string with whatever you want in it and that will get written to the stack.

15:33 - - [Mickey] So in the past, when we had to work on explaining bugs like this, it was basically set the easy mode because we could set the hardware to be in debug and using Intel tools we could just single step through instructions in real time and see how the bug is being triggered and how to exploit it.

15:50 - But that’s not common anymore. Modern computers and modern platforms no longer have that option easily available.

15:57 - So you have to be creative. Now it is however possible to do this.

16:02 - It’s just harder, but that will be in a different talk.

16:07 - Instead of using that debug mechanism, we are using the PCI Leech.

16:13 - We love PCI Leech (indistinct) is great. - [Jesse] The PCI Leech was a great way to dump all the memory in the system.

16:22 - So we didn’t have direct debug access. We couldn’t single step.

16:27 - We couldn’t do live debugging, but we had the ability to dump the entire address space, or most of the address space.

16:36 - So we ended up with a three gigabyte dumps and a lot of those.

16:41 - Since we had kind of an interesting year, we’ve been doing socially distant debugging.

16:46 - And Mickey initially found this bug and was able to dump the system using PCI Leech.

16:54 - And then he would upload this three gig memory dump.

16:58 - I would download it loaded into IDA, which has some issues of its own, and do some analysis and send a payload back, try something.

17:07 - And we had kind of this workflow, which was not ideal because Mickey has much faster internet access than I do.

17:15 - And at one point we discovered that because the system is booting up there isn’t really a lot, there isn’t a lot of live memory yet.

17:24 - So it’s mostly just a little bit larger than the BIOS region.

17:28 - So it turns out that these three gig memory dumps compressed down to around 17 megs if you throw it in a 7ZIP.

17:35 - So that sped things up a lot and helped quite a bit.

17:41 - For actually debugging these vulnerabilities one thing that’s really nice about exploiting UEFI is that there’s a one-to-one virtual to physical mapping.

17:53 - So all of the physical map, all of the pointers that you would see in the memory space are actually at those physical offsets into the file.

18:01 - So it was pretty easy to do that mapping and figure out what was going on.

18:08 - Where to find where things were, because I didn’t need to do any kind of translation or mapping between those.

18:13 - So it ended up where we were able to basically pass these dumps and payload attempts back and forth.

18:20 - Where we were able to test the payload remotely and confirm arbitrary code execution when I never even saw what the physical device looked like.

18:29 - So there are some things to be aware of when you’re doing this type of analysis.

18:34 - Especially with really large images, loading those into IDA.

18:38 - Make sure you turn off analysis before you load the image into IDA.

18:42 - These were three gig memory images. Even just loading that into IDA with 64 gigs of RAM it would go down unresponsive for awhile.

18:51 - I’d sit there for awhile, wait for it to load.

18:53 - And if you forget and leave analysis turned on, it’s really easy to run out of memory.

18:59 - And there are some cases where you might need to turn on analysis momentarily.

19:05 - Like if you’re using Hex Rays and something isn’t decompiled properly.

19:09 - You might want to turn on, just click to turn on analysis.

19:12 - Click again, to disable it and eventually it’ll start responding again and disable analysis.

19:19 - But if you forget, you’ll run out of memory.

19:21 - And even with analysis turned off, loading these three gig dumps into IDA was creating about 12 gig IDBs.

19:29 - I totally ran out of memory, out of disc space, multiple times while doing this and had to shuffle things around.

19:35 - Doing some preprocessing ahead of time to strip out the regions that only want it to do.

19:40 - That would have been a good idea. Some other things we ran into was once we were able to come and start working in the office again we put our test equipment in the office.

19:51 - We were able to do some tests that way, but then we didn’t really have the ability to test remotely in some scenarios.

20:00 - So I did some experiments of loading three gig dumps into Unicorn Engine and debugging first stage shell code payloads that way.

20:10 - And that actually worked really well. And I have a 128 gig (indistinct) system at home, and it would take about five minutes to test a payload and it would run through until it was jumping to the next stage.

20:25 - So that’s another thing that was really useful.

20:31 - So there’s some interesting complications to modern exploitation.

20:37 - There’s a lot of exploit mitigation techniques like the stack and heap used to be fully executable.

20:47 - All these mitigations were put in place. Address randomization, sandboxes.

20:52 - But in UEFI environment, it’s kind of like going back to the 90s because that’s still lagging significantly behind all these mitigations that were in the OS application space.

21:02 - So in most cases you have an executable stack and heap.

21:06 - You don’t have any canaries, you don’t have address randomization and you’re running and ring zero, essentially running in kernel mode.

21:13 - So (indistinct) core has started providing initial implementations of some of these things.

21:19 - Like non executable stack, but those need to be enabled by the OEMs.

21:24 - And we haven’t seen any real systems that have these turned on yet.

21:28 - Essentially anything that slows down the boot process, OEMs are hesitant to turn on.

21:35 - So, one of the things that we looked at for our payload is although there is no address randomization things can still load at different addresses just because of you might have a different system, different controller.

21:50 - Things might load at different addresses. So we took a look at places where we could find gadgets at known fixed locations.

21:58 - So, one thing that’s really useful is that the BIOS region in SPI is mapped at physically known locations in physical memory.

22:08 - starting at FF0 through the reset vector at 16 bytes below four gig.

22:15 - So we know where the UEFI firmware is going to be mapped at a physical location.

22:21 - So we can go look for ROP gadgets in the BIOS region that’s mapped from the SPI chip.

22:28 - There’s a couple of ways that you can get the contents.

22:31 - You can either dump the BIOS region using tools like ChIPSEC.

22:35 - You can use physical access (indistinct) SPI reader, or you can also just download BIOS updates and you can extract them using this great Dell PFS BIOS extractor.

22:47 - And it turns out there’s actually a lot of useful gadgets at fixed addresses in the BIOS region.

22:52 - Here’s an example of using ROPer to search for jmp rso equivalent instructions.

22:59 - In this particular BIOS image, we found 441 in this image.

23:04 - So the firmware across model families and different models tends to be different.

23:10 - But within a specific model, the different firmware versions tend to be similar enough that you could find common gadget addresses across all of the available firmware images.

23:22 - Here’s an example from the Latitude 5320. All of these versions have this gadget at the same address.

23:28 - It’s totally useful for us. So let’s take a look at what our exploit payload contains.

23:35 - So our first stage includes a JMP RSP at a known address that’s mapped from SPI.

23:42 - So we can reliably get remote (indistinct) without caring where we loaded.

23:47 - At this point, we can do whatever we want, but we want to use UEFI functions to do things for us.

23:52 - So to do that, we need a pointer to the boot services table.

23:55 - We can scan for the boot serve signature, take a look, find it that way, but we also need to point or to EFI handle for the current executable to do things like load image and start image.

24:07 - It turns out that that executable that they just downloaded from us.

24:12 - Dell SISA SOS launcher contains pointers to both of these.

24:16 - So we can just scan memory, find that executable that we just ran.

24:22 - We know exactly what version they have. And then we know offsets to the services pointer.

24:27 - We know the offset for the image handle for the currently running executable.

24:32 - There are going to be multiple copies of these files in memory.

24:36 - You do need to determine what is the correct one.

24:38 - As an example, when Dell CSOS launcher is loaded, there will be one copy that is before it has actually been executed.

24:48 - So those pointers will be null. In the live version that boot services pointer and EFI handle variables will not be null.

24:58 - So, again, search for a pattern, check the pointers.

25:01 - If they’re non null we found the correct one.

25:04 - But what about Secure Boot? We talked about calling a load image and start image, but there’s still Secure Boot to contend with and the cryptographic image verification.

25:16 - So the UEFI framework is designed in a modular way, and it uses this UEFI security2 protocol to abstract some of these security functions, including TCG measured boot, UEFI secure boot.

25:28 - Essentially there are a callback handlers to get registered in this protocol.

25:32 - In order to actually do that cryptographic signature verification and the measurement into the TPM registers.

25:39 - So when Dxe core is loading an image. CoreLoadImageCommon calls, Security2StubAuthenticate, which calls ExecuteSecurity2Handlers, and that function before it actually calls any of the handlers checks to see if any are registered and returns success if there are no handlers registered.

25:59 - So it turns out there’s a really easy thing we can do.

26:02 - In order to turn off image verification. We just scan memory to find that SecurityStubDxe executable, and write a zero to that global variable.

26:11 - And now we can load whatever we want. This also stops updating the TPM measurements and the rest of the UEFI firmware still thinks that secure boot is on and being enforced.

26:22 - So another thing that we have to deal with is we have somewhat of a limited amount of space in our payload, in the stack.

26:31 - Where do we want to load our next EFI executable from? The easiest thing to do is have a very small EFI.

26:37 - That’s just appended to the first stage. You can also call UEFI network functions to do connections to your own network infrastructure.

26:46 - Download new executable is run that way. So it turns out there’s actually something a lot easier that we can do.

26:52 - Dell has their own EFI RamDisk implementation.

26:55 - And Dell CSOS launcher will actually download all those URLs that we saw in the JSON file into RamDisk file systems.

27:05 - It’ll verify them, it’ll even extract zip files for you.

27:09 - And all of these files can be accessed using standard UEFI functions.

27:12 - Like EFI simple file system protocol. And our payload actually ended up using both of these.

27:18 - Where we appended a very small executable to keep our shell code simple.

27:24 - And then the appended EFI executable iterated over the file systems in order to find the next stage and run that.

27:33 - For our first demo we’ll just show the classic example of popping calc, except in BIOS when security was turned off.

27:42 - (jaunty music) So for our second demo, we’ll increase the difficulty level a little bit by using a Secure Core PC where Secure Boot and all the other features are turned on and we’ll pop shell.

28:09 - (jaunty music) (jaunty music continues) So for our third demo, or the boss level, we’ll increase the difficulty even further by still using the Secure Core PC with all the security features enabled, but we’ll drop a malicious executable into the Windows startup folder and run that.

29:31 - (jaunty music) (jaunty music continues) (jaunty music continues) (jaunty music continues) (jaunty music continues) (jaunty music continues) (jaunty music continues) - [Mickey] But BitLocker.

33:02 - Some of you might say, “Hey, BitLocker is enabled.

33:05 - Why do you have to suspend it?” We get to that age old question of, “What came first, chicken or the egg. ” What is this the right thing to do once you have an update process you need to follow when the BitLocker measurements measure the firmware, but you need to update the firmware? So, according to Dell, the easiest solution is to suspend BitLocker before you update the BIOS.

33:31 - Unsurprisingly, HP has a very similar recommendation.

33:35 - and last but not least, Microsoft also recommends this for third party updates.

33:42 - So you can’t update firmware without suspending BitLocker.

33:46 - Now we do have modern mitigations in place.

33:49 - So there are some challenges If you want to persist.

33:53 - For example, Boot Guard and BIOS Guard are there to prevent you from modifying the firmware and persisting inside the firmware image.

34:03 - There are ways around this. If you see recent vulnerabilities published, you might spot some Boot Guard bypasses.

34:11 - HP Sure Start is another mechanism to verify the integrity of firmware.

34:16 - So if you do happen to be an attacker and modify flash, you will get caught by HP Sure Start.

34:21 - Kernel DMA protections are there as well. VBS and HVCI.

34:26 - There are protections in place that prevent you from abusing low-level mechanisms.

34:31 - So how would you exploit this at a large scale? Well, we know these vulnerabilities impact a large number of laptops.

34:43 - We also know that home routers are being attacked actively right now.

34:49 - And enterprise device vulnerabilities. For example, we’ve seen a lot of effort done by attackers against VPN servers.

34:57 - Once they gain that foothold they are potentially able to modify internal network appliances, to redirect DNS traffic inside an enterprise environment and so on and so forth.

35:10 - We can’t forget all the ASN hijacking stuff.

35:13 - Let’s say someone managed to social engineer their way to redirect or the ownership of a DNS through a registrar or modify records.

35:22 - There’s also BGP hijacking. And we should never forget what the ISPs are capable of doing.

35:31 - No one really knows what ISP’s are doing. So we are at their mercy.

35:35 - These attacks are actually in the wild and although not common, they have happened repeatedly and are most likely to happen again.

35:44 - We can’t have a talk without mentioning supply chain.

35:48 - Now let’s say we want to attack this mechanism of remote firmware updates.

35:54 - The simple way to do this, by supply chain attack, is by compromising the web server hosting the XML files.

36:02 - Let’s assume we didn’t have the TLS vulnerability.

36:05 - We still wanted to gain access to all the machines that are doing updates and exploit the other buffer overflows without the SSL issue.

36:14 - So a web vulnerability and a web server expert would come in handy.

36:19 - You just replace the files in downloads. dell. com and you’re done.

36:23 - The more complex scenario is when you have an insider threat inside the chain.

36:28 - Let’s say an employee manages to modify files in some of the servers that hosts these files, or an insider who is involved in adding code to the sign binaries that adds vulnerabilities to them.

36:44 - It’s less likely, but it’s still a scenario that we should talk about.

36:47 - In conclusion, a couple of words about the disclosure process.

36:52 - It was not easy at first to gain a measure of how many models were actually affected by this issue.

36:58 - But we ended up agreeing that there were 129 models affected.

37:04 - The initial disclosure, went out to Dell on March 3rd.

37:07 - And by the time we published our initial high level blog post on June 24th, all updates for this issue have been released publicly.

37:16 - Note that this has been 90 days plus two weeks from disclosure to patch of 129 models, a vulnerability in BIOS.

37:26 - This, I hope will be an example for every other vendor and every other OEM.

37:31 - Once you find a vulnerability in BIOS, you can achieve a 90 day timeline without arguing for more.

37:39 - If you are affected by this issue, and you would like to securely update your system, we recommend you do not use these features from, For obvious reasons, and download the manual OEM updates set up files from the Dell website and use those to update your BIOS locally.

37:59 - If you are afraid of rollback and downgrade attacks on your system, you can go into BIOS and uncheck the checkbox that says allow for downgraded BIOS.

38:11 - And only check it if you manually need to roll back your BIOS for some reason in the future.

38:17 - All our tools, exploits, data, information is going to be available on GitHub in the following address.

38:27 - Feel free to submit issues. If you want to ask us questions, you can DM us on Twitter.

38:32 - And we would like to say, thank you. A final thank you to Dell, CERT for working with us and resolving this issue in around 90 days and US CERT for helping us as well.

38:44 - But that’s it. Thank you for your time. And we appreciate you listening, and we hope you enjoyed our talk. .