DEF CON 29 - Tomer Bar, Eran Segal - 2021 Our Journey Back To The Future Of Windows Vulnerabilities

00:10 - My name is Tomer Bar. I’ve been in the cybersecurity field for more than 15 years, currently leading SafeBreach Labs as director of security research.

00:21 - My main focus is on vulnerability research and nation state APT research.

00:26 - My name is Eran Segal. I’ve been in the cyber security field for more than seven years.

00:32 - Currently, I’m working as a security researcher in SafeBreach Labs for the last two years.

00:39 - My experience involves research on windows and the better devices.

00:46 - In memory of my dad, David, who bought me my first personal computer and he’s the reason I’m standing here.

00:54 - In 2020, security researchers reported a record number of 1000 Windows vulnerabilities.

01:01 - We were curious, what superpowers will we get from researching this huge number of vulnerabilities? Can we leverage our findings to discover 0-days? We decided to go back in time to 2016, to search for patterns and automatically classify all the public vulnerabilities since then.

01:21 - We believe that only by connecting the dots to a bigger picture, we will be able to come back to 2021 with the success of achieving our goal.

01:32 - We will start with describing the research goals, assumptions, motivations and approach, then we will explain the challenge and our chosen solution, process and infrastructure.

01:45 - We will detail the process step-by-step, provide a detailed end to end example from 0 to 0-day.

01:52 - We will present the six vulnerabilities and past exportation techniques we discovered.

01:59 - We’ll end our talk with a new proposed idea for discovering vulnerable Windows machines and open a Q&A session.

02:07 - We define three main goals. First, dive in and understand the root cause of each vulnerability and how Microsoft chose to address it.

02:18 - Second, automate and provide tools to ease the process from root cause to POC.

02:26 - Last but most important, discover new 0-days based on a semi-automated process.

02:33 - Every research start with assumptions. Let’s describe them.

02:37 - The first assumption is that although Microsoft is a huge enterprise with thousands of developers, we believe that similar vulnerabilities will be mitigated by similar patching techniques.

02:52 - The second assumption is that Microsoft will try to fix each vulnerability with as minority change as possible in order to avoid backward compatibility issues.

03:04 - This approach might be prone to patch bypasses.

03:09 - Last, it will be a good idea to search for 0-days near a code that’s already been known as vulnerable.

03:18 - Probably the first thing you will do is to start checking if your assumptions are correct.

03:25 - We encountered a recent public research on just one ento scalar function, which included five different vulnerabilities from various categories, in a short block of code.

03:37 - We won’t dive into the specific details of each vulnerability, but you can get the impression that our assumptions were fulfilled.

03:46 - Vulnerable code is a good place to search for new vulnerabilities.

03:50 - The vulnerabilities have different categories, but all are due to wrong bound checks or wrong entering of memory allocations.

04:01 - Now that we are more confident in the research idea, it was time to think about our research approach.

04:10 - Until now, patch diffing was done manually by comparing the differences of a vulnerable executable to its new code version after the fix.

04:19 - Furthermore, the main goal of this process was focused on understanding the root cause of a single vulnerability and building 1-day to exploit it.

04:32 - We aimed higher, we wanted to find 0-days in the end.

04:36 - But is it possible to jump from root cost to 0-days? We understood that in order to achieve it, we will need to build an automated process that will gather the insights from all the patches in a single searchable DB.

04:53 - Let’s dive into our infrastructure implementation, moving over to Eran.

05:01 - - We were required to take four steps in order to achieve our goal.

05:06 - The first step is to understand each one of the patches Microsoft released and infer the vulnerability root cause.

05:14 - Then we want to integrate the context of each vulnerability by correlating publicly available information about the vulnerability with each patch.

05:25 - The second step is to find a way to trigger the vulnerability.

05:29 - In other words, which actions lead to the vulnerable code.

05:35 - Finally, after gaining this valuable knowledge, we had to find ways to harness this knowledge for hunting 0-days.

05:45 - Let’s begin with step one. The automated process includes five sub-steps.

05:52 - First, downloading all Windows 8 security only updates since 2016.

05:59 - the reason we chose to download security updates of Windows 8 and not Windows 10, is because Windows 8 is a security only updates while Windows 10 doesn’t.

06:14 - It is possible to discover all the vulnerabilities Microsoft ever fixed in Windows 8 since 2016, using the security updates.

06:26 - After we downloaded all Windows 8 security only updates, the automated process, extract the KBs and compare the extracted files versus the older version of the same files using BinDiff tool.

06:42 - Now the fun part begins. The changes are classified into groups and inserted into a database so we will be able to search for patterns.

06:54 - Each group represent a specific type of change and we will talk about these features in the next slides.

07:02 - To get some perspective on the scale we are talking about, here are a few numbers.

07:08 - You can see, we have more than 100,000 unique functions, each one of them may be a part of a patch so it is clear that we need to understand which changes are interesting and which aren’t.

07:24 - Inside the KB, some of the files are interesting while others aren’t because APE can get indirectly updated such as a change in one of its libraries.

07:35 - It have huge effect. For example, GDI 32 is one of the most vulnerable PEs in Windows.

07:43 - It has more than 26 statically linked libraries.

07:48 - Some of these libraries are statically linked to another libraries and so on.

07:54 - In addition, every PE in Windows 8 is part of a package and every time one of the PEs is affected, has to be updated.

08:03 - The entire package is really compiled together and all the files are included in the KB.

08:10 - In order to detect which changes are interesting and which aren’t, first, we need to understand which changes the compiler can do.

08:21 - It is not simple to distinguish between changes made by the developer and the changes made by the compiler because of free compilations.

08:29 - If you compile the same code twice, the compiler sometimes is compiled with different alignments of the code.

08:41 - We all do some instructions and all other optimizations.

08:47 - We had to find ways to reduce the compiler noise.

08:51 - We chose to reduce the compiler noise using features.

08:56 - The features group similar changes together and allow us to look for vulnerability patterns.

09:02 - We developed 33 features, most of them are in the function level, but other are in the executable level.

09:11 - Each feature is optimized differently. Some are optimized to have the lowest amount of false positives, while others give us the overview insights on the patch.

09:24 - There are two types of features, patch-related features and vulnerability-related features.

09:30 - Patch-related features group patches by the type of the change made by Microsoft, such as add a new function call, while vulnerability-related features group patches by vulnerability category such as off by one, use after free and so on.

09:49 - The beauty of the features lie in their simplicity, we’ll provide some examples in the next slides.

09:57 - 2019, here we come. The first example of patch-related features is the number of Xrefs.

10:05 - It is not directly linked to a specific vulnerability category.

10:10 - This feature compares the number of function calls between each patched function versus the unpatched version.

10:18 - In this example, ReadPROPVARIANT added one Xref to IStream_Read.

10:24 - Let’s look into the overview of ReadPROP variant function.

10:31 - It is very easy to spot the change block. Let’s zoom in to understand the root cause.

10:38 - As we can see, one call and slim move operations were added.

10:43 - The root cause of this vulnerability is type confusion due to the fact that ReadPROP variant, reads a decimal from the file without resetting VT to VT_DECIMAL This means that we can control the type of ReadPROP variant object.

11:01 - The patch added a call to item read and set VT to VT_DECIMAL to avoid type confusion.

11:11 - Let’s jump back to 2018. An additional patch-related feature is number of conditions.

11:19 - It compares the patched and unpatched version of the file and looks for different amounts of conditions in those functions.

11:30 - In this example, the patch added five new conditions to the function NTFS find files owned by SID, changing the number of conditions between 27 and 32.

11:49 - We automatically correlation between finding in our DB and public exploits.

11:58 - Going into the patch, we can see the five added code blocks in the patched files on the right.

12:06 - Their goal is to verify that the user has admin permissions by calling SE token is admin and allowing the listing, only if the user have listing permissions.

12:21 - Let’s move to vulnerability-specific features, Tomer.

12:25 - - Thank you, Eran. Until this point, we introduced patch-related features.

12:31 - Now we will represent how these patch-related features can be used to understand the vulnerability root cause.

12:38 - We will go over a few examples. The professor told us not to, but we are bound to break rules.

12:50 - Following our guidelines of learning from the past, we look at high-profile integer overflow vulnerability, the SMB GHOST, the patch usage function RtlULong in order to verify that our location size will not overflow before calling the allocation function.

13:11 - Is this a unique fix or should we expect Microsoft to use this fixed method in other integer overflow vulnerabilities? Let’s go back in time to the earliest patches we identified two binary defic.

13:27 - We went back in time to 2016, Las Vegas DEFCON 25.

13:34 - It seems that there is a searchable pattern for the integer overflow vulnerability category.

13:40 - The fix added Xref to the several ulong arithmetic function before calling the vulnerable function.

13:48 - In this example, it calls the ulong multiply function in order to verify that allocation size will not overflow before calling the allocation function.

13:59 - We constructed a list of ulong functions and added in-safe feature.

14:05 - Our integer overflow feature, we tell with more than 200 results.

14:10 - We selected the vulnerability, but as far as we know, has not been publicly analyzed yet and see if the feature provide us with automated root cause analysis.

14:22 - We chose the NTDLL pitch from April, 2020. The only function that was really changed was LDRP search resource section and the change included adding both RtlULong multiply and add functions.

14:41 - Indeed, the patch was implemented by verifying that allocated mapping size will not overflow.

14:47 - This was done using the same ulong function as the vulnerability we saw in the previous example.

14:54 - As far as we know, this patch pattern used since 2016, so now we have a working integer overflow feature.

15:05 - Sometimes features are very simple, but are still very effective, searching for all added functions that include integrity level, expand the category and provide several additional vulnerabilities.

15:21 - There are additional features that we have researched and found interesting.

15:25 - One feature is vice-conditioned vulnerabilities, which are usually fixed by adding log functions.

15:32 - Another feature is direct traversal, which are mitigated by detecting the. / in strings, we’ll speak about it later.

15:41 - And finally, symbolic link vulnerabilities, which are very common and are usually mitigated by adding a check for the final path.

15:51 - Let’s describe the second step. Patch Tuesday occurs on the second Tuesday of each month and includes a report for each patch vulnerability.

16:02 - The report includes important data, such as name, CVE number the affected OS, vulnerability category and et cetera.

16:11 - The cue is to have a description until mid 2020.

16:15 - The information can help us focus on the relevant features and the related executables.

16:23 - We have created an automated process that uses the API for downloading of all published CVE data since mid 2016.

16:33 - Please note that Microsoft recently changed the API and released the new one.

16:39 - The coalition process consists of four steps.

16:43 - First, take the previously extracted patches files, then query all CVE data using Microsoft’s API.

16:51 - Then, extract the vulnerable component name, we will refer it as VCN from vulnerability CVE name or description.

17:00 - And finally, call it the CVEs to the patch files based on four different coalition methods.

17:09 - First, we check if the VCN extracted for Microsoft’s API is a Windows service.

17:15 - The list of Windows service names is available in the registry.

17:19 - As we can see, connected user experiences and telemetry is the name of diagtrack service.

17:27 - If the VCN is not a service name, we will check if the VCN is included in the file description of any of the system files.

17:37 - As we can see, compatibility appraiser, VCN, is the description of the appraiser executable.

17:45 - The third method of correlation was built manually.

17:49 - We classify those VCN based on our Windows internal knowledge.

17:56 - The last correlation is based on get all statistics.

17:59 - Past association help in understanding the correlation between VCNs and the vulnerable executable.

18:06 - In this example, arrow reporting was the VCN, which was found in three Patch Tuesday during 2020.

18:15 - If we search for files which were patched during these months and were not patched in other 22 months, we’ve found eight possible patched files.

18:25 - Print spooler was the VCN in four monthly the patches and was associated with 12 possible patch files.

18:33 - Next time, we will see this VCN as part of a future vulnerability report.

18:38 - We will be able to correlate them to those files.

18:43 - The four methods automatically produced correlation of 90% of the CVEs.

18:49 - Now that we know more about the context of each patch, we can prioritize which changes are more interesting and which are less.

18:58 - Moving over to Eran. - So we found the patch linked to the corresponding CVE and found which type of vulnerability it was.

19:08 - Now, how do you find which PE can trigger that code? Who is calling that PE? And which functions are called? Our goal in step three is finding out how to trigger the vulnerable function and generate the code that will take it.

19:30 - There are two sub steps for this step. First, find which executables can trigger the vulnerable code and the second, generate the code with the correct input to trigger the vulnerability.

19:47 - We added new features that will extract all the function calls from all the PEs in Windows and for all the versions in order to generate a call graph from or to any function in Windows.

20:03 - We are talking about a very large scale, we are talking about more than 26 million function calls.

20:13 - Our graph is just like the graphs in IDA but across binaries and huge.

20:20 - With the data we collected, now we can create a call graph across the entire Windows system.

20:27 - In the picture you can see a visual representation of the call graph we created in order to find which functions are called to unwrap XML invitation.

20:40 - Later on, we will demonstrate how we are going to use this function in past exploitation scenario.

20:49 - We support multiple ways to detect a function call from a function to another.

20:54 - Load-time linking is the common way to call for an external function.

20:59 - Runtime linking such as gettalkaddress and COM servers and clients.

21:05 - We generate this class for Windows 8 and Windows 10 because after all, we want to find 0-days in Windows 10.

21:14 - In addition to creating the graph, we collected information we need to choose which function are the most interesting.

21:24 - We do that by looking for function, which are close in terms of distance to the vulnerable function, verifying whether or not the function is exported and events scraping the internet.

21:39 - We collected information and call examples about each function for multiple sources, such as MSDN documentation and scraping project in GitHub.

21:51 - User existing examples from the internet is much quicker than writing them ourselves, especially when we are talking about non-documented functions.

22:02 - But we found that even that wasn’t enough. We were still missing lots of functions so we had to find additional ways to generate PLCs.

22:15 - So we want to have the option to trigger all RPC servers quickly.

22:21 - RPC is a common interprocess communication.

22:25 - It can be over network or locally. RPC calls use IDL, interface definition language, to set up the communication between the client and the servers.

22:36 - In order to communicate with an RPC server, we have to include the corresponding IDL file.

22:44 - Therefore, we would like to extract from Windows as many ideas as possible.

22:50 - Since the original version of RPC view support only extraction of a single interface IDL, we use a modified RPC view tool to extract all IDLs with all the interfaces.

23:04 - The extracted IDL file include dozens of sparks and unions.

23:09 - Most of them raise compilation and all due to order of definition so we fixed that as well.

23:16 - RPC view works on the running RPC servers, so we had to start all of them.

23:23 - After running a script to automatically start Windows services, we got 150 running services.

23:31 - After we extracted the IDL from the opposite view, we used the automated process.

23:37 - For each interface, the automation created a new project, setting the relevant parameters for the code and compile it using MSBuild.

23:49 - In the end, we successfully automatically generated 127 working projects.

23:57 - We’ll provide a specific example of how easy it is to exploit the task scheduler ALPC vulnerability, using our semi-automated process, calling some of the functions that the IDL exposes.

24:13 - We generate and compile the template project.

24:17 - The project includes two fives, the IDL and the short generic template for settings that needed opposite parameters for composed RPC binding.

24:30 - In this example, the provider DUID, the protocol, the RPC endpoint name, are relevant to the task scheduler opposite.

24:40 - This template allows us to call each RPC function that we would like to take trigger.

24:48 - After the automation created our project with all the dependencies, comes the manual part, writing the exploit itself.

24:56 - All we need to do is call the correct functions with the correct input and we’ll get a working project, we will get privilege escalation.

25:06 - In order to exploit this vulnerability, we created and had a link and did two RPC calls.

25:15 - The first RPC call creates a folder in the task scheduler for them and the second RPC call sets the permissions.

25:24 - This would trigger the task scheduler to set the permissions of our executable, resulting previous escalation to anti-system.

25:33 - Moving on to Tomer. - Until this point, we covered how we can understand the root cause and trigger a 1-day in scale.

25:42 - But how do we find 0-days? We will use the XXE vulnerability as an end to end example, to demonstrate the four-step process from 0 to 0-day.

25:54 - We enrich our DB with the vulnerability category, name CWE, for each vulnerability.

26:01 - Then when we queried our DB for the different CWE categories, we noticed the 611 category improper restriction of XML entity resonance with six relevant vulnerabilities.

26:14 - Let’s query to see more details about them.

26:19 - We eventually found eight patched vulnerabilities, six of them with full details in our DB.

26:25 - So we were curious, what is this vulnerability category? As described by CWE, using XML with an external entity, allows remote file read.

26:39 - Hmm, sounds very interesting. Let’s dig deeper in order to understand how XXE happens.

26:50 - XXE vulnerabilities occur in XML parsers. When the XML contains a reference to an external entity, such an HTTP server, this external entity can get the content of local files.

27:04 - XXE vulnerabilities contain multiple parts.

27:08 - The upper entity is the input to the XML parser.

27:12 - The XML parser reads the content of the file system, INI and then sends a request to the attacker server to get the rest of the XML.

27:23 - The second entity, the lower one, is the response of the server.

27:28 - When the XML parser parses this response, it generates an additional HTTP GET request with the content of the file system INI.

27:39 - This is according to the standard of XML. And in order to prevent this feature in the XML parser, the DTD, which stands for document type definition, must be disabled.

27:52 - Let’s analyze the patches and understand the root cause of these XXE vulnerabilities.

27:59 - The patch for CVE-2018-0878, added four conditions to a function called LoadRATicket in the MSRA executable.

28:11 - We know that the MSRA executable is used for Windows or remote systems where a basic user can send an invitation ticket to advanced user to log into his agent and remotely assist him.

28:25 - This function probably loads the invitation ticket.

28:31 - The LoadRATicket creates the XML DOM document COM object and uses it to load and pass the XML invitation file.

28:41 - In the patch version of this function, in order to disable the support for external XML entities, four properties were added, first thing document, XS script, externals and prohibitDTD.

28:54 - The rest, stay the same, calling put a sync and load functions.

28:59 - We also followed the Xref to the user COM CLSIDs.

29:03 - We will get to it later. We wonder, either a pattern for XXE patching, so we develop a feature to search for all added prohibitDTD patches and found 20 past patches.

29:20 - Let’s verify the first patch in the UPNP host.

29:24 - We can see that HR load documents now cause the restrict DOM documents.

29:31 - Let’s see who also calls this patch function.

29:35 - The ISAPI extension executable was patched by calling restrict DOM document before a call to load XML.

29:44 - This is a different function than the load function used by remote assistance.

29:49 - So there are probably other vulnerable function used by the same COM object.

29:56 - Digging deeper, we found a third vulnerable function, set XML.

30:02 - At this point, we understood the root cause and define the conditions for exploiting the vulnerable code.

30:10 - Let’s dig into the first condition. We develop a code to trigger COM object.

30:17 - First, we queried all CLSIDs from all the files in Windows 10.

30:22 - Then for each CLSID, we enumerated all functions and interfaces then we generated source code, which created each one of the COM objects.

30:32 - And finally, we called all these function with an XXE XML file as input.

30:40 - We automatically discovered the vulnerable COM objects to the filtration data by adding the vulnerable CLSID to it.

30:49 - As we can see, we found four common interfaces and 16 vulnerable CLSIDs.

30:56 - We developed a new feature to detect all the locations that seems to be vulnerable to XXE.

31:03 - This feature is different from other feature, it does not compare between unpatched and patched version.

31:10 - Instead, it searches for XXE condition in all Windows 10 executables.

31:17 - Eventually, we found 52 candidates, 25 of them are marked as possibly vulnerable.

31:25 - They will be vulnerable if one last condition is met, if we are able to control the input of the past XML.

31:33 - For example, we can see the MSRA patch function LoadRATicket which is patched, while at the same time, the LoadandSOTARAInvitationsHistory function might still be vulnerable.

31:46 - Let’s see if we can control the input XML. At the bottom, we can see the patched XML DOM object that was used in the original vulnerability and was called from LoadRATicket.

32:02 - To our surprise, there is a second instance of the exact same vulnerability XML DOM object, just a few commands above used by several functions, including our possibly vulnerable function LoadandSOTARAInvitationsHistory.

32:22 - LoadandSOTARAInvitationsHistory, indeed, uses the vulnerable load function.

32:27 - We can see that the file to be loaded is the parameter A2.

32:34 - The GetInvitationManagerLoaded function calls our vulnerable function with the XML file RA contact history from UB data.

32:43 - This file is controlled by the user with no need for admin privileges.

32:50 - This is the history data read from a legitimate RA contact history XML file that we changed to contain the address, 1111 as the previous IP requested remote assistance.

33:04 - Now we know how to trigger the vulnerability.

33:09 - So let’s begin with the fun stuff. On the bottom left, we see the MSRA that was run with offer RA as a parameter.

33:18 - It can be reached also with double-click on MSRA.

33:22 - In Pokemon, you can see the reduction of the RA export is the refile and it’s also it’s content, which includes the exploit code.

33:34 - On the right, we can say the first DTD GetRequest for XXE XML, which reads remote file from the Windows 10 machine and ex filtrate it to the C2 server using a second GetRequest.

33:52 - Microsoft fixes this MSRA vulnerability we found and assign it the ID, CVE-2021-34507.

34:02 - In total, we discovered six vulnerabilities.

34:05 - All were reported to Microsoft. We will go over them one by one.

34:12 - The most critical vulnerability we found was the vulnerability in the Windows Help.

34:17 - We sent a spear phishing mail with a compressed attachment of an HTML file.

34:23 - We named the HTML file to include. chn twice.

34:27 - This forced the vulnerable process HH executable to pass it, although it’s plain HTML and not a CHM file.

34:36 - We can choose almost any extension to this file and it will still be passed.

34:43 - We tested the attack on default fully-patched Windows 10 machine and got blocked by the mark of the web mechanism.

34:51 - But when we compress the attachment, even without encryption, it bypassed the sandbox and ex filtration was successful.

35:00 - The third liability we found in MMC, include several snappings.

35:06 - The link to a web address snapping, expects an HTML file, but if we will provide an XXE XML exploit instead, it will be passed by MSHTML. DLL.

35:19 - We can see on the top right that it will read the remote file and actually fight it to the C2 server.

35:27 - It will provide an error message which includes the content of the ex filtrated file.

35:35 - To trigger the Windows Media Player remote file read vulnerability, you will only need to open the option screen and select the network top.

35:44 - This will trigger vulnerable parsing of the XML file, which we can control.

35:50 - On the right, you can see the structures. Please pay attention to the calling of the vulnerable load function from MSXML3 DLL.

35:59 - Moving over to Eran. - In addition to finding vulnerabilities in native code, we want them to discover 0-days in managed code.

36:10 - So we added a feature that compiles all. Net executables in windows 10 using ILSpy.

36:19 - ILSpy de-compiles each executable to a visual studio solution with Cshop files.

36:25 - The files look very similar to the XL code, even the parameter names and function names are kept.

36:34 - We sell inside all the. Net files for non-classes and functions that are vulnerable or configured to use DTD.

36:44 - All the XML parses with DTD processing enabled, are vulnerable to XXE, such as XMLTextReader.

36:54 - We found two XXE vulnerabilities in official Windows SDK executables.

37:00 - We found vulnerabilities in XXD, the utility to generate disclaimer or a class from a given source and another in XSLTC.

37:13 - In order to exploit a vulnerability in XXD, it is required to execute it with a path to XML file, which contains the XXE.

37:25 - Unlike XSD, XSLTC requires multiple parameter so it is a little bit more complex to trigger.

37:35 - In addition to the vulnerabilities we found, we found two XXE past exploitation techniques.

37:42 - We can use them to ex filtrate text files using DLL signed by Microsoft instead of using suspicious network APIs.

37:52 - This increases the odds for bypassing security controls.

37:58 - The first one is P2P, PeerGroupParseInvitation.

38:02 - It is documented function found in MSDN and the root cause of the XXE found in internal function named unwrap XML invitation.

38:13 - We traced back to find which function it is called from, using our call graph.

38:20 - We found multiple options, but we could not find any attack vector that can trigger these functions without calling one of them ourself.

38:31 - The second past exploitation technique is found in set XML in PLA DLL.

38:39 - In order to trigger that function, we used one of the examples provided by MSDN, so we had to change only a few lines of code.

38:50 - In June, 2020, Microsoft released a fix to CVE-2020-1300.

38:58 - It is a directory of XL vulnerability. You can see that they declared to fix it on Windows 8 among other Windows versions.

39:10 - Based on our correlation capability between the CVE report and the relevant patch files, we understood that the patch provided partial coverage so we dug deeper.

39:23 - Using our directorate of our XL feature, we searched for any function with. . / or. . \ as an argument.

39:32 - We found that on June, 2020, Microsoft indeed patched two files, localspl and win32spl but the patch to the PrintBRM engine was done only in August.

39:47 - We compared the pitch to the paths of Windows 10 and found that on Windows 10, all three files were patched in June.

39:57 - Does it means that Windows 8 was vulnerable to a 1-day for two months? The PrintBRM engine executable was patched only in August and with the same patch logic used in Windows 10 in June and in two WCSDR function for mitigating. . / attacks.

40:20 - The PrintBRM engine was not patched in June, 2020.

40:26 - We verified that in Windows 8, in June, it was vulnerable to 1-day attack of CVE-2020-1300.

40:36 - The PrintBRM engine allows importing of a CAB file.

40:40 - If the CAB file contains a file name that contains. . /charles, it will extract the file to an attacker-controlled location, such as System32 wbem, which is prone to DLL hijacking.

40:59 - We proved that it was possible to have RCE on fully patched Windows 8 between June and August, 2020 with 1-day.

41:09 - We also found an additional unpatched issue in 2020.

41:14 - This time the vulnerability provided arbiter delete capabilities.

41:19 - Normal search is needed in order to determine whether this is a new opportunity for finding low-hanging force or just a coincidence.

41:30 - Microsoft response. Regarding the MSI vulnerability, the bug was fixed as part of July Patch Tuesday.

41:39 - Regarding the other vulnerabilities, no fix is currently planned since they don’t meet Microsoft service bottom.

41:47 - We are encouraging you all to use and expand our tools that will be published today.

41:53 - We think that the vulnerabilities we found are just the tip of the iceberg.

41:59 - We would like to credit multiple researchers.

42:02 - We based our research on top of their previous results.

42:06 - Thanks for joining, moving on to the Q&A session. .