Kashif Ali

A much overlooked but essential part in financially motivated (cyber)crime is making sure that the origins of criminal funds are obfuscated or made to appear legitimate, a process known as money laundering. ’Cleaning’ money in this way allows the criminal to spend their loot with less chance of being caught. In the physical world, for instance, criminals move large sums of cash into offshore accounts and create shell companies to obfuscate the origins of their funds. In the cyber underground where Bitcoin is the equivalent of cash money, it works a bit differently. As Bitcoin has an open ledger on which every transaction is recorded, it makes it a bit more challenging to obfuscate funds.

When a victim pays a criminal after being extorted with ransomware, the ransom transaction in Bitcoin and all additional transactions can then be tracked through the open ledger. This makes following the money a powerful investigative technique, but criminals have come up with an inventive method to make tracking more difficult; a mixing service.

A mixing service will cut up a sum of Bitcoins into hundreds of smaller transactions and mixes different transactions from other sources for obfuscation and will pump out the input amount, minus a fee, to a certain output address. Mixing Bitcoins that are obtained legally is not a crime but, other than the mathematical exercise, there no real benefit to it.

The legality changes when a mixing service advertises itself as a success method to avoid various anti-money laundering policies via anonymity. This is actively offering a money laundering service.

Bestmixer.io

Last year advertisements for new mixing service called Bestmixer.io appeared on several Crypto currency related websites.

Judging by the article It sounded like it offered a service that could be considered money laundering or aid tax evasion.

Bestmixer’s frontpage

Nature of the service

Bestmixer offered a very clear page on why someone should mix their cryptocurrency. On this page Bestmixer described the current anti-money laundering policies and how its service could help evade these policies by making funds anonymous and untraceable. Offering such a service is considered illegal in many countries.

Bestmixer’s explanation page, “why someone should mix bitcoins”.

A closer inspection of the Bestmixer site revealed that its website was hosted in the Netherlands. McAfee ATR contacted the Financial Advanced Cyber Team (FACT) of the Dutch anti-Fraud Agency (FIOD) of Bestmixer.io’s location. FACT is a team that is specialized in investigating the financial component of (cyber)crime.  A yearlong International investigation led to the takedown of Bestmixer’s infrastructure today.

The post Crypto Currency Laundering Service, BestMixer.io, Taken Down by Law Enforcement appeared first on McAfee Blogs.

During Microsoft’s May Patch Tuesday cycle, a security advisory was released for a vulnerability in the Remote Desktop Protocol (RDP). What was unique in this particular patch cycle was that Microsoft produced a fix for Windows XP and several other operating systems, which have not been supported for security updates in years. So why the urgency and what made Microsoft decide that this was a high risk and critical patch?

According to the advisory, the issue discovered was serious enough that it led to Remote Code Execution and was wormable, meaning it could spread automatically on unprotected systems. The bulletin referenced well-known network worm “WannaCry” which was heavily exploited just a couple of months after Microsoft released MS17-010 as a patch for the related vulnerability in March 2017. McAfee Advanced Threat Research has been analyzing this latest bug to help prevent a similar scenario and we are urging those with unpatched and affected systems to apply the patch for CVE-2019-0708 as soon as possible. It is extremely likely malicious actors have weaponized this bug and exploitation attempts will likely be observed in the wild in the very near future.

Vulnerable Operating Systems:

• Windows 2003
• Windows XP
• Windows 7
• Windows Server 2008
• Windows Server 2008 R2

Worms are viruses which primarily replicate on networks. A worm will typically execute itself automatically on a remote machine without any extra help from a user. If a virus’ primary attack vector is via the network, then it should be classified as a worm.

The Remote Desktop Protocol (RDP) enables connection between a client and endpoint, defining the data communicated between them in virtual channels. Virtual channels are bidirectional data pipes which enable the extension of RDP. Windows Server 2000 defined 32 Static Virtual Channels (SVCs) with RDP 5.1, but due to limitations on the number of channels further defined Dynamic Virtual Channels (DVCs), which are contained within a dedicated SVC. SVCs are created at the start of a session and remain until session termination, unlike DVCs which are created and torn down on demand.

It’s this 32 SVC binding which CVE-2019-0708 patch fixes within the _IcaBindVirtualChannels and _IcaRebindVirtualChannels functions in the RDP driver termdd.sys. As can been seen in figure 1, the RDP Connection Sequence connections are initiated and channels setup prior to Security Commencement, which enables CVE-2019-0708 to be wormable since it can self-propagate over the network once it discovers open port 3389.

 

Figure 1: RDP Protocol Sequence

The vulnerability is due to the “MS_T120” SVC name being bound as a reference channel to the number 31 during the GCC Conference Initialization sequence of the RDP protocol. This channel name is used internally by Microsoft and there are no apparent legitimate use cases for a client to request connection over an SVC named “MS_T120.”

Figure 2 shows legitimate channel requests during the GCC Conference Initialization sequence with no MS_T120 channel.

Figure 2: Standard GCC Conference Initialization Sequence

However, during GCC Conference Initialization, the Client supplies the channel name which is not whitelisted by the server, meaning an attacker can setup another SVC named “MS_T120” on a channel other than 31. It’s the use of MS_T120 in a channel other than 31 that leads to heap memory corruption and remote code execution (RCE).

Figure 3 shows an abnormal channel request during the GCC Conference Initialization sequence with “MS_T120” channel on channel number 4.

 

Figure 3: Abnormal/Suspicious GCC Conference Initialization Sequence – MS_T120 on nonstandard channel

The components involved in the MS_T120 channel management are highlighted in figure 4. The MS_T120 reference channel is created in the rdpwsx.dll and the heap pool allocated in rdpwp.sys. The heap corruption happens in termdd.sys when the MS_T120 reference channel is processed within the context of a channel index other than 31.

Figure 4: Windows Kernel and User Components

The Microsoft patch as shown in figure 5 now adds a check for a client connection request using channel name “MS_T120” and ensures it binds to channel 31 only (1Fh) in the _IcaBindVirtualChannels and _IcaRebindVirtualChannels functions within termdd.sys.

 

Figure 5: Microsoft Patch Adding Channel Binding Check

After we investigated the patch being applied for both Windows 2003 and XP and understood how the RDP protocol was parsed before and after patch, we decided to test and create a Proof-of-Concept (PoC) that would use the vulnerability and remotely execute code on a victim’s machine to launch the calculator application, a well-known litmus test for remote code execution.

Figure 6: Screenshot of our PoC executing

For our setup, RDP was running on the machine and we confirmed we had the unpatched versions running on the test setup. The result of our exploit can be viewed in the following video:

There is a gray area to responsible disclosure. With our investigation we can confirm that the exploit is working and that it is possible to remotely execute code on a vulnerable system without authentication. Network Level Authentication should be effective to stop this exploit if enabled; however, if an attacker has credentials, they will bypass this step.

As a patch is available, we decided not to provide earlier in-depth detail about the exploit or publicly release a proof of concept. That would, in our opinion, not be responsible and may further the interests of malicious adversaries.

Recommendations:

• We can confirm that a patched system will stop the exploit and highly recommend patching as soon as possible.
• Disable RDP from outside of your network and limit it internally; disable entirely if not needed. The exploit is not successful when RDP is disabled.
• Client requests with “MS_T120” on any channel other than 31 during GCC Conference Initialization sequence of the RDP protocol should be blocked unless there is evidence for legitimate use case.

 

It is important to note as well that the RDP default port can be changed in a registry field, and after a reboot will be tied the newly specified port. From a detection standpoint this is highly relevant.

Figure 7: RDP default port can be modified in the registry

Malware or administrators inside of a corporation can change this with admin rights (or with a program that bypasses UAC) and write this new port in the registry; if the system is not patched the vulnerability will still be exploitable over the unique port.

McAfee Customers:

McAfee NSP customers are protected via the following signature released on 5/21/2019:

0x47900c00 “RDP: Microsoft Remote Desktop MS_T120 Channel Bind Attempt”

If you have any questions, please contact McAfee Technical Support.

 

The post RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 appeared first on McAfee Blogs.