Python Server for PoshC2

We are delighted to announce the release of our PoshC2 Python Server, allowing cross-platform support.

Over the past six months we have been working on a Python server for PoshC2, which allows it to be run on almost any Unix or Windows based system that is capable of running Python. We have thoroughly tested the server on Kali, and Debian based Linux distributions without any issues. The server-side repository has been named ‘PoshC2_Python’ so as not to confuse it with the Windows PowerShell server version, ‘PoshC2’, which is still widely used in a client environment or enclave when needed. Here are a few of the main advantages we’ve identified of running PoshC2 via Python:

  • Removes the need for Windows
  • Team Collaboration
  • AutoComplete on the Implant Handler
  • GraphViz Visualisation
  • Lower CPU Utilization

Team Collaboration

The Python code enhances the flexibility of PoshC2. One of the main features is cross-platform support, therefore the server will run on both Windows and Unix based systems. The main feature of running the server on Linux is to enhance the team collaboration piece, which has always been limited via a Windows system. The Python server can be installed as a service; see the ‘Systemctl Service’ section below for more details on how to achieve this. It also allows multiple users to connect remotely and run their own implant handler to interact with each implant, while viewing the output from journalctl. Alternatively, the server session can be run from a screen terminal and multiple users can view the same screen session. The best results would be to run this as a systemctl service so it survives a reboot and will automatically re-start.

Almost all features have been ported over to Python from the server side, apart from the compiled executables that were ordinarily generated using .NET’s command line compiler csc.exe. However, instead of generating .NET binaries, we have introduced new template files that are written in C++ that can be modified and used as a template. See the ‘Templates’ section below for more information. This gives the user the ability to modify the template files, customize the binary, change the process the shellcode is injected into, the injection method, hardcode a domain name or any other additional functionality you can think of to enrich the dropper.

This is an example of the C2 server up and running. Similarly to PoshC2, the server window is usually viewed side by side to the Implant Handler to maintain consistency. The server will populate all the payloads only the fly, including the one liners, shellcode, HTA and macro files.

Systemctl Service

The PoshC2 server can now automatically be started as a service using systemctl within Linux. You can choose to either have this functionality enabled or not during the install; by default the service is not created, but it can be enabled by following the steps below. The advantages of having the C2 server installed as a service are endless, but most importantly if you are on a live engagement and the server for some reason fails or reboots, your C2 server will be resilient and bounce back once the system is back up and running.

To add the service, create the following file with the code in the block below:

#> vim /lib/systemd/system/poshc2.service

Once the file is in the correct location, the systemctl command will know how to enable the service, should you require this. To enable the service, run the enable command, followed by start, as shown below.

#> systemctl enable poshc2.service

#> systemctl start poshc2.service

You can also stop or restart the service if you need to change the config or re-run the server for any reason.

#> systemctl stop poshc2.service

#> systemctl restart poshc2.service

The best feature of running PoshC2’s python server as a service is the fact you can view the server output using the journalctl log. If you are running the server on an engagement with multiple users, it is very easy to share the output by running this command when you login via SSH.

#> journalctl -n 20000 -u poshc2.service -f –output cat

Reporting

While this hasn’t changed significantly since the first iteration of PoshC2, it’s one of the most important elements of the tool.  It will fundamentally assist in the SOC detection and response phase of your engagements, i.e. when assessing the response of the Blue Team.  It is, of course, also a professional requirement to have full logs of offensive activity.

One addition to the reporting section is the introduction of the opsec command which is in the pre-implant help. This will provide a list of all files uploaded to the system, including a unique list of hosts touched for reporting purposes.

The output-to-html now uses a GraphViz implementation which is still a work in progress, but aims to visually represent the compromise in action, including all hosts that are connected to the C2 server and how they are communicating back to the infrastructure. For example, if you have a host daisy chaining via an implant this will be displayed on the GraphViz output below. These files are generated when the output-to-html function is run within the pre-implant handler window. All icons are customizable via the output file that is generated or you can switch these out editing the files folder in PoshC2.

It should be noted that proxy aware implants and daisy payloads are still all functioning within the Python server and work the same way as in PoshC2. For more information on Daisy Chaining please refer to the documentation or the following blog:

Z:\Desktop\pyshc2.png

The HTML output has also been improved and now has some additional JavaScript that allows the commands to be searched and all output data truncated for easier viewing. The output can also be searched using the same method. If there are any additional reporting requirements you would like to see in here, please hit us up on Slack or Twitter.

Videos will be released shortly on how to get started with PoshC2, including customizing the Config.py file and editing the source files for better optimization.

Quick Install

To install PoshC2 on Ubuntu from a terminal, run the following:

curl -sSL https://raw.githubusercontent.com/nettitude/PoshC2_Python/master/Install.sh | bash

To get started, follow the instructions on the readthedocs webpage, which walk you through how to customize your install and have a better chance of not being detected within your engagement.

If you have any issues regarding crypto, this could be due to a dependency installation failure. The best way to get around this has been to create a virtualenv in Python and then install the requirements file manually for that virtualenv. For more information, read how to create a virtualenv in Python online.

Wine SharpSocks

But what about SharpSocks? Never fear, SharpSocks works with Wine! If you need to find out how to get Wine installed for SharpSocks, there is a file called Install_SOCKS that has step-by-step instructions on how to achieve this. For those who don’t know what SharpSocks is, the following blog post discusses our release of a SOCKS server for PoshC2in detail.

Templates

As previously mentioned, PoshC2 now has template files that can be optimized prior to starting the service. An example of why you might want to do this is environment detections such as domain name or user. The template files are created using C++; by default there is an executable that creates a file which migrates automatically, and one that stays in the same process.

Signtool

To reduce the likelihood of the binary files being detected, you could also sign the executables that are generated from PoshC2 by using a code signing certificate. This will add some legitimacy to the binary when calling out to the internet.

#> signtool.exe sign /f code_signing_cert.pfx /p password Posh64.exe

Delay

As part of the initial payload, the PowerShell script will attempt to execute. If the C2 Proxy or implant cannot reach the server, the process will wait for 300 seconds (5 minutes) and retry. If required, it will then wait for 600 seconds (10 minutes) and try one final time. This has been implemented as a backup in case your C2 infrastructure is locked down too securely and for some reason doesn’t accept the implant first time. This could be due to a number of environmental detections, including the external IP address. The implant could have passed the domain check but come from a non-whitelisted IP address. This will give you the opportunity to evaluate the IP address and add to the whitelist if this should have been part of the organisations external IP address range given to you. This can all be modified if the timings need to be increased for any reason; all of this code is in the Payloads.py file.

Autoloads

Autoruns have always been a great feature for us. There is nothing worse than having to tell the C2 tool to load the following PowerShell module before running the command when this can all be coded into the tool. PoshC2 has implemented a lot of these by default, but if you want to customize them you can amend the autoloads by editing the AutoLoads.py file and adding extra lines.

Modules

The philosophy of PoshC2 has always been to use a selection of amazing PowerShell cmdlets that have been written by others in the industry. The PoshC2 folder has a Modules folder where all the scripts are loaded from. You can simply add any PowerShell script that conforms to the PowerShell standard into this folder and load using the Implant Handler:

loadmodule Invoke-Mimikatz.ps1

Python Dropper

As you will notice, we have made a small start on the Python dropper to allow for Unix support. This has not been exhaustively tested, however, it is a start at making it possible to support execution on the likes of a macOS based system or similar. There is currently a requirement to have pycrypto on the box that is executing the payload but we are working on solutions to implement the crypto piece without requiring this dependency. Something along the lines of in memory module imports, or similar. If anyone would like to contribute to this side of the PoshC2, please don’t hesitate to get in touch.

A Python implant has limited features right now. Currently you can set the beacon timer and execute commands on the host.

PoshC2 Execution Tips

A pro tip for executing PoshC2 on a client device that is highly monitored and has PoshC2 v5 with script block logging, module logging and transcript Logging is combining the work Dave Hardy did with the PoSHBypass (including the authors of the bypass techniques) and the transcript logging bypass we put together using this gist code snippet:

The script block logging, Module Logging & AMSI bypass was put together here by Dave Hardy:

The Transcript Evasion technique was from here:

From an OpSec perspective, similarly to most C2 frameworks and adversaries, PoshC2 has some default IoCs that it is highly recommended you optimize to avoid detection. These items include:

  • Comms URLS
  • UserAgent
  • Use Domain Fronting
  • Change Default Migration Process (netsh.exe)
  • Change Default Persistence Methods
  • Template Files

When you start PoshC2 ,you have to optimize the Config.py file which will provide you a list of default URLs that can be used. These are publicly available and will most likely get signatured in time. To ensure you are providing the best chance of remaining undetected, you should optimize these URLs. This also goes for the UserAgent string. Prior to sending in any payloads, it is necessary to do reconnaissance against a target. This will often include techniques like web bugs or similar. This will give you a change to identify the default UserAgent for the target estate. This could range from IE11, Chrome, Firefox or even Edge. You should re-configure the UserAgent configuration to be in line with the corporate estate to merge into normal business traffic on the proxy.

As most of us know, domain fronting is the best form of hiding censorship when performing Red Teaming. Unless the organization is performing SSL inspection, there is no way this type of communication can be detected. If the organization is using SSL inspection, its best to use a site that falls into one of these two categories to have the best chance of going under the radar:

  • Financial Services
  • Health Care

Frameworks such as Cobalt Strike and Metasploit also have common indicators of comprise (IoC), such as ‘notepad.exe’ for Metasploit and ‘rundll32.exe’ for Cobalt Strike. PoshC2 has a similar default process that is used for migration; this is netsh.exe. When performing the default migration within PoshC2, e.g. running the ‘migrate’ command, it will always start the process netsh.exe unless directed by the user on the command line. It is highly recommended that you customize this option; the new PoshC2 ‘Inject-Shellcode’ or ‘migrate’ function also has the ability to spoof the parentpid. Note, this works on Windows 7 but has had some failures on Windows 10. Also, the default method for process migration was using the win32 API call ‘CreateRemoteThread’. PoshC2 now has the ability to use ‘RtlCreateUserThread’ which is not quite as widely used across C2 frameworks. This was largely due to the help from @uint_ptr, who is our in house Windows wizard!

You can use the migrate command with all of the above in mind as follows:

  • migrate -procpath c:\windows\system32\searchprotocolhost.exe -suspended -RtlCreateUserThread
  • migrate -procpath c:\windows\system32\svchost.exe -suspended -RtlCreateUserThread -ParentID 4502

From a logging and monitoring perspective, it is always good practice to migrate to a process that is expected to go out to the internet, e.g. Internet Explorer, Outlook, Lync or similar. If the client has an endpoint product that tracks process migration and history, going from netsh.exe out to the internet should be suspicious. Keep this is mind when selecting the process to migrate into.

Here is an example of parent process spoofing in Windows 7. The following command was ran to migrate the process searchprotocolhost.exe and set the parentid of explorer (pid: 432). Note, this was all done using a standard user account.

  • migrate -procpath c:\windows\system32\ searchprotocolhost.exe -suspended -RtlCreateUserThread -ParentID 432

Persistence is also another function that should be completely optimized. PoshC2 has some default persistence methods, however, these are likely to be highly signatured and should be changed accordingly. There are many methods of persistence you can use, depending on your privileges. COM Hijacking is highly recommended or WMI if elevated. DLL Hijacking is also fairly difficult to detect; if you want to create a custom DLL that can be used for DLL hijacking, here is a simple code snippet that can be used to launch another process when the DLL is attached, which is perfect for DLL hijacking.

AMSI Checker

A new feature we’ve added is an Anti-Malware Scan Interface (AMSI) checker. We have baked this into the core-implant module. This does a quick process check using PowerShell and determines if the amsi.dll is loaded into the core implant. If this module is loaded, it will notify you through the C2Server response and provide a way of unhooking this DLL.

The way we unhook this module is using the work Adam Chester (@_xpn_) put together on exploring PowerShell AMSI and logging evasion. The way this function works is by using C# to pinvoke various Win32 API calls to identify where a certain DLL is loaded and its export functions reside in memory. As we own the memory for our process, we can simply overwrite the code in memory, returning the same response as if the malware check was benign.

For visibility, it is possible to identify if PoshC2 is running in another process by using Process Explorer which comes as part of the sysinternals suite (https://docs.microsoft.com/en-us/sysinternals/). This allows you to see if any .NET assemblies have been loaded into the running process. If the process is in fact PoshC2, there is a known Indicator of Compromise when running the CLR v4.0.30319 because you will see a DLL loaded called ‘posh’. This does not appear in .NET version two, as shown in the examples below.

Python 3

In the not too distant future, this will be ported over to Python v3. Currently it’s only designed to work in version 2.7.

Conclusion

In conclusion, both the traditional Windows PoshC2 and the Python Server PoshC2 repositories will be actively maintained by various contributors.  We encourage you to use it, provide feedback and generally contribute to the project.  You can always grab the latest version from GitHub.

github GitHub: https://github.com/nettitude/PoshC2_Python.

COM and the PowerThIEf

Recently, Component Object Model (COM) has come back in a big way, particularly with regards to it being used for persistence and lateral movement. In this blog we will run through how it can also can be used for limited process migration and JavaScript injection within Internet Explorer. We will then finish with how this was put together in our new PowerShell library Invoke-PowerThIEf and run through some situations it can aid you, the red team, in.

Earlier this year I became aware of a technique that involved Junction Folders/CLSID that had been leaked in the Vault 7 dump. It was when I began looking at further applications of these that I also learned about the Component Object Model (COM) ability to interact with and automate Internet Explorer. This, of course, is not a new discovery; a lot of the functionality is well documented on sites like CodeProject. However, it hadn’t been organised into a library that would aid the red team workflow.

This formed the basis of my talk “COM and the PowerThIEf” at SteelCon in Sheffield on 7th July 2018. The slides for the talk can be found at:

The talk itself is here:

Getting up to speed with COM

Before we dive into this, if you are not familiar with COM then I would highly recommend the following resources. These are a selection of some of the recent excellent talks & blog posts on the subject that I would recommend if you want to know more.

Junction Folders

I first came across the Junction Folders/CLSID technique mentioned above in one of b33f’s excellent Patreon videos. As I understand it, this was first used as a method for persistence, in that if you name a folder in the format CLSID.{<CLSID>} then when you navigate to that folder, explorer will perform a lookup in the registry upon the CLSID and then run whatever COM Server has been registered. As part of his DefCon 25 WorkShop (which is worth a read, hosted at https://github.com/FuzzySecurity/DefCon25) he released a tool called Hook-InProcServer that enabled you to build the registry structure required to be used for a COM Hijack or for the JunctionFolders/CLSID technique. These were both being used as a Persistence mechanism and I began wondering if this might be possible to use as a means of Process Migration, at least into explorer.exe.

Step one was to find if it was possible to programmatically navigate to one of the configured folders and – yes – it turns out that it is. In order to be able to navigate, we first need to gain access to any running instances of explorer. Windows makes this easy via the ShellWindows object:

Enumerating the Item property upon this object lists all the current running instances of Explorer and Internet Explorer (I must admit I thought this was curious behaviour). ShellWindows is identified by the CLSID “{9BA05972-F6A8-11CF-A442-00A0C90A8F39}”; the following PowerShell demonstrates activating it.

The objects returned by indexing the .Item collection will be different based upon if it is an explorer and IE instance. An easy check is using the FullName which exists on both and has the name of the application, as shown here.

This article (https://www.thewindowsclub.com/the-secret-behind-the-windows-7-godmode) from 2010 not only contains the Vault7 technique but also shows that it is possible to navigate to a CLSID using the syntax shell:::{CLSID}. Assuming that we have at least one IE window open, we are able to index the ShellWindows.Item object in order to gain access to that window (e.g. to gain access to the first IE window, use $shWin[0].Item). This will provide us an object that represents that instance of IE and is of a type called IWebBrowser2. Looking further into this type, we find in the documentation that it has a method called Navigate2. (https://msdn.microsoft.com/en-us/library/aa752134(v=vs.85).aspx). The remarks on the MSDN page for this method state that it was added to extend the Navigate method in order to “allow for shell integration”.

The following code will activate ShellWindows, assuming the first window is an IE instance (this is a proof of concept) and will then attempt to navigate to the Control Panel via the CLSID for Control Panel (which can be found in the registry).

The following animation shows what happens when this code is run:

Control Panel being navigated to via CLSID ID:

We can then see via a trace from Process Monitor that IE has looked up the CLSID and then navigated to it, eventually opening it up in explorer, which involved launching the DLL within the InProcServer registry key. If we create our own registry keys we then have a method of asking IE (or Explorer) to load a DLL for us all from the comfort of another process. We don’t always want network connections going out from Word.exe, do we? In the case of IE the DLL must be x64. There are methods of configuring the registry entries to execute script; I suggest that you look at subTee’s or bohop’s excellent work for further information.

JavaScript

Once a reference is obtained to an Internet Explorer window it is then possible to access the DOM of that instance. As expected, you then have full access to the page and browser. You can view and edit HTML, inject JavaScript, navigate to other tabs and show/hide the window, for example. The following code snippet demonstrates how it is possible to inject and execute JavaScript:

The difference this time is that we actually have to locate the eval method on the DOM window before being able to call it. This requires using .NET’s Reflection API to locate and Invoke the method.

The following shows what happens this code is run.

Where is this all going?

Well, despite the programming constructs and some of the techniques being well documented, there didn’t appear to be a library out there which brought it all together in order to help a red team in the following situations:

  • The target is using a password manager, e.g. LastPass where key-logging is ineffective.
  • The user is logged into an application and we want to be able to log them out without having to clear all browser history and cookies.
  • The target application is in a background tab and can‘t wait for user to switch tabs. We need to view or get HTML from that page.
  • We want to view a site from the targets IP address, without the target being aware.

This led to me writing the PowerThIEf library which is now hosted at https://github.com/nettitude/Invoke-PowerThIEf.

The functionality included in the initial release is as follows:

  • DumpHtml: Retrieves HTML from the DOM, can use some selectors (but not jQuery style – yet).
  • ExecPayload: Uses the migrate technique from earlier to launch a payload DLL in IE.
  • HookLoginForms: Steals credentials by hooking the login form and monitoring for new windows.
  • InvokeJS : Executes JavaScript in the window of your choice.
  • ListUrls: Lists the urls of all currently opened tabs/windows.
  • Navigate: Navigate to another URL.
  • NewBackgroundTab: Creates a new tab in the background.
  • Show/HideWindow: Shows or Hides a browsing window.

Examples of usage and functionality include:

Extracting HTML from a page:

Logging the user out, in order to capture credentials:

Using the junction folders to trigger a PoshC2 payload:

Capturing credentials in transit entered via LastPass:

Usage

The latest Invoke-PowerThIEf documentation can be found at:

Roadmap

Further functionality is planned in the future and will include

  • Screenshot: Screenshot all the browser windows.
  • CookieThIEf: Steal cookies (session cookies).
  • Refactor DOM event handling: Developing Complex C# wrapped in Powershell is not ideal.
  • Pure C# Module
  • Support for .Net 2.0-3.5

Download

github GitHub: https://github.com/nettitude/Invoke-PowerThIEf

CVE-2018-6851 to CVE-2018-6857: Sophos Privilege Escalation Vulnerabilities

We have recently disclosed a list of vulnerabilities to Sophos that allow local attackers to elevate their privileges and execute code in the security context of the SYSTEM user account.

Affected Products

  • SafeGuard Enterprise 8.00.4 and earlier (Fix: install 8.00.5)
  • SafeGuard Easy 7.00.2.35 and earlier (Fix: install 7.00.3)
  • SafeGuard LAN Crypt 3.95.1.13 and earlier (Fix: install 3.95.2)

Sophos has also provided patches for earlier versions in case there are issues upgrading to one of the aforementioned latest versions.

For further details regarding the affected products and the respective fixed versions please visit:

Proof of Concept

Technical details

In this section we provide a few technical details about the reported issues.

Module: lcencvm.sys

1. Local Privilege Escalation via IOCTL 0x802022E0 [CVE-2018-6857]

By crafting an input buffer we can control the execution path to the point where the constant 0x12 will be written to a user-controlled address (0xF8F8F8F8).

eax=00000000 ebx=0028ef18 ecx=00000000 edx=0028ef1a esi=f8f8f8f8 edi=87d34a80

eip=8906e0c5 esp=a59c5100 ebp=a59c5994 iopl=0 nv up ei ng nz ac po cy

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010293

lcencvm+0x580c5:

8906e0c5 c70612000000 mov dword ptr [esi],12h ds:0023:f8f8f8f8=????????

We can take advantage of this condition to modify the SEP_TOKEN_PRIVILEGES structure of the Token object belonging to the exploit process and grant the SE_DEBUG_NAME privilege. This allows the exploit process to interact with higher privileged processes running as SYSTEM and execute code in their security context.

2. Local Privilege Escalation via IOCTL 0x80202014 [CVE-2018-6855]

By crafting an input buffer we can control the execution path to the point where the constant 0xFFFFFFF will be written to a user-controlled address (0xF8F8F8F8).

eax=0022e400 ebx=0022e400 ecx=f8f8f8f8 edx=0022e400 esi=00000000 edi=00000000

eip=890645b7 esp=a5984698 ebp=00000000 iopl=0 nv up ei pl zr na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246

lcencvm+0x4e5b7:

890645b7 c701ffffffff mov dword ptr [ecx],0FFFFFFFFh ds:0023:f8f8f8f8=????????

The same method as used previously can be used to successfully exploit this issue.

3. Local Privilege Escalation via IOCTL 0x80202298 [CVE-2018-6852]

By crafting an input buffer we can control the execution path to the point where nt!memset is called to zero out contents of a user-controlled address (0xF8F8F8F8).

eax=00000000 ebx=0021fb90 ecx=00000001 edx=00000000 esi=f8f8f8f8 edi=f8f8f8f8

eip=82a7da45 esp=a59bd4dc ebp=00000000 iopl=0 nv up ei pl nz na po nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202

nt!memset+0x45:

82a7da45 f3ab rep stos dword ptr es:[edi]

We can take advantage of this condition to zero-out the pointer to the security descriptor in the object header of a privileged process and run code in the context of a process running as SYSTEM.
This method can be used up to Windows 10 prior to v1607 as discussed here: https://labs.nettitude.com/blog/analysing-the-null-securitydescriptor-kernel-exploitation-mitigation-in-the-latest-windows-10-v1607-build-14393/

4. Local Privilege Escalation via IOCTL 0x80206040 [CVE-2018-6851]

By crafting an input buffer we can control the execution path to the point where the constant DWORD 0 will be written to a user-controlled address (0xF8F8F8F8).

eax=00000000 ebx=00000000 ecx=002cf9e8 edx=002cf9e8 esi=002cf9e8 edi=f8f8f8f8

eip=89063ffa esp=a5970948 ebp=a5970998 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206

lcencvm+0x4dffa:

89063ffa c70700000000 mov dword ptr [edi],0 ds:0023:f8f8f8f8=????????

The same method as previously used can be used to successfully exploit this issue.

5. Local Privilege Escalation via IOCTL 0x8020601C [CVE-2018-6856]

By crafting an input buffer we can control the execution path to the point where a global variable [lcencvm+0x6725c (8907d25c)] will be written to a user controlled address (0xF8F8F8F8).

eax=f8f8f8f8 ebx=00000000 ecx=00000003 edx=00000000 esi=852a0638 edi=87e3a6e0

eip=89065d7a esp=a91df954 ebp=a91df998 iopl=0 nv up ei ng nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286

lcencvm+0x4fd7a:

89065d7a 890 mov dword ptr [eax],ecx ds:0023:f8f8f8f8=????????

The same method as previously used can be used to successfully exploit this issue.

6. Local Privilege Escalation via IOCTL 0x80206024 [CVE-2018-6853]

By crafting an input buffer we can control the execution path to the point where a global variable [lcencvm+0x67268 (8907d268)] will be written to a user controlled address (0xF8F8F8F8).

eax=f8f8f8f8 ebx=00000000 ecx=00000002 edx=00000000 esi=852a0638 edi=8512b6f0

eip=89065daa esp=a5970954 ebp=a5970998 iopl=0 nv up ei ng nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286

lcencvm+0x4fdaa:

89065daa 8908 mov dword ptr [eax],ecx ds:0023:f8f8f8f8=????????

The same method as previously used can be used to successfully exploit this issue.

Module: SGStDrvm.sys

1. Local Privilege Escalation via multiple IOCTLs [CVE-2018-6854]

IOCTL examples: 0x8810200B, 0x8810200F, 0x8810201B, 0x8810201F, 0x8810202B, 0x8810202F, 0x8810203F, 0x8810204B, 0x88102003, 0x88102007, 0x88102013, 0x88102017, 0x88102027, 0x88102033, 0x88102037, 0x88102043, 0x88102047

When some conditions are not met, the driver writes an error code (0x2000001A) to user-controlled address. Also, note that all the aforementioned IOCTLs use transfer type METHOD_NEITHER, which means that the I/O manager does not validate any of the supplied pointers and buffer sizes. So, even though the driver checks for input/output buffer sizes, it doesn’t validate if the pointers to those buffers are actually valid.

So, we can supply a pointer for the output buffer to a kernel address space address, and the error code will be written there. We can take advantage of this condition to modify the SEP_TOKEN_PRIVILEGES structure of the Token object belonging to the exploit process and grant the SE_DEBUG_NAME privilege. This allows the exploit process to interact with higher privileged processes running as SYSTEM and execute code in their security context.

Disclosure Timeline

  1. Date of discovery: December 2017
  2. Vendor informed: 11 January 2018
  3. Vendor fix received: 20 April 2018
  4. Fix tested : 25 April 2018
  5. Agreed to disclose from 30 May onward: 26 April 2018
  6. Public Disclosure: 25 June 2018

CVE-2018-10956: Unauthenticated Privileged Directory Traversal in IPConfigure Orchid Core VMS

Affected Software: IPConfigure Orchid Core VMS (All versions < 2.0.6, tested on Linux and Windows)

Vulnerability: Unauthenticated Privileged Directory Traversal

CVE: CVE-2018-10956

Impact: Arbitrary File Read Access

Metasploit module:

https://github.com/nettitude/metasploit-modules/blob/master/orchid_core_vms_directory_traversal.rb

Summary of Vulnerability

IPConfigure Orchid Core VMS is a Video Management System that is vulnerable to a directory traversal attack, which allows underlying database access, access to camera feeds and more. This allows a remote, unauthenticated attacker to send crafted GET requests to the application, which results in the ability to read arbitrary files outside of the applications web directory. This issue is further compounded as the Linux version of Orchid Core VMS application is running in context of a user in the “sudoers” group. As such, any file on the underlying system, for which the location is known, can be read.

Nettitude has performed limited testing on the Windows version of Orchid Core VMS, and has been able to read files such as ‘C:/Windows/debug/NetSetup.log’ and ‘C:/WINDOWS/System32/drivers/etc/hosts’. Reading these files does not require permissions greater than a regular user account, however, it is possible that the Orchid Core VMS web server is running in a privileged context.

Below is an image for the login page of Orchid Core VMS.

Metasploit Module

We have created a Metasploit module for this vulnerability, which can be found here:

Vulnerability Analysis and Impact

Discovery of the vulnerability involved multiple steps, such as identifying the correct URL encoding that is accepted by the application, as well as the location of files on the underlying system, the latter of which was conducted through manual and automated fuzzing techniques.

The following images will help explain the discovery and exploitation of this vulnerability. This is the first GET request that was sent through a browser.

Request: https://ip/../../../../../../../etc/shadow

The response is interesting as the error suggests that it may be possible to read resources on the underlying web server. In this request it appears that the dot-dot-slash ( ../) was removed by the application. As such, in the second request, the dot-dot-slash was URL encoded and once again submitted through the browser.

Request: https://ip/%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e/etc/shadow

In this request, the URL encoding for the forward slash ( %2e) was removed. Nettitude submitted a third request, the browser was bypassed and the same request was sent to the web server using curl.

The following image demonstrates the ability to read the ‘/etc/shadow’ file on a Linux file system. This is of particular concern as it displays that the Orchid web service is running with high user privileges. With this level of access an attacker is in the position to read certain files of interest. This includes SSH private keys, VPN configuration files and all other files on the underlying system.

The following image demonstrates the ability to read the ‘C:\Windows\debug\NetSetup.log’ file on a Windows file system. This demonstrates that the vulnerability is not limited to the Linux file system and affects both Windows and Linux operating systems.

Furthermore, Nettitude was able to identify the applications structure and database location using readily available developer documentation and the online knowledge base for Orchid Core VMS (https://support.ipconfigure.com/hc/en-us/categories/200146489-Orchid-Core-VMS).

Orchid Core VMS uses a SQLite database, which is intended to be treated as a file on modern operating systems. Nettitude was able to download this database using the previously described directory traversal vulnerability. The image below represents the users which have access to the application, along with their SHA1 16-byte salted password hashes. Upon successfully cracking password hashes and obtaining the cleartext password for a user account, an attacker is placed in the position to view live-camera streams, manage user accounts and perform other application functions which are otherwise restricted to authenticated users.

Perusing through the database, Nettitude also discovered valid session ID’s for the web application and connected-camera descriptions.

Proof of Concept for Linux

curl --insecure https://IP/%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e/etc/shadow

Proof of Concept for Windows

curl http://IP:PORT/%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e/Windows/debug/NetSetup.log

Disclosure Timeline

  • 20 April 2018: Discovered directory traversal vulnerability in Orchid VMS 2.0 on Ubuntu 14.04 LTS.
  • 7 May 2018: Confirmation of vulnerability on other Linux OS and Windows OS across all Orchid VMS versions.
  • 7 May 2018: Initial write up of vulnerability.
  • 7 May 2018: Initial reach out to IPConfigure. Submitted request for contact details for an information security employee.
  • 8 May 2018: Verified that the correct contact has been reached.
  • 9 May 2018: Requested CVE reservation from Mitre.
  • 9 May 2018: Received CVE-2018-10956 from Mitre.
  • 9 May 2018: Sent PGP encrypted vulnerability write up to contact at IPConfigure.
  • 11 May 2018: Received confirmation of vulnerability from IPConfigure.
  • 11 May 2018: IPConfigure releases v2.0.6 for public download, resolving the identified vulnerability.
  • 20 June 2018: Nettitude publicly disclosed the vulnerability