1 00:00:00,560 --> 00:00:02,880 Hi, thank you for joining our talk. 2 00:00:02,880 --> 00:00:07,700 A decade after Stuxnet's printer vulnerability, printing is still the stairway to heaven. 3 00:00:07,800 --> 00:00:09,660 First, let's introduce ourselves. 4 00:00:10,580 --> 00:00:12,180 My name is Pele Gadar. 5 00:00:12,180 --> 00:00:14,760 I'm in the InfoSec field for more than 7 years. 6 00:00:14,760 --> 00:00:18,140 Currently working as a Senior Security Researcher at Saybridge Labs. 7 00:00:18,360 --> 00:00:21,960 My main focus is on Windows internals and vulnerability research. 8 00:00:24,440 --> 00:00:26,840 Hi, my name is Tomer Bar. 9 00:00:26,920 --> 00:00:29,720 I'm in the InfoSec field for more than 15 years. 10 00:00:29,720 --> 00:00:33,860 Currently working as a Research Team Leader at Saybridge Labs. 11 00:00:33,860 --> 00:00:39,640 My main focus is on APT research, Windows internals, and vulnerability research. 12 00:00:44,020 --> 00:00:47,300 In this presentation, we will cover the following. 13 00:00:47,320 --> 00:00:54,480 We will demonstrate how a threat actor might have the ability to build the propagation part of Stuxnet 2.0. 14 00:00:54,480 --> 00:01:00,000 We will do that by a walkthrough on the vulnerabilities which were used by Stuxnet. 15 00:01:00,000 --> 00:01:08,160 For each one, we will describe the root cause, describe the patch, and evaluate the effectiveness of the patch. 16 00:01:08,640 --> 00:01:16,860 We will continue with a deep walkthrough of our print spooler research findings, including demos of the 2.0 dates. 17 00:01:16,860 --> 00:01:22,320 Finally, we will suggest a new mitigation for the entire arbitrary firewrite bug class. 18 00:01:23,740 --> 00:01:27,300 We will be focused on answering two fundamental questions. 19 00:01:27,300 --> 00:01:31,780 Is it possible to build equivalent propagation capabilities as Stuxnet capabilities? 20 00:01:32,000 --> 00:01:37,520 Second question, if I fully patch my entire Windows operating system, am I safe now? 21 00:01:38,500 --> 00:01:40,480 Last note before we start. 22 00:01:40,480 --> 00:01:43,380 We will use two symbols during our presentation. 23 00:01:43,620 --> 00:01:49,520 A narrow patch means that the patch logic is very specific and it was possible to re-exploit it. 24 00:01:49,700 --> 00:01:58,120 And secondly, a regular patch means that it solved the problem and had not been bypassed until nowadays, as much as we know. 25 00:01:58,800 --> 00:02:03,100 Now that we are ready, let's see the recap and the timeline of Stuxnet. 26 00:02:04,660 --> 00:02:11,700 Stuxnet is considered by many to be one of the most complex and well-engineered computer worms ever seen. 27 00:02:11,880 --> 00:02:18,680 It is believed that the project was developed in 2006 and lasted four years until it was discovered. 28 00:02:19,080 --> 00:02:22,920 Stuxnet can be described by the following three parts. 29 00:02:22,920 --> 00:02:32,980 The first part is the propagation to the target network by using three remote code execution exploits and two local privilege escalation exploits. 30 00:02:32,980 --> 00:02:40,280 The next part is the special evasion techniques, which allows Stuxnet to operate under the radar. 31 00:02:41,020 --> 00:02:46,140 The third part is the final payload, delivering specifically to Siemens PLC. 32 00:02:46,140 --> 00:02:56,640 In our opinion, a decade after Stuxnet, the most interesting part is the propagation capabilities, which is still relevant to almost any targeted attack. 33 00:02:58,840 --> 00:03:02,720 Let's zoom in into Stuxnet propagation capabilities. 34 00:03:02,720 --> 00:03:05,240 We will describe them one by one. 35 00:03:05,540 --> 00:03:19,560 Although it was a decade ago, it's still relevant to all of us because according to a research posted in 2017, those capabilities were used widely after Stuxnet for attacking a wide range of organizations. 36 00:03:19,820 --> 00:03:21,240 Let's dive deeper. 37 00:03:21,260 --> 00:03:22,500 Ending over to Pele. 38 00:03:24,800 --> 00:03:26,300 Thank you, Tomer. 39 00:03:26,360 --> 00:03:30,780 So let's start and talk about the LNK vulnerability, which was used by Stuxnet. 40 00:03:31,020 --> 00:03:37,520 It used it to spread via weaponized USB flash drives traveling between Internet-facing computers and internal network computers. 41 00:03:43,160 --> 00:03:47,360 So the attack vector contained a crafted LNK file, which is a shortcut file. 42 00:03:47,600 --> 00:03:54,240 Once it was displayed, an arbitrary DLL, which was specified as the icon file of the LNK, was executed. 43 00:03:56,740 --> 00:04:00,500 Here's a screenshot of a crafted LNK file, which exploited the vulnerability. 44 00:04:00,880 --> 00:04:03,620 You can observe that the LNK file contains the following. 45 00:04:03,620 --> 00:04:14,120 The path of the CPL, external file, and the icon ID, 0, which caused the code to trigger the execution of the DLL every time the LNK file was displayed. 46 00:04:16,300 --> 00:04:20,080 So let's take a look at the exploitation path and how it was patched. 47 00:04:20,640 --> 00:04:32,520 The main problem was that instead of loading the CPL DLL file as a data-only file by using loadLibraryX, the code actually called the loadLibraryW function and also executed the DLL. 48 00:04:32,520 --> 00:04:38,700 We expected the patch to replace this call in order to avoid execution, but let's see what would actually happen. 49 00:04:40,940 --> 00:04:44,520 So the patch added two validations in order to mitigate the vulnerability. 50 00:04:44,740 --> 00:04:50,660 First, it checked that the provided CPL file was on Microsoft's whitelist and was allowed to be loaded. 51 00:04:51,400 --> 00:04:56,980 Next, the icon ID, which we control, would have been extracted and converted from a string. 52 00:04:57,500 --> 00:05:02,940 If the ID was 0, it would override the 0 with minus 1, meaning it wouldn't be loaded. 53 00:05:04,680 --> 00:05:16,220 The patch was very specific, because as you can see, the loadLibrary function still existed, meaning that if someone would have been able to bypass the validations, then the CPL could have been executed. 54 00:05:19,120 --> 00:05:22,260 So let's see the bypass, which was patched five years later. 55 00:05:25,330 --> 00:05:30,670 In order to bypass the patch, we need to bypass the icon ID check and transform it to 0. 56 00:05:31,830 --> 00:05:37,710 It can be done if you will be able to send the minus sign as a parameter to strToIntW function. 57 00:05:38,370 --> 00:05:40,470 Let's see exactly how it was done. 58 00:05:41,010 --> 00:05:47,610 Because of a type confusion between a white car buffer and a cow buffer, the original icon ID string was truncated. 59 00:05:49,130 --> 00:05:54,910 We can exploit it by providing a long enough buffer, so the icon ID will turn into the minus sign. 60 00:05:55,290 --> 00:06:01,030 Once strToInt will return 0 as the icon ID, our arbitrary CPL will be executed. 61 00:06:04,540 --> 00:06:06,960 The patch for this one was pretty simple. 62 00:06:07,520 --> 00:06:09,240 The truncation bug was removed. 63 00:06:09,720 --> 00:06:13,800 The call to loadLibrary, which was the actual root call, wasn't changed. 64 00:06:13,800 --> 00:06:20,360 That means that if there is another way to trigger the loadCplModule function, it would have been still vulnerable. 65 00:06:22,840 --> 00:06:24,640 And apparently there was. 66 00:06:25,280 --> 00:06:29,200 Two years later, a new vulnerability was discovered and patched. 67 00:06:29,520 --> 00:06:35,280 It called the loadCplModule function by using another exploitation path, which was left unpatched. 68 00:06:37,960 --> 00:06:42,220 The patch for this one was adding the previous logic of a CPL whitelist. 69 00:06:42,220 --> 00:06:46,480 But loadLibrary still was not replaced. 70 00:06:48,440 --> 00:06:54,060 What's interesting here is that we have noticed that there is another last patch to loadLibrary function. 71 00:06:54,060 --> 00:06:57,880 But we haven't seen any disclosed vulnerability yet. 72 00:07:00,010 --> 00:07:03,330 So moving to the next propagation capability. 73 00:07:03,430 --> 00:07:08,450 Next, we will talk about the Stuxnet RPC vulnerability, handing over to Tomer. 74 00:07:12,310 --> 00:07:13,950 Thanks, Penel. 75 00:07:14,090 --> 00:07:22,170 On 2006, three years before Stuxnet's first known infection, a new vulnerable RPC vulnerability was discovered and patched. 76 00:07:22,170 --> 00:07:26,390 According to Microsoft, it was a very limited scoped attack back then. 77 00:07:26,390 --> 00:07:36,910 But later on, a very similar exploitation path was used by both Stuxnet and Configure.Warm, which became one of the most spreadable warms ever seen. 78 00:07:36,910 --> 00:07:42,570 RPC vulnerabilities were the main cause of global computer warms since 2003. 79 00:07:42,590 --> 00:07:43,590 Remember Blaster? 80 00:07:44,070 --> 00:07:48,610 So it's obvious that the cost of a vulnerability in this mechanism is huge. 81 00:07:48,610 --> 00:07:50,930 Let's dive into the specific details. 82 00:07:51,130 --> 00:07:55,610 The RPC vulnerability root cause that we will present is due to a canonical path. 83 00:07:55,610 --> 00:07:58,130 So let's understand what is it, a canonical path. 84 00:07:58,130 --> 00:07:59,790 It's actually pretty simple. 85 00:07:59,870 --> 00:08:05,310 It gets an absolute path and converts it to the shortest absolute path in the meaning of string length. 86 00:08:05,310 --> 00:08:13,410 The most common usage of canonical path is for textual comparison of two different representations of the same canonical path. 87 00:08:15,030 --> 00:08:22,250 The original vulnerability was a type confusion, which led to a classic stack-based buffer overflow. 88 00:08:22,250 --> 00:08:29,210 The vulnerable function was copying a buffer which exceeded the allocated buffer, causing memory corruption. 89 00:08:29,810 --> 00:08:31,990 Here is the exploitation path. 90 00:08:31,990 --> 00:08:40,690 The RPC request triggered the vulnerable function remotely, which led to an out-of-bound write caused by WCSCAT function. 91 00:08:40,990 --> 00:08:45,610 Please notice the RPC function's name, NTNetPW. 92 00:08:45,610 --> 00:08:49,090 We will explain why it's important in the following slides. 93 00:08:50,810 --> 00:08:56,970 The patch added a proper buffer length check, which eliminated the original buffer overflow vulnerability. 94 00:08:56,970 --> 00:09:03,090 Two years later, a newer vulnerability was discovered in the same exploitation path. 95 00:09:03,090 --> 00:09:09,190 This time, it was discovered in the RPC wrapper function, which is called NetPR. 96 00:09:09,290 --> 00:09:13,150 This function calls the original vulnerable function directly. 97 00:09:13,150 --> 00:09:14,910 Remember NetPW? 98 00:09:15,050 --> 00:09:17,270 Let's dive into the root cause. 99 00:09:17,270 --> 00:09:27,490 The root cause of the vulnerability is that the input path includes more slash-dot-dot-slash calls than the number of prior directory entries. 100 00:09:27,530 --> 00:09:40,170 This will result in gaining control over the output buffer pointer, which will point backwards on the stack and will trigger out-of-bound writing after calling the WCS copy this time. 101 00:09:40,970 --> 00:09:51,070 So the patch MS867 replaced the WCS copy function with a safer function, StringCopyWorkerW. 102 00:09:52,110 --> 00:09:55,990 Let's dive into Stuxnet task scheduler vulnerability. 103 00:09:56,370 --> 00:10:00,050 But first, let's understand how the task scheduler works. 104 00:10:00,050 --> 00:10:07,010 The task scheduler job XML file contains the metadata of a job, including which user will execute the job. 105 00:10:07,010 --> 00:10:11,090 The folder which contains it is writable by all users. 106 00:10:11,230 --> 00:10:22,230 To protect the integrity of the job configuration files and prevent users from modifying them, task scheduler calculated a CRC32 checksum on each created task XML. 107 00:10:22,350 --> 00:10:32,270 When it's time to start the job, task scheduler recalculated the XML checksum and compared it to the original value, if they matched the job executed. 108 00:10:32,690 --> 00:10:35,290 If not, it would have been ignored. 109 00:10:35,290 --> 00:10:40,310 The CRC32 algorithm is collision-prone, which may lead to data forgery. 110 00:10:40,530 --> 00:10:49,250 Stuxnet ZeoDay exploited this fact by forging an XML file of a job which was executed as anti-authority system. 111 00:10:49,270 --> 00:10:54,470 It had a custom CRC32 checksum, which was identical to the original task XML. 112 00:10:54,890 --> 00:11:00,710 Therefore, it would have been executed as a system, resulting in a local privilege isolation. 113 00:11:00,710 --> 00:11:13,690 In the patch MS1092, Microsoft implemented a second integrity check by using the SHA256 algorithm, implemented by the compute-hash function, which is less collision-prone. 114 00:11:14,290 --> 00:11:19,570 Moving forward nine years later, a newer task scheduler vulnerability was found. 115 00:11:19,570 --> 00:11:34,050 The vulnerability abused the backward compatibility feature of the task scheduler mechanism, which provides the option of migrating all tasks from C Windows task folder to the new task folder, which is system32tasks. 116 00:11:34,370 --> 00:11:39,670 In order to exploit it, the attacker would need to perform the following four steps. 117 00:11:39,770 --> 00:11:42,190 Step one, create a new job. 118 00:11:42,230 --> 00:11:46,970 As a result, an XML file would be created in the new tasks folder. 119 00:11:46,970 --> 00:11:55,130 Step two, override the job file in the legacy task folder with an R link to the file which the attacker wishes to control. 120 00:11:55,770 --> 00:12:01,330 Third step is creating a new legacy task with the same name. 121 00:12:01,390 --> 00:12:05,810 And finally, trigger an old to new task migration over RPC. 122 00:12:06,170 --> 00:12:16,970 As a result, the task scheduler service would update the security information of the file, which the attacker wishes to control, granting the attacker full control privileges on it. 123 00:12:17,490 --> 00:12:22,950 The attacker can now replace or write to any file, gaining a local privilege escalation. 124 00:12:25,660 --> 00:12:29,020 So this is the exploitation path that was used. 125 00:12:29,180 --> 00:12:31,660 Let's see how Microsoft patched it. 126 00:12:32,320 --> 00:12:38,080 The patch makes sure that the file is not a symbolic thing by using two different checks. 127 00:12:38,080 --> 00:12:43,700 The third check verified that the original path is the final path of the file. 128 00:12:43,740 --> 00:12:47,960 If it's different, it means that it was redirected by a symbolic link. 129 00:12:47,960 --> 00:12:53,480 And the second check verified that the number of the file's NTFS links is not bigger than one. 130 00:12:56,200 --> 00:13:00,600 OK, so let's see the fourth vulnerability moving over to Win32k. 131 00:13:03,760 --> 00:13:10,620 Actually, there were dozens of Win32k local privilege escalation vulnerabilities over the last decade. 132 00:13:10,620 --> 00:13:22,420 Here is a list of several options from 2020, which can replace the original already patched vulnerability, in order to rebuild the Stuxnet 2.0 propagation capabilities part. 133 00:13:23,180 --> 00:13:27,220 The only capability which remained is the print spooler vulnerability. 134 00:13:31,120 --> 00:13:35,140 Let's start to talk about our printer spooler research and findings. 135 00:13:36,260 --> 00:13:43,940 We will start by presenting how we found a 20 plus year old bug by using 20 minutes of fuzzing. 136 00:13:44,200 --> 00:13:50,220 We have noticed that each time a print job is being created, it is represented by two files. 137 00:13:50,220 --> 00:13:55,620 First, an SPL file, which simply contains the data to be printed. 138 00:13:55,680 --> 00:14:00,040 Second, an SHD file, shadow file, which will be focused on. 139 00:14:00,040 --> 00:14:06,640 It is represented by the undocumented shadow file struct and contains the metadata of the print job. 140 00:14:06,640 --> 00:14:12,080 For example, printer name, printer port name, document name, and etc. 141 00:14:12,080 --> 00:14:19,920 We found that the printer's folder, which contains the SHD files, is writable by all users. 142 00:14:20,460 --> 00:14:25,680 And that the SHD files are being processed once the service is started. 143 00:14:25,680 --> 00:14:31,160 So, we asked ourselves, what will happen if we craft our own SHD file? 144 00:14:31,300 --> 00:14:35,980 So, we started to mutate the SHD files and fuzz the service. 145 00:14:37,340 --> 00:14:40,780 After 20 minutes of fuzzing, we had our first crash. 146 00:14:41,120 --> 00:14:48,820 We have managed to crush the print spooler service by using a limited user and a crafted SHD file. 147 00:14:49,080 --> 00:14:53,700 It appeared that the code was trying to dereference some part of our data. 148 00:14:53,700 --> 00:15:03,580 Treating it as a pointer to a security descriptor without any validation or sanitization of the data we'd provided in the SHD file. 149 00:15:03,900 --> 00:15:05,960 Microsoft did not fix this bug. 150 00:15:06,260 --> 00:15:09,040 We will show the response in the end of our talk. 151 00:15:09,560 --> 00:15:10,880 Okay, demo time. 152 00:15:10,880 --> 00:15:14,840 Let's see a demo of the crash in the latest Windows 10 insider build. 153 00:15:16,400 --> 00:15:20,000 So, on the left side, Johnny is a limited user. 154 00:15:20,000 --> 00:15:24,200 We can see that we are running on the latest Windows 10 fully patched machine. 155 00:15:24,200 --> 00:15:27,540 On the right, the user John is administrator. 156 00:15:27,560 --> 00:15:31,320 And it is used only for convenience to avoid restarts of the OS. 157 00:15:31,320 --> 00:15:33,960 Instead, we will restart the service to trigger the vulnerability. 158 00:15:34,180 --> 00:15:42,180 So, we are copying the crafted SHD file to the printer spooler directory. 159 00:15:51,710 --> 00:15:59,870 And now, we will trigger the vulnerability by restarting the service and 160 00:16:05,750 --> 00:16:11,290 listing the printers via WMI command. 161 00:16:17,860 --> 00:16:21,520 As we can see in ProcMon, we crashed the service. 162 00:16:24,830 --> 00:16:26,450 Handing over to Peleg. 163 00:16:29,530 --> 00:16:30,870 Thank you, Tomer. 164 00:16:30,910 --> 00:16:33,730 So, the crash was cool, but we wanted more. 165 00:16:33,730 --> 00:16:37,070 Let's talk on how we got local privilege escalation twice. 166 00:16:37,070 --> 00:16:38,850 One of them is still zero-day. 167 00:16:40,250 --> 00:16:46,230 So, in order to understand the next vulnerabilities we found, we will dive into the printing process in the Windows OS. 168 00:16:47,410 --> 00:16:52,430 The print spooler is the service which is responsible for creating and handling print ops in the Windows OS. 169 00:16:52,890 --> 00:16:59,090 Accessing the print spooler is possible remotely, for example, using a shared printer, and locally. 170 00:16:59,530 --> 00:17:01,450 We will focus on the local scenario. 171 00:17:01,450 --> 00:17:08,070 More specifically, we will focus on the fact that the spooler allows the user to print to a file by using a virtual printer. 172 00:17:08,550 --> 00:17:11,990 This is an important part which our further slides rely on. 173 00:17:14,700 --> 00:17:17,600 A quick brief on the flow of printing to a file scenario. 174 00:17:18,040 --> 00:17:26,600 First, the user sends some data to be printed using an application, for example, Notepad, and specifies which file he would like to print to. 175 00:17:26,600 --> 00:17:36,540 It means that the data will be printed, which means it will be written to a file using a virtual printer, instead of printed to a real printer. 176 00:17:37,240 --> 00:17:42,620 The spooler service, spoolsv.exe, which is the RPC server, gets the request. 177 00:17:43,500 --> 00:17:52,120 Later on, the local print provider, which is responsible for printing data to files, will print the data into the file which was specified by the user. 178 00:17:54,980 --> 00:17:59,160 Let's start with the first print spooler vulnerability which was used in Stuxnet. 179 00:17:59,620 --> 00:18:03,900 This is the flow of the vulnerability which was providing a remote code execution. 180 00:18:04,340 --> 00:18:17,140 The vulnerability exploited the fact that the spooler allows the user to print to a file on a remote computer on behalf of the system, and has printed the malicious file to system32, which was a MOV file. 181 00:18:19,690 --> 00:18:22,110 So it was patched on 2010. 182 00:18:22,550 --> 00:18:24,630 The patch included two validations. 183 00:18:24,630 --> 00:18:26,010 A. 184 00:18:26,150 --> 00:18:31,050 Check if the printing job was dispatched locally on the machine itself or remotely. 185 00:18:31,450 --> 00:18:35,830 If remotely, it will override and ignore any requested file write operation. 186 00:18:36,750 --> 00:18:44,350 Second, it will check that the user has write permissions to the path of the file that he wanted to print to, before retrying to it. 187 00:18:46,860 --> 00:18:53,280 Moving forward to 2020, we have found a way to bypass the patch locally using almost the same exploitation path. 188 00:18:53,980 --> 00:19:01,540 The first check bypass is obvious because we shifted from a remote code execution to a local privilege escalation. 189 00:19:01,800 --> 00:19:06,720 The second check needed some work, so let's dive into our print spooler research. 190 00:19:08,580 --> 00:19:15,760 We found that a limited user can do some interesting operations without any elevation required by just using partial commands. 191 00:19:15,760 --> 00:19:21,960 For example, adding a virtual printer which prints to a local printer pool, meaning it will print to a file. 192 00:19:21,960 --> 00:19:28,460 And, specifying a path of the file which it doesn't have access to, for example system32. 193 00:19:28,840 --> 00:19:34,840 Ok, interesting, so does that mean that a user can just print any data he would like to system32? 194 00:19:34,980 --> 00:19:36,220 Let's check. 195 00:19:37,760 --> 00:19:40,400 So apparently no, or that's what we thought. 196 00:19:40,480 --> 00:19:48,180 As we mentioned before, the MS1061 patch has added a function which validates if the user can write to the path he asked to print to. 197 00:19:48,180 --> 00:19:51,940 Which means that the user won't be able to print data to system32. 198 00:19:51,940 --> 00:19:55,180 So let's understand how can we bypass it. 199 00:19:59,550 --> 00:20:07,870 Every time the print spooler initializes, it processes the SHD files which are waiting to be spooled in the same directory for every user. 200 00:20:08,530 --> 00:20:16,190 A limited user can create an SHD file which represents a print job which prints to any path, for example system32. 201 00:20:16,570 --> 00:20:24,750 Once the print spooler restarts, it will process the SHD file without being impersonated or aware of who created the print job. 202 00:20:24,750 --> 00:20:31,510 Therefore, it will operate as an anti-authority system and will print the data to any file as an anti-authority system. 203 00:20:31,690 --> 00:20:40,490 Resulting with allowing the user to write data to any file on the system and gaining an arbitrary file write and a local pre-write escalation. 204 00:20:42,350 --> 00:20:48,930 This was actually the bypass of the second patch validation, specifically for the validate output file function. 205 00:20:48,930 --> 00:20:55,650 Because the spooler is running as an anti-authority system, it has writing permissions to almost every file on the file system. 206 00:20:55,650 --> 00:20:57,590 So the check will pass successfully. 207 00:20:59,310 --> 00:21:03,810 So let's see a demo of the first local pre-write escalation we found in the print spooler. 208 00:21:07,430 --> 00:21:10,990 As you can see, we are running under the context of a limited user. 209 00:21:11,170 --> 00:21:17,330 We are using a Windows 10 machine from March, before our vulnerability was patched. 210 00:21:18,090 --> 00:21:20,230 We are using Johnny which is a limited user. 211 00:21:23,590 --> 00:21:28,770 So first, we will use PowerShell in order to do the following stuff. 212 00:21:29,450 --> 00:21:33,190 We will add a printer port which allows us to print to system32. 213 00:21:35,110 --> 00:21:39,010 We will add a printer driver which allows us to create a virtual printer. 214 00:21:40,130 --> 00:21:45,350 And finally, we will add a printer which is using the system32 port. 215 00:21:46,990 --> 00:21:52,870 Next, we will use a pre-crafted SAGD file which represents a print job which prints to system32. 216 00:21:52,870 --> 00:21:57,030 And we will use a DLL payload which we would like to write to system32. 217 00:21:57,030 --> 00:22:07,670 We will rename it to SPL and we will copy it by using our limited user to the spool printers folder in system32 which is writable by all users. 218 00:22:11,830 --> 00:22:19,570 Now, before we will restart the VM, I want you to notice that there are only three users in the computer. 219 00:22:19,630 --> 00:22:21,350 Administrator, Johnny and John. 220 00:22:21,370 --> 00:22:28,090 And that the following file in Windows 32 which is named exploited.txt does not exist. 221 00:22:29,130 --> 00:22:36,550 Next, let's restart the VM by our limited user in order to... the print spooler will process our SAGD file. 222 00:22:43,110 --> 00:22:54,410 Once we are logged in back into Johnny user, the print spooler service will process our SAGD file, will treat it as a print job and will write our file to system32. 223 00:22:54,510 --> 00:22:58,430 Next, Windows service will execute our DLL. 224 00:22:58,690 --> 00:23:04,670 And as you can see, we will be able to add a new administrator to the computer. 225 00:23:05,270 --> 00:23:11,130 And it was able to write a file to system32 named exploited.txt. 226 00:23:11,950 --> 00:23:15,390 Now, let's verify that we actually added an administrator. 227 00:23:17,350 --> 00:23:23,730 We will open a command prompt which is elevated and we will just log in using our new administrator user. 228 00:23:24,670 --> 00:23:27,670 As you can see, 229 00:23:31,250 --> 00:23:34,310 the administrators group contains our user. 230 00:23:35,250 --> 00:23:40,150 So, we have been able to gain local privilege escalation using the print spooler service. 231 00:23:42,130 --> 00:23:45,770 So, now that we coupled them all together, we reached our destination. 232 00:23:56,350 --> 00:24:04,230 We have found equivalent capabilities to allegedly build Stuxnet 2.0 propagation prompt, but our work is not over yet. 233 00:24:06,870 --> 00:24:15,790 After the first vulnerability we found was patched, we've been able to re-exploit it and we created it with CVE-2020-1337. 234 00:24:16,910 --> 00:24:21,430 Microsoft are currently working on a fix which will be deployed in the upcoming patch Tuesday. 235 00:24:21,610 --> 00:24:24,810 Therefore, we can't release any technical details right now. 236 00:24:25,110 --> 00:24:27,550 We will publish it once the patch will be deployed. 237 00:24:27,730 --> 00:24:29,390 But, let's see a demo. 238 00:24:38,770 --> 00:24:43,230 So, as you can see, we are running under the context of Johnny, which is a limited user. 239 00:24:48,040 --> 00:24:51,580 We are running under a fully patched VM. 240 00:24:56,700 --> 00:25:00,080 Under the context of Johnny, we will execute our exploit. 241 00:25:01,340 --> 00:25:05,500 Which will bypass the patch of CVE-2020-1048. 242 00:25:10,080 --> 00:25:17,740 After we crafted our shd file, we will copy to the print spooler directory. 243 00:25:18,880 --> 00:25:26,320 But first, you can notice that the exploited txt file does not exist and that we have only three users as before. 244 00:25:26,620 --> 00:25:28,860 Now, let's restart the VM. 245 00:25:34,970 --> 00:25:39,510 Once it was initialized, we will log in again to our limited user Johnny. 246 00:25:41,990 --> 00:25:50,870 Now, as before, the print spooler will process our shd file and will print the data to system32, which is our payload, which is a dll file. 247 00:25:51,050 --> 00:25:58,070 Our dll file will be loaded into an elevated anti-authority system service and we will gain code execution. 248 00:26:04,400 --> 00:26:07,940 Now, let's try and find the exploited.txt file. 249 00:26:07,940 --> 00:26:16,020 As you can see, we write the data to system32 and we have been able to add an administrator user once again to the VM. 250 00:26:16,620 --> 00:26:19,680 Let's execute a command prompt, which is elevated. 251 00:26:26,470 --> 00:26:29,730 And let's log in using our new administrator user. 252 00:26:32,050 --> 00:26:41,150 As you can see, we have gained a local private installation and code execution using the print spooler once again after the first vulnerability was patched. 253 00:26:42,390 --> 00:26:44,310 Handing over to Tomer. 254 00:26:46,570 --> 00:26:50,730 Wow, 1337, that's awesome. 255 00:26:50,930 --> 00:26:59,310 So, going back to our second question, we would like to propose an additional possible solution as a second level for patching. 256 00:26:59,710 --> 00:27:11,130 We believe in a level security mitigation approach, so we reported to MSRC on each vulnerability we found, but we still believe it's not enough. 257 00:27:11,150 --> 00:27:15,990 So we developed a POC for real-time prevention of the attack. 258 00:27:16,610 --> 00:27:28,770 The main root cause of the arbitrary file write bug loss in the context of local privilege installation is the fact that a limited user is allowed to write directly to the following location. 259 00:27:29,110 --> 00:27:36,470 This is dangerous and can be exploited very easily, and we found that it's actually not really needed for the regular use. 260 00:27:36,470 --> 00:27:45,730 Today, we will release a mini-filter driver which restricts any file write operation by a limited user to some of this location as a POC. 261 00:27:45,950 --> 00:27:55,690 This mitigation proposal is not specific to the spooler's vulnerabilities and can be used as a template for mitigating the arbitrary file write bug loss. 262 00:27:55,790 --> 00:28:05,170 Please treat that driver as a POC and be careful not to execute it in production system before validating it for false positive. 263 00:28:05,170 --> 00:28:07,010 Let's see at the end. 264 00:28:07,650 --> 00:28:16,370 Okay, so this time we are running on Windows 10 RS1, an older version, without the patch for the vulnerability we were going to use. 265 00:28:16,370 --> 00:28:19,370 And as usual, we are running as Johnny, a limited user. 266 00:28:23,820 --> 00:28:27,280 Let's make sure that our driver is loaded to memory. 267 00:28:34,350 --> 00:28:40,630 And now we'll present that regular usage of printing is allowed. 268 00:28:49,400 --> 00:28:56,940 So our driver will examine the file write of the SPL and SHD file and will allow it. 269 00:28:56,940 --> 00:29:02,600 We can see that there are two files in the printer's spooler folder with size which is not zero. 270 00:29:16,400 --> 00:29:26,640 And now, let's copy the SHD SPL file to the printer's spooler directly. 271 00:29:28,260 --> 00:29:33,880 Now, actually, our driver examined the write and blocked it. 272 00:29:33,880 --> 00:29:38,580 You can see that the files have zero size. 273 00:29:41,700 --> 00:29:46,100 Let's demonstrate a task scheduler exploit. 274 00:29:46,100 --> 00:29:50,120 Let's make sure that our driver blocked the write. 275 00:29:53,390 --> 00:30:08,370 So, for Microsoft's response for the spooler's local privilege escalation, the additional vector for CVE-2020-1048 will be addressed in August 2020 as CVE-2020-1337. 276 00:30:08,550 --> 00:30:18,410 And for the spooler denial of service, the technique results in a local denial of service which doesn't meet Microsoft's servicing bar for security updates. 277 00:30:20,110 --> 00:30:25,150 We would like to give credit for the following people for researching similar areas. 278 00:30:25,150 --> 00:30:31,790 Alex Ionesco and Yarden Shafir, Dave Weinstein, Iti Aker, and Jingua Kia. 279 00:30:33,150 --> 00:31:02,270 Today, we will release our repository which includes an exploit POC for CVE-2020-1048 and an exploit POC for the zero-day denial of service of the spooler service, the driver for the arbitrary file write mitigation, and in a few days, on August 12, we will release the CVE-2020-1337 super-lit exploit POC. 280 00:31:02,270 --> 00:31:03,820 Please check our repository. 281 00:31:06,540 --> 00:31:10,840 Thank you for joining us and let's go over for the Q&A.