#0x800 | Explore Tumblr posts and blogs

ryadel · 5 years ago

Text

Enable TLS 1.1 and TLS 1.2 on Windows 7 and Windows 8 - OS + Regedit patches

As you might already know, TLS version 1.0 is not safe anymore and should be disabled, just like SSL 2.0 and SSL 3.0: if you want to know why you can either read this post, which summarizes pretty much you have to know, or recover some info regarding the three biggest attacks that managed to exploit the various TLS 1.0 vulnerabilities discovered within 2011 and 2014: BEAST, Heartbleed and POODLE. Anyway, if you have a recent version of Windows - such as Windows 10 - you won't be affected by this issue, provided you always install the OS updates through the official channels. Conversely, if you're still using Windows 7 or Windows 8, you might have to perform some manual tasks in order to get rid of that outdated TLS version: on these systems, all applications created in WinHTTP (Windows HTTP Services) such as MS Outlook, MS Word, and the likes will use TLS 1.0 support, which is the default encryption standard for these OSes. As a result, if you attempt to establish a secure connection from your Outlook client to a "TLS secured" server, there is a high chance that MS Outlook will display one of the following error messages: The server does not support the specified connection encryption type. Your server does not support the connection encryption type you have specified. Luckily enough, this can be fixed by telling your OS to never use TLS 1.0 anymore, and stick with TLS 1.1 and 1.2 by default. Here's a small guide explaining how you can do that.

Install the KB3140245 Security Patch

The first thing to do is to download and install the Windows KB3140245: you can do that using Windows Update, since it's available as an optional update, or manually download it from the following official website: http://www.catalog.update.microsoft.com/search.aspx?q=kb3140245 This will equip your OS with TLS versions 1.1 and 1.2.

Updating your Windows Registry file

The next step you need to do is to patch your Windows Registry file, so that your OS will actually use the new TLS protocol versions (1.2, and 1.1 as a fallback) instead of the outdated and vulnerable 1.0 one. This can be done either automatically (with an official Microsoft-released patch file) or by manually editing the registry file using regedit or our own TLS12fix.reg file. Microsoft Patch File The Microsoft patch file is called MicrosoftEasyFix51044.msi and can be downloaded from this url: https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi#easy If you're doing this to face a common MS Outlook scenario, downloading and executing this file is all that you need to fix your issue. Manual update If you're an experienced user this probably is the recommended approach, since it allows you to choose which protocol to enable or not. #1. Setting the default TLS protocols The first thing you do is to create a new DWORD key called DefaultSecureProtocols in the following sections of your registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp The HEX value to set depends on which protocol(s) you would like to enable by default: To enable TLS 1.0, TLS 1.1 and TLS 1.2, set the value to 0xA80 (not recommended- that's what you want to avoid). To enable TLS 1.1 and TLS 1.2 only, thus disabling TLS 1.0, set the value to 0xA00. This is the recommended approach as of today (might change in the future if TLS 1.1 becomes outdated as well). To enable TLS 1.1 only, set the value to 0x200. To enable TLS 1.2 only, set the value to 0X800. If you want to know more about these settings, take a look at this official Microsoft page, which explains everything and also adds some valuable info about the whole topic. #2. Enable TLS 1.1 and 1.2 at the SChannel component level The second thing to do, as explained in this TechNet article, is to create another DWORD key called DisabledByDefault in the following sections of your registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client And set a value of 0 (zero). Registry Patch File(s) If you don't want to manually edit your Windows Registry file using regedit, you can download use these registry patch files which we made, that will automatically set all the above registry keys with a single click. Download Registry Patch File to enable TLS 1.1 and TLS 1.2 (recommended as of 2019.10) Download Registry Patch File to enable TLS 1.1 only Download Registry Patch File to enable TLS 1.2 only

Conclusion

That's it, at least for now: I sincerely hope that this post will be useful for those system administrators, power users and enthusiasts who want (or need) to patch their system to get rid of TLS 1.0 and fix this security vulnerability for good. Read the full article

#BEAST #Heartbleed #POODLE #SChannel #Security #SSL #TLS #WinHTTP

1 note · View note

terabitweb · 6 years ago

Text

Original Post from Microsoft Secure Author: Eric Avena

With Microsoft continuously improving kernel mitigations and raising the bar for exploiting native kernel components, third-party kernel drivers are becoming a more appealing target for attackers and an important area of research for security analysts. A vulnerability in a signed third-party driver could have a serious impact: it can be abused by attackers to escalate privileges or, more commonly, bypass driver signature enforcement—without the complexity of using a more expensive zero-day kernel exploit in the OS itself.

Computer manufacturers usually ship devices with software and tools that facilitate device management. These software and tools, including drivers, often contain components that run with ring-0 privileges in the kernel. With these components installed by default, each must be as secure as the kernel; even one flawed component could become the Achilles’ heel of the whole kernel security design.

We discovered such a driver while investigating an alert raised by Microsoft Defender Advanced Threat Protection’s kernel sensors. We traced the anomalous behavior to a device management driver developed by Huawei. Digging deeper, we found a lapse in the design that led to a vulnerability that could allow local privilege escalation.

We reported the vulnerability (assigned to CVE-2019-5241) to Huawei, who responded and cooperated quickly and professionally. On January 9, 2019, Huawei released a fix. In this blog post, we’d like to share our journey from investigating one Microsoft Defender ATP alert to discovering a vulnerability, cooperating with the vendor, and protecting customers.

Detecting kernel-initiated code injections with Microsoft Defender ATP

Starting in Windows 10, version 1809, the kernel has been instrumented with new sensors designed to trace User APC code injection initiated by a kernel code, providing better visibility into kernel threats like DOUBLEPULSAR. As described in our in-depth analysis, DOUBLEPULSAR is a kernel backdoor used by the WannaCry ransomware to inject the main payload into user-space. DOUBLEPULSAR copied the user payload from the kernel into an executable memory region in lsass.exe and inserted a User APC to a victim thread with NormalRoutine targeting this region.

Figure 1. WannaCry user APC injection technique schematic diagram

While the User APC code injection technique isn’t novel (see Conficker or Valerino’s earliest proof-of-concept), detecting threats running in the kernel is not trivial. Since PatchGuard was introduced, hooking NTOSKRNL is no longer allowed; there’s no documented way drivers could get notification for any of the above operations. Hence, without proper optics, the only sustainable strategy would be applying memory forensics, which can be complicated.

The new set of kernel sensors aim to address this kind of kernel threat. Microsoft Defender ATP leverages these sensors to detect suspicious operations invoked by a kernel code that might lead to code injection into user-mode. One such suspicious operation triggered this investigation.

Investigating an anomalous code injection from the kernel

While monitoring alerts related to kernel-mode attacks, one alert drew our attention:

Figure 2. Microsoft Defender ATP kernel-initiating code injection alert

The alert process tree showed an abnormal memory allocation and execution in the context of services.exe by a kernel code. Investigating further, we found that an identical alert was fired on another machine around the same time.

To get a better understanding of the observed anomaly, we looked at the raw signals we got from the kernel sensors. This analysis yielded the following findings:

A system thread called nt!NtAllocateVirtualMemory allocated a single page (size = 0x1000) with PAGE_EXECUTE_READWRITE protection mask in services.exe address space

The system thread then called nt!KeInsertQueueApc to queue user APC to a services.exe arbitrary thread with NormalRoutine pointing to the beginning of the executable page and NormalContext pointing to offset 0x800

The payload copied from kernel mode is divided into two portions: a shellcode (NormalRoutine) and a parameter block (NormalContext). At this point, the overall behavior looked suspicious enough for us to proceed with the hunting. Our goal was to incriminate the kernel code that triggered the alert. Incriminating the source

In user-mode threats, the caller process context could shed light on the actor and link to other phases in the attack chain. In contrast, with kernel-mode threats, the story is more complicated. The kernel by nature is asynchronous; callbacks might be called in an arbitrary context, making process context meaningless for forensics purposes.

Therefore, we tried to find an indirect evidence to third-party code loaded into the kernel. By inspecting the machine timeline, we found that several third-party drivers were loaded earlier that day. We concluded based on their file path that they are all related to an app from Huawei called PC Manager, a device management software for Huawei MateBook laptops. The installer is available on Huawei website, so we downloaded it for inspection. For each Huawei driver we used dumpbin.exe to examine imported functions.

And then we had a hit:

Figure 3. dumpbin utility used to detect user APC injection primitives

HwOs2Ec10x64.sys: Unexpected behavior from a driver

Hunting led us to the kernel code that triggered the alert. One would expect that a device management software would perform mostly hardware-related tasks, with the supplied device drivers being the communication layer with the OEM-specific hardware. So why was this driver exhibiting unusual behavior? To answer this question, we reverse-engineered HwOs2Ec10x64.sys.

Our entry point was the function implementing the user APC injection. We found a code path that:

allocates RWX page in some target process;

resolves CreateProcessW and CloseHandle function pointers in the address space of the target process;

copies a code area from the driver as well as what seemed to be a parameter block to the allocated page; and

performs User APC injection targeting that page

The parameter block contains both the resolved function pointers as well as a string, which was found to be a command line.

Figure 4. User APC injection code

The APC normal routine is a shellcode which calls CreateProcessW with the given process command line string. This implied that the purpose of the code injection to services.exe is to spawn a child process.

Figure 5. User shellcode performing process creation

Inspecting the xrefs, we noticed that the injection code originated from a create-process notify routine when Create = FALSE. Hence, the trigger was some process termination.

But what command does the shellcode execute? Attaching a kernel debugger and setting a breakpoint on the memcpy_s in charge of copying the parameters from kernel to user-mode revealed the created process: one of Huawei’s installed services, MateBookService.exe, invoked with “/startup” in its command line.

Figure 6. Breakpoint hit on the call to memcpy_s copying shellcode parameters

Why would a valid service be started that way? Inspecting MateBookService.exe!main revealed a “startup mode” that revived the service if it’s stopped – some sort of watchdog mechanism meant to keep the Huawei PC Manager main service running.

Figure 7. MateBookService.exe /startup code path

At this point of the investigation, the only missing piece in the puzzle was making sure the terminated process triggering the injection is indeed MateBookService.exe.

Figure 8. Validating terminated process identity

The code path that decides whether to inject to services.exe uses a global list of watched process names. Hitting a breakpoint in the iteration loop revealed which process was registered: it was MateBookService.exe, as expected, and it was the only process on that list.

Figure 9. Breakpoint hit during process name comparison against global list

HwOs2Ec10x64.sys also provided process protection against external tampering. Any attempt to force MateBookService.exe termination would fail with Access Denied.

Abusing HwOs2Ec10x64.sys process watch mechanism

The next step in our investigation was to determine whether an attacker can tamper with the global watched process list. We came across an IOCTL handler that added an entry to that list. MateBookService.exe process likely uses this IOCTL to register itself when the service starts. This IOCTL is sent to the driver control device, created from its DriverEntry.

Figure 10. HwOs2Ec10x64.sys control device creation with IoCreateDevice

Since the device object is created with IoCreateDevice, Everyone has RW access to it. Another important observation was that this device isn’t exclusive, hence multiple handles could be opened to it.

Nevertheless, when we tried to open a handle to the device \.HwOs2EcX64, it failed with Last Error = 537, “Application verifier has found an error in the current process”. The driver was rejecting our request to open the device. How is access enforced? It must be on the CreateFile path; in other words, in HwOs2Ec10x64.sys IRP_MJ_CREATE dispatch routine.

Figure 11. IRP_MJ_CREATE dispatch routine

This function validates the calling process by making sure that the main executable path belongs to a whitelist (e.g., C:Program FilesHuaweiPCManagerMateBookService.exe). This simple check on the initiating process name, however, doesn’t guarantee the integrity of the calling process. An attacker-controlled instance of MateBookService.exe will still be granted access to the device \.HwOs2EcX64 and be able to call some of its IRP functions. Then, the attacker-controlled process could abuse this capability to talk with the device to register a watched executable of its own choice. Given the fact that a parent process has full permissions over its children, even a code with low privileges might spawn an infected MateBookService.exe and inject code into it. In our proof-of-concept, we used process hollowing.

Figure 12. Procmon utility results showing POC process start/exit & IL

Because watched processes are blindly launched by the watchdog when they’re terminated, the attacker-controlled executable would be invoked as a child of services.exe, running as LocalSystem, hence with elevated privileges.

Figure 13. Procexp utility process-tree view showing LPE_POC running as LocalSystem

Responsible disclosure and protecting customers

Once we had a working POC demonstrating the elevation of privilege from a low-integrity attacker-controlled process, we responsibly reported the bug to Huawei through the Microsoft Security Vulnerability Research (MSVR) program. The vulnerability was assigned CVE-2019-5241. Meanwhile, we kept our customers safe by building a detection mechanism that would raise an alert for any successful privilege escalation exploiting the HwOs2Ec10x64.sys watchdog vulnerability as we described.

Figure 14. Microsoft Defender ATP alerting on the privilege escalation POC code

Abusing a second IOCTL handler

Having been able to freely invoke IOCTL handlers of the driver from user-mode, we looked for other capabilities that can be abused. We found one: the driver provided a capability to map any physical page into user-mode with RW permissions. Invoking this handler allowed a code running with low privileges to read-write beyond the process boundaries—to other processes or even to kernel space. This, of course, means a full machine compromise.

We also worked with Huawei to fix this second vulnerability, which was assigned CVE-2019-5242. Huawei addressed the flaw in the same security advisory.

We presented our research at the Blue Hat IL Conference in February. Watch the video recording here, and get the slide deck here.

Summary

The two vulnerabilities we discovered in a driver prove the importance of designing software and products with security in mind. Security boundaries must be honored. Attack surface should be minimized as much as possible. In this case, the flaws could have been prevented if certain precautions were taken:

The device object created by the driver should be created with a DACL granting SYSTEM RW access (since only the vendor’s services were communicating directly with the driver)

If a service should persist, developers should check that it’s not already provided by the OS before trying to implement a complex mechanism

User-mode shouldn’t be allowed to perform privileged operations like writing to any physical page; if needed, the driver should do the actual writing for well-defined, hardware-related scenarios

Microsoft’s driver security checklist provides some guidelines for driver developers to help reduce the risk of drivers being compromised.

Our discovery of the driver vulnerabilities also highlights the strength of Microsoft Defender ATP’s sensors. These sensors expose anomalous behavior and give SecOps personnel the intelligence and tools to investigate threats, as we did.

Anomalous behaviors typically point to attack techniques perpetrated by adversaries with only malicious intent. In this case, they pointed to a flawed design that can be abused. Nevertheless, Microsoft Defender ATP exposed a security flaw and protected customers before it can even be used in actual attacks.

Not yet reaping the benefits of Microsoft Defender ATP’s industry-leading optics and detection capabilities? Sign up for free trial today.

Amit Rapaport (@realAmitRap) Microsoft Defender Research team

The post From alert to driver vulnerability: Microsoft Defender ATP investigation unearths privilege escalation flaw appeared first on Microsoft Security.

#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Go to Source Author: Eric Avena From alert to driver vulnerability: Microsoft Defender ATP investigation unearths privilege escalation flaw Original Post from Microsoft Secure Author: Eric Avena With Microsoft continuously improving kernel mitigations and raising the bar for exploiting native kernel components, third-party kernel drivers are becoming a more appealing target for attackers and an important area of research for security analysts.

#Microsoft Security

0 notes