 Hello everyone, I'm Jordan Ding from Tencent Security Charm Lab and today I'm going to talk about Windows security medications. So um in uh in recent years um uh Microsoft Windows has already released uh five re- five major releases and each one of them uh Microsoft has decided to put some new security features in the release. And in 2017 uh they they decided to put many of the security features under uh Windows Defender brand. And uh some of the uh some of the names are code integrity guard, exploit guard, arbitrary code guard and application guard. So today we all go through these security features. Um Microsoft Edge has become the new default browser on Windows 10. It is also the most targeted browser in recent Pantone competitions. In fact it has already surpassed its famous predecessor, Internet Explorer. So normally a attacker compromise a browser by first scanning code execution in a renderer process. That's the process that parses the web page and executes JavaScript code etc. And then the attacker needs to exit uh to use another vulnerability to escape from the renderer sandbox. This will get the attacker's normal user privilege on the target system. Uh in order to do some real harm, the attacker can optionally use another bug to uh escalate to kernel or system privilege and that will gain a attacker full compromise of the target system. The first one I'm going to talk about is code integrity guard. So after compromise the process uh attacker can uh after compromise the process use uh piece of shield code, attacker can uh load a deal into the compromised process or it can uh create a evil process to execute a larger amount of code. Because this way it's easier to write than shield code. So Windows 10 threshold 2 introduced two mitigation policies to prevent these from happening. Uh the first one I'm going to talk about is child process policy. Uh when the child process policy is enabled for a certain process, it prevents the process from uh it prevents process from creating a sub-process um uh as the child process of this process. So how does it work? Well actually um at that time Windows did not have a uniform way of recording mitigation policies for a certain process. So this particular policy is recorded in the token flag field of the kernel uh token kernel object. So when the process is created uh it first needs to derive its token from its parent process. Uh that is done in the security subsystem or SE in the NTOS kernel. And the security substance check checks the token flag field to see if there's a child process restricted bit in that token flag field. And it found it denies the process creation. And also there's uh a tagger can also choose to load a deal into a compromised process. So the process signature policy uh is checked during pro uh during a section creation. Uh whenever a deal is loaded into a process it first needs to create an image section into that process. So before the section is created uh the memory subsystem or mm uh calls the calls the code integrity subsystem or CI to check if the executable deal backing this backing this section is has a digital signature or is digitally signed. Uh if not it prevents the section from create created. So there's three levels for process signature policy. The first one is Microsoft signed online. Uh this is the most restrictive one as it only allows uh loading of certain Microsoft core system files. The second one is store signed online. The store signed online allows loading additional files from Windows Store. All the universal Windows apps has this uh level of uh protection enabled so they cannot load on sign deals by default. And the last one is mitigation opt-in. This not only allow load Microsoft or store files but also WHQL files which is normally part of a device driver package. So CIG has some limitations. Um attackers can choose to implement their own loader such as uh a loader that maps the deal file into uh a block of execute memory. Since it's only an executable memory and not an amateur section it cannot trigger the uh code integrity policy. So it's little bit harder but still trivial to bypass. Next thing I'm going to talk about is Windows Defender exploit guard. Um Windows Defender exploit guard uh is used to protect memory vulnerabilities. The memory vulnerabilities are the most common way to remotely compromise an application such as a web browser. Uh we do have DP or ASLR on uh more than operating systems but this is not enough. DP SLR has too many bypasses. Um so we do need, what we do need is a built-in protection at the system level. The EMET or enhanced mitigation experience toolkit uh by Microsoft is quite powerful but it's not pre-installed. The exploit guard is basically a system level re-implemented EMET. It is internally called payload restrictions uh because it restricts attackers ability to deliver a malicious payload after uh attacker against uh control outward execution flow. So uh exploit guard can um be enabled both dynamically or statically. For dynamic enablement the source process uh the process that starts the uh starts the exploit guard process uh pass a payload restriction policy structure to the uh NTS kernel. For the static enablement there's uh uh image file execution options. Uh actually Microsoft has introduced a new feature for IFEO called IFEO filter. Uh traditionally IFEO can only set options by the image base name. Now uh by using IFEO filter uh we can specify a for pass for the for the uh executable to be to be filtered to be enabled uh certain mitigation policies. So exploit guard is enabled via uh via our undocumented feature undocumented feature called uh verifier hook. The verifier hook starts at the earliest time possible in NTDL. NTDL calls the verifier hook and loads the payload restrictions deal from the system 32 directory. Uh although the exploit guard is completely implemented in the user mode, there are also kernel facilities to help uh implement the exploit guard. This uh this structure is uh on sign loan 32 bit. Uh it records all the features that exploit guard has and NTDL before the process initialization will read this read the information from the structure and pass it on to the payload restrictions deal. So the exploit guard also registered for deal notification. This is another undocumented feature in NTDL. Uh after this uh notification is registered uh whenever a deal loaded into or unloaded from the process, the NTDL first calls the uh notification callback. So by uh by registering this notification, uh exploit guard can patch the newly loaded deal uh into into the process. Exploit guard uh like EMET also use uh user mode hook to implement its features. Uh in this in all these hooks it checks for potentially illegal operations. But exploit guard also comes with its own limitations just like EMET. Uh its user mode hook can be bypassed of course. And it definitely increase the difficulty of code execution but it's really not preventing it because already already the attacker already get the uh get control over the execution flow. Next thing I'm going to talk about is called arbitrary code guard. Arbitrary code guard is introduced in Windows 10 Redstone 2. Uh today most exploits needs to either allocate or modify executable memory by uh by limiting that behavior. Exploit guard uh uh arbitrary code guard actually breaks most of exploits available uh in the wild. So uh uh arbitrary code guard limits uh three kinds of behavior. First is creating executable memory. And second is modifying executable memory. And third is uh uh mapping a writeable or uh and executable section. So there are four policies for dynamic code policy. This is called prohibited dynamic code, allows red opt out, allow remote downgrade and audit prohibited dynamic code. The first one turns on the arbitrary code guard. And the second one allows uh dynamic disable of the arbitrary code guard on a per threat basis. And third one allows uh disable of arbitrary code guard from another process. And first one is enabling the arbitrary code guard in a log only mode. This is quite useful when you are developing an application that uses the arbitrary code guard. So this uh this policy is actually checked in three uh in three uh three different API calls. Uh the first one is mapping a view of section. This mapping uh executable section. Second is allocating a executable memory. And third is changing the protection of the existing memory blocks. Uh all these are going to MI arbitrary code block function. And this function actually checks for the preprocess ACG switch. And also the prepros uh pro threat uh ACG disable switch. If uh if the process is opt into the ACG and the threat is not opt out of the ACG. Well this action is blocked by the ACG. So for by enabling the ACG the most uh no most most important problem is how do we deal with the legitimate applications that actually use dynamic code generation. Uh the most obvious example being the web browsers. Web browser has JavaScript engines. JavaScript engine nowadays always use just in time compiler to generate native code for JavaScript. And this we all need to allocate executable memory in the renderer process. And this will of course be this uh this will of course be blocked by the ACG. So to solve that problem the Microsoft Edge has choose to re-architect this JavaScript engine to move the jet part out of the process. So it turns out ACG only checks the source process not the target. Which means that if you are ACG process you cannot allocate executable memory in the normal process but if you are normal process you can allocate uh executable memory in ACG process. So by sending the JavaScript code to a JIT server and the JIT server compiles the JavaScript code and send back through uh send back through writing and executable memory in the renderer process. This way uh we implemented an out of process jet compilation. So ACG has its own set of limitations. First it increased design complexity dramatically because it requires out of process compilation for any dynamic code. Also attackers can also generate limited native code via out of process jet. Because uh uh because the the JIT server cannot distinguish between legitimate or illegal request for the jet code compilation. Also not uh also not all GPU drivers are compatible with ACG. Uh Windows 10 uses a blacklist to detect any incompatibility and if detected it uses uh allows red opt out switch to disable the ACG. Also ACG does not protect against return-oriented programming or ROP. So ROP does not generate any new code or or modifying any existing code. So it does not trigger any ACG policies. And yet another layer of protection is is introduced in Windows 10 RS3 is called Windows Defender Application Guard. So the application guard is basically a virtual machine running on the local computer, running only only Microsoft Edge inside the virtual machine. So powered by the Hyper-V virtualization technology. It is not enabled by default and can be enabled via group policy. So when a user opens the web page in application guard it automatically renders the web page in a virtual machine. So like like any other virtual machines uh application guard shares the same hardware with the host operating system. But it does have its own operating system kernel uh services and applications. So by enabling ACG we see several process popped up on the host operating system. Uh there is Hyper-V service, VM compute, and also the uh Hyper-V manager process. So the Hyper-V service actually create a unique identifier for the new container. And the VM compute process uh actually starts the container for a for the for the application guard. And finally after the container is started uh uh after the container is started it uses remote desktop protocol to connect to the local computer. So there's the RDP client running on local computer. It's called actually a local desktop protocol if you will. So this this RDP client relates all the UI clipboard and printer through the RDP protocol. And this is sandbox by default with all the mitigation enabled. And also um this is a simplified overview of the application guard. On the left hand side, on the left hand side is the is the host OS and on the right hand side the child partition is the guest OS. These two operating systems can only communicate via VM bus. It's a communication mechanism implemented via shared memory. So there's a set of VSCs or virtual service clients that relates all the uh device request file operations to the VSPs on the host operating system. Also there's a DNS client that actively detects if it's running application guard. If so it redirects its uh DNS request to the host uh WDAG proxy. So there's a virtual hard disk for the for the for the virtual machine. The first one the system template base is a virtual disk for the container OS image. This is generated from the system files of the host OS. Um and for the file rights operations in the virtual machine is use another virtual disk called sandbox virtual disk. This capture all the right operations and it it is discarded after each run of the virtual machine. The storage virtual service provider handles all the container storage access. So you see the sandbox virtual disk is mounted on C and there's another persistent disk another two persistent disk uh for storing logs and user files. So when you run trying to run anything apart from Microsoft Edge in the container it gives you this message. It says this app cannot be run in Windows Defender application guard. Please contact your administrator for help. Well I am the administrator right. So how can I get around this? Actually uh it uses another guard called device guard to implement this to to restrict certain application from running in the container. This device guard is uses a undocumented binary format for its for its roles. This is converted from the XML format and comes preloaded with the virtual machine. After a bit of reverse engineering we were able to recover its file format and it has a fixed lens header and also uh multiple blocks of variable lens data. It has many information stored uh the signers, signing scenarios and uh EKUs and secure board settings. But the most important part is the file roles. The file roles uh allows the allows the device guard to deny certain applications from running by checking its file name or version information or signatures. So how do we run our own tools in the application guard? Well remember we say it's a binary file. It turns out if you remove the file physically from the container image and the device guard policy will be disabled. So the most simple way to do this is to get the open source WIM lib tool. It's a editor for the Windows imaging format. So use the use the WIM delete command to remove the policy file from the Windows defender application guard uh image and restart the application guard. Then use the common dialog to open the explore explorer window in the application guard. Then you can run anything inside it. So what's actually inside the virtual machine? Well actually it's a pure Windows 10 professional edition. It has certain virtual machine agents running inside for process operations. Um this virtual machine has a random password set by the HyperV service. It is used for remote desktop connections. Uh uh things like clipboard printers uh is not enabled by default but can be configured via a group policy. So there's two virtual machine agents running inside. First one is called HyperV guest compute service. This uh this service is uh is the service to communicate with the host via the HyperV socket. It controls the container state and modify container settings. And also it redirects the standard output and input for uh uh for any application to the HyperV socket. The second is called container execution agent or EXEC service. It's a RPC server uh running inside the virtual machine for creating users and shutdown systems. But actually there's no process for Microsoft Edge controller. Actually there's no need for controlling Microsoft Edge. The user is directly controlling it from outside the virtual machine through the remote desktop protocol. So in conclusion Windows is more secure with many more newly added medications. But these medications are not server bullets. Attackers and always find ways around them. Virtualization as additional layer of protection can significantly re-increase the difficulty of exploitation but at the cost of performance actually the runtime performance penalty is too high for everyday use. Uh that will be all for today. Thank you.