Cedric Cochin – McAfee Blogs https://www.mcafee.com/blogs Securing Tomorrow. Today. Tue, 11 Feb 2020 15:40:35 +0000 en-US hourly 1 https://wordpress.org/?v=5.4.1 https://www.mcafee.com/wp-content/uploads/2018/11/cropped-favicon-32x32.png Cedric Cochin – McAfee Blogs https://www.mcafee.com/blogs 32 32 Knock, Knock – Who’s There? https://www.mcafee.com/blogs/other-blogs/mcafee-labs/knock-knock-whos-there/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/knock-knock-whos-there/#respond Tue, 11 Feb 2020 15:40:35 +0000 /blogs/?p=98542

A Windows Linux Subsystem Interop Analysis Following our research from Evil Twins and Windows Linux Subsystem, interoperability between different WSL versions was something that caught our attention. The protocol and mechanism to do file management from/to WSL is a must for Blue and Red Teams whose research will provide new ways to execute known techniques […]

The post Knock, Knock – Who’s There? appeared first on McAfee Blogs.

]]>

A Windows Linux Subsystem Interop Analysis

Following our research from Evil Twins and Windows Linux Subsystem, interoperability between different WSL versions was something that caught our attention. The protocol and mechanism to do file management from/to WSL is a must for Blue and Red Teams whose research will provide new ways to execute known techniques to achieve tactics such as Persistence, Defense Evasion and Execution, among others.

It is important (even if not seen today in regular arsenals) to understand how to protect, detect and react to this attack surface which could be widely spread in the future where WSL could be a de-facto component in every Enterprise machine.

Since Windows 10 version 1903, it is possible to access Linux files from Windows by using the \wsl$[DistroName] path syntax using 9P protocol. During our research, we found some design issues in WSLv1 that were propagated to WSLv2 — even though the core component differs. The main issue involves the lack of security control in the WSL communication object, leading to any user owning the instance to own the listening Planet 9 File System server. At first sight, this may look obvious, but once you control that communication, different ways of using the data being sent back and forth from Windows to the container begin to emerge.

It is important to mention that when running inside an isolated environment like WSLV2, certain activities not crossing boundaries may remain hidden for security products, but once an attempt to execute a malicious app on the Windows side is detected, the scanning mechanism provided by MVISION Endpoint and ENS will trigger to protect. MVISION EDR will provide visibility and detection on some of these artifacts. At the end of this article, we present certain objects to monitor to detect such cases in your organization.

Potential usages for Red Teams and  Researchers:

  • Persistence by hiding the real content, especially on WSLv2 where the root folder is a VHDX image.
  • Protocol fuzzing for discovering vulnerabilities on the implementation.
  • Security bypass by using \\wsl$ syntax in applications that have options to disable Network Folders scan and thus, do not consider this as a local path. (McAfee MVision Endpoint will consider this special path).
  • File tampering (the user accesses a file expecting some content, but it is changed during the transfer).

P9 Server Hijack Pre-Requisites:

  • WSL Enabled
  • Same user privileges as the WSL instance
  • A P9 compatible server

In the following section P9 (Planet 9 File System Protocol) and 9P (the protocol) are used interchangeably

WSLv1 and P9

The communication is done using an AF_UNIX socket (local file) that is currently owned by the user executing the WSL instance. The socket is created by the custom init process. Processes from the Windows side use a p9driver to access that socket by using an implementation of the P9 FileSystem instead of accessing the files as “Windows local”.

Note: Plan 9 has several implementations; currently the format supported by Windows is L / W.

A simple string on init shows that:

  1. The first WSL instance will open the p9 server for that distribution.
  2. Init has an embed server that creates a Unix socket into the distro path.
  3. The Unix socket is used to communicate.
  4. Whenever \\wsl$\ is accessed, P9 driver starts the communication.
  5. A P9 client communicates with the server.

Now, is that fsserver file protected? No! That means that we can hijack that socket and start our P9 server (in this case, I used DIOD as the main source) and from there… the options are endless from protocol fuzzers to trigger something unexpected, to protection bypass, to something very simple that just serves different content than expected.

To find programmatically the fsserver root location using PowerShell:

From there, the next step would be to start our p9 server from WSL (assuming the path was provided as the script argument as shown above):

In this example, next time we access \\wsl$\Debian, it will serve the files from mynewroot.

The below screenshot shows the full procedure using a modified P9 server:

  1. DIOD listening on the local socket.
  2. WSL directory listing before the hijack.
  3. WSL directory listing after the hijack.

At the time we were working on this, WSLv2 was announced and available in the latest Win10 Update. The next question was obvious—can we still do the same, given that the instance is now hosting a real kernel due to its nature of being hosted as a Hyper-V internal instance?

WSLv2 and P9

Now that there is a Linux Kernel the real “p9 Linux” module is activated. C: drive is mounted using P9 with several rdfd/wdfd arguments on top of drvfs.

The host is at CID:2, and ports  50000/1/2 are used for InterOp Messages and instance control.

Back to work — there are some steps to follow to determine whether we can achieve the same P9 Server Hijack or not.

  • Scan open ports listening on WSLv2 instance (a starting point could be modifying sample client code to became a scanner).
  1. Find the instance UID (an option is to check the task manager and wslhost.exe command line).
  2. Scan the instance!

3. Hey! Port 0x405(1029d) is open, let us Knock-Knock to find who is there.

  • P9 server port found… let us go hijack!!!
    1. Listening to the same port as with WSLv1 is not possible , unless we find a way to bypass the restrictions (app/module not using reuseaddr/port, not possible to close from user-space, etc.).
    2. We cannot kill init nor unload the module serving the files, so our best bet would be to close the port from the kernel. At the end of the day, it is our instance and we login as root .
    3. Let us create a vsock module that will:
      1. List current vsock connected sockets.
      2. Close a socket listening on a certain port.

  1. Compile the module using kernel source.
  2. Test it! (Note that same ports are not present and should be fixed, but for what we want the output is enough).

3)   Now, we are free to go, but still, we need to start our P9 DIODserver listening somehow on that port using a VSOCK socket. Since `socat` supports this type of socket it will be a piece of cake.

  • Access \\wsl$\DistributionName and voila!

Protection and Detection with McAfee Products

In Addition to rules related to WSL presented in previous posts, McAfee products provide several ways to detect and protect against P9 hijacking:

  • MVISION Endpoint will scan \\wsl$\ even if network scanning is disabled, so from the execution perspective on Windows side protection will still apply.
  • By using Endpoint Security Expert Rules it’s possible to block execution from WSL paths.
  • To configure Active Response (WSLv1) follow the below steps:
    • Setup a trigger to be notified of this situation a file fsserver is deleted.
      • File Trigger with condition: Files name equals fsserver”
    • Files collector if enabled, looking for fsserver modifications.
      • “Files where Files name equals fsserver”

In MVISION EDR (WSLv1), the file collector should be enabled and looking for wsl.conf modifications (files where files name equals “fsserver”

As a final note, we expect this post to provide new insights about the future exploration of these key areas, mostly considering that WSLv1 and WSLv2 can be converted online and both versions will be fairly used during the next years.

References:

  1. http://doc.cat-v.org/plan_9/misc/ubiquitous_fileserver/
  2. http://9p.io/magic/man2html/5/intro
  3. https://github.com/chaos/diod/blob/master/protocol.md
  4. https://w4mhi.wordpress.com/complete-hyper-v-socket-client-code/
  5. https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/make-integration-service
  6. https://tyranidslair.blogspot.com/2019/07/digging-into-wsl-p9-file-system.html
  7. https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/using-expert-rules-in-ens-10-5-3-to-prevent-malicious-exploits/
  8. https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/the-twin-journey-part-1/

 

The post Knock, Knock – Who’s There? appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/knock-knock-whos-there/feed/ 0
The Twin Journey, Part 3: I’m Not a Twin, Can’t You See my Whitespace at the End? https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-twin-journey-part-3-im-not-a-twin-cant-you-see-my-whitespace-at-the-end/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-twin-journey-part-3-im-not-a-twin-cant-you-see-my-whitespace-at-the-end/#respond Tue, 13 Aug 2019 14:01:34 +0000 https://securingtomorrow.mcafee.com/?p=96357

In this series of 3 blogs (you can find part 1 here, and part 2 here), so far we have understood the implications of promoting files to “Evil Twins” where they can be created and remain in the system as different entities once case sensitiveness is enabled, and some issues that could be raised by […]

The post The Twin Journey, Part 3: I’m Not a Twin, Can’t You See my Whitespace at the End? appeared first on McAfee Blogs.

]]>

In this series of 3 blogs (you can find part 1 here, and part 2 here), so far we have understood the implications of promoting files to “Evil Twins” where they can be created and remain in the system as different entities once case sensitiveness is enabled, and some issues that could be raised by just basic assumptions on case-sensitiveness during development.

In this 3rd post we focus on the “confusion” technique, where even though the technique is already known (Medium / Tyranidslair), the ramifications of these effects have not all been analyzed yet.

Going back to normalization, some Win32 API’s remove trailing whitespaces (and other special characters) from the path name.

As mentioned in the last publication, the normalization can, in some cases, provide the wrong result.

The common scenario that could be used as “bait” for the user to click, and even to hide what is seen, is to create a directory with the same name ending with a whitespace.

A very trivial example “That’s not my notepad…..”:

Open task manager, Right click on the “notepad” with putty icon -> Properties. (The properties were read from the “non-trailing-space” binary)

Open Explorer on “C:\Windows “; it will generate the illusion that the original files (from the folder without trailing whitespace) are there. This will happen for any folder/file not present in the whitespace version.

Screenshots opening a McAfee Agent Folder:

Both folders opened; note that the whitespace version does not have any .dll or additional .exe but Explorer renders the missing files from the “normalized – non-whitespace directory”.

Trying to open the dll…

Getting properties from task manager will fetch those from the normalized folder path, that means you can be tricked to think it is a trusted app.

Watch the video recorded by our expert Cedric Cochin illustrating this technique:

Related Links / Blogs:

https://tyranidslair.blogspot.com/2019/02/ntfs-case-sensitivity-on-windows.html

https://medium.com/tenable-techblog/uac-bypass-by-mocking-trusted-directories-24a96675f6e

The post The Twin Journey, Part 3: I’m Not a Twin, Can’t You See my Whitespace at the End? appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-twin-journey-part-3-im-not-a-twin-cant-you-see-my-whitespace-at-the-end/feed/ 0
The Twin Journey, Part 2: Evil Twins in a Case In-sensitive Land https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-twin-journey-part-2-evil-twins-in-a-case-in-sensitive-land/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-twin-journey-part-2-evil-twins-in-a-case-in-sensitive-land/#respond Tue, 06 Aug 2019 16:04:38 +0000 https://securingtomorrow.mcafee.com/?p=96304

In the first of this 3-part blog series, we covered the implications of promoting files to “Evil Twins” where they can be created and remain in the system as different entities once case sensitiveness is enabled. In this 2nd post we try to abuse applications that do not work well with CS changes, abusing years […]

The post The Twin Journey, Part 2: Evil Twins in a Case In-sensitive Land appeared first on McAfee Blogs.

]]>

In the first of this 3-part blog series, we covered the implications of promoting files to “Evil Twins” where they can be created and remain in the system as different entities once case sensitiveness is enabled.

In this 2nd post we try to abuse applications that do not work well with CS changes, abusing years of “normalization” assumptions.

It is worth noting that the impact of this change will vary depending on the target folder.

Out of the box, Windows provides a tool to change CS information by invoking the underlying API NtSetFileInformation with FILE_CASE_SENSITIVE_INFORMATION flags.

This tool contains several checks at user-mode level to restrict the target folder but, as usual, it can be easily bypassed using different path combinations. It is possible to create a tool or invoke the API from PowerShell to remove these checks.

Let us go over the following scenarios:

  • Changing ROOT drive CS:
    1. fsutil restrictions will be bypassed and most of the console will not work unless you specify full paths (mostly due to environment variables broken on case-sensitiveness).

  • Combinations to bypass this check include:
    • \\?\C:\ (by drive letter with long path)
    • \\.\BootPartition\\  (by partition)
    • \\?\Volume{3fb4edf7-edf1-4083-84f8-7fbca215bfee}\ (volume id)
  • Change “protected folders” CS.
    1. For some folders is not enough to be Administrator, but to have other type of ACL’s instead.
    2. TrustedInstaller has the required permissions to do so and… you just need Admin permissions to change the service path:

If you change Windows folder case sensitiveness by using the same technique, Windows will not boot anymore.

These scenarios introduce new unexpected behaviors in the current applications, like for instance:

  • There is a folder with CS enabled and two directories with the same name, different case.
  • Trying to change CS will fail due to “multiple files/folders with the same name already exists” check.
  • Move to recycle bin on one of the folders.
  • Change CS of the folder.
  • Restore the deleted file.
  • The contents of the deleted file overwrite the one originally kept.

Screenshots

Left: Root drive with case sensitive enabled.

Right: Program Files CS changed thanks to Trusted Installer ACL. If an application is not considering the proper case, next time it tries to execute a binary whose name may be normalized (to uppercase) it can spawn a different app.

Watch the video recorded by our expert Cedric Cochin illustrating this technique:

Protection and Detection with McAfee Products

  • Products that rely on SysCore will protect C:\ from case sensitive changes
  • Endpoint Security Expert Rules
  • Active Response:
    • Create a custom collector to query Case sensitiveness of important folders.
    • Search for fsutil executions (or even History Processes if that collector is part of your Active Response version)
      • “Processes where Processes name equals fsutil.exe”
    • MVISION EDR:
      • Realtime search
        • “Processes where Processes name equals fsutil.exe”
      • Search for fsutil execution in the historical view

Artifacts involved:

  • NT attributes change
  • Fsutil execution
  • Trusted Installer service changes

Outcomes for this technique include:

  • A ransomware could create C:\Windows\SYSTEM32 and cause a BSOD on next restart
  • Change dll being loaded or an event stops application from starting

The post The Twin Journey, Part 2: Evil Twins in a Case In-sensitive Land appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-twin-journey-part-2-evil-twins-in-a-case-in-sensitive-land/feed/ 0
The Twin Journey, Part 1 https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-twin-journey-part-1/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-twin-journey-part-1/#respond Wed, 31 Jul 2019 16:39:48 +0000 https://securingtomorrow.mcafee.com/?p=96153

Summary and Introduction: The recent changes in Windows 10, aiming to add case sensitivity (CS) at directory level, have prompted our curiosity to investigate the potential to use CS as a mean of obfuscation or WYSINWYG (What You See is NOT What you Get). While CS was our entry point, we then ventured into other […]

The post The Twin Journey, Part 1 appeared first on McAfee Blogs.

]]>

Summary and Introduction:

The recent changes in Windows 10, aiming to add case sensitivity (CS) at directory level, have prompted our curiosity to investigate the potential to use CS as a mean of obfuscation or WYSINWYG (What You See is NOT What you Get). While CS was our entry point, we then ventured into other file naming techniques to achieve similar outcomes.

Threats and Red Teams may include these techniques in their arsenal to execute various versions of persistence tricks, scan avoidance, security bypass or, in extreme cases, make the system totally unusable.

As part of this blog we use the term “Evil Twins” to describe a scenario where 2 files on disk are crafted using specific file naming techniques to confuse security mechanisms, leading to the good twin being scrutinized while the evil twin flies under the radar.

This is part of a series that will explore each of the different scenarios and techniques we researched.

Evil Twins and WSL (Windows Sub-System for Linux) to the Rescue

Windows Linux Subsystem introduces a set of new cool features and provides interoperability between Linux & Windows, including the ability to execute ELF files.

Some time ago, case sensitiveness was enabled by default when using DRVFS, the file system driver that allows to mount Windows drives. (C:\\, D:\\) from a WSL instance.

After some internal releases it was removed, and case-sensitiveness did change over time in terms of CS inheritance, including the restriction to change sensitiveness of folders that already have “twins”.

The following technique relies on the ability to mount DRVFS with case=force that will literally override any case-sensitiveness set for any directory.

Any attacker that has admin rights and wants to achieve any of the following goals can rely on this approach to:

  • Persist & Hide files
  • Make the OS unusable
  • Stop many products from starting (even if they have other kinds of protection).
  • Alter dlls loaded to control the applications.

This scenario is based on the premise that WSL and a Linux distribution are installed. In case those requirements are not met, scripts that automate that process, or even importing your custom distribution.

For complex scenarios where installing WSL & importing a distribution is required, even although it’s possible to di programmatically for any adversary and even remove WSL, it will still be very noisy in terms of suspicious activities whether the workstation does not belong to a developer for instance. As time goes on, many companies that have Linux development will include WSL as part of the daily basics for developer workstations, servers, etc.

The execution steps would include something like:

  1. Enable WSL
  2. Check if a distribution is already installed / Install it if missing
  3. Look for LXSS and enable DRVFS force flag
  4. Depending on how the twin will be created you can do several things:
    1. Create a WSL conf file with automount options. This is optional since you can remount the /mnt/c folder with new options.
    2. Copy files from the rootfs folder in Windows to preserve permissions (read/execute/etc.) without messing with ACL’s on the Linux side.
      1. Approach #1: Create the proper files without starting bash until the end (only touching Windows files): Ex: One of the scripts just copies the environment file and, if it is empty, it adds some content, so it is executed from bashrc next time bash is launched.
      2. Approach #2: Create the proper files from bash itself, so you do not need to mess with permissions (this will depend on how systems will be alerted by detecting bash execution, etc.)
    3. Terminate WSL instances.
    4. Start bash (by using a task, autorun, or just as part of the PowerShell script)
      1. From here you can just execute commands on the POC example, depending on the script arguments; the commands to be executed are of /etc/bashrc file.
      2. VOILA, the script will create a folder or copy the twin dll in a non-cs enabled folder, thus promoting the twin as the file to look for next time.

Sample script:

Executing the technique to implant an Evil Twin dll: (replacing IEPROXY.dll for a mock that will just change the background)

The IEPROXY.DLL implant taking effect😊

Watch the video recorded by our expert Cedric Cochin, illustrating the entire technique:

Outcomes for this technique include:

  • A piece of ransomware creating C:\Windows\SYSTEM32 twin folder and not allowing a normal boot.
  • A targeted attack could create a IEPROXY.DLL so next time any application loads the dll it will load the compromised dll.
  • A targeted attack could create a C:\Program Files\[FAVORITE VENDOR] to disable such application, if the application is not CS aware/compatible

Protection and Detection with McAfee Products:

  • By using Endpoint Security Expert Rules, the registry key required to execute the entire workflow can be protected.
  • Active Response:
    • Setup a trigger to be notified of this situation whenever this registry key or a file is modified
      • File Trigger with condition: Files name equals wsl.conf”
      • Registry Trigger with condition: WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss
    • Custom collector: PowerShell Script that can find duplicated names in a folder. (Scanning the entire disk may take longer that search timeout)
    • Files collector if enabled, looking for wsl.conf modifications.
      • “Files where Files name equals wsl.conf”
    • WinRegistry Collector :
      • “WinRegistry where WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss”
  • MVISION EDR:
    • File collector if enabled, looking for wsl.conf modifications.
      • “Files where Files name equals wsl.conf”
    • WinRegistry Collector:
      • “WinRegistry where WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss”

  • Historical search activity

Artifacts involved:

  • Modification of HKLM:\System\CurrentControlSet\Services\lxss\DrvFsAllowForceCaseSensitivity
  • Bash execution
  • Creation of new folder / dll (twin)
  • Optional:
    • Creation of /etc/wsl.conf ( Can be tracked from Windows rootfs folder)
    • Wslconfig /t execution to terminate instances
    • Installation / Download of Linux distribution or tar file import
    • WSL enabled

The post The Twin Journey, Part 1 appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-twin-journey-part-1/feed/ 0
In NTDLL I Trust – Process Reimaging and Endpoint Security Solution Bypass https://www.mcafee.com/blogs/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/#respond Thu, 20 Jun 2019 16:00:14 +0000 https://securingtomorrow.mcafee.com/?p=95608

Process Reimaging Overview The Windows Operating System has inconsistencies in how it determines process image FILE_OBJECT locations, which impacts non-EDR (Endpoint Detection and Response) Endpoint Security Solution’s (such as Microsoft Defender Realtime Protection), ability to detect the correct binaries loaded in malicious processes. This inconsistency has led McAfee’s Advanced Threat Research to develop a new […]

The post In NTDLL I Trust – Process Reimaging and Endpoint Security Solution Bypass appeared first on McAfee Blogs.

]]>

Process Reimaging Overview

The Windows Operating System has inconsistencies in how it determines process image FILE_OBJECT locations, which impacts non-EDR (Endpoint Detection and Response) Endpoint Security Solution’s (such as Microsoft Defender Realtime Protection), ability to detect the correct binaries loaded in malicious processes. This inconsistency has led McAfee’s Advanced Threat Research to develop a new post-exploitation evasion technique we call “Process Reimaging”. This technique is equivalent in impact to Process Hollowing or Process Doppelganging within the Mitre Attack Defense Evasion Category; however, it is , much easier to execute as it requires no code injection. While this bypass has been successfully tested against current versions of Microsoft Windows and Defender, it is highly likely that the bypass will work on any endpoint security vendor or product implementing the APIs discussed below.

The Windows Kernel, ntoskrnl.exe, exposes functionality through NTDLL.dll APIs to support User-mode components such as Endpoint Security Solution (ESS) services and processes. One such API is K32GetProcessImageFileName, which allows ESSs to verify a process attribute to determine whether it contains malicious binaries and whether it can be trusted to call into its infrastructure. The Windows Kernel APIs return stale and inconsistent FILE_OBJECT paths, which enable an adversary to bypass Windows operating system process attribute verification. We have developed a proof-of-concept which exploits this FILE_OBJECT location inconsistency by hiding the physical location of a process EXE.

The PoC allowed us to persist a malicious process (post exploitation) which does not get detected by Windows Defender.

The Process Reimaging technique cannot be detected by Windows Defender until it has a signature for the malicious file and blocks it on disk before process creation or performs a full scan on suspect machine post compromise to detect file on disk. In addition to Process Reimaging Weaponization and Protection recommendations, this blog includes a technical deep dive on reversing the Windows Kernel APIs for process attribute verification and Process Reimaging attack vectors. We use the SynAck Ransomware as a case study to illustrate Process Reimaging impact relative to Process Hollowing and Doppelganging; this illustration does not relate to Windows Defender ability to detect Process Hollowing or Doppelganging but the subverting of trust for process attribute verification.

Antivirus Scanner Detection Points

When an Antivirus scanner is active on a system, it will protect against infection by detecting running code which contains malicious content, and by detecting a malicious file at write time or load time.

The actual sequence for loading an image is as follows:

  • FileCreate – the file is opened to be able to be mapped into memory.
  • Section Create – the file is mapped into memory.
  • Cleanup – the file handle is closed, leaving a kernel object which is used for PAGING_IO.
  • ImageLoad – the file is loaded.
  • CloseFile – the file is closed.

If the Antivirus scanner is active at the point of load, it can use any one of the above steps (1,2 and 4) to protect the operating system against malicious code. If the virus scanner is not active when the image is loaded, or it does not contain definitions for the loaded file, it can query the operating system for information about which files make up the process and scan those files. Process Reimaging is a mechanism which circumvents virus scanning at step 4, or when the virus scanner either misses the launch of a process or has inadequate virus definitions at the point of loading.

There is currently no documented method to securely identify the underlying file associated with a running process on windows.

This is due to Windows’ inability to retrieve the correct image filepath from the NTDLL APIs.  This can be shown to evade Defender (MpMsEng.exe/MpEngine.dll) where the file being executed is a “Potentially Unwanted Program” such as mimikatz.exe. If Defender is enabled during the launch of mimikatz, it detects at phase 1 or 2 correctly.  If Defender is not enabled, or if the launched program is not recognized by its current signature files, then the file is allowed to launch. Once Defender is enabled, or the signatures are updated to include detection, then Defender uses K32GetProcessImageFileName to identify the underlying file. If the process has been created using our Process Reimaging technique, then the running malware is no longer detected. Therefore, any security service auditing running programs will fail to identify the files associated with the running process.

Subverting Trust

The Mitre ATT&CK model specifies post-exploitation tactics and techniques used by adversaries, based on real-world observations for Windows, Linux and macOS Endpoints per figure 1 below.

Figure 1 – Mitre Enterprise ATT&CK

Once an adversary gains code execution on an endpoint, before lateral movement, they will seek to gain persistence, privilege escalation and defense evasion capabilities. They can achieve defense evasion using process manipulation techniques to get code executing in a trusted process. Process manipulation techniques have existed for a long time and evolved from Process Injection to Hollowing and Doppelganging with the objective of impersonating trusted processes. There are other Process manipulation techniques as documented by Mitre ATT&CK and Unprotect Project,  but we will focus on Process Hollowing and Process Doppelganging. Process manipulation techniques exploit legitimate features of the Windows Operating System to impersonate trusted process executable binaries and generally require code injection.

ESSs place inherent trust in the Windows Operating System for capabilities such as digital signature validation and process attribute verification. As demonstrated by Specter Ops, ESSs’ trust in the Windows Operating system could be subverted for digital signature validation.

Similarly, Process Reimaging subverts an ESSs’ trust in the Windows Operating System for process attribute verification.

When a process is trusted by an ESS, it is perceived to contain no malicious code and may also be trusted to call into the ESS trusted infrastructure.

McAfee ATR uses the Mitre ATT&CK framework to map adversarial techniques, such as defense evasion, with associated campaigns. This insight helps organizations understand adversaries’ behavior and evolution so that they can assess their security posture and respond appropriately to contain and eradicate attacks. McAfee ATR creates and shares Yara rules based on threat analysis to be consumed for protect and detect capabilities.

Process Manipulation Techniques (SynAck Ransomware)

McAfee Advanced Threat Research analyzed SynAck ransomware in 2018 and discovered it used Process Doppelganging with Process Hollowing as its fallback defense evasion technique. We use this malware to explain the Process Hollowing and Process Doppelganging techniques, so that they can be compared to Process Reimaging based on a real-world observation.

Process Manipulation defense evasion techniques continue to evolve. Process Doppelganging was publicly announced in 2017, requiring advancements in ESSs for protection and detection capabilities. Because process manipulation techniques generally exploit legitimate features of the Windows Operating system they can be difficult to defend against if the Antivirus scanner does not block prior to process launch.

Process Hollowing

Process hollowing occurs when a process is created in a suspended state then its memory is unmapped and replaced with malicious code. Execution of the malicious code is masked under a legitimate process and may evade defenses and detection analysis” (see figure 2 below)

Figure 2 – SynAck Ransomware Defense Evasion with Process Hollowing

Process Doppelganging

Process Doppelgänging involves replacing the memory of a legitimate process, enabling the veiled execution of malicious code that may evade defenses and detection. Process Doppelgänging’s use of Windows Transactional NTFS (TxF) also avoids the use of highly-monitored API functions such as NtUnmapViewOfSection, VirtualProtectEx, and SetThreadContext” (see figure 3 below)

Figure 3 – SynAck Ransomware Defense Evasion with Doppleganging

Process Reimaging Weaponization

The Windows Kernel APIs return stale and inconsistent FILE_OBJECT paths which enable an adversary to bypass windows operating system process attribute verification. This allows an adversary to persist a malicious process (post exploitation) by hiding the physical location of a process EXE (see figure 4 below).

Figure 4 – SynAck Ransomware Defense Evasion with Process Reimaging

Process Reimaging Technical Deep Dive

NtQueryInformationProcess retrieves all process information from EPROCESS structure fields in the kernel and NtQueryVirtualMemory retrieves information from the Virtual Address Descriptors (VADs) field in EPROCESS structure.

The EPROCESS structure contains filename and path information at the following fields/offsets (see figure 5 below):

  • +0x3b8 SectionObject (filename and path)
  • +0x448 ImageFilePointer* (filename and path)
  • +0x450 ImageFileName (filename)
  • +0x468 SeAuditProcessCreationInfo (filename and path)

* this field is only present in Windows 10

Figure 5 – Code Complexity IDA Graph Displaying NtQueryInformationProcess Filename APIs within NTDLL

Kernel API NtQueryInformationProcess is consumed by following the kernelbase/NTDLL APIs:

  • K32GetModuleFileNameEx
  • K32GetProcessImageFileName
  • QueryFullProcessImageImageFileName

The VADs hold a pointer to FILE_OBJECT for all mapped images in the process, which contains the filename and filepath (see figure 6 below).

Kernel API NtQueryVirtualMemory is consumed by following the kernelbase/NTDLL API:

  • GetMappedFileName

Figure 6 – Code Complexity IDA Graph Displaying NtQueryVirtualMemory Filename API within NTDLL

Windows fails to update any of the above kernel structure fields when a FILE_OBJECT filepath is modified post-process creation. Windows does update FILE_OBJECT filename changes, for some of the above fields.

The VADs reflect any filename change for a loaded image after process creation, but they don’t reflect any rename of the filepath.

The EPROCESS fields also fail to reflect any renaming of the process filepath and only the ImageFilePointer field reflects a filename change.

As a result, the APIs exported by NtQueryInformationProcess and NtQueryVirtualMemory return incorrect process image file information when called by ESSs or other Applications (see Table 1 below).

Table 1 OS/Kernel version and API Matrix

Prerequisites for all Attack Vectors

Process Reimaging targets the post-exploitation phase, whereby a threat actor has already gained access to the target system. This is the same prerequisite of Process Hollowing or Doppelganging techniques within the Defense Evasion category of the Mitre ATT&CK framework.

Process Reimaging Attack Vectors
FILE_OBJECT Filepath Changes

Simply renaming the filepath of an executing process results in Windows OS returning the incorrect image location information for all APIs (See figure 7 below).  This impacts all Windows OS versions at the time of testing.

Figure 7 FILE_OBJECT Filepath Changes – Filepath Changes Impact all Windows OS versions

FILE_OBJECT Filename Changes

Filename Change >= Windows 10

Simply renaming the filename of an executing process results in Windows OS returning the incorrect image information for K32GetProcessImageFileName API (See figure 8.1.1 below). This has been confirmed to impact Windows 10 only.

Figure 8.1.1 FILE_OBJECT Filename Changes – Filename Changes impact Windows >= Windows 10

Per figure 8.1.2 below, GetModuleFileNameEx and QueryFullProcessImageImageFileName will get the correct filename changes due to a new EPROCESS field ImageFilePointer at offset 448.  The instruction there (mov r12, [rbx+448h]) references the ImageFilePointer from offset 448 into the EPROCESS structure.

Figure 8.1.2 NtQueryInformationProcess (Windows 10) – Windows 10 RS1 x64 ntoskrnl version 10.0.14393.0

Filename Change < Windows 10

Simply renaming the filename of an executing process results in Windows OS returning the incorrect image information for K32GetProcessImageFileName, GetModuleFileNameEx and QueryFullProcessImageImageFileName APIs (See figure 8.2.1 below). This has been confirmed to impact Windows 7 and Windows 8.

Figure 8.2.1 FILE_OBJECT Filename Changes – Filename Changes Impact Windows < Windows 10

Per Figure8.2.2 below, GetModuleFileNameEx and QueryFullProcessImageImageFileName will get the incorrect filename (PsReferenceProcessFilePointer references EPROCESS offset 0x3b8 SectionObject).

Figure 8.2.2 NtQueryInformationProcess (Windows 7 and 8) – Windows 7 SP1 x64 ntoskrnl version 6.1.7601.17514

LoadLibrary FILE_OBJECT reuse

LoadLibrary FILE_OBJECT reuse leverages the fact that when a LoadLibrary or CreateProcess is called after a LoadLibrary and FreeLibrary on an EXE or DLL, the process reuses the existing image FILE_OBJECT in memory from the prior LoadLibrary.

Exact Sequence is:

  1. LoadLibrary (path\filename)
  2. FreeLibrary (path\filename)
  3. LoadLibrary (renamed path\filename) or CreateProcess (renamed path\filename)

This results in Windows creating a VAD entry in the process at step 3 above, which reuses the same FILE_OBJECT still in process memory, created from step 1 above. The VAD now has incorrect filepath information for the file on disk and therefore the GetMappedFileName API will return the incorrect location on disk for the image in question.

The following prerequisites are required to evade detection successfully:

  • The LoadLibrary or CreateProcess must use the exact same file on disk as the initial LoadLibrary
  • Filepath must be renamed (dropping the same file into a newly created path will not work)

The Process Reimaging technique can be used in two ways with LoadLibrary FILE_OBJECT reuse attack vector:

  1. LoadLibrary (see figure 9 below)
    1. When an ESS or Application calls the GetMappedFileName API to retrieve a memory-mapped image file, Process Reimaging will cause Windows OS to return the incorrect path. This impacts all Windows OS versions at the time of testing.

Figure 9 LoadLibrary FILE_OBJECT Reuse (LoadLibrary) – Process Reimaging Technique Using LoadLibrary Impacts all Windows OS Versions

2. CreateProcess (See figure 10 below)

    1. When an ESS or Application calls the GetMappedFileName API to retrieve the process image file, Process Reimaging will cause Windows OS to return the incorrect path. This impacts all Windows OS versions at the time of testing.

Figure 10 LoadLibrary FILE_OBJECT Reuse (CreateProcess) – Process Reimaging Technique using CreateProcess Impacts all Windows OS Versions

Process Manipulation Techniques Comparison

Windows Defender Process Reimaging Filepath Bypass Demo

This video simulates a zero-day malware being dropped (Mimikatz PUP sample) to disk and executed as the malicious process “phase1.exe”. Using the Process Reimaging Filepath attack vector we demonstrate that even if Defender is updated with a signature for the malware on disk it will not detect the running malicious process. Therefore, for non-EDR ESSs such as Defender Real-time Protection (used by Consumers and also Enterprises) the malicious process can dwell on a windows machine until a reboot or the machine receives a full scan post signature update.

CVSS and Protection Recommendations

CVSS

If a product uses any of the APIs listed in table 1 for the following use cases, then it is likely vulnerable:

  1. Process reputation of a remote process – any product using the APIs to determine if executing code is from a malicious file on disk

CVSS score 5.0 (Medium)  https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N (same score as Doppelganging)

  1. Trust verification of a remote process – any product using the APIs to verify trust of a calling process

CVSS score will be higher than 5.0; scoring specific to Endpoint Security Solution architecture

Protection Recommendations

McAfee Advanced Threat Research submitted Process Reimaging technique to Microsoft on June 5th, 2018. Microsoft released a partial mitigation to Defender in the June 2019 Cumulative update for the Process Reimaging FILE_OBJECT filename changes attack vector only. This update was only for Windows 10 and does not address the vulnerable APIs in Table 1 at the OS level; therefore, ESSs are still vulnerable to Process Reimaging. Defender also remains vulnerable to the FILE_OBJECT filepath changes attack vector executed in the bypass demo video, and this attack vector affects all Windows OS versions.

New and existing Process Manipulation techniques which abuse legitimate Operating System features for defense evasion are difficult to prevent dynamically by monitoring specific API calls as it can lead to false positives such as preventing legitimate processes from executing.

A process which has been manipulated by Process Reimaging will be trusted by the ESS unless it has been traced by EDR or a memory scan which may provide deeper insight.

Mitigations recommended to Microsoft
  1. File System Synchronization (EPROCESS structures out of sync with the filesystem or File Control Block structure (FCB)
    1. Allow the EPROCESS structure fields to reflect filepath changes as is currently implemented for the filename in the VADs and EPROCESS ImageFilePointer fields.
    2. There are other EPROCESS fields which do not reflect changes to filenames and need to be updated, such as K32GetModuleFileNameEx on Windows 10 through the ImageFilePointer.
  2. API Usage (most returning file info for process creation time)
    1. Defender (MpEngine.dll) currently uses K32GetProcessImageFileName to get process image filename and path when it should be using K32GetModuleFileNameEx.
    2. Consolidate the duplicate APIs being exposed from NtQueryInformationProcess to provide easier management and guidance to consumers that require retrieving process filename information. For example, clearly state GetMappedFileName should only be used for DLLs and not EXE backing process).
    3. Differentiate in API description whether the API is only limited to retrieving the filename and path at process creation or real-time at time of request.
  3. Filepath Locking
    1. Lock filepath and name similar to lock file modification when a process is executing to prevent modification.
    2. Standard user at a minimum should not be able to rename binary paths for its associated executing process.
  4. Reuse of existing FILE_OBJECT with LoadLibrary API (Prevent Process Reimaging)
    1. LoadLibrary should verify any existing FILE_OBJECT it reuses, has the most up to date Filepath at load time.
  5. Short term mitigation is that Defender should at least flag that it found malicious process activity but couldn’t find associated malicious file on disk (right now it fails open, providing no notification as to any potential threats found in memory or disk).
Mitigation recommended to Endpoint Security Vendors

The FILE_OBJECT ID must be tracked from FileCreate as the process closes its handle for the filename by the time the image is loaded at ImageLoad.

This ID must be managed by the Endpoint Security Vendor so that it can be leveraged to determine if a process has been reimaged when performing process attribute verification.

The post In NTDLL I Trust – Process Reimaging and Endpoint Security Solution Bypass appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/feed/ 0
Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253 https://www.mcafee.com/blogs/other-blogs/mcafee-labs/microsoft-cortana-allows-browser-navigation-without-login-cve-2018-8253/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/microsoft-cortana-allows-browser-navigation-without-login-cve-2018-8253/#respond Tue, 14 Aug 2018 17:31:48 +0000 https://securingtomorrow.mcafee.com/?p=90900 A locked Windows 10 device with Cortana enabled on the lock screen allows an attacker with physical access to the device to do two kinds of unauthorized browsing.

The post Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253 appeared first on McAfee Blogs.

]]>
A locked Windows 10 device with Cortana enabled on the lock screen allows an attacker with physical access to the device to do two kinds of unauthorized browsing. In the first case, the attacker can force Microsoft Edge to navigate to an attacker-controlled URL; in the second, the attacker can use a limited version of Internet Explorer 11 using the saved credentials of the victim.

In June we published our analysis of a full login bypass mechanism for all Windows 10 devices for which Cortana is enabled on the lock screen. (This is still the default option.) The discovery of the full login bypass was part of a wider research effort into what access the digital assistant Cortana might offer to an adversary when the device is locked. This post details these two additional issues; we reported them to Microsoft at the same time we reported the login bypass. The two new flaws have now been addressed as part of Microsoft’s August update. Some of the issues are also partially mitigated by modifying the answer obtained from a Bing search query.

In the first scenario, a Cortana privilege escalation leads to forced navigation on a lock screen. The vulnerability does not allow an attacker to unlock the device, but it does allow someone with physical access to force Edge to navigate to a page of the attacker’s choosing while the device is still locked. This is not a case of BadUSB, man in the middle, or rogue Wi-Fi, just simple voice commands and interacting with the device’s touchscreen or mouse.

Several months ago, researchers from Israel demonstrated a similar attack using a BadUSB device, masquerading as a network interface card to inject content into trusted HTTP sites while using Cortana to force navigation. Microsoft has since removed this ability to navigate directly to a domain and instead now opens a search in Bing over HTTPS to the domain in question. Some of our findings could also be combined with a BadUSB approach.

We explored whether one could still force navigation to an attacker-controlled page. In short, yes, one can, but it does take some extra effort.

Cortana is very helpful when it comes to defining terms, or looking up corporations, movies, artists, or athletes. She can even do math. However, Cortana’s behavior and the answers she gives are affected by the way you ask a question. For example, if you were to ask the colloquial question “Hey Cortana, what is McAfee?” you would get a quick answer directly from a Bing search. If, however, you asked only “Hey Cortana, McAfee,” you would receive a more detailed response, including links to various trusted sites. These include Wikipedia, Twitter, Facebook, LinkedIn, and the “official website” (more later on this important link).

Cortana’s answers to similar but not identical queries about “McAfee.”

It is surprising that links are offered and clickable when the device is locked. If you start your favorite network sniffer or man-in-the-middle proxy, you will see that the links are visited as soon as the user clicks on them, irrespective of the device’s locked status.

This means we can force navigation to a website (though not yet the one we want) when the device is locked. However, we have seen that Cortana can be picky in how she offers results. Bing must already know these results, and most links are known trusted sites.

That leaves us with the official website. You might recognize this terminology: It is a common link presented by Wikipedia. If you look at the bottom of a Wikipedia article, you will often find a link to an official website.

Could Cortana just use Wikipedia as a trusted source? After a few delightful conversations with her, we can confirm that the official website for items she refers from Wikipedia is indeed the same as the Official Website link on Wikipedia. There is no one-to-one correlation on Wikipedia’s official website for Cortana to display the corresponding link. We assume there is some possible weighting of the domain name or logic in the Bing output that influences Cortana’s displayed links.

We can leverage this information to craft a fake Wikipedia entry, add enough content to get the review to succeed, add an official website link, and see what Cortana presents. Wikipedia reviewers do a pretty good job of vetting content, but we also need Bing to become aware of the entry so that Cortana could offer the answer and the link. Because of the time-dependent factor of the approach (and the ethical aspect of tampering with Wikipedia content in a malicious way), we decided to take a different path—although others could use this attack vector.

Instead of creating an entry in Wikipedia, making sure that Bing indexes it and that Cortana provides the official website link, we opted for an alternative. We can instead hunt Wikipedia for unmaintained or dead official website links. Fortunately for us, Wikipedia maintains a list of “dead links” and “permanent dead links.” A search for “Xbox Linux” looks like this:

To aid in our hunt, Wikipedia has a fairly robust search engine that accepts regular expressions.

With just a little bit of tinkering we come up with the following search:

insource:/\{official (website)?\|https?\:\/\/[^}]+\.com\/[^}]\}\}\{\{dead link/

This is neither an exhaustive list, nor the most efficient regular expression, but it does find some candidates without triggering the Wikipedia query timeout.

The next step is to write a script to parse the output, grab a list of domains, and check whether they are actually vacant. Many of them are still registered but do not serve any content; others are live despite the “dead link” tag. We end up with a list of domains, some more expensive than others, that are vacant.

What will Cortana display for each of these Wikipedia entries? One after another, we ask. Retrospectively, writing a text-to-speech script would have been faster. Cortana answers surprisingly well to other digital speech synthesizers.

Many of the entries do not provide the official website link, but some do. It is annoying that the way you ask the question interferes with the results. Not only is the phrasing of the question important; the decision of whether to dictate a word or spell it out may change the answer. To obtain the answer you want from Cortana, you may have to combine both approaches.

For example, we asked “Hey Cortana, what is Miss Aruba?” We saw, while the device was locked, the following answer:

The official website link points to “hxxp://www.missaruba.aw.” A quick search shows the domain is still available.

In conclusion, we now have Wikipedia articles for which Cortana will display an official website link, and for which the domain is available for purchase. After spending $11.99 for a cheaper domain, we own one.

Although it took some regular-expression authoring, some scripting, and buying a domain, this method was faster and more satisfying than waiting for Bing to publish and index a new Wikipedia entry.

After this setup, what can we accomplish? We can ask Cortana (either via the interactive icon or vocal command “Hey Cortana”) to conduct a search while the device is locked. When she replies, we can click on the official website link and observe as Edge retrieves the content while the device remains locked.  To put a malicious spin on this unauthorized access, we have at least one straightforward option. We could install the latest exploit kit on our newly acquired domain and infect any locked Windows 10 PC with Cortana enabled without ever logging in. This attack could occur at a coffee shop, retailer, bank, or against targeted individuals. This configuration is the default on Windows, and our research has shown that many users never disable Cortana from the lock screen.

Digital voice assistants can be useful, but they must also be considered an attack vector. Although some may think this is a “noisy” vector, not applicable when stealth is required, you can employ techniques such as the DolphinAttack, which uses inaudible voice commands to close an air gap. Or if you have physical access to the device, a $5 3.5mm-jack cable will do as well.

An inexpensive 3.5mm-jack cable for silent interaction.

How can we protect against this attack vector? You can disable Cortana on your lock screen. Microsoft should not allow navigation to untrusted websites until it receives permission from the authenticated user, confirming on login that the user wants to visit a site.

Self-service Internet Explorer from the Windows lock screen

When we investigate a technology, we sometimes find that our initial findings are less substantial than what we learn after further investigation. Our research into Cortana and this attack surface was no different. What if one could surf the web freely with a full-fledged browser such as Internet Explorer 11, with access to cached credentials and autocomplete on a locked Windows 10 device? All thanks to Cortana? That could be much more impactful than browsing to just one URL.

That is possible with Cortana’s skills. It makes sense that Cortana offers skills similar to those of Amazon’s Alexa or Google Assistant. But it does not make sense to offer these skills directly from the lock screen when they are not yet configured.

One example is the “Real Estate Search” skill. While conversing with Cortana to analyze the capabilities she could offer an attacker, we found that she occasionally offered to try skills, including Real Estate Search.

One easy trigger is to ask “Hey Cortana, I want to sell my house.” This leads to the following screen:

If we click “Real Estate Search,” we get a login screen. Instead of logging in, let’s look at the other links offered by the interface. In the current case, the “Privacy Policy” link seems interesting:

Cortana’s skill login screen with a link to Privacy Policy.

Opening the link, we see a lengthy policy. If we scroll to the bottom of the page, we discover a few social media icons:

Privacy policy screen with links to social media sites.

These icons are indeed links, allowing us to reach Facebook or YouTube, and from there the rest of the Internet:

Reaching Facebook from the lock screen of a Windows 10 system.

Let’s summarize. You left for lunch with your new Windows Surface Book locked on your desk. Cortana is on by default on your lock screen. Your disk is encrypted. What could go wrong?

Anybody who has physical access to your locked device can start browsing the web. What if someone were to navigate to a work-unfriendly website from your device, or post inflammatory comments in a public forum that could be attributed to your device’s IP address?

A device-specific attribution would be bad, but could you use the same method to post or access something from a real person’s name or account? We next investigated which browser is being used? Is it a Cortana custom browser? Is it a sandboxed Microsoft Edge? It is actually a customized Internet Explorer 11 restricted engine running in the context of AuthHost.exe. (We will publish another analysis on this limited “browser” because its properties and lack of security mechanisms could become handy for red teams.)

This is the Internet Explorer engine and not the full browser, though both JavaScript and cookies are enabled. Worse, this incarnation shares the autocomplete and credentials saved in the context of the current user’s Internet Explorer session.

Thus in addition to posting a comment on a public forum from another user’s device while the device is locked, you can also impersonate the user thanks to its cached credentials.

One potential attack scenario arises if a corporation offers a mechanism to reset Windows credentials via a web server but does not require users to reenter the old password. One could simply navigate to the reset link, input a new password, exit the limited navigator, and unlock the device with the newly set password, all from a locked computer.

We have explored a couple of attack scenarios and security issues in this post, and we will continue our investigation into Cortana and other digital assistants as an attack vector. Your best mitigation at this point is to turn off Cortana on the lock screen. Here is a good tutorial on how to do so.

 

The post Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253 appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/microsoft-cortana-allows-browser-navigation-without-login-cve-2018-8253/feed/ 0
Want to Break Into a Locked Windows 10 Device? Ask Cortana (CVE-2018-8140) https://www.mcafee.com/blogs/other-blogs/mcafee-labs/want-to-break-into-a-locked-windows-10-device-ask-cortana-cve-2018-8140/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/want-to-break-into-a-locked-windows-10-device-ask-cortana-cve-2018-8140/#respond Tue, 12 Jun 2018 17:15:28 +0000 https://securingtomorrow.mcafee.com/?p=89585 June’s “Patch Tuesday” (June 12) is here, but it is likely many Windows 10 users have not yet applied these updates.

The post Want to Break Into a Locked Windows 10 Device? Ask Cortana (CVE-2018-8140) appeared first on McAfee Blogs.

]]>
June’s “Patch Tuesday” (June 12) is here, but it is likely many Windows 10 users have not yet applied these updates. If you have not, just be sure not to leave your laptop lying around! The patches in this cycle fix a code execution vulnerability using the default settings for Windows 10 and the “Cortana” voice assistant. We’ll detail how this vulnerability can be used to execute code from the locked screen of a fully patched Windows 10 machine (RS3 at the time of our original submission, and confirmed on RS4 prior to this patch cycle). The vulnerability was submitted to Microsoft as part of the McAfee Labs Advanced Threat Research team’s responsible disclosure policy, on April 23. Attribution for this vulnerability submission goes to Cedric Cochin, Cyber Security Architect and Senior Principal Engineer.

In this post, we will address three vectors of research that have been combined by Microsoft and together represent CVE-2018-8140. The first of these is an information leak, but we’ll culminate with a demo showing full code execution to log in to a locked Windows device!

Using “Hey Cortana!” to Retrieve Confidential Information

Personal digital assistants such as Siri, Alexa, Google Assistant, and Cortana have become commodities in many technologically inclined houses. From telling jokes, to helping with the grocery list, to turning on the kitchen lights, these robotic voices are beginning to feel oddly more and more personal as they expand their roles in our daily lives. However, we should consider the increased risk of built-in digital personal assistants when looking at new attack vectors for laptops, tablets, and smartphones. Our research on Microsoft’s Cortana voice assistant began after reading about the “BadUSB” attacks demonstrated by industry researchers. We decided to take this a step further and ended up finding and reporting to Microsoft several issues related to Cortana.

If you have spoken with Cortana, you may have noticed that “she” is very helpful for a number of simple tasks: providing definitions, or looking up corporations, movies, artists, or athletes. She can even do math! In Windows 10, on the most recent build at the time of submission, we observed that the default settings enable “Hey Cortana” from the lock screen, allowing anyone to interact with the voice-based assistant. This led to some interesting behavior and ultimately vulnerabilities allowing arbitrary code execution.

We begin this analysis with a quick look into Windows indexing. If you have ever opened the advanced view of the Windows Indexing control panel, and navigated to the File Types tab, you will see a long list of file extensions. For each of them you will find details about the associated filter used by the indexing process. Essentially you have the “file properties filter” and several other filters that could all be summarized as “file properties and file content filter.”

This means the index process will crack open the files and index their content, including some strings present in these documents. Let’s keep that in mind for later as we continue.

Using this knowledge, we wanted to try to access the same menu that you would see when using a Cortana search on an unlocked device.

This will come as a surprise and lies at the core of all the issues we found, but simply typing while Cortana starts to listen to a query on a locked device will bring up a Windows contextual menu, as shown below:

On top: the result of typing “pas” in the Cortana search field on an unlocked computer.
Above: the result of asking “Hey Cortana, P A S” and using a whitespace keyboard sequence.

In the preceding example, we queried Cortana for the term pas, no preamble to the question, just speaking the three letters, P. A. S. Why not “pass”? Because Cortana can be quite picky with verbal statements and there is no dictionary definition for “pass,” leading to Cortana inviting us to continue in Edge after unlocking the device. Alternatively, instead of issuing a verbal statement, we could click on the “tap and say” button and just start typing this text, for example.

We now have a contextual menu, displayed on a locked Windows 10 device. What could go wrong?

Remember that all the results presented by Cortana come from indexed files and applications, and that for some applications the content of the file is also indexed. Now we can simply hover over any of the relevant matches. If the match is driven by filename matching, then you will be presented with the full path of the file. If the match is driven by the file content matching, then you may be presented with the content of the file itself.

Keep in mind that the entire user folder structure is indexed, which includes the default location for most documents but also for mappings like OneDrive.

Example of data leakage using voice command with Cortana and the whitespace keyboard sequence.

Armed with this knowledge, you can use your imagination to come up with specific keywords that could be used to start harvesting confidential information from the locked device.

Code Execution from the Windows Lock Screen (User Interaction May be Required)

Next, we asked the question: Could we go a step further and get code execution in the context of the authenticated user? Remember we are using only a combination of voice commands and mouse/touchpad/touchscreen to gain access to the contextual menu at this point. We observed that just by hovering over a file, the full path or content of the file would be displayed. What happens if we were to click on it? That depends on the target. If the file being opened is an application or an executable (such as notepad or calc.exe), the file will run and be accessible only after the user properly logs in. If it is a document, script, or text file, it will be opened by an editor instead of being executed. At this point we can execute various preloaded Windows utilities such as calculator, but we cannot pass any parameters to the command line. We can open scripts including PowerShell, but instead of being executed, they will be opened in a text editor (notepad). The lack of parameters is a limitation for a “live off the land” attack, which uses current tools and content to achieve a malicious purpose; however, there are plenty of malicious activities that could be performed even with these restrictions. For example, many uninstallers will happily remove software without any need for parameters.

Let’s return to our goal: code execution from the lock screen. The only requirement for something to show up in the contextual menu is for it to be indexed.

Public folders indexed by default.

There are multiple ways for an unauthenticated attacker to get results to show up in the index of an authenticated user. One method relies on OneDrive. As the root of the OneDrive directory structure is in the user folder, all the OneDrive content is indexed by default. Basically, if you ever share a folder or file with “edit” rights, the person you share it with, as well as any other recipients of a forwarded link, can now drop a file that will be indexed. With the file indexed we have multiple options to proceed.

Option 1: Drop an Executable File

This method assumes you can write an executable file to the disk; it does not require you to have executed it. Via a phishing attack or another vulnerability, an attacker could drop a backdoor (for example, Cobalt Strike Beacon or Meterpreter) and be in business. If you need to execute the payload as an administrator, you can simply right-click (for a touchscreen this is a longer-hold screen press) and select “Run as administrator.”

When running applications that do not have the Auto-Elevate Privilege, you will trigger a user account control (UAC) prompt and nothing will execute. This could still result in a valid attack because users rarely check the content of the prompt and often proceed through the warning dialog box. The attacker would have to execute the program, and then wait for the authenticated user to log in and finish the job. If the application has auto-elevate privileges, there will be no UAC prompt and the application will execute at high integrity.

This is interesting behavior, but on its own not a very likely attack scenario, so let’s continue to explore our options. Why not simply use a USB key to drop the payload because we have physical access? The content of the USB key is not indexed, so it would not be presented as a result of the search query (although there are other ways to use a USB device; see below).

Option 2: Drop a non-PE Payload

Portable executable (PE) backdoors are great, but can we gain execution with a non-PE payload, for example, a PowerShell script?  We can use the same right-click capability to assist, but with a small twist. The right-click menu is not always the same, even for a given file type.

When you ask Cortana about “PS1,” you will be presented with your indexed PowerShell scripts. A right click will allow you to “open file location” or “copy full path,” but with no means of execution.

If you click on the file as we already mentioned, the file will open in edit mode. Curiously, it will not open the default editor (PowerShell ISE) for PowerShell scripts; instead, it will open the script in notepad. We assume this was intended as a security measure because notepad cannot execute scripts, unlike PowerShell ISE.

The default right-click menu for PS1 files.

Remember we mentioned that Cortana changes results based on your input query? When properly logged in, if you ask Cortana about “txt” using the query “Hey Cortana” followed by the letters “T,” “X,” “T,” she will present you with text documents, Notepad, and the most recent documents open by Notepad. Yet the right-click menu for items in the Recent category is different than the right-click menu for the same item in the Documents category.

At top:the context menu for a Recent item; above: the context menu for a Document item.

We follow a three-step process:

  • Land a PowerShell script in a location that will be indexed
    • Public folder, public share, or OneDrive
  • Execute a search query that will show the document and click on it
    • “Hey Cortana, PS1”
    • Select the PowerShell script you just indexed and left click
    • The PowerShell script opens in Notepad
  • Execute a search query that will show the recent documents, right click, and…
    • Using Cortana, type or search in the contextual menu for “txt”
    • Right click on the PowerShell script in the Recent category under the Apps tab at the top (not Documents)
    • Click “Run with PowerShell”

“Run with PowerShell” right-click menu option for Recent items.

We now have local code execution with the payload of our choosing, without any exploit, even if the device is encrypted, on an up-to-date locked Windows 10 device.

This technique helps us understand some of the differences between apps, documents, extensions, and the way Windows handles them from a locked or unlocked screen. Yet it probably does not represent much of a real-world attack vector. Then again, we are not finished.

Logging into a Locked Device with no User Interaction

Finally, we have local code execution, but with some real limitations. We need to get our payload indexed but we cannot pass command-line parameters. This could be a limiting factor for our PowerShell attack vector because the execution policy may prevent its execution, and without command-line parameters we cannot pass an “-ExecutionPolicy Bypass” (or any other flavor). We would also have to find a way to land a PS1 script on the victim’s box, and have remote access to the physical machine or the login screen.

The techniques we have described so far are far too complicated compared with the simplicity and effectiveness of what comes next.

You recall the use of the keyboard-timing sequence to trigger the contextual search menu from a locked screen while querying Cortana. Any keystroke can trigger the menu from the time when Cortana begins to listen to when the answer is displayed. Press any key at this point; we like to use the spacebar because you cannot backspace and Windows will nicely ignore or trim out the space in its text results anyways. Invoke keyboard input too early or before Cortana is listening and you will be prompted to enter your password; invoke too late and Cortana goes back to sleep or returns normal results without a context menu.

It is not very intuitive to use the keyboard in addition of voice commands, but you can type your search the same way you do on an unlocked device, assuming that you triggered Cortana to listen.

The following screenshot demonstrates this behavior:

  • Trigger Cortana via “Tap and Say” or “Hey Cortana”
  • Ask a question (this is more reliable) such as “What time is it?”
  • Press the space bar, and the context menu appears
  • Press esc, and the menu disappears
  • Press the space bar again, and the contextual menu appears, but this time the search query is empty
  • Start typing (you cannot use backspace). If you make a mistake, press esc and start again.
  • When done (carefully) typing your command, click on the entry in the Command category. (This category will appear only after the input is recognized as a command.)
  • You can always right click and select “Run as Administrator” (but remember the user would have to log in to clear the UAC)

You can use the following example of a simple PowerShell command to test. Enjoy the soothing beeps that demonstrate code execution from a locked device.

What can we do at this point? You name it. Our demo below shows a password reset and login on a Windows 10 build, using only this simple technique.


 

The easiest mitigation technique, in the absence of patching the device (which we strongly recommend), is to turn off Cortana on the lock screen. This week’s Patch Tuesday from Microsoft contains fixes for these issues under CVE-2018-8140.

This concludes our examination of Cortana (at least for now). The McAfee Advanced Threat Research team has a fundamental goal of eliminating critical threats to the hardware and software we use; this month’s patch is a clear step toward furthering that goal. The attack surface created by vocal commands and personal digital assistants requires much more investigation; we are just scratching the surface of the amount of research that should be conducted in this critical area.

A team of several independent researchers also discovered and disclosed this vulnerability around the time of our submission. Additional credit for this discovery goes to: Ron Marcovich, Yuval Ron, Amichai Shulman and Tal Be’ery. Their names are also on the Microsoft disclosure page.

The post Want to Break Into a Locked Windows 10 Device? Ask Cortana (CVE-2018-8140) appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/want-to-break-into-a-locked-windows-10-device-ask-cortana-cve-2018-8140/feed/ 0