1
00:00:15,040 --> 00:00:16,260
Hello, everyone.

2
00:00:16,260 --> 00:00:21,360
Welcome back to DEF CON 28 Safe Mode, Blue Team Village live stream.

3
00:00:21,360 --> 00:00:31,960
Today, we're going to be talking with, I'm not talking, but he'll be talking, Connor Morley, discussing Outer Haven, the UEFI memory space decision to be misused.

4
00:00:32,200 --> 00:00:44,540
Reminder, if you have any questions for the speaker, you can obviously reach them at their Twitter handle, DM them within the Discord channel, or reach them on the Flamingo Hotel Text Talks Track 1.

5
00:00:44,540 --> 00:00:46,980
We'll be watching for questions there.

6
00:00:47,220 --> 00:00:49,300
And over to you, Connor.

7
00:00:49,620 --> 00:00:50,900
Thank you very much.

8
00:00:50,900 --> 00:00:51,940
So, hi, everyone.

9
00:00:51,940 --> 00:00:53,100
My name is Connor Morley.

10
00:00:53,100 --> 00:00:57,580
I'm a threat hunter with F-Secure Countercept, which is an MDR DRT service.

11
00:00:57,740 --> 00:01:05,900
Today, I'll be talking about the UEFI memory space, how it can be exploited by a range of attackers, and how it can defend against it.

12
00:01:05,900 --> 00:01:08,420
And I give it the app name of Outer Haven.

13
00:01:08,820 --> 00:01:10,840
So, proper agenda.

14
00:01:10,840 --> 00:01:26,860
What we're going to run through, I'm going to do a quick crash course on what exactly UEFI is, why this is of interest to attackers and defenders, how to exploit the UEFI memory space, regardless of your technical expertise.

15
00:01:26,860 --> 00:01:30,920
So, all the way from APT actors, all the way down to script gettys.

16
00:01:31,340 --> 00:01:44,780
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, and what this means for us as an industry.

17
00:01:44,800 --> 00:01:47,180
So, let's dive straight in.

18
00:01:47,660 --> 00:01:50,440
The crash course of what exactly is UEFI.

19
00:01:50,440 --> 00:01:55,240
So, a lot of people may have heard the term UEFI, but may not know exactly what it is.

20
00:01:55,460 --> 00:01:59,620
So, UEFI stands for the Unified Extensible Firmware Interface.

21
00:01:59,620 --> 00:02:01,980
It's the successor to BIOS.

22
00:02:01,980 --> 00:02:05,740
Most people will be familiar with BIOS, the basic input-output system.

23
00:02:05,760 --> 00:02:11,820
It interfaces between the mechanical elements of a system and its operating system.

24
00:02:11,980 --> 00:02:21,680
So, effectively, it works as a translation layer between the operating system and the firmware for the hardware of your device, hence a firmware interface.

25
00:02:22,000 --> 00:02:35,360
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.

26
00:02:35,360 --> 00:02:42,080
It then allocates that memory sector and returns it, and then that's how it's read, as a very, very general basic overview.

27
00:02:42,320 --> 00:02:45,360
It's key for all system functionality.

28
00:02:45,540 --> 00:02:47,600
It conducts all boot operations.

29
00:02:47,600 --> 00:02:58,820
It can, as I said, conducts all interfaces between the software and the hardware, and it is essential in all modern computers.

30
00:02:58,820 --> 00:03:03,080
So, it is found everywhere, regardless of the operating system that you're using.

31
00:03:03,520 --> 00:03:08,120
It's also widely considered far more secure than BIOS.

32
00:03:08,120 --> 00:03:11,240
So, we introduced the concept of something called Secure Boot.

33
00:03:11,280 --> 00:03:23,880
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 that they're the correct and authorized driver.

34
00:03:23,920 --> 00:03:40,240
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.

35
00:03:40,400 --> 00:03:50,260
One of the key things to mention about UEFI is that it is stored on an independent chip on your motherboard, an NVRAM chip, which is totally isolated.

36
00:03:50,260 --> 00:03:56,260
It's its own independent component of the machine, and it is attached to the motherboard.

37
00:03:56,260 --> 00:03:58,760
So, it's completely isolated from everything else.

38
00:03:58,760 --> 00:04:01,460
It is its own piece of kit.

39
00:04:01,800 --> 00:04:09,320
So, just to really intensify and solidify where this sits in your computer.

40
00:04:09,320 --> 00:04:14,600
So, the UEFI, as I said, sits between the operating system and firmware, and the firmware that talks to the hardware.

41
00:04:14,600 --> 00:04:18,880
So, the operating system, if it wants to talk to your hardware, has to go through the UEFI.

42
00:04:20,620 --> 00:04:31,880
It is essentially just a translation layer of operating system commands down to firmware layer commands to receive whatever the operating system needs the host to do.

43
00:04:33,100 --> 00:04:38,420
So, most people, when you're talking about UEFI and BIOS, they'll think of this sort of screen.

44
00:04:38,420 --> 00:04:44,760
Your boot screen, sometimes with the boot menu or BIOS settings as one of those options at the bottom.

45
00:04:44,760 --> 00:04:51,720
But the majority of the users will see this sort of screen and just, you know, as it boots up your computer and not the device.

46
00:04:52,820 --> 00:04:57,640
Some people will obviously go into those settings, which looks something like this.

47
00:04:57,640 --> 00:05:08,980
So, on the left, you have the older BIOS settings configuration menu, and on the right, you have the newer UEFI interactive GUI.

48
00:05:09,000 --> 00:05:15,580
So, one of the things that UEFI actually allows to do is the use of graphical user interfaces, which is not available in BIOS.

49
00:05:15,580 --> 00:05:18,300
This allows for, as you can see, this is there.

50
00:05:18,300 --> 00:05:22,920
It allows for branding, it allows for, you know, CPU temperatures and all this sort of stuff.

51
00:05:22,920 --> 00:05:27,960
It also allows for point and click, so the use of a mouse, whereas BIOS doesn't.

52
00:05:27,960 --> 00:05:36,300
This is to do primarily with how EFI operates using EFI binary files, which allows for these layers to be put on top of it.

53
00:05:37,340 --> 00:05:45,040
Again, this allows for security settings, it allows for the boot order to be configured, and such things like that.

54
00:05:46,060 --> 00:05:55,020
So, most people will think this is sort of the limit of what you can, or this will be like the limit of what most people have dealt with, but the UEFI itself is actually a lot more complicated.

55
00:05:55,060 --> 00:06:12,280
It does a lot more in relation to your host, and it runs the entire time that your computer is operating, 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.

56
00:06:12,600 --> 00:06:27,140
So, there's a lot more to it that a lot of people are not privy to, but the key thing to know is it is always active, is essential, and it's isolated from the rest of the system.

57
00:06:27,720 --> 00:06:34,880
So, why is UEFI interesting to attackers and defenders alike?

58
00:06:34,880 --> 00:06:39,340
So, why are attackers, red team, is looking at UEFI?

59
00:06:39,360 --> 00:06:46,020
So, as I said earlier, the UEFI is isolated from the rest of the system on its own little island of silicon.

60
00:06:46,020 --> 00:06:48,700
So, it's segregated from the rest of the system by design.

61
00:06:50,580 --> 00:07:08,540
Because it's isolated, it's not well known about, and it's considered quite low-level technology, it's commonly overlooked in a lot of attack situations, and normally isolated to the sort of APT rootkit sort of attack frameworks and methodologies and TDPs.

62
00:07:08,580 --> 00:07:18,160
So, it's normally overlooked in most operations by defenders, so it gives this sort of idea that it's lucrative and valuable to pro attackers.

63
00:07:18,700 --> 00:07:24,940
The other thing to note is that remediation of anything on the UEFI is really difficult.

64
00:07:26,260 --> 00:07:33,900
With a lot of components on the machine, obviously you can chop and change them, hard drives, RAM, CPU, all that sort of stuff, if you really had to.

65
00:07:34,000 --> 00:07:37,480
Changing the UEFI, if you had to, much more difficult.

66
00:07:37,480 --> 00:07:40,280
A lot of the time, they're soldered onto the motherboard.

67
00:07:40,600 --> 00:07:43,520
So, as you can imagine, changing that is a real pain.

68
00:07:43,960 --> 00:07:51,640
And even removing it, obviously, interactively through an interface can be really tricky if you don't have experience with UEFI.

69
00:07:53,800 --> 00:08:02,240
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.

70
00:08:02,440 --> 00:08:14,300
One of the other things to note about UEFI is that by standard, by the standards of UEFI, everything written to it is automatically put as a system.

71
00:08:14,380 --> 00:08:19,980
So, it's non-volatile and everything that's written will automatically stay there throughout boot.

72
00:08:19,980 --> 00:08:28,480
Which, as you can imagine, from a sort of persistence attack methodology sort of mentality, is inherently quite valuable.

73
00:08:29,460 --> 00:08:34,480
So, although this is why attackers are looking at it, why are they looking at it now?

74
00:08:34,480 --> 00:08:36,220
What exactly has changed?

75
00:08:37,300 --> 00:08:46,640
So, as I said, it's normally put as being rootkits and little actors, ATPs, because it's a complex sort of area and a lot of people overlook or don't really understand.

76
00:08:47,140 --> 00:09:02,520
But what's happened is that since Windows... actually, since Windows XP, surprisingly, but more recently since Windows Vista and onwards, Windows has... Microsoft has gradually introduced more runtime access to the UEFI memory space.

77
00:09:02,700 --> 00:09:21,460
So, 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.

78
00:09:21,500 --> 00:09:39,740
So, research done last year at DEF CON, DEF CON 27, Michael Liebowitz 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.

79
00:09:39,940 --> 00:09:46,580
I was really recommending their research, really cool stuff, and obviously this is where this entire piece of research stemmed from.

80
00:09:47,440 --> 00:09:55,420
And they went into how they could use native Windows API functions to read and write into the UEFI memory space.

81
00:09:56,520 --> 00:10:03,340
So, originally, when I first saw their talk, I thought, oh, this is worrying, but surely there must be a way around this.

82
00:10:03,720 --> 00:10:15,660
Again, this is a section that will come later on, but it was a gap that was found, or that I, when looking into it, I did see was in the security defensive structure.

83
00:10:17,160 --> 00:10:34,840
So, because of their research, there is now very, because, not because of the research, but because of Microsoft's expansion, which is runtime service access, there is, by their exposure, Windows API basic functionalities that allow read and write access into this lucrative,

84
00:10:34,840 --> 00:10:42,960
sort of, not well understood memory sector that's isolated from the rest of the system, which is pretty valuable.

85
00:10:44,180 --> 00:10:49,260
So, how is it that the UEFI memory space is exploited?

86
00:10:49,260 --> 00:10:57,020
All the way from the APT actors, all the way down to script kitties or, you know, newer attackers.

87
00:10:57,820 --> 00:11:17,820
So, the way that Leibovitz and Timson exposed was to use C-sharp precompiled payloads using kernel32.dll exploit functions and get firmware environment variable ex and set firmware environment variable ex.

88
00:11:17,820 --> 00:11:20,660
As you can imagine, these are the read and write functions.

89
00:11:21,440 --> 00:11:43,440
With these two methods, an attacker 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 from the UEFI memory space.

90
00:11:44,260 --> 00:11:55,300
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.

91
00:11:56,620 --> 00:12:09,060
It also has to specify, at the time of compilation, the variable names and the GUIDs or the vendor IDs of the variable they're going to be injecting into the memory space.

92
00:12:09,580 --> 00:12:22,880
And because of this, and 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 in order to access the UEFI and write into it.

93
00:12:22,880 --> 00:12:33,280
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.

94
00:12:33,280 --> 00:12:42,460
So as attack methods go, this is quite advanced compared to obviously just copying and pasting off the internet and running it as you like.

95
00:12:43,980 --> 00:12:50,200
You also have to have an understanding of UEFI variable constructs, their attributes, and how they're constructed.

96
00:12:50,820 --> 00:12:59,540
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.

97
00:13:00,020 --> 00:13:02,240
I decided to approach this from another angle.

98
00:13:02,240 --> 00:13:10,540
So instead of going for something pre-compiled and thought about what if we could just do like a drive-by sort of attack.

99
00:13:10,760 --> 00:13:23,140
So we went back to the tried-and-true PowerShell, which is able to leverage the same DLL import functionality.

100
00:13:23,500 --> 00:13:34,760
So ignoring high-level codes, we found that the same functionality into the UEFI memory space read and write could be emulated in PowerShell just as effectively.

101
00:13:36,800 --> 00:13:45,400
You can do this as a PowerShell script, or you can actually do it as a on-the-fly sort of write to terminal and execute, and both work just as well.

102
00:13:45,400 --> 00:13:50,700
The only caveat for both attacks is that it has to be run at an administrative level.

103
00:13:50,700 --> 00:14:02,180
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.

104
00:14:04,760 --> 00:14:22,580
So emulating what Tinsman and Leibovitz 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 and fully functional.

105
00:14:22,720 --> 00:14:44,040
It was only after I translated their C Sharp 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 nicely wrapped as two separate functions,

106
00:14:44,040 --> 00:15:00,920
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 APIs and understanding how to do that.

107
00:15:00,920 --> 00:15:02,220
It does it all for you.

108
00:15:02,220 --> 00:15:21,700
So we've gone from pre-compiled targeted C Sharp payloads to very small on-the-fly copy-paste PowerShell scripting, which as you can imagine if you put that online anyone can tweak the payload and start playing around with it and it's much easier to do much quicker.

109
00:15:22,980 --> 00:15:29,240
So I made some POC code, there's a link at the end to a repository where this is available to everyone.

110
00:15:30,620 --> 00:15:40,800
So the POC code is PowerShell dumps a reverse shell payload, the idea is that it dumps a reverse shell payload into your file and then immediately runs it.

111
00:15:40,800 --> 00:15:44,140
So it's just a write, read, execute.

112
00:15:44,140 --> 00:15:51,320
Obviously in the real world, as I said earlier, you'd obviously write it to the memory space, you'd create persistence, read it later, extract it and execute.

113
00:15:51,760 --> 00:15:55,760
For a PSA this seemed to work very well.

114
00:15:57,080 --> 00:16:16,660
When I tested this, so the antivirus I was using on the host, Windows 10, it detected obviously the reverse shell when it was running to memory, which is what you'd expect, but it didn't terminate it and it didn't remove the payload itself from the UFI memory space.

115
00:16:16,660 --> 00:16:26,780
So the payload itself was still on the host even after the AV had flagged it, which I'll demonstrate later.

116
00:16:28,020 --> 00:16:48,820
As an extra point, this will tie into the defensive problems later, as an attacker, you might want to do is the first write operation you have into a UFI memory space and the persistence that you create, when you run that first payload, delete the original entry into UEFI and the persistence and recreate it again.

117
00:16:48,820 --> 00:17:00,640
The reason 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.

118
00:17:00,640 --> 00:17:15,240
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.

119
00:17:15,960 --> 00:17:18,080
So now comes the tricky bit.

120
00:17:18,260 --> 00:17:19,680
I do have a demo.

121
00:17:20,140 --> 00:17:30,320
So the demo has been created, just as a heads up, to... it was OBS of a virtual machine, however it is fairly small.

122
00:17:30,720 --> 00:17:32,180
So I do apologize.

123
00:17:32,180 --> 00:17:36,300
The videos themselves are available afterwards.

124
00:17:36,300 --> 00:17:40,040
They'll be available for people to look over.

125
00:17:40,920 --> 00:17:44,440
And it will be a good description of what's going on.

126
00:17:44,440 --> 00:17:46,340
So this is the first one.

127
00:17:46,340 --> 00:17:53,160
So this screen shows the drive by header that I'm going to be using in Notepad.

128
00:17:53,160 --> 00:17:55,940
As you can see, it's in byte arrays.

129
00:17:56,420 --> 00:17:58,560
So I copy that.

130
00:18:00,000 --> 00:18:04,900
This payload is fully available from the repository that's available at the end.

131
00:18:05,200 --> 00:18:10,400
This is pasted into the administrative PowerShell terminal.

132
00:18:10,400 --> 00:18:13,360
As you can see the whoami cm underscore test.

133
00:18:14,500 --> 00:18:16,800
That's now being executed.

134
00:18:17,760 --> 00:18:23,080
So that's being written into the UEFI memory space and then being extracted and executed.

135
00:18:23,080 --> 00:18:35,340
So we're going to go to my attack box where I have a reverse TCP handler waiting for the connection from the POC code, which is going to be extracted from UEFI memory.

136
00:18:35,340 --> 00:18:38,440
So we give that a few seconds.

137
00:18:43,080 --> 00:18:44,240
And there it is.

138
00:18:44,240 --> 00:18:48,600
So that's the reverse shell from the UEFI hosted payload.

139
00:18:48,600 --> 00:18:51,780
And the whoami shows that it is cm underscore test.

140
00:18:51,780 --> 00:18:57,360
So it's the same machine that we just ran the PowerShell POC code on.

141
00:19:01,140 --> 00:19:06,980
One thing to note is that the PowerShell instance in that case will be running

142
00:19:14,660 --> 00:19:16,480
in the background.

143
00:19:23,220 --> 00:19:35,540
So when you execute the outputs of the PID of the PowerShell instance that it's going to be running as a POC code, obviously in real attacks you wouldn't keep it as a PowerShell instance.

144
00:19:35,540 --> 00:19:39,720
You might migrate it to something else, but they're irrelevant.

145
00:19:41,020 --> 00:19:52,680
So that's basically the advance of moving from generating payloads and then targeted attacks all the way down to copy pasting and getting the same effect.

146
00:19:52,680 --> 00:19:55,520
So that's the attack side of it, but what about defending?

147
00:19:55,680 --> 00:20:00,740
So there are a number of issues with defending UEFI memory space.

148
00:20:01,020 --> 00:20:11,020
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.

149
00:20:12,100 --> 00:20:19,060
One of the main reasons is the simplification for firmware updates and maintenance.

150
00:20:19,060 --> 00:20:39,380
So for example, if you're 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 or you'd have to do specialized boot time scans in order to check that it was the correct version.

151
00:20:39,480 --> 00:20:50,800
Whereas now using these interfaces, the operating system is able to run software that can check the installed version, make sure it's compatible, the right type, the right vendor, so on and so forth.

152
00:20:51,240 --> 00:20:57,420
It's also able to change the boot order from runtime, so you no longer have to go into the UEFI or BIOS menu.

153
00:20:57,420 --> 00:21:04,820
You can just do that straight from the operating system, which obviously is much more user-friendly for a lot of users.

154
00:21:06,140 --> 00:21:14,660
One of the interesting things is that in development of Windows, they use UEFI variables and memory space for crash dump data.

155
00:21:15,220 --> 00:21:26,880
So if you ever run Windows Developer Editions and you have a crash, you'll find that it will output crash data to the UEFI memory space because it's non-volatile by nature.

156
00:21:26,900 --> 00:21:30,480
They know that it will be stored and it will be safe so that they output there.

157
00:21:32,600 --> 00:21:44,220
Yeah, so it allows for just much easier maintenance and upgrading and patching of the firmware level of a machine.

158
00:21:45,280 --> 00:21:50,860
But what restrictions are there on this variable access that Windows has introduced?

159
00:21:50,860 --> 00:21:53,900
Well, none, effectively.

160
00:21:53,900 --> 00:21:58,880
The only restriction I could find was a variable size.

161
00:21:58,880 --> 00:22:06,700
Over a certain size, when you try to extract it, you might have some issues because it assumes that it's going to be a certain size.

162
00:22:06,700 --> 00:22:14,740
You can overload the UEFI if you try hard enough, although I haven't actually tried that and I don't recommend it.

163
00:22:15,740 --> 00:22:27,820
You must provide, if you want to read data from UEFI, you must provide the variable name and the GUID or the vendor ID to access that particular variable's data.

164
00:22:28,840 --> 00:22:33,100
And this is where the trouble arises from.

165
00:22:33,100 --> 00:22:51,200
There is no currently available way to enumerate the variables, well, there wasn't, available way to enumerate the variables on the UEFI RAM chip at runtime, with only one exception, which Ligritz and Timzen demonstrated last year.

166
00:22:51,380 --> 00:22:54,700
I couldn't find any other except for one exception, which I'll cover in a second.

167
00:22:55,220 --> 00:23:04,200
Therefore, users, software systems, operating systems, anything like that, can only access variables that they already know exist and they already have the necessary credentials for.

168
00:23:04,320 --> 00:23:07,780
So, from a defense point of view, that creates an issue.

169
00:23:07,960 --> 00:23:24,680
If an attacker creates a new variable with a randomized name and a GUID that's non-specific, an attacker, a defender, can't enumerate these variables and therefore can't analyze what's inside the UEFI memory.

170
00:23:24,960 --> 00:23:34,160
So these, any nasties they put in there, effectively go undetected because the defender doesn't know where they're called and can't extract them, can't access them.

171
00:23:34,960 --> 00:23:39,600
So, the only exception that was found was a tool called Chipsack.

172
00:23:39,600 --> 00:23:41,900
It was designed by the guys over at Intel.

173
00:23:41,900 --> 00:23:47,620
It's a deep firmware security analysis and repair tool.

174
00:23:48,000 --> 00:23:49,900
It's really powerful.

175
00:23:50,360 --> 00:23:51,880
I was quite impressed with it.

176
00:23:51,880 --> 00:23:55,760
It does output the UEFI variables at runtime.

177
00:23:55,760 --> 00:23:59,920
It was the only tool, and I did a lot of searching, and I found it did that.

178
00:24:01,160 --> 00:24:05,660
But the tool itself, even in their reputations, they say it's not for production.

179
00:24:05,660 --> 00:24:07,220
It's for development only.

180
00:24:07,240 --> 00:24:09,040
It's very large.

181
00:24:09,040 --> 00:24:10,400
It's quite clunky.

182
00:24:10,400 --> 00:24:28,860
It requires the installation of a custom kernel driver, and it also requires the disablement of certain security functions in order for it to operate, which obviously, as a defense software, if you're going to be using this remotely in production, is counterintuitive.

183
00:24:28,860 --> 00:24:36,620
Although it does what I was looking for, it wasn't capable of doing it in the way that was required.

184
00:24:43,320 --> 00:24:46,900
Although those are the difficulties, how do you monitor the memory space?

185
00:24:47,820 --> 00:24:54,520
I tested a lot of methods in order to try and find runtime access and enumeration.

186
00:24:54,900 --> 00:24:59,840
This is just a few of them, but I spent a lot of time going through these methods.

187
00:25:00,320 --> 00:25:03,880
Examination of runtime enumeration.

188
00:25:04,660 --> 00:25:11,880
First of all, I looked at the UEFI specification itself, which is really extensive.

189
00:25:11,880 --> 00:25:29,760
There are lots of sections that explain how you can enumerate UEFI variables, but they mainly focus on what's called the EFI shell, which is a specialized shell that can be accessed at boot time in order to interface with the EFI layer of your device.

190
00:25:29,760 --> 00:25:38,200
It requires a custom loader to be put normally on removal medium, which you then access and it provides the shell.

191
00:25:38,760 --> 00:25:50,640
So the specification provides a lot of information 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.

192
00:25:50,900 --> 00:25:56,240
So it was inconclusive and I couldn't find runtime services from the specification, unfortunately.

193
00:25:58,660 --> 00:26:06,620
Attempts to... so the operating system, as I said, Windows introduced the interaction for the operating system to have access and control over certain elements of UEFI.

194
00:26:06,620 --> 00:26:12,140
So UEFI should have an understanding of what is in there.

195
00:26:13,040 --> 00:26:26,620
So analyzing how the operating system interfaces with the UEFI showed that it works off of a database inside the isolated EFI partition of your hard drive.

196
00:26:26,920 --> 00:26:41,900
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 at installation.

197
00:26:42,200 --> 00:26:45,280
So backtracing this all the way down.

198
00:26:45,340 --> 00:26:53,460
By the way, the BCD file in the EFI 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.

199
00:26:55,620 --> 00:27:04,140
So the operating system only knows what it knows at installation, it can't enumerate what is in the EFI memory space.

200
00:27:04,140 --> 00:27:06,640
So unfortunately, that was a dead end.

201
00:27:08,660 --> 00:27:19,180
I turned back to Chipseq 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.

202
00:27:19,560 --> 00:27:26,340
So I began looking at how it functions, I began following its procedures and how it accesses the memory.

203
00:27:28,600 --> 00:27:36,700
On assessment, I found that it imported something called EDK2, which seemed to be very important in EFI enumeration.

204
00:27:40,380 --> 00:27:58,540
Effectively, what the EDK2 does is, after a lot of time playing with it, extracting it, running it independently from Chipseq, 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,

205
00:27:58,540 --> 00:28:03,040
which can be run within an EFI shell to output specific results.

206
00:28:03,040 --> 00:28:20,740
So it's more like a compiler for EFI payloads or capsules, as you may call them, which was run from Chipseq for, I think, mainly for remediation or repairs to the firmware.

207
00:28:21,040 --> 00:28:24,760
Unfortunately, it didn't do what I was looking for, which was obviously runtime enumeration.

208
00:28:26,520 --> 00:28:30,700
So the operating system doesn't enumerate, it only has a list of what it already knows.

209
00:28:30,700 --> 00:28:42,700
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 and couldn't figure out how it was operating.

210
00:28:42,700 --> 00:28:48,060
So I ended up kind of down a rabbit hole for quite a while, trying to dig myself out of it.

211
00:28:48,060 --> 00:29:00,100
Eventually, I did basically knuckle down and get back to Chipseq, and I spent a lot of time following it, debugging it, really analyzing how it worked.

212
00:29:00,100 --> 00:29:10,160
And eventually, I figured out through its abstract process how it accesses the UEFI memory space from runtime.

213
00:29:10,160 --> 00:29:22,200
And to do this, it uses an undocumented function of the NTDLL.DLL file called NTEnumerateSystemEnvironmentVariable values EX.

214
00:29:22,760 --> 00:29:36,420
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.

215
00:29:37,480 --> 00:29:41,280
So you run this function from the NTDLL.

216
00:29:41,280 --> 00:29:48,880
It provides a data blob in a buffer, which you can then loop through and carve and extract all of the variables for analysis.

217
00:29:48,880 --> 00:29:52,340
And this proved to be the saving grace.

218
00:29:53,280 --> 00:30:04,840
From the Chipseq tool, I extracted the methodology, I put it in a lightweight wrapper, really analyzed it, put it through its paces.

219
00:30:05,120 --> 00:30:14,320
The resulting POC code, which is in Python, runs on everything Windows 7 forwards that I tested.

220
00:30:14,640 --> 00:30:27,880
It should, in theory, run on Windows XP because the function within NTDLL was introduced in one of the NTDLL versions, which was released alongside a Windows XP Service Pack 2.

221
00:30:28,120 --> 00:30:32,260
So technically, it should run on Windows XP, but I didn't try that one.

222
00:30:32,540 --> 00:30:40,840
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.

223
00:30:41,980 --> 00:30:53,860
As it uses the native NTDLL.dll, which is found on every single Windows host, you're not required to install anything custom except for Python, but also run the POC code.

224
00:30:53,860 --> 00:30:58,540
So it leverages local files in order to enumerate this memory space.

225
00:30:59,120 --> 00:31:06,040
As with the attacks, it must be run as admin because of the token escalation that's required for firmware access.

226
00:31:06,800 --> 00:31:26,600
But as you can see from the left, when running this POC Python code, it did successfully dump all of the AFI variables, including the malicious codes that were not defined anywhere else, and allowed them for analysis as byte data and as translated Unicode.

227
00:31:27,020 --> 00:31:40,880
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.

228
00:31:42,600 --> 00:31:44,560
I do have another demo for that.

229
00:31:45,040 --> 00:31:46,140
Bear with me.

230
00:31:59,770 --> 00:32:02,430
So this just shows some Python code.

231
00:32:03,110 --> 00:32:07,250
We're now going to run that Python file, Python 2.

232
00:32:09,770 --> 00:32:14,110
As you can see, it's outputting the AFI variables nice and clearly.

233
00:32:14,110 --> 00:32:20,050
As you can see, the ones going past, although it may be quite small on your screen, is showing the DefCon demo.

234
00:32:21,010 --> 00:32:37,210
P2 entries, 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 NSFenum.

235
00:32:40,200 --> 00:32:41,080
There we are.

236
00:32:41,080 --> 00:32:47,460
That on the left there is DefCon demo-p1.

237
00:32:47,560 --> 00:32:50,560
That's an example of how that works.

238
00:33:02,240 --> 00:33:13,140
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.

239
00:33:13,140 --> 00:33:16,620
Very lightweight and integrated into defensive software.

240
00:33:16,620 --> 00:33:23,580
What does this mean for computer users and as researchers?

241
00:33:24,520 --> 00:33:26,620
Everyone can be targeted.

242
00:33:26,620 --> 00:33:28,980
Equally, everyone can patch them now.

243
00:33:29,220 --> 00:33:48,550
So despite the obvious ease with which all critical attackers can leverage this memory space using the API function exposed last year, and as I've demonstrated, it can be all the way up from defined calculated attack methodology all the way down to drive-by copy-pasting,

244
00:33:50,810 --> 00:33:58,830
defenders equally now have the equal ease in accessing and enumerating this memory space for analysis.

245
00:34:00,270 --> 00:34:13,770
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.

246
00:34:14,490 --> 00:34:36,670
So integration into standard detection rules, 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 operating systems,

247
00:34:36,670 --> 00:34:38,650
modern hosts.

248
00:34:39,610 --> 00:34:45,230
It also allows for increased sort of research in this area.

249
00:34:45,230 --> 00:35:05,030
So although we now can monitor this, there may be custom payloads that they use that are specific, or there might be malware variations that are specific for leveraging this memory space, which allow us to create custom rules and remediation methods in order to remove this as a threat.

250
00:35:05,030 --> 00:35:19,190
So as we can now enumerate these malicious payloads when they're on a unified memory space, it also allows us to remediate it by leveraging the same capabilities of the attackers, the read-write.

251
00:35:19,190 --> 00:35:28,010
If a defender knows what the payloads are called and where they're stored, they can overwrite and remove their payloads from the victim's host.

252
00:35:28,010 --> 00:35:44,870
So we are in a situation now where attackers have this capability to leverage this isolated memory space, but defenders equally have the same level of ease in order to monitor and neuter any attempts to leverage it.

253
00:35:46,430 --> 00:35:48,350
So that's me.

254
00:35:48,350 --> 00:35:51,070
That's my email, if anyone has any questions.

255
00:35:51,070 --> 00:36:03,850
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 than this presentation.

256
00:36:04,990 --> 00:36:08,110
So if anyone does have any questions, please feel free to email me.

257
00:36:08,110 --> 00:36:13,330
There's also the talk.txt channel, if anyone has any questions there.

258
00:36:13,330 --> 00:36:18,870
Or please feel free to direct message me, and I will answer any questions that I'm capable of.

259
00:36:19,670 --> 00:36:22,170
And I look forward to hearing from you guys.

260
00:36:24,310 --> 00:36:25,890
The last slide I have prepared.

261
00:36:25,890 --> 00:36:29,110
So please, if anyone has any questions, do just let me know.

262
00:36:29,110 --> 00:36:30,070
Thank you very much.

263
00:36:31,150 --> 00:36:32,050
Thanks a lot, Connor.

264
00:36:32,050 --> 00:36:32,930
Appreciate it.

265
00:36:33,030 --> 00:36:33,810
Good talk.

266
00:36:33,810 --> 00:36:34,430
Thank you.