Leandro Costantino – 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 Leandro Costantino – 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