[01:00.530 --> 01:02.310]  Okay, my name is Eric Koeppen.
[01:02.450 --> 01:05.450]  I work for IBM, X-Force, Advanced Research.
[01:06.270 --> 01:08.170]  I'm just gonna apologize in advance.
[01:08.790 --> 01:13.110]  I'm not gonna have as polished a briefing as the last guy, but I'll do my best.
[01:18.870 --> 01:21.270]  So here's what I'm gonna talk about today.
[01:21.530 --> 01:22.990]  I'm gonna give an introduction on boot kits.
[01:23.370 --> 01:24.430]  Talk about...
[01:25.870 --> 01:29.110]  walk through the boot processes of various operating systems.
[01:29.170 --> 01:34.170]  I'm sticking mostly to x86 architecture, x64.
[01:35.230 --> 01:39.930]  We're gonna take a deep look at the technologies involved in booting.
[01:41.510 --> 01:47.190]  And give some advice for how to prevent exploitation.
[01:47.510 --> 01:56.910]  Take a look at some case studies that are real-world examples of lower-than-OS exploitation.
[02:02.240 --> 02:05.040]  So here I just wanted to set out the scope.
[02:06.740 --> 02:14.640]  For this presentation, we're talking about boot kit is anything that exists below ring zero, below the level of the the OS kernel.
[02:16.060 --> 02:22.600]  This talk's going to cover those infections that are persistent.
[02:23.860 --> 02:32.020]  They maintain presence on the hardware after reboot.
[02:32.560 --> 02:41.160]  We're... I'm not really gonna talk about stuff like bootable CD-ROMs that are auto-pone.
[02:48.840 --> 02:52.620]  Like I said, we're sticking to x86, x64 architectures.
[02:53.100 --> 02:56.220]  I'm not really covering virtualization in depth.
[02:57.240 --> 03:04.320]  Not every system uses it, but it is definitely an important area of infection and persistence.
[03:06.220 --> 03:09.860]  It was just beyond the scope of what I was doing my research on.
[03:11.060 --> 03:14.140]  I'm releasing white paper eventually.
[03:14.520 --> 03:16.160]  It's probably about halfway finished.
[03:17.740 --> 03:20.560]  But I'll try and distribute that out to hope.
[03:22.780 --> 03:36.220]  If you grab my Twitter from the first slide, if we can publish the slides on the website for hope, feel free to add me.
[03:36.640 --> 03:38.600]  And I'll post the white paper there when it's finished.
[03:44.240 --> 03:48.920]  So before I get into the boot process, I just want to talk about a little bit about boot kits.
[03:49.980 --> 03:51.600]  They've been around a long time.
[03:53.200 --> 03:59.820]  Stone virus hit in 1987 and that was an overwrite to master boot record.
[04:01.860 --> 04:10.300]  UEFI got popular 2013 with the dream boot boot exploit.
[04:12.680 --> 04:18.940]  So the danger of boot kits is that they sit below the OS.
[04:19.480 --> 04:23.400]  So many times you cannot detect them from the OS.
[04:25.680 --> 04:31.560]  They're persistent so you can reinstall the operating system and still have an infected machine.
[04:32.600 --> 04:39.800]  You can, in some cases, you can even reflash firmware and still have an infected machine.
[04:40.120 --> 04:51.200]  So I think this is an important area of research and trying to prevent and detect what we can of these becomes very important.
[04:54.000 --> 05:01.800]  So here, this slide, I'm talking about the basic boot process for old windows machines on power on self test.
[05:02.580 --> 05:04.120]  Power on self test.
[05:06.140 --> 05:07.860]  Hardware gets initialized.
[05:12.160 --> 05:13.360]  Drivers get loaded.
[05:14.820 --> 05:16.820]  RAM gets checked out on post.
[05:21.730 --> 05:45.930]  From there, the BIOS gets read in off of a ROM chip and searches the devices for the master boot record, which has a boot sector on the beginning of the physical media being used for boot.
[05:47.070 --> 05:52.350]  From there, it looks for volume boot records, VBR.
[05:52.770 --> 05:56.490]  And from there, it selects a partition to boot.
[05:57.730 --> 06:13.290]  Once it's found a partition it wants to boot, uses NT loader, which uses boot.ini for specific boot options.
[06:13.570 --> 06:26.890]  It runs NT detect to gather information about the computer's hardware and then passes all that information to the NT kernel and starts loading the OS.
[06:31.560 --> 06:39.380]  Here we've got boot processes for later architectures starting with WinVista.
[06:41.900 --> 06:54.320]  Instead of just loading the NT kernel straight out, as it did in XP architecture, it calls the Windows boot manager.
[06:55.000 --> 06:55.800]  It calls the Windows boot manager.
[06:55.800 --> 06:56.940]  And the Windows boot manager
[07:02.020 --> 07:06.200]  uses, loads boot configuration data from the BCD file.
[07:07.560 --> 07:12.960]  And it passes that data to the Winloader, Winloader.exe.
[07:14.140 --> 07:22.000]  And then loads the kernel operating system kernel environment.
[07:29.040 --> 07:32.300]  So starting with Windows Visa Service Pack 1,
[07:36.020 --> 07:39.960]  Windows began to add support for UEFI.
[07:40.280 --> 07:47.040]  Now UEFI is a technology that a consortium came up with a specification for.
[07:47.260 --> 07:52.500]  They're currently on version 2.3.4 or 2.3.1.
[07:53.040 --> 07:57.660]  And basically UEFI is a much stronger version of the BIOS.
[07:58.480 --> 08:03.260]  It can be split between firmware and other storage devices.
[08:03.480 --> 08:06.540]  But it's basically a mini operating system.
[08:06.540 --> 08:09.980]  much more powerful than the old BIOS technology.
[08:12.320 --> 08:19.000]  And because of that power is that much more exploitable and dangerous if it gets exploited.
[08:19.620 --> 08:38.040]  So from here we've got UEFI loading either a master boot record or a new GUID partition table, which is a new way to store partitions for hardware storage devices that are over 2 terabytes.
[08:38.880 --> 08:44.800]  Again, from there goes Windows Boot Manager, boot configuration data, and then the Windows loader.
[08:47.880 --> 08:52.280]  Windows 8 came shipped with Secure Boot.
[08:52.440 --> 09:02.700]  Secure Boot is a technology that checks the signatures of every piece of software involved in the boot process.
[09:02.700 --> 09:07.900]  So if something doesn't match up, it just won't let it run.
[09:12.060 --> 09:16.060]  It's kind of like a bouncer at the entry to a club or something.
[09:17.020 --> 09:18.420]  It checks signatures.
[09:18.420 --> 09:30.220]  If they don't match the master keys stored in UEFI, then that particular phase in the boot process doesn't get to run.
[09:30.560 --> 09:32.360]  And it has to go back to setup mode.
[09:35.240 --> 09:40.480]  Mac's been using kind of an older version called EFI boot.
[09:40.900 --> 09:42.360]  They've been using that for a while.
[09:43.340 --> 09:52.980]  I think it's still based off of the EFI 1.2 implementation before EFI became UEFI.
[09:56.880 --> 10:05.320]  Again, the boot ROM has two major functions or two major other services.
[10:05.640 --> 10:12.660]  One is power on self-test, which does the RAM checking and some basic, some initial hardware checking.
[10:12.900 --> 10:28.240]  And then EFI, which does the more standard hardware initialization, it selects the OS, and then loads the bootloader, boot.efi Mac bootloader.
[10:30.120 --> 10:32.080]  Here's how it works for Linux.
[10:33.040 --> 10:36.600]  When Linux uses BIOS, it goes through post BIOS.
[10:38.900 --> 10:45.220]  Linux has capabilities for master boot record or GUID partition table.
[10:46.580 --> 10:52.660]  And then it'll call either Lilo, Grub, whatever Linux bootloader you've installed.
[10:53.100 --> 10:55.260]  And there it'll load the Linux kernel.
[10:57.860 --> 10:59.920]  Linux also has support for UEFI.
[11:07.260 --> 11:09.860]  Linux also has support for secure boot process.
[11:10.520 --> 11:15.840]  There was a lot of controversy when Windows 8 machines came out.
[11:16.280 --> 11:20.320]  They had all secure boot enabled by default.
[11:21.240 --> 11:28.420]  And the keys that were being checked for were always Microsoft signed keys.
[11:29.160 --> 11:36.700]  So Microsoft released some keys for open-source developers to use.
[11:37.020 --> 11:38.620]  There was a bit of an outcry.
[11:38.820 --> 11:46.740]  Initially, people thought that Microsoft was attempting to limit certain hardware architectures to only being able to boot Windows.
[11:48.660 --> 11:52.200]  I think some people are still wary of the keys that were distributed.
[11:54.320 --> 12:00.260]  Again, the boot manager, the bootloader, and the Linux, even the kernel, all have to be
[12:03.480 --> 12:05.800]  signed with valid keys.
[12:05.980 --> 12:12.080]  So if something's been tampered with, its signature is not going to match.
[12:13.500 --> 12:15.560]  UEFI secure boot says, no good.
[12:15.760 --> 12:16.960]  Goes back to setup mode.
[12:17.900 --> 12:19.540]  Or possibly Brickshare system.
[12:25.030 --> 12:27.090]  So here, let's talk about BIOS.
[12:29.250 --> 12:33.250]  It's basically a bunch of compressed modules.
[12:36.090 --> 12:40.010]  Each module is signed with a checksum.
[12:40.770 --> 12:46.450]  But there are a couple of modules that are not compressed.
[12:47.370 --> 12:50.750]  The first is the boot block that handles post.
[12:52.090 --> 12:57.850]  And then the second one is the decompression routine for the LZH compression, compressed modules.
[12:58.630 --> 13:05.190]  And if you module, modify a module without updating its checksum, again, you've kind of bricked your system.
[13:08.450 --> 13:16.030]  So some examples of persistent BIOS infection were presented by CORE at CanSec West in 09.
[13:17.230 --> 13:27.310]  Again, they used, that should say building, BIOS building tools such as the Pinkzakos method.
[13:27.450 --> 13:33.670]  That's basically just a method for updating checksums and making sure they get stored.
[13:33.670 --> 13:36.550]  Then go ahead and run the patch and update the checksums.
[13:37.170 --> 13:41.890]  Dump the BIOS with flash ROM, patch and update, reflash.
[13:45.810 --> 13:48.690]  Here we have four ways to avoid this type of attack.
[13:50.090 --> 13:54.230]  So you're going to see the first bullet quite often throughout this paper.
[13:55.650 --> 14:00.350]  And you can pretty much assume that this is a basic way to avoid most infections.
[14:00.350 --> 14:03.230]  A lot of these things need multiple stage infections.
[14:03.450 --> 14:06.110]  So they initially get on with some exploit.
[14:07.210 --> 14:17.770]  They then escalate privileges and then use those escalated privileges to install at the very low level.
[14:18.670 --> 14:27.970]  So if you can protect yourself with antivirus, firewalls, intrusion prevention systems, host-based intrusion prevention systems.
[14:33.490 --> 14:38.290]  And good security policies, which you can't always predict your users.
[14:39.410 --> 14:42.370]  They're usually going to find the way to do the worst thing possible.
[14:42.370 --> 14:50.970]  But if these things are in place, a lot of times you can prevent some of these attacks.
[14:51.110 --> 14:57.030]  A lot of these attacks that I'm covering, I mean, you'll notice the last one, first case study was from 2009.
[14:57.270 --> 14:59.050]  So some of them are pretty well known.
[14:59.050 --> 15:17.030]  And some of the mechanisms have already been patched that that they're using to get down, not only to gain persistence for the boot kit, but also to gain initial staging for escalating the privileges.
[15:17.410 --> 15:26.390]  So the smaller you make your target profile, the better luck you'll have mitigating some of these risks.
[15:27.730 --> 15:31.130]  You can also enable write protection on flash.
[15:32.930 --> 15:35.770]  Digitally signed BIOS firmware has been out a long time.
[15:38.090 --> 15:40.570]  And number four goes back to policy.
[15:40.750 --> 15:43.350]  Don't download BIOS updates from untrusted sources.
[15:43.750 --> 15:57.010]  Again, if it's malware that's going after the BIOS anyway and bundled, it may not even be a firmware flash that you're doing and rather something that gets run automatedly.
[15:57.270 --> 16:02.050]  So I guess just be careful.
[16:04.470 --> 16:06.470]  So here we are back to UEFI.
[16:08.230 --> 16:10.570]  Again, it allows pre-OS networking.
[16:10.770 --> 16:13.150]  It's not the only technology I'm going to cover on here that does.
[16:14.910 --> 16:23.810]  So there have been a couple versions, such as I believe Phoenix's implementation that provides antivirus for the host operating system.
[16:24.070 --> 16:27.190]  It allows you to run that before the kernel's been loaded.
[16:31.520 --> 16:44.480]  If you can see the second bullet down there under the two types of services, it actually has a significant amount of functionality while the OS is still running.
[16:44.480 --> 16:53.080]  So there...it definitely has a staging footprint that you can still access while the OS is running.
[16:53.360 --> 16:57.840]  And it also has extremely extensive boot services that it opens up.
[16:58.860 --> 17:00.760]  Much more so than traditional BIOS.
[17:02.140 --> 17:07.520]  Now the first...the biggest example I could think of for an attack on this was Dream Boot.
[17:09.180 --> 17:11.100]  Again, it finds the boot loader, patches it.
[17:14.640 --> 17:17.280]  Takes the kernel entry point at the end of the boot process.
[17:18.160 --> 17:23.860]  Redirects the control flow so that it can do what it needs to do.
[17:25.520 --> 17:28.880]  As you can see, the deactivates kernel protections like patch guard.
[17:31.860 --> 17:34.460]  And it hides in a relocation table.
[17:39.800 --> 17:41.660]  So again, back to countermeasures.
[17:42.520 --> 17:44.920]  Secure boot will help with this one.
[17:45.740 --> 17:49.240]  Intel has a trusted execution technology.
[17:49.500 --> 17:50.780]  Provides late launch.
[17:51.200 --> 17:56.870]  It basically low...refuses to load software that it does not...
[17:58.660 --> 18:04.600]  I'll cover more later, but it refuses to load software that does not match its metrics.
[18:05.600 --> 18:10.080]  It's stored metrics for the footprint of the software.
[18:11.400 --> 18:13.640]  BitLocker and TPM mode helps out a lot.
[18:16.700 --> 18:21.220]  So TPM mode allows different types of encryption.
[18:21.700 --> 18:23.380]  One of them is sealing.
[18:24.600 --> 18:29.700]  So if, again, TPM also uses software metrics.
[18:29.920 --> 18:50.280]  And if the software metrics don't match up to what it expects, it will not allow the unsealing of the keys, the encryption keys that are being used to encrypt the system.
[18:55.060 --> 18:57.920]  And as we talked about before, here's secure boot.
[19:07.560 --> 19:12.100]  Secure boot has been bypassed.
[19:13.060 --> 19:24.800]  Here we have a good example of this was a talk given at Hack in the Box Amsterdam 2014 by the MITRE research team headed by Corey Kallenberg.
[19:28.620 --> 19:30.460]  What they found was that
[19:33.750 --> 19:41.800]  there was there was a way to bypass the signature checking that secure boot offers.
[19:42.230 --> 20:02.880]  Certain OEM vendors didn't want such things as graphics card drivers which have or graphics cards with option ROMs that can be updated didn't want those option ROM updates to be in a state that could possibly keep the system from booting.
[20:03.250 --> 20:08.780]  So they programmed in a way to avoid the signature check.
[20:09.560 --> 20:17.780]  So the MITRE researchers found a way to manually set the flag that describes how lax your policy is.
[20:18.060 --> 20:24.960]  So they were they found out that the system variables were not being protected.
[20:25.360 --> 20:35.460]  So they were able to say oh yeah don't don't run signature checking on any of the software which completely trumps secure boot's entire purpose for being so
[20:41.380 --> 20:42.060]  that they were able to do that.
[20:42.060 --> 20:49.120]  So yeah so the the first bullet on here is make sure the UEFI version follows the spec.
[20:49.740 --> 21:03.120]  So the reason that that lax policy was implemented was one vendor's and I believe it was American Microtrend's implementation of UEFI didn't really match up with the spec.
[21:03.300 --> 21:09.940]  The spec doesn't say anything about or being able to skip signature checks.
[21:10.840 --> 21:17.020]  But American Microtrend's wasn't the only one that that used what they started.
[21:17.920 --> 21:21.760]  A bunch of other OEM vendors began to use the same thing.
[21:21.940 --> 21:26.440]  So it was it was kind of a problem of lax implementation that spread.
[21:28.620 --> 21:37.720]  So there are some technologies such as you know BIOS control and BIOS write enabled protection that you can turn on.
[21:38.380 --> 21:45.940]  You can also do the set Intel protective range SPI flash protections like setting the flash configuration lockdown bit.
[21:48.520 --> 21:50.820]  Setting SMM BIOS write protection.
[21:50.960 --> 22:00.640]  These are all things you can do in UEFI or the BIOS options that you can set as long as you've got I guess the latest up-to-date BIOS or UFI.
[22:02.160 --> 22:04.420]  You've got to go into boot options of course to do it.
[22:06.100 --> 22:11.580]  And back to the original common security mechanisms will measures will help quite a bit.
[22:17.560 --> 22:22.260]  So here we have Mac EFI used on all Intel Macs.
[22:22.260 --> 22:24.600]  So you find a way into Mac EFI.
[22:25.840 --> 22:27.920]  You've got basically a golden ticket.
[22:29.020 --> 22:31.680]  Some of the other technologies are a lot more hardware specific.
[22:32.060 --> 22:33.420]  BIOS in particular.
[22:34.220 --> 22:36.500]  UEFI is quite hardware and vendor specific.
[22:37.280 --> 22:40.000]  But Mac EFI, you own it once, you own all Macs.
[22:45.520 --> 22:49.940]  And here it was briefed at Black Hat by Snare in 2012.
[22:52.320 --> 22:57.500]  He ranks three different options for gaining persistence.
[22:57.900 --> 23:01.280]  Patching and replacing the bootloader, which he ranked pretty low.
[23:02.800 --> 23:14.200]  Writing to PCI device expansion ROM, which is similar to what we were talking about with the option ROMs with the graphics card on the earlier example that would defeat secure boot.
[23:14.440 --> 23:16.560]  And then the last one was flashing the firmware.
[23:19.880 --> 23:25.840]  And he was saying that newer Macs right protect the flash, which makes that very difficult.
[23:27.820 --> 23:36.720]  And that the signature of the flash firmware update gets checked.
[23:36.720 --> 23:43.600]  So, if your signatures don't match up to what's in there, it's, you know, no go.
[23:44.220 --> 23:45.800]  He ranked this one as the highest.
[23:46.700 --> 23:49.280]  He said, if you can do it, I would do it anytime.
[23:52.460 --> 23:53.180]  So, countermeasures.
[23:53.760 --> 23:58.900]  Actually, the researcher's statement was that, you know, we're all out of luck.
[23:59.020 --> 24:00.100]  We're all doomed.
[24:01.140 --> 24:07.240]  But, you know, EFI passwords, that's one of the few options you've got for securing Mac EFI.
[24:09.140 --> 24:13.140]  It's a rather low barrier of entry, but, I mean, it helps.
[24:13.560 --> 24:15.700]  It turns off some of the booting features.
[24:17.540 --> 24:22.660]  UFI secure boot would help out the situation a lot, but currently unsupported.
[24:25.700 --> 24:27.700]  Third bullet, we've seen this time again.
[24:28.580 --> 24:32.380]  So, the fourth bullet, it talks about the evil maid scenario.
[24:32.880 --> 24:38.340]  And that's basically somebody gaining physical access to your machine.
[24:38.940 --> 24:40.280]  You step out of the room for a minute.
[24:40.460 --> 24:42.780]  They drop by with a USB drive and pop it in.
[24:43.560 --> 24:44.540]  That's one of the...
[24:47.760 --> 24:55.960]  It's one of the most dangerous options for a lot of these technologies, as far as being exploited.
[24:57.020 --> 25:01.640]  But, again, it's also one of the ones that you may have the most control over.
[25:03.720 --> 25:12.360]  At the very least, if you're that scared of somebody being able to pop in a USB drive, you may consider blocking your ports.
[25:12.360 --> 25:20.600]  I've even seen people glue gun in the USB ports in certain offices where they just didn't want anybody plugging in USB.
[25:20.920 --> 25:29.420]  So, if it's that important to keep your hardware from being physically compromised, then that's something to consider.
[25:32.420 --> 25:34.600]  So, here we have a system management mode.
[25:34.800 --> 25:43.860]  It's low-level technology, privileged execution on Intel X86 and 64 architectures.
[25:45.580 --> 25:49.440]  Has access to all system memory, including NVRAM.
[25:49.640 --> 25:54.120]  It's not subject at all to OS protections.
[25:56.920 --> 26:00.540]  And it gets access by system interrupt handlers.
[26:03.200 --> 26:08.140]  So, these handlers will run at a very low level and can capture stuff like keyboard presses.
[26:08.740 --> 26:12.840]  Stuff you would normally think the OS drivers would catch.
[26:13.860 --> 26:16.020]  Here's a piece of firmware that can also catch it.
[26:21.840 --> 26:35.260]  Flip, I can't pronounce his last name, but he was able to do proof of concept code for modifying SMM through the SMIO.
[26:35.480 --> 26:39.700]  He was able to do it for ACES motherboards.
[26:40.280 --> 26:46.520]  SMM is one that is very dependent on who your motherboard and chip manufacturers are.
[26:50.700 --> 27:04.480]  So, he created a chip, a key logger that would trap at the IO, IO trap on the SMM firmware.
[27:04.780 --> 27:14.860]  And he wrote a, he was kind enough to write a simple C program that would detect it by checking to see if the controller port, to see if it was enabled.
[27:16.360 --> 27:18.880]  If you're specifically worried about SMM
[27:22.160 --> 27:29.660]  boot kits running in the background, capturing key logging, that would be definitely something to look into.
[27:29.860 --> 27:34.720]  I think you can get to it from the presentation notes from his slides.
[27:39.240 --> 28:02.800]  The one important thing about the key logging situation is that it can be used to capture passphrases so that even if you've encrypted your hard drive with, say, BitLocker and TPM motor, you capture the passphrase, you can then decrypt the drive.
[28:03.660 --> 28:09.520]  So, this one can be extremely dangerous for cascading and finding other
[28:14.180 --> 28:16.780]  mechanisms to exploit.
[28:17.820 --> 28:22.320]  The last bullet is a SMM transfer monitor.
[28:23.000 --> 28:27.020]  This is a technology that Intel designed, but they haven't implemented.
[28:29.600 --> 28:34.980]  It virtualizes the SMM handler and it would go a very long way to securing systems.
[28:38.180 --> 28:41.120]  Quite a few of the presenters have actually complained.
[28:41.360 --> 28:48.340]  They make it a point to complain about Intel's lack of implementation for this technology in countless briefings.
[28:48.340 --> 28:59.640]  So, yeah, if that's going to be one of the morals of my presentation that I'll inherit from the people that came before me, it's definitely a pressure Intel to get some of that implemented.
[29:02.480 --> 29:04.780]  This is Intel active management technology.
[29:04.940 --> 29:09.060]  This is allowing remote maintenance of machines.
[29:10.160 --> 29:14.140]  Your system doesn't need to have an operating system installed for this thing to kick off.
[29:14.140 --> 29:16.660]  It doesn't need to even be initially powered on.
[29:17.120 --> 29:18.840]  And it has network access.
[29:22.140 --> 29:25.700]  So, it stores various data to the firmware memory.
[29:25.940 --> 29:33.340]  You can get access to, you know, any type of configuration to DALE's credentials, network configuration, security configuration.
[29:35.080 --> 29:42.380]  It provides direct memory access, which basically you have access to the PCI,
[29:45.400 --> 29:49.660]  access to RAM via the PCI bus without getting the CPU involved.
[29:53.420 --> 30:01.080]  Patrick Stewart of Berlin actually did a, he has a number of talks actually.
[30:01.080 --> 30:04.360]  If you check out the Berlin Institute of Technology page.
[30:06.500 --> 30:11.820]  And yeah, he's, he has a good number of proof of concept code.
[30:13.200 --> 30:15.260]  AMT comes disabled by default.
[30:15.600 --> 30:16.980]  It's an option you're supposed to turn on.
[30:17.160 --> 30:21.120]  But there are actually AMT functions that run periodically whether it's enabled or not.
[30:21.420 --> 30:28.320]  So, his proof of concept was hijacking some of one of those functions that ran periodically.
[30:29.520 --> 30:36.520]  And then using that to gain further access.
[30:36.840 --> 30:38.900]  I believe he did a keylogger as well.
[30:39.180 --> 30:46.020]  And he took advantage of the fact that it had network capabilities already outside of the U.S. OS.
[30:47.060 --> 30:52.220]  And, you know, set up a exfiltration mechanism as well.
[30:52.660 --> 31:00.200]  So, he had complete and total out of band communications with his keylogger that, you know, you would have to be elsewhere on the network to even detang.
[31:02.440 --> 31:10.340]  The problem with his proof of concept, it only works on old Q35 chipsets, was I think our 2008, maybe 2007.
[31:12.420 --> 31:14.740]  Q45 was common, at least by 2009.
[31:15.080 --> 31:17.440]  So, you know, as long as you update your hardware.
[31:20.580 --> 31:28.400]  In order to pull off his proof of concept, updated BIOSes were blocking him in certain circumstances.
[31:28.400 --> 31:37.620]  So, he found out that you can kick off a BIOS downgrade without any kind of user consent on older versions.
[31:38.220 --> 31:43.920]  And was able to do that to open up the door to run his code.
[31:49.080 --> 31:52.160]  Yeah, his initial proof of concept was in Linux.
[31:52.680 --> 31:58.040]  So, the last presentation where he said that there are viruses for Linux, Windows, and Mac.
[31:59.600 --> 32:01.100]  This is pretty much proof.
[32:01.780 --> 32:03.740]  He did port it to Windows.
[32:09.240 --> 32:13.700]  Countermeasures, update your hardware, update your software, update your firmware.
[32:15.720 --> 32:19.700]  Intel trusted execution technology, and again, I'll cover that in a little bit.
[32:20.680 --> 32:23.060]  And common security practices.
[32:25.600 --> 32:29.980]  So, here we've got the... I'll try and wrap this up in the next five or ten minutes.
[32:33.740 --> 32:39.620]  Trusted platform module is the heart of low-level security.
[32:40.660 --> 32:45.660]  It was standard for dedicated microprocessor for doing crypto.
[32:46.280 --> 32:54.240]  And at the bottom, the last two bullets, you can kind of see the two different types of encryption it offers.
[32:55.180 --> 32:57.320]  So, not only key generation system has it.
[32:57.640 --> 33:09.900]  The binding is encryption with a factory burn key or a derivative of that factory burn key that comes with the chip itself.
[33:10.320 --> 33:17.000]  And then, sealing means that that chip has to be in a certain machine state in order for it to even consider trying to decrypt something.
[33:18.000 --> 33:20.220]  So, TPM is pretty solid.
[33:23.180 --> 33:43.000]  Again, Joanna Rutkowska of Invisible Things Lab said that her main scenario that she pressured for compromising TPM was, again, the evil-made scenario, dropping by with a USB key, allowing a user to grab keys.
[33:45.820 --> 33:54.820]  Again, restrict physical access, consider gluing your USB ports, disable your CD-ROM if it's that important.
[33:56.900 --> 33:59.600]  Okay, here we've got Trusted Execution Technology.
[34:01.880 --> 34:03.780]  It offers secure storage.
[34:05.020 --> 34:07.220]  It gets a secure storage from TPM.
[34:07.420 --> 34:18.880]  What it does is it stores the metrics for the programs it's about to load, and then
[34:22.120 --> 34:24.520]  will not load things that don't match up.
[34:27.290 --> 34:32.030]  And again, AMD has a version that they implement with a SK instruction.
[34:34.090 --> 34:56.190]  And here, Joanna Rutkowska again, Invisible Things Labs, it has exploited a flaw to basically leveraged authenticated code module.
[34:59.230 --> 35:19.570]  There was the ability to do a buffer overflow in SNET, and it required some heat manipulation, but was able to write in a malicious ACPIDMAR table, which is, you know, hardware memory access table.
[35:22.550 --> 35:24.890]  Requires pretty low levels of execution.
[35:29.060 --> 35:34.180]  Basically hijacks SMM, and Intel jumped right on it.
[35:36.040 --> 35:39.480]  It issued advisories, offered patches right away.
[35:41.400 --> 35:44.640]  So protecting it, yeah, just make sure you're up to date.
[35:48.960 --> 35:59.640]  The Intel got involved with the OEM vendors and made sure that they could get patches out to people as soon as possible, required downloads.
[36:07.930 --> 36:28.170]  Yeah, one thing Intel did was change the layout of the trusted execution technology and make it so that the launching control policy was executed first, so that you can blacklist stuff ahead of time and not necessarily need to rely on patches.
[36:28.170 --> 36:40.030]  So it was an architectural change that would prevent anything similar, even if they found another avenue to attack TXT.
[36:42.570 --> 36:53.070]  So, master boot record, boot sector at the beginning of storage devices, partition information, limited because it only handles up to two terabytes, two terabyte drives.
[36:53.070 --> 37:02.150]  This is pretty much your classic, traditional, the oldest form of boot kit available.
[37:05.650 --> 37:09.210]  So, stone boot kit was originally 1987.
[37:09.970 --> 37:14.730]  Peter Kleissner briefed an updated version at 2009's Black Hat.
[37:17.630 --> 37:24.950]  He basically dumps firmware, updates it, reflashes it.
[37:25.490 --> 37:30.770]  In this case, he also patches the OS loader.
[37:35.050 --> 37:39.040]  Full disk encryption using BitLocker would definitely help with this one.
[37:39.320 --> 37:50.260]  So, with UEFI Secure Boot, you would be able to see that the modified kernel loader was not legit.
[37:52.130 --> 37:55.340]  And even the updated NBR wouldn't match up.
[37:56.960 --> 38:03.680]  Volume boot record, loaded the same way as an NBR, it's just another level down.
[38:08.790 --> 38:15.540]  So, GAPS was a boot kit that was briefed at REcon in 2013.
[38:17.880 --> 38:29.020]  Requires Windows layout, patches four bytes, so it modifies a variable that that increases the number of hidden sectors.
[38:29.500 --> 38:32.320]  And that allowed them to hijack control flow.
[38:33.940 --> 38:36.160]  They also patched the boot manager and wind load.
[38:40.800 --> 38:45.890]  So, the countermeasure for this would be switching your partitioning mechanism to GPT.
[38:46.680 --> 38:49.340]  The GPT would be the quickest, but that would also be a pain.
[38:50.240 --> 38:52.610]  Because you'd probably need to reinstall.
[38:52.900 --> 38:54.720]  UEFI Secure Boot would help.
[38:55.300 --> 38:56.740]  BitLocker in TPM mode.
[38:57.340 --> 39:13.880]  Being able to check, you know, having encrypted boot process, encrypted hard drive, and then expected signatures and metrics before it will decompress and boot.
[39:14.980 --> 39:18.200]  And the final bullet, yeah, common security practices.
[39:18.610 --> 39:19.960]  I'll try and wrap this up.
[39:26.720 --> 39:29.240]  Here's the NBR replacement.
[39:29.840 --> 39:31.480]  This is going to be the way of the future.
[39:31.760 --> 39:33.420]  I think Windows 8 already comes with it.
[39:33.560 --> 39:36.300]  Pre-installed, a lot of people have bad problems.
[39:37.200 --> 39:50.180]  Multi-booting Linux and Win 8, because on certain systems with GPT pre-loaded, they had to make sure that their Linux distro supported the GPT.
[39:51.100 --> 39:59.800]  I think Ubuntu 12.04, for example, I do not believe supported it when it was first coming out.
[40:00.040 --> 40:00.080]  So,
[40:04.720 --> 40:17.720]  another stage in Win XP boot, the NT loader, it gets compromised by a bunch of the earlier examples I gave.
[40:17.980 --> 40:22.980]  So, I kind of felt like giving another example would be repetitious.
[40:23.240 --> 40:25.000]  Its replacement is Windows boot manager.
[40:28.840 --> 40:30.560]  Its hidden system file.
[40:31.900 --> 40:35.280]  Again, we talked about it earlier that it loads the BCD data.
[40:39.140 --> 40:44.400]  So, there was a couple of proof of concepts for this one.
[40:46.020 --> 40:51.860]  Vboot from Nitin and Vipin Kumar of NV Labs.
[40:53.740 --> 40:57.880]  They basically, they did one version and then they just updated it a few years later.
[41:01.040 --> 41:03.840]  They had to use a CD in order to get it to load.
[41:04.100 --> 41:14.460]  I said I wasn't really going to focus on ones that were not already persistent on the system, but this is the type of attack you could probably run in an EVO-MADE scenario.
[41:17.480 --> 41:23.860]  Hook N13, which is, you know, hardware read, I think, CD-ROM read.
[41:26.660 --> 41:30.940]  So, when they hit bootmanager.exe, they run their payload.
[41:31.360 --> 41:33.320]  Patch in three different places.
[41:34.460 --> 41:37.000]  Bypass, checksums, digital signatures, and depth.
[41:37.420 --> 41:39.880]  Because they're hitting an already loaded
[41:43.760 --> 41:44.980]  piece of software.
[41:47.400 --> 42:01.560]  And then, because they're, they're, I think they're patching in memory, when, at that, when, when load runs, it, it runs off of the pre-patched information.
[42:03.640 --> 42:05.460]  Again, don't allow physical access.
[42:08.000 --> 42:13.900]  We need to find a better way to, to prevent in-memory modification between loading and execution.
[42:13.900 --> 42:20.160]  Again, BitLocker with, in TPM mode will, will, will take measurements.
[42:20.180 --> 42:22.760]  And if it doesn't match up with the measurements, won't let it run.
[42:23.300 --> 42:27.600]  It won't even unseal the, the keys to decrypt the drives.
[42:30.260 --> 42:35.200]  So, in conclusion, everything has, we all know software is vulnerable.
[42:36.560 --> 42:42.060]  We haven't, we haven't, we haven't written complex software yet that is completely invulnerable.
[42:44.380 --> 42:57.920]  A lot of the new technologies that have been coming out have been, uh, uh, uh, uh, offer a lot of mitigation, um, trying, trying to stay current, trying to stay updated in hardware and firmware is, is, is actually becoming important.
[42:58.560 --> 43:01.280]  Um, they're, you, they've made a lot of advances.
[43:01.440 --> 43:02.560]  They still have a long way to go.
[43:02.780 --> 43:03.700]  They still need to get better.
[43:03.700 --> 43:09.040]  Again, the main point, Intel should definitely release STM.
[43:10.040 --> 43:12.440]  And then back to the common security practices.
[43:12.880 --> 43:33.680]  If you can stop exploitation of your machine, you can avoid a lot of the problems with malware trying to, you know, elevate its access and permissions and burrow down deep into your system and maybe install something you can't get.
[43:33.700 --> 43:35.620]  rid of even with an OS reinstall.
[43:38.420 --> 43:42.740]  So, I covered a lot of the references here.
[43:42.940 --> 43:51.140]  Hopefully, when I release the paper, hopefully you can check out some of the conference briefings if you want some more in-depth information.
[43:51.880 --> 43:53.240]  I'm going to release a white paper.
[43:53.360 --> 43:59.540]  It's going to have a lot more references in that than even I mentioned here.
[44:00.780 --> 44:03.080]  It would have been 20 or 30 slides.
[44:03.700 --> 44:04.540]  to quote them.
[44:04.900 --> 44:10.710]  So, that's... Thanks a lot for attending it.
[44:18.880 --> 44:22.340]  I think I've got 10 minutes or so for questions.
[44:23.120 --> 44:29.180]  Would you recommend that we have a machine that remains infected after we install an operating system?
[44:29.540 --> 44:30.880]  What's the next step after that?
[44:33.080 --> 44:34.720]  Take it out back and shoot it?
[44:35.080 --> 44:35.160]  No.
[44:41.000 --> 44:45.420]  So, identifying where the infection is becomes important.
[44:45.580 --> 44:53.220]  If you re-flash the firmware, you know, BIOS UEFI, and that's not working.
[44:56.280 --> 45:05.220]  If AMT is not working and you know, you try and update Intel's active management technology or...
[45:06.660 --> 45:10.580]  Every step of the way, you try and update firmware, try and isolate the problem.
[45:10.720 --> 45:15.740]  If it's something that you still can't get off no matter how much you've flashed or...
[45:15.740 --> 45:23.880]  You know, could even possibly be a hardware infiltration where they've soldered something onto your board that's not supposed to be there.
[45:24.060 --> 45:34.840]  So, I mean, at a certain point, these things do get deep enough where, you know, you got to hope that something comes out down the road to help you identify it.
[45:34.840 --> 45:37.440]  But, I mean, that's kind of the idea with zero days.
[45:37.540 --> 45:38.600]  You can't always detect them.
[45:38.700 --> 45:41.940]  You can't always block against them right away.
[45:42.620 --> 45:47.440]  So, just try and stay as current as you can and re-flash everything that you've got options to.
[45:48.000 --> 45:49.060]  I'll go here first.
[45:49.840 --> 45:53.300]  About the AMT services that were being enabled.
[46:04.480 --> 46:06.740]  I'm sorry, I don't have more information on me.
[46:07.600 --> 46:12.380]  I probably should have done a better job of keeping track of the actual function that runs.
[46:15.280 --> 46:20.340]  I want to say it had something to do with a timer that would run periodically.
[46:21.700 --> 46:23.960]  A low-level timer that gets initialized.
[46:24.580 --> 46:27.120]  Or a low-level check to see if something has been changed.
[46:29.780 --> 46:31.160]  And, let me double-check.
[46:31.340 --> 46:37.300]  The presentation was the
[46:40.510 --> 46:41.970]  Berlin Institute of Technology.
[46:41.970 --> 46:49.790]  Okay, he's got probably three or four presentations on Patrick Stewart, if you can Google him.
[46:50.310 --> 46:51.850]  And Berlin Institute of Technology.
[46:51.870 --> 46:55.190]  He does a much better job than I can of breaking down the attack.
[47:03.530 --> 47:06.810]  Yeah, probably three or four presentations and at least a couple of white papers.
[47:07.250 --> 47:08.610]  I'm sorry, was there anybody else?
[47:08.790 --> 47:08.910]  Yeah.
[47:14.340 --> 47:15.740]  I can't hear very well.
[47:29.240 --> 47:32.860]  Some of these technologies exist on their own chips.
[47:34.980 --> 47:41.720]  So, some of the other technologies will not be hit if you do a BIOS or UEFI reflash.
[47:41.720 --> 47:44.420]  You have access to it.
[47:49.660 --> 47:51.000]  It doesn't care with others.
[47:51.840 --> 47:53.240]  You don't have the same firmware.
[47:53.880 --> 47:58.360]  It's like the app is locked up and nothing else.
[47:58.720 --> 47:59.280]  Right.
[47:59.660 --> 48:04.600]  So, for example, trusted platform module.
[48:04.800 --> 48:05.620]  It's its own chip.
[48:05.800 --> 48:06.820]  Has its own firmware.
[48:07.140 --> 48:08.080]  Does its own thing.
[48:08.260 --> 48:10.600]  Exists outside of the ban of a standard BIOS update.
[48:10.600 --> 48:12.700]  If you found a way onto that chip.
[48:13.540 --> 48:14.840]  Yes, you can check.
[48:15.400 --> 48:20.380]  If you can find a way to read the memory involved with that chip.
[48:20.940 --> 48:25.080]  You know, hooking up JTAG debuggers and finding out what's stored in the bytes there.
[48:25.500 --> 48:27.820]  Yes, you could double check to make sure.
[48:28.780 --> 48:31.160]  Do a sanity check to make sure things match up.
[48:31.160 --> 48:34.200]  But, some of these technologies exist very low.
[48:35.540 --> 48:38.430]  Like, outside the normal scope of...
[48:45.700 --> 48:47.080]  I wouldn't say impossible.
[48:47.380 --> 48:49.440]  I think it is definitely feasible.
[48:49.860 --> 48:52.340]  It's just one flash is not going to do it.
[48:52.440 --> 48:54.580]  You might have to flash a few different components.
[48:55.880 --> 48:57.500]  Sorry if that...
[48:58.640 --> 49:00.420]  I'll go... you in the back first.
[49:00.660 --> 49:01.400]  Oh, sorry.
[49:01.700 --> 49:01.900]  Okay.
[49:02.920 --> 49:04.600]  I can't see that direction.
[49:19.840 --> 49:20.440]  Okay.
[49:34.020 --> 49:34.620]  Right.
[49:49.980 --> 49:52.280]  Have you looked into that at all?
[49:52.660 --> 49:53.220]  Just...
[49:53.220 --> 49:54.100]  Just very little.
[49:55.540 --> 49:56.100]  My...
[49:56.940 --> 50:01.360]  A lot of my RE experience is reversing firmware for embedded devices.
[50:01.680 --> 50:05.180]  So, to say I haven't looked into it is probably not entirely accurate.
[50:05.420 --> 50:17.620]  But, I haven't done in-depth research or surveys of what's available for exploiting the boot process on, you know, Raspberry Pi and whatnot.
[50:19.460 --> 50:21.460]  Definitely something to look at in the future though.
[50:22.860 --> 50:23.540]  Sorry.
[50:24.600 --> 50:25.280]  Sorry.
[50:27.240 --> 50:27.920]  Sorry.
[50:28.240 --> 50:28.920]  So,
[50:31.960 --> 50:33.260]  in the markets for...
[50:37.540 --> 50:41.080]  I know that there's a whole industry, right?
[50:45.230 --> 50:47.490]  There's at least...
[50:47.490 --> 50:51.050]  There are a few for Android, for sure.
[50:51.770 --> 50:52.230]  And...
[50:53.770 --> 51:00.370]  I don't remember seeing anything for iPhone when I was doing research this time, but...
[51:02.330 --> 51:07.450]  I can say without a doubt that there's a way to the hardware on iPhone.
[51:08.530 --> 51:10.670]  I meant to answer you in the back, sorry.
[51:20.000 --> 51:21.020]  That's a tough call.
[51:22.280 --> 51:42.640]  From what I was researching, UEFI, because it is kind of a nebulous spec with so many people's input, I think that one in particular, because nobody took the lead and stamped out, I think that the spec might have been a little bit nebulous for some of the vendors.
[51:42.640 --> 51:49.020]  I do know that the more times you release an RFP or a spec and...
[51:50.180 --> 51:51.420]  Sorry, not RFP.
[51:53.520 --> 51:54.140]  RFC.
[51:56.880 --> 51:59.140]  20 people implement it in different ways.
[51:59.520 --> 52:15.580]  I've done a lot of network device research, and there's an entire field of fingerprinting based on different vendors' implementations of standard networking protocols.
[52:17.100 --> 52:26.800]  So I think any time you release a standard, you're definitely open to the idea that people are going to implement it in different ways and be more or less strict with it.
[52:28.780 --> 52:34.600]  I would say it's a common thing that any time you try and have a public standard that bugs are going to find their way in.
[52:36.120 --> 52:36.720]  Yes?
[52:37.200 --> 52:38.540]  These are all talks.
[52:38.880 --> 52:40.720]  These are all talks and concepts.
[52:41.740 --> 52:45.820]  How often do you come across boot kit type problems?
[52:47.440 --> 52:49.680]  Oh, so, I'm sorry.
[52:52.460 --> 52:57.820]  Going back, each one of these has in the wild exploits.
[52:57.820 --> 53:06.720]  So, the stone boot kit I was talking about, very similar to Meb Brut, which is a Trojan that does pretty much the same thing.
[53:07.360 --> 53:09.620]  Dream Brut is actually in the wild.
[53:11.100 --> 53:15.360]  I think a few of the other ones on there were...
[53:18.240 --> 53:26.000]  They had kind of clones, maybe not the exact same thing as the proof of concept, but something that worked very similar.
[53:26.000 --> 53:28.960]  But were they developed right after the presentation?
[53:31.640 --> 53:37.000]  That's a tough call, because the updated stone briefing was in 2009.
[53:37.420 --> 53:40.700]  I think Meb Brut was released in 2009.
[53:40.980 --> 53:51.720]  So, I believe that, yeah, in some cases the research may drive some of the technology, but in other cases it's definitely the opposite.
[53:51.720 --> 53:56.120]  Somebody sees a nasty piece of malware and briefs on how the mechanism works.
[53:57.040 --> 53:57.600]  Sorry.
[53:58.700 --> 53:59.740]  Thank you very much.
[53:59.740 --> 54:00.000]  That's him.