Blue Team Village - OuterHaven: UEFI Memory Space Waiting To Be Misused
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 374 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/49811 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
Algebraisches ModellATMFirmwarePhysikalisches SystemVirtuelle MaschineHardwareSoftwareTranslation <Mathematik>SchnittmengeNeuroinformatikFunktionalElektronische UnterschriftOrdnung <Mathematik>Virtuelle MaschineComputersicherheitPhysikalismusNichtlinearer OperatorMultiplikationsoperatorBootenROM <Informatik>RelativitätstheorieMinkowski-MetrikTreiber <Programm>Zusammenhängender GraphInverser LimesElektronische PublikationPhysikalisches SystemTranslation <Mathematik>SchlüsselverwaltungQuick-SortHardwareMaßerweiterungFlächeninhaltInterface <Schaltung>Software Development KitNetzbetriebssystemATMFirmwareStreaming <Kommunikationstechnik>HauptplatineEntscheidungstheorieStochastische AbhängigkeitSystemzusammenbruchTermProxy ServerExploitFunktion <Mathematik>MinimumTouchscreenMenütechnikKonfiguration <Informatik>BinärdatenDeskriptive StatistikElement <Gruppentheorie>Speicher <Informatik>App <Programm>Spannweite <Stochastik>Dienst <Informatik>Graphische BenutzeroberflächeBefehlsprozessorSoftwareRechter WinkelKonfigurationsraumInteraktives FernsehenDämpfungGeradeSkriptspracheInnerer PunktTwitter <Softwareplattform>BinärcodePunkt
06:35
VektorrechnungStandardabweichungATMROM <Informatik>Funktion <Mathematik>BildschirmfensterMathematikElektronischer FingerabdruckDynamisches RAMBildschirmfensterFramework <Informatik>Minkowski-MetrikQuick-SortPhysikalisches SystemRootkitLaufzeitfehlerGarbentheorieDatenstrukturROM <Informatik>TypentheorieFunktionalGanze FunktionCoxeter-GruppeDienst <Informatik>IterationKomplex <Algebra>sinc-FunktionBootenStandardabweichungInterface <Schaltung>MultiplikationsoperatorComputersicherheitFlächeninhaltZusammenhängender GraphNP-hartes ProblemSkriptspracheNichtlinearer OperatorWärmeausdehnungHauptplatineVersionsverwaltungVirtuelle MaschineBefehlsprozessorFestplatteMAPComputeranimation
10:57
ATMRechenwerkZeiger <Informatik>CodeReverse EngineeringSystemprogrammierungNabel <Mathematik>Wurm <Informatik>Mechanismus-Design-TheorieTaskROM <Informatik>Minkowski-MetrikComputersicherheitLASER <Mikrocomputer>SoundverarbeitungDokumentenserverAttributierte GrammatikSampler <Musikinstrument>CodeReverse EngineeringMinkowski-MetrikLesen <Datenverarbeitung>VerschlingungVariableNabel <Mathematik>BildschirmfensterROM <Informatik>Wurm <Informatik>Mechanismus-Design-TheorieFunktionalWinkelParametersystemQuick-SortProgrammierumgebungMultiplikationsoperatorOrdnung <Mathematik>FirmwareInternetworkingKonstruktor <Informatik>Schreiben <Datenverarbeitung>BitSchreib-Lese-KopfBimodulGüte der AnpassungDemo <Programm>Elektronische PublikationElektronischer ProgrammführerInteraktives FernsehenEindringerkennungMAPPunktVirenscannerNichtlinearer OperatorVirtuelle MaschineProgrammierspracheKernel <Informatik>Gibbs-VerteilungUrbild <Mathematik>Formation <Mathematik>SystemverwaltungRechter WinkelSkriptspracheComputeranimation
17:29
ATMVideokonferenzGüte der AnpassungDeskriptive StatistikDokumentenserverWurm <Informatik>SystemverwaltungGraphfärbungROM <Informatik>SoftwaretestArray <Informatik>Minkowski-MetrikTouchscreenRadikal <Mathematik>E-MailComputeranimation
18:21
ATMQuaderReverse EngineeringWurm <Informatik>Nabel <Mathematik>InstantiierungVirtuelle MaschineEinfach zusammenhängender RaumROM <Informatik>SoftwaretestCodeCASE <Informatik>ZweiFormation <Mathematik>Computeranimation
19:17
ATMDemo <Programm>InstantiierungCodeMinkowski-MetrikSoundverarbeitungWurm <Informatik>ROM <Informatik>ZahlenbereichFunktion <Mathematik>Packet Loss ConcealmentPatch <Software>HauptidealringComputeranimation
20:00
Strom <Mathematik>SoftwareSpeicher <Informatik>SpeicherabzugInformation RetrievalFirmwareHecke-OperatorATMVariableLaufzeitfehlerROM <Informatik>AusnahmebehandlungMinkowski-MetrikNonstandard-AnalysisIntelAbzählenComputersicherheitSystemprogrammierungKernel <Informatik>Treiber <Programm>Nabel <Mathematik>BootenFestspeicherPCMCIAPhysikalisches SystemSoftwareentwicklerAnalysisKernel <Informatik>Funktion <Mathematik>ROM <Informatik>Ordnung <Mathematik>Minkowski-MetrikVariableSystemzusammenbruchElektronischer ProgrammführerFirmwareNichtlinearer OperatorLaufzeitfehlerVersionsverwaltungAusnahmebehandlungNabel <Mathematik>SoftwarewartungQuick-SortPunktPortscannerGamecontrollerÜberlagerung <Mathematik>ZweiProgrammierumgebungComputersicherheitBootenSoftwareDienst <Informatik>AbzählenVirtuelle MaschineLesen <Datenverarbeitung>InformationsüberlastungMultiplikationsoperatorUmwandlungsenthalpieGarbentheorieSpeicherabzugNetzbetriebssystemBildschirmfensterInformationPatch <Software>FunktionalNatürliche ZahlPhysikalisches SystemRadikal <Mathematik>HardwareIntelNichtflüchtiger SpeicherTreiber <Programm>TypentheorieMenütechnikLokales MinimumSoftwaretestProdukt <Mathematik>Interface <Schaltung>SichtenkonzeptComputeranimation
25:54
LaufzeitfehlerNabel <Mathematik>Prozess <Informatik>ATMMechatronikPCMCIAROM <Informatik>Funktion <Mathematik>SpeicherabzugVariableAttributierte GrammatikCodeE-MailTreiber <Programm>SystemverwaltungToken-RingVersuchsplanungElektronische PublikationBildschirmfensterSchlüsselverwaltungNetzbetriebssystemPartitionsfunktionAbzählenKonfigurationsdatenbankOrdnung <Mathematik>QuellcodeAnalysisMinkowski-MetrikElement <Gruppentheorie>StellenringCodeROM <Informatik>FunktionalPhysikalisches SystemInstallation <Informatik>FehlertoleranzSoftwaretestEinfache GenauigkeitFestplatteGamecontrollerPuffer <Netzplantechnik>DatenbankNichtlinearer OperatorFigurierte ZahlInteraktives FernsehenMultiplikationsoperatorMailing-ListeVariableUmwandlungsenthalpieInformationCompilerWindows XPWurm <Informatik>MalwareLaufzeitfehlerFunktion <Mathematik>AusnahmebehandlungAlgorithmische ProgrammierspracheDemo <Programm>Nabel <Mathematik>FirmwareUnicodeSkriptspracheProgrammierumgebungVersionsverwaltungOnline-DienstPhysikalische TheorieResultanteWrapper <Programmierung>Prozess <Informatik>SpeicherabzugSystemverwaltungPacket Loss ConcealmentService PackComputeranimation
31:48
ATMCodeDemo <Programm>EinsReverse EngineeringWurm <Informatik>TouchscreenElektronische PublikationUnicodeVariableComputeranimation
32:46
ATMROM <Informatik>Minkowski-MetrikBenutzerfreundlichkeitProzess <Informatik>AbzählenVariableDesintegration <Mathematik>ComputersicherheitPhysikalisches SystemStandardabweichungSchlussregelSystemtechnikFunktion <Mathematik>IntegralStandardabweichungMinkowski-MetrikMessage-PassingMultiplikationsoperatorDifferenzkernCodeInformationROM <Informatik>SoftwareSpannweite <Stochastik>Arithmetisches MittelDokumentenserverPatch <Software>SchlussregelFunktionalNetzbetriebssystemBenutzerfreundlichkeitSchreiben <Datenverarbeitung>Wurm <Informatik>Ordnung <Mathematik>E-MailNeuroinformatikCoxeter-GruppeFlächeninhaltAnalysisTVD-VerfahrenAlgorithmische ProgrammierspracheVirenscannerQuick-SortMAPProzess <Informatik>TeilbarkeitRechenbuchRechenschieberComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:16
Everyone, welcome back to DEFCON 28 Safe Mode, Blue Team Village live stream.
00:22
Today, we're going to be talking with Therum, not talking, but he'll be talking, Connor Morley, discussing Outer Haven, the UEFI memory space decision to be misused. Reminder, if you have any questions for the speaker, you can obviously reach them at their Twitter handle, DM them with, DM them within the Discord channel,
00:40
or reach them on the Flamingo Hotel, text, talks, track one. We'll be watching for questions there. And over to you, Connor. Thank you very much. So hi everyone, my name is Connor Morley. I'm a threat hunter with Esecure Countercept, which is an MDRDRT service. Today, I'll be talking about the UEFI memory space,
01:01
how it can be exploited by a range of attackers, and how it can defend against it. And I gave it the app name of Outer Haven. So, proper agenda. What we're gonna run through, I'm gonna do a quick crash course on what exactly UEFI is, why this is of interest to attackers and defenders,
01:20
how to exploit the UEFI memory space, regardless of your technical expertise, so all the way from APT actors, all the way down to the script kiddies. You better go over some of the issues with defending against exploitation of this memory sector, how we can overcome those difficulties and monitor this memory area,
01:41
and what this means for us as an industry. So let's dive straight in. The crash course of what exactly is UEFI. So a lot of people may have heard the term UEFI, but may not know exactly what it is. So UEFI stands for the Unified Extensible Foundry Interface. It's the successor to BIOS.
02:02
Most people will be familiar with BIOS, the basic input-output system. It interfaces between the mechanical elements of a system and its operating system. So effectively, it works as a translation between the operating system and the firmware for the hardware of your device, hence a firmware interface.
02:22
So for example, if the operating system requests a file to be opened, the file command gets run from the OS through the UEFI to the firmware of your storage device. It then allocates that memory sector and returns there, and then that's how it's read. It's a very, very general basic overview.
02:42
It's key for all system functionality. It conducts all boot operations. It can, as I said, it conducts all interfaces between, oh, between the software and the hardware, and it is essential in all modern computers. So it is found everywhere,
03:01
regardless of operating system that you're using. It's also widely considered almost secure in BIOS. So it introduced the concept of something called Secure Boot. So Secure Boot is the idea that when drivers are loaded at boot time, their OEM signature is checked in order to guarantee and verify
03:21
that they're the correct and authorized driver. This idea of Secure Boot actually eliminated a really easy physical access bypass to older machines, which basically means as soon as you had physical access to a machine, you could easily bypass any security.
03:41
One of the key things to mention about UEFI is that it is stored on the independent chip on your motherboard, an NV RAM chip, which is totally isolated. It's its own independent component of the machine, and it is attached to the motherboard. So it's completely isolated from everything else. It is its own piece of kit.
04:02
So just to really intensify and solidify where this sits in your computer, so the UEFI, as I said, sits between your operating system and firmware, and the firmware that talks to the hardware. So operating system, if it wants to talk to your hardware, has to go through the UEFI.
04:21
It is essentially just a translation of operating system commands and to firmware letter commands to receive whatever the operating system needs the host to do. So most people, when you're talking about UEFI and BIOS, they'll think of this sort of screen. You know, your boot screen,
04:40
sometimes with the boot menu or BIOS settings is one of those options at the bottom, but the majority of the users will see this sort of screen and just, you know, float by it as it boots up your computer and not think fast. And some people will obviously go into those settings, which looks something like this. So on the left, you have the older BIOS settings
05:01
configuration menu, and on the right, you have the newer UEFI interactive GUI. So one of the things that EFI actually allows to do is the use of graphical user interfaces, which is not available in BIOS. This allows for, as you can see, this is there. It allows for branding. It allows for CPU temperatures and all this sort of stuff.
05:23
It also allows for point and click, so use for mouse, whereas BIOS doesn't. This is to do primarily with how EFI operates using EFI binary files, which allows all these layers to be put on top of it. Again, so this allows for security settings.
05:41
It allows for the boot order to be configured and such things like that. So most people will think this is sort of the limit of what you can ... This will be the limit of what most people have dealt with, but the UEFI itself is actually a lot more complicated. It does a lot more in relation to your host. It runs the entire time that your computer is operating,
06:04
and so it's not just the boot service. It's fundamental to all operations of all modern hosts that you find around the world. So there's a lot more to it than a lot of people are not privy to, but the key thing to note is it is always active.
06:20
It is essential, and it's isolated from the rest of the system. So why is UEFI interesting to attackers and defenders? So why are attackers red teamers looking at UEFI? So as I said earlier, the UEFI is isolated
06:43
from the rest of the system on its own little island of silicone, so it's segregated from the rest of the system by design. Because it's isolated, it's not well known about, and it's considered quite a low-level technology, it's commonly overlooked in a lot of attack situations and normally isolated to the sort of APT rootkit
07:04
sort of attack frameworks and methodologies and TDPs. So it's normally overlooked in most operations by defenders, so it gives this sort of idea that it's lucrative and valuable for attackers. The other thing to note is that remediation of anything
07:22
on the UEFI is really difficult. With a lot of components on a machine, obviously you can chop and change them, hard drives, RAM, CPU, all that sort of stuff if you really had to. Changing the UEFI, if you had to, much more difficult. A lot of the time they're soldered onto the motherboard,
07:41
so as you can imagine, changing that is a real pain. And even removing it, obviously interactively through an interface can be really tricky if you don't have experience with the UEFI. So as I said, there's a whole section later on that I'm going to cover about why remediation is difficult, and I'm going to go over that in a lot more detail.
08:03
One of the other things to note about the UEFI is that by standard, by the standards of the UEFI, everything written to it is automatically put as persistent. So it's non-volatile, and everything that's written will automatically stay there throughout boots,
08:20
which as you can imagine from a sort of persistence attack methodology sort of mentality is inherently quite valuable. So although this is why attackers are looking at it, why are they looking at it now? What exactly has changed? So as I said, it's normally as being rootkits
08:41
and low-level actors, ATPs, because it's a complex sort of area that a lot of people overlook or don't really understand. But what's happened is that since Windows ... Actually, since Windows actually surprisingly, but more recently since Windows Vista and onwards, Windows has ... Microsoft had gradually introduced more runtime access to the UEFI memory space.
09:03
So the UEFI runs boot services and runtime services, and through the iterations of Windows and obviously their updates and newer versions, they've steadily introduced more and more runtime service access to the UEFI memory space.
09:22
So research done last year at DEF CON, DEF CON 27, Michael Leibovitz and Tova Timson, they did a whole presentation on this type of attack. About how to avoid threat hunters and EDR by utilizing the UEFI memory space because it avoids detection.
09:40
I was really recommending their research, really cool stuff, and obviously this is where this entire piece of research stemmed from. And they went into how they could use native Windows API functions to read and write into the UEFI memory space. So originally when I first saw their talk, I thought, oh, this is worrying,
10:01
but surely there must be a way around this. Again, this is a section that will come later on, but it was a gap that was found, or when looking into it, I did see was in the security defensive structure. So because of their research, there is now very ...
10:21
Not because of their research, but because of Microsoft's expansion into the runtime service access, there is, by their exposure, Windows API basic functionalities that allow read and write access into this lucrative, sort of not well understood memory sector that is isolated from the rest of the system, which is pretty valuable.
10:45
So how is it that the UEFI memory space is exploited all the way from the APT actors, all the way down to script goodies or newer attackers? And so the way Leibovitz and Timson exposed
11:04
was to use a C-sharp pick-and-file payloads using kind of 32. DLL functions and get firmware environment variable E8s and set firmware environment variable E8s. As you can imagine, these are the read and write functions.
11:22
With these two methods, the attack effect can install a payload into this memory space and then create an external persistence mechanism to read from this isolated memory space at a later point or by a trigger in order to run a more malicious or internal payload or a beacon or agent or anything like that
11:41
from the UEFI memory space. This obviously requires the payloads to be pre-built, so they have to be obviously targeted and have an understanding of where they're going and what they can leverage out of the environment they're going into. It also has to specify at the time of compilation
12:02
the variable names and the GUIDs or the vendor IDs of the variable they're going to be injecting into the memory space. And because of this, obviously you have to have an understanding of how C-sharp can be used for API DLL interactions in order to leverage the kernel32.dll
12:20
in order to access the UEFI and write into it. So you have to have a good understanding and preparedness of who you're going to attack, how you're going to attack them, and obviously an understanding of the programming language itself in order to utilize it. So as attack methods go, this is quite advanced compared to obviously you just copy and pasting off the internet and running it as you like.
12:44
You also have to have an understanding of UEFI variable constructs, their attributes and how they're constructed. So there's a lot of layers to this sort of attack, but it is very powerful. And if leveraged correctly, as they demonstrated was very effective.
13:00
I decided to approach this from another angle. So instead of going for something precompiled and thought about what if we could just do like a drive-by sort of attack. And so we went back to the old tried and true PowerShell, which is able to leverage the same DLL imports functionality.
13:24
So ignoring high level codes, we found that the same functionality into the U of M space read and write could be emulated in PowerShell just as effectively. You can do this as a PowerShell script, or you can actually do it as a on the fly
13:42
sort of write to terminal and execute and both work just as well. The only caveat for both attacks is that it has to be run at an administrative level. The reason for this is the session that you're using in order to have firmware edit privileges, you have to do token escalation that can only occur as an admin.
14:05
So anyway, seeing what Timms and Lebowitz did, I was able to replicate theirs as a PowerShell, as I said, as a script and as a drive-by. And they were both extremely effective
14:21
and fully functional. It was only after I translated their C-Shop code into PowerShell, I found that a guy called Michael Nehas, sorry if I'm pronouncing that wrong, he's actually already written a PowerShell module online, which you can download and import, which has the read and write functionality
14:41
nicely wrapped as two separate functions, arguments and all this sort of stuff, making the copy paste of my PowerShell scripting even easier and much smaller because you don't have to take into account the token escalation and importing the API and understanding how to do that.
15:01
It does it all for you. So we've gone from a precompiled targeted C-Shop payloads to a very small on the fly, copy paste PowerShell scripting, which as you can imagine, if you put that online, anyone can tweak the payload inside it and start playing around with it. And it's much easier to do much quicker.
15:23
So I made some POC code. There's a link at the end for a repository where this is available to everyone. So the POC code is PowerShell. I need to dump to reverse shell payload. The idea is that you would dump a shell payload into your file and then immediately runs it.
15:41
So it's just a write, read, execute. Obviously in the real world, as I said earlier, you'd obviously write it to the memory space, you create persistence, read it later, extract it and execute. And for a POC, this seemed to work very well. When I tested this,
16:00
so the antivirus that I was using on the host, Windows 10, it detected obviously the reverse shell when it was running to memory, which is what you would expect, but it didn't terminate it and it didn't remove the payload itself from the unified memory space. So the payload itself was still on the host even after the AV had flagged it,
16:24
which I'll demonstrate later. As a extra point, this will tie into the defensive problems later. As an attacker, what you might wanna do is the first write operation you have into your unified memory space and the persistence that you create.
16:42
When you run that first payload, delete the original entry into UEFI and the persistence and recreate it again. The reason is, is that the payload inside the first UEFI, if they find the way that you've injected into it, they can obviously trace that back and figure out what you put there or what you've labeled it under and things like that.
17:01
Whereas if you do it a second time from an encoded or encrypted payload inside the UEFI that you then extract and run again, it becomes much, much harder for investigators to track that from a point of infection to where you're going and what you're doing. So now comes the tricky bit. I do have a demo.
17:20
So the demo has been created, this is a heads up, it was OBS of a virtual machine. However, it is fairly small. So I do apologize. The videos themselves are available afterwards. They'll be available for people to look over
17:41
and it will be a good description of what's going on. So this is the first one. So this screen shows the drive-by header that I'm gonna be using in Notepad. As you can see, it's in byte arrays. So I copied that.
18:00
This payload is fairly available from the repository that's available at the end. This is pasted into the administrative PowerShell terminal. As you can see, the Who am I, cm underscore test. That's now being executed. So that's being written into the UEFI memory space
18:20
and then being extracted and executed. So we're gonna go to my attack box where I have a reverse TCP handler waiting for the connection from the POC code, which is gonna be extracted from UEFI memory. So we give that a few seconds and there it is.
18:44
So that's the reverse shell from the UEFI hosted payload and the Who am I shows that it is cm underscore test. So it's the same machine that we just ran the PowerShell POC code on.
19:01
One thing to note is that the PowerShell instance in that case will be running in the background.
19:22
Will be running in the background. So when you actually execute it, the output's a PID of the PowerShell instance that it's gonna be running as a POC code. Obviously in real attacks, you wouldn't keep it as a PowerShell instance. You might migrate it to something else, but later on. Lovely.
19:42
So that's basically the bounce of moving from generating payloads and then targeted attacks all the way down to copy pasting and getting this in effect. So that's the attack side of it. But what about defending? So there are a number of issues with defending UEFI memory space.
20:01
And to understand these issues, it's good to understand why Microsoft has slowly included more access controls to this memory space in their iterative versions. One of the main reasons is the simplification for firmware updates and maintenance.
20:21
So for example, if you are a vendor of any sort of hardware, if you want to update the firmware of your device in the old versions, you would have to run the update and all you'd have to do specialized boot time scans in order to check that it was the correct version. Whereas now using these interfaces,
20:42
the operating system is able to run software that can check the installed version, make sure it's compatible with the right type, the right vendor, so on and so forth. It's also able to change the boot order from runtime. So you no longer have to go into the UEFI or BIOS menu. You can just do that straight from the operating system, which obviously is much more user-friendly for a lot of users.
21:06
One of the interesting things is that in development of Windows, they use UEFI variables and memory space for crash dump data. So if you ever run Windows Developer Editions and you have a crash, you'll find that it will output
21:21
crash data to the UEFI memory space because it's non-bontile by nature. They know that it will be stored and it will be saved so that they output it there. Yeah, so it allows for just much easier maintenance and upgrading and patching of the firmware level of a machine.
21:46
But what restrictions are there on this variable access that Windows has introduced? Well, effectively, the only restriction I could find was a variable size. Over a certain size, when you try to extract it,
22:02
you might have some issues because it assumes that it's going to be a certain size. You can overload the UEFI if you try hard enough. Although I haven't actually tried that, I'm going to recommend it. You must provide, if you want to read data from UEFI, you must provide the variable name
22:20
and the GUID or the vendor ID to access that particular variable's data. And this is where the trouble arises from. There is no currently available way to enumerate the variables. Well, there wasn't. A variable way to enumerate the variables
22:41
on the UEFI RAM chip at runtime, with only one exception, which Liguritts and Topher Timson demonstrated last year. I couldn't find any other except for one exception, which I'll cover in a second. Therefore, users, software systems, operating systems, anything like that can only access variables
23:00
that they already know exist, and they already have the necessary credentials for. So from a defense point of view, that creates an issue. If an attacker creates a new variable with a randomized name and a GUID that's nonspecific, an attacker, a defender, can't enumerate these variables
23:21
and, therefore, can't analyze what's inside the UEFI memory space. So these, any Nazis they put in there, effectively go undetected because the defender doesn't know where they're killed and can't extract them, can't access them. So the only exception that was found was a tool called Chipsec. It was designed by the guys over at Intel.
23:42
It's a deep firmware security analysis and repair tool. It's really powerful. I was quite impressed with it. It does output the UEFI variables at runtime. It was the only tool, and I did a lot of searching, but I could find it did that.
24:01
But the tool itself, even in their own recommendations, they say it's not for production. It's for development only. It's very large. It's quite clunky. It requires the installation of a custom kernel driver, and it also requires the disable, the disablement of certain security functions in order for it to operate,
24:22
which, obviously, as a defense software, if you're going to be using this remotely in production, is counterintuitive. So although it does what I was looking for, it just wasn't capable of doing it in the way that was required.
24:41
So how to monitor, although those are the difficulties, how do you monitor the memory space? So I tested a lot of methods in order to try and find runtime access and enumeration. This is just a few of them, but I spent a lot of time going through these methods.
25:00
So examination of runtime enumeration. First of all, I looked at the UEFI specification itself, which is really expensive. There are a lot of sections that explain how you can enumerate UEFI variables, but they mainly focus on what's called the EFI shell,
25:22
which is a specialized shell that can be accessed at boot time in order to interface with the EFI layer of your device. It requires a custom loader to be put normally on a removable medium, which you then access and it provides the shell. So the specification provides a lot of information
25:42
about commands that can be run in this particular terminal, this sort of environment in order to get these variables, but not enough really to do it from runtime. So it was inconclusive and I couldn't find runtime services from the specification unfortunately. Attempts to, so the operating system,
26:01
as I said, Windows introduced the interaction for the operating system to have access and control over certain elements of the UEFI. So UEFI should have an understanding of what is in there. So analyzing how the operating system interfaces with the UEFI showed that it works off of a database
26:22
inside the isolated EFI partition of your hard drive. From that partition, it then interfaces with a file called BCD, which is a registry file, so key value pairs, which effectively match up to the values that it already knows about
26:41
at installation. So back tracing this all the way down, by the way, the BCD file in the UEFI partition is held by system, so you can't access it from while you're running the Windows system, which was always a fun caveat. So the operating system only knows what it knows at installation, it can't enumerate
27:02
what is in the UEFI memory space. So unfortunately, that was a dead end. I turned back to Chipsec as it was the only tool that I could find that did what I was looking for, and the source code is fully available online, which is really, really cool, a really good thing to look at. So I began looking at how it functions,
27:22
I began following its procedures and how it accesses the memory. On assessment, I found that it imported something called EDK2, which seemed to be very important in EFI enumeration.
27:40
Effectively, what the EDK2 does is, after a lot of time playing with it, extracting it, running it independently from Chipsec, which was very difficult, I found that instead of accessing it from runtime, what EDK2 does is it creates what's called an EFI payload, which can be run within an EFI shell
28:01
to output specific results. So it's more like a compiler for EFI payloads or capsules, as you may call them, which was run from Chipsec for, I think mainly for remediation or repairs to the firmware.
28:21
Unfortunately, it didn't do what I was looking for, which was obviously one time enumeration. So the operating system doesn't enumerate, anyway, it has a list of what it already knows. The specification didn't provide the information I was looking for. And the tool under analysis that I knew could do it, I stumbled at the first hurdle
28:40
and couldn't figure out how it was operating. So I ended up kind of down a rabbit hole for quite a while, trying to think myself out of it. Eventually I did basically knuckle down and get back to Chipsec, and I spent a lot of time following it, debugging it, really analyzing how it worked.
29:00
And eventually I figured out through its abstract process, how it accesses the EFI memory space from runtime. And to do this, it uses an undocumented function of the NTDLL file called
29:21
NTEnumerateSystemEnvironmentValuesEx. And what this command does is it extracts the variable information within UEFI to a buffer of your creation, which can then be extracted and carved to find each variable within it. So you run this function from the NTDLL,
29:41
it provides a data blob in a buffer, which you can then loop through and carve and extract all of the variables for analysis. And this proved to be the saving grace. From the Chipsec tool, I extracted the methodology, I put it in a lightweight wrapper,
30:02
really analyzed it, put it through its paces. The resulting POC code, which is in Python, runs on everything, Windows 7 forwards, tested. It should, in theory, run on Windows XP because the function within NTDLL was introduced
30:22
in one of the NTDLL versions, which was released alongside a Windows XP Service Pack 2. So technically it should run on Windows XP, but I didn't try that one. It does check if the system you're on is UEFI-based before it allows it to run, which is obviously something else to note.
30:41
As it uses the native NTDLL.ELL, which is found on every single Windows host, you're not required to install anything custom, except for Python, in order to run the POC code. So it leverages local files in order to enumerate this memory space. As with the attacks, it must be run as admin
31:02
because of the token escalation that's required for firmware access. But as you can see from the left, when running this POC Python code, it did successfully dump all of the EFI variables, including the malicious codes that were not defined anywhere else, and allowed them for analysis as byte data
31:24
and as translated Unicode. So we've gone from a very large, powerful, clunky tool to a very lightweight wrapped Python script, which can run on any Windows host post Windows 7.
31:43
I do have another demo for that, bear with me. So this just shows Python code.
32:03
We're now gonna run that Python file, Python 2. As you can see, it's outputting the EFI variables nice and clearly. As you can see, the ones going past, although it may be quite small in your screen, is showing the DefCon demo P2 entries
32:23
that was from the attack that I demonstrated earlier, along with the associated byte data and the Unicode of the reverse TCP payload that I generated using MSF-Venom.
32:40
There we are. That on the left there is DefCon demo-p1. That's an example of how that works.
33:03
So now we have a good understanding of how this attack can be used at all range of attack levels and how it can be monitored and defended against very lightweight and integrated into defensive software. What does this mean for computer users
33:20
and as researchers? Everyone can be targeted, but equally everyone can patch them now. So despite the obvious ease with which all credit factors can leverage this memory space using the API function exposed last year, and as I've demonstrated,
33:41
it can be all the way up from find calculated attack methodology all the way down to drive-by copy pasting, defenders equally now have the equal ease in accessing and enumerating this memory space for analysis.
34:01
So although standard hunting procedures or antivirus or defensive technologies may not look into this currently, the integration of such technologies now is very, very easy. So integration into standard detection rules,
34:21
processes, techniques and defensive software is extremely easy using the lightweight capabilities that I've outlined, which effectively neuter this as a malicious haven on all available modern hosts. It also allows for increased sort of research in this area.
34:45
So although we now can monitor this, there may be custom payloads that they use that are specific, or there might be malware variation that are specific for leveraging this memory space, which allow us to create custom rules and remediation methods
35:02
in order to remove this as a threat. So as we can now enumerate these attack, these malicious payloads when they're on a UEFI memory space, it also allows us to remediate it by leveraging the same capabilities of the attackers that read write. If a defender knows what the payloads are called
35:22
and where they're stored, they can overwrite and remove their payloads from the victim's host. So we are in a situation now where attackers have this ability to leverage this isolated memory space, but defenders equally have the same level of ease in order to monitor and neuter any attempts
35:43
to leverage it. So that's me, that's my email. If anyone has any questions, the GitHub below is the repository with the POC codes as well as the full research paper, which outlines processes taken and has a lot more technical information
36:02
than this presentation. So if anyone does have any questions, please feel free to email me. There's also the tool text channel if anyone has any questions there, or please feel free to direct message me and I will answer any questions that I'm capable of. And I look forward to hearing from you guys.
36:25
The last slide I have prepared. So please, if anyone has any questions, do just let me know. Thank you very much. Thanks a lot, Connor. Appreciate it. Good talk, thank you.