Remote access systems have become a necessity rather than an option for the enterprise due to the COVID-19 crisis. When the entire world found itself faced with unprecedented healthcare challenges, numerous organizations got busy implementing telework as a dominant way of doing business. Because IT departments in some companies were scarcely prepared for these circumstances, they bumped into roadblocks such as a buggy configuration of the service or the use of obsolete, and hence vulnerable software.
A lot of businesses have felt the adverse outcomes of these slip-ups already. Some are in the clear for the time being but continue to be exposed to potential exploitation. Either way, companies should finally learn from their mistakes. As working off-premises is now the norm, safeguarding the underlying digital infrastructure is increasingly important.
Organizations have a handful of remote access implementation options to choose from. Virtual Private Network (VPN), Virtual Network Computing (VNC), Remote Desktop Systems (RDS), TeamViewer are a few common instruments. The best bet depends on the unique characteristics of the network architecture and the types of devices that compose it. VPN tools are traditionally the most popular across the board, but many small businesses go for RDS services instead due to the ease of deploying them.
This article is going to give you insights into RDS from a security perspective. It includes a rundown of known vulnerabilities these solutions are susceptible to. Additionally, you will learn how cybercriminals can execute attacks against networks based on Active Directory. These details should help you avoid the worst-case scenario and take your company’s security posture to the next level.
RDS/RDP security flaws unearthed recently
Just like any other software, RDS is not immune to exploitation. Security researchers have given organizations a heads-up about several new vulnerabilities in these solutions lately. Here are brief descriptions of these findings.
This loophole undermines the security of users who establish a connection with a hacked web server. If exploited, it allows an adversary to control the device or infiltrate the system and maintain surreptitious remote access.
All components of this trio have one thing in common: they allow an unauthenticated user to perpetrate a remote code execution (RCE) attack against a server that runs RDS. This is doable through a specially crafted request, which should not be a problem for a well-motivated hacker.
A malicious actor can also exploit these bugs to install arbitrary malicious software, spawn new user accounts with elevated privileges, and view, modify or erase data. This tampering can, obviously, endanger the entire enterprise network. The most effective defense is to be proactive and apply patches that arrive with operating system updates.
With telework soaring, remote access tools are the focal point of both white and black hats. It means that more vulnerabilities will be surfacing down the road. The silver lining is that few of these flaws have public exploits underlying them.
The flip side of the coin, though, is that tech-savvy cybercrooks may be able to come up with an exploit by thoroughly analyzing a vulnerability description. A technique called “patch diffing” can also play into malefactors’ hands as it helps them identify changed functions in a security update and thereby figure out what imperfections the patch addresses. Since the update hygiene is far from perfect in the enterprise environment overall, the latter method can pave felons’ way towards creating a viable exploit that will impact numerous unpatched networks in a snap.
The moral of the story is that businesses should follow proper software update practices and stay tuned for new reports about vulnerabilities in the applications they use.
This section will give you an idea of the classic incursions targeting networks that use Active Directory. The generic profile of an attacker who can set these mechanisms in motion is as follows: he has a valid user account on the network and can access the Remote Desktop Gateway, or the terminal server. For the record, this server may be accessible from an outside network.
The techniques below allow a malefactor to gain a foothold in an enterprise ecosystem and broaden the attack surface. Although the specific hallmarks of a network can vary, these tactics apply to most configurations.
Tricks to escape restricted shell environment and escalate privileges
When trying to gain unauthorized access to a Remote Desktop Gateway, the hacker will likely bump into a roadblock – a sort of an isolated area with no easy entry options. The normal process of establishing a connection with the terminal server typically involves a particular application being executed automatically. For instance, it can be an RDP connection interface, the File Explorer tool, or office packets.
What the adversary will try to do at this stage is tamper with the workflow of launching commands. This will give the green light to running PowerShell scripts or firing up the CMD utility. The evildoer does not have to reinvent the wheel to evade the Windows sandbox. The following mechanisms have been around for quite some time and can do the wicked trick.
Scenario A. Let us assume that the crook has access to the Remote Desktop connection dialog. By clicking on the “Show Options” button, he will see the advanced connection settings. From there, accessing the File Explorer window is as easy as hitting the “Open” or “Save” button.
As soon as the File Explorer is launched, the address area in its upper part allows the perpetrator to execute permitted processes. It also presents the tree view of the file system and thereby reveals hidden system volumes.
A similar exploitation technique goes for a situation where Microsoft Excel is leveraged as a remote program. An extra malicious flavor of this routine is that the attacker can “weaponize” the Office macros feature to download harmful code surreptitiously.
Scenario B. The attacker who has the same initial access as in the above situation establishes a series of RDP connections under a single account. Every subsequent connection attempt terminates the previous session and triggers an error screen. Clicking “Help” on this message will open Internet Explorer on the server. This, in turn, is a workaround for accessing the File Explorer and continuing the attack.
Scenario C. In many cases, users are prohibited from running certain executables on the terminal server due to Group Policies. If so, the malefactor cannot launch cmd.exe in a regular way. The attacker can overcome this hurdle, though. All it takes is executing a BAT file from the Remote Desktop that includes a string in the following format: cmd.exe /K < application name>.
Scenario D. Some organizations hinge upon blacklists to ban certain executable files. However, this approach is not as reliable as it may appear.
Let us suppose that a network administrator has disabled the command prompt and specified Group Policies that prevent PowerShell and Internet Explorer from being triggered. The intruder attempts to run PowerShell through the context menu in a modal pop-up dialog, but to no avail. Executing a PowerShell script through the address bar does not work either.
There is a way to get around the block, though. The hacker needs to copy the PowerShell.exe file from the Windows\System32\WindowsPowerShell\v1.0 path to the user’s home directory and rename it. This will unlock the script execution capability.
Because Remote Desktop permits access to a client’s local disk paths by default, the threat actor can mishandle this privilege to copy the PowerShell.exe file, modify its name, and execute it. The blacklist might not embrace all such folders, which means that they can be accessed.
Another dodgy opportunity kicks in if the software installed on a company-issued device has some redundant scripts a developer left behind. The attacker may be able to run or even repurpose these scripts, possibly even with administrator privileges. Long story short, blacklists are not a cure-all and should be combined with additional defenses.
Keeping your Remote Desktop connections intact
There are plenty of other methods a cybercriminal can use to circumvent the commonplace protection and pull off a privilege escalation raid. In nearly every scenario, accessing the File Explorer is the launchpad for the attack. Since third-party apps tend to harness the traditional Windows file management instruments, the same attack vectors can pan out if these programs run within a restricted environment.
To thwart easy compromise via security loopholes and crude implementation of Remote Desktop, you can resort to the following techniques.
- Make the most of Group Policies. The primary use case of the Group Policy feature comes down to specifying application whitelists and blacklists. As previously stated, though, this technique is not a one-size-fits-all remedy and has its drawbacks. Therefore, it is recommended to apply a combo of different restrictions. For example, consider allowing Microsoft-signed executables and blocking cmd.exe.
- Turn off Internet Explorer settings tabs. This is doable locally through the Windows registry.
- Restrict the use of Windows Help functionality. The built-in support feature can be abused to execute malicious scripts, so it should not be accessible from the RDP connection window. Consider using the Regedit GUI tool to turn it off.
- Disallow mounting local drives for RDP connections. If your company does not rely heavily on this permission, disabling it makes a whole lot of sense security-wise.
- Audit access to a remote computer’s local drives. You would be better off restricting this type of access while only keeping the user directories within reach.
Please note that Windows is not the only platform suffering from these attacks. Apple’s environment has also seen a huge increase in ransomware attacks related to remote desktops.
To recap, Remote Desktop is a mixed blessing. On the one hand, it helps organizations move on with their day-to-date activities in a pandemic world. On the other hand, it is a Pandora’s box full of loopholes for exploitation. Take the above information into account to ramp up the security of your company’s remote access practices.
David Balaban is a computer security researcher with over 17 years of experience in malware analysis and antivirus software evaluation. David runs the Privacy-PC.com project which presents expert opinions on contemporary information security matters, including social engineering, penetration testing, threat intelligence, online privacy, and white hat hacking. David has a strong malware troubleshooting background, with the recent focus on ransomware countermeasures.