The COVID-19 virus pandemic has radically changed the work model of the staff of many organizations on a voluntary-compulsory basis, “rewarding” most of them with the status of “remote”, and some, even “remote worker”.
If before the “mega-epidemic” employees performed their work duties from the office using the corporate infrastructure controlled by the company's IT department, then during self-isolation, the “lion's” share of office work began to be performed from home devices using the Remote Desktop Protocol (RDP). Popular, like the OS itself from MS, but, as the list of vulnerabilities suggests, not the most secure protocol. We'll talk about how to protect your RDP from outside attacks.
Unfortunately, to consider the features of each of the vulnerabilities to which I would like to draw your attention, one article is definitely not enough for me, so in this one I will limit myself to the details of the life cycle of one of the last.
RDP vice versa
In 2018, in the course of research into the security of the Remote Desktop Protocol, Check Point Research specialists discovered multiple vulnerabilities in three popular clients designed to work with it:
- RDP client from Microsoft / Mstsc.exe
- rdesktop
- FreeRDP
In total, 25 vulnerabilities were discovered, including critical ones, including those that allow an attacker to change the usual direction of communication and attack a client computer, that is, to carry out an attack using a reverse RDP connection (reverse RDP attack).
In Microsoft's RDP client, this vulnerability lurked in the shared clipboard between the client and the server. Which, when using the buffer during the connection, allowed the server with the exploit to "include" its own files in the user-initiated exchange process. And the functionality of the path traversal attack is to determine the “final destination” for the file any place on the client computer. For example, without unnecessary notifications, send an executable file (miner, encryption program) to the startup folder of the user's computer to launch it at the next system reboot.
Demonstration of the vulnerability from Check Point Research
The fact of which was reported to Microsoft (MSRC) on October 16, 2018. In response to which, on December 17, 2018, the addressee replied:
“Thank you for your submission. We determined your finding is valid but does not meet our bar for servicing. For more information, please see the Microsoft Security Servicing Criteria for Windows (https://aka.ms/windowscriteria). "
“Thank you for submitting your application. We have determined that your find is valid but does not meet our level of service. For more information, see Microsoft Servicing Criteria for Windows (https://aka.ms/windowscriteria).
As a result, this vulnerability did not receive its ID and patch for its fix. a source
HyperRDP
After the publication of information about this vulnerability, Check Point Research employees began to receive many comments and questions, one of which aroused genuine interest and prompted them to return to further research and look at the vulnerability from a "different angle", namely: can the vulnerability of the Microsoft RDP client be used in Microsoft Hyper-V?
As a result of further study, it turned out that at the heart of the GUI for managing VM - Hyper-V manager, RDP technology is secretly used, in extended sessions of which, as well as in the properties of the remote desktop, it is possible to enable a shared clipboard. And as a consequence, the same vulnerability is present!
Demonstration of a vulnerability in Hyper-V from Check Point Research
About this, Check Point Research employees talked about this in their blog, as well as at the Black Hat USA 2019 conference .
Vulnerability presentation at Black Hat USA 2019
And, of course, MSRC reported . This time, Microsoft opened a ticket and in October 2019 released a patch to fix this vulnerability, which received ID: CVE-2019-0887 . a source
Inscrutable ways
After analyzing the effectiveness of the patch, when Check Point Research experts were about to assign the vulnerability the "closed" status, they were contacted by a Mac OS RDP Client user with information about the features of the client's behavior after installing the patch from MS.
In the process of prototyping the RDP connection model using this client, it became clear that the patch itself has security holes that allow you to bypass the protection and recreate the original exploit. This was reported to the MSRC .
In February 2020, Microsoft rallied and released a patch to fix this CVE-2020-0655 vulnerability ., which, according to experts at Check Point Research, has not fully solved the problem of path traversal attacks, in particular, for the Windows API. Microsoft announced about this "joint" has not yet commented on this situation. a source
So what…
As the astute reader might notice, a compromised RDP server is required to successfully carry out this type of attack. And you can "get" it in three ways:
- Create your own and pass it off as legitimate
- Access the existing one and compromise it
- Hybrid
A relatively safe, optimal cost and provisioning speed option in today's realities would be to "take over" a cloud or VPS / VDS server rented from a service provider. And there are three main reasons for this:
- Each rented virtual server running Windows is already an RDP server by default
- Each rented virtual server running Windows, as a rule, already has an RDP account with admin rights and a single login for all users.
- As a rule, RDP access to the virtual server is carried out through the TCP port available on the public IP address: 3389.
Actually, this port "sticking out" is probably the very "red rag" for a cyber attacker who wants to take over some virtual server, picking up a password for it using a simple automated brute-force method. Or as it is also called a brute force attack.
For reference: An example of an increase in the number of attacks from the Bruteforce.Generic.RDP family, February - April 2020 from Kaspersky Lab.
a source
… farther
In order not to become a victim of the above situations, you can, of course, change account settings and standard RDP ports, block unauthorized connection attempts using Windows firewall or third-party programs such as IPBAN , use encryption and certificates, and much, much more. But for me, the easiest and fastest way to secure an RDP connection to a newly created server is to allow RDP access to it only from hosts from a trusted network.
In RUVDS, this requires three simple steps:
- Combine a virtual server with computers that need to access it via RDP with a virtual private network. I am using - ZeroTier
- :
.
:
—
— . — ZeroTier.
— RDP- . . - RDP- IP- .
On this I want to take a leave and advise you to monitor the "health" of the RDP connection of your virtual server. For, since CVE-2020-0655, three more vulnerabilities with reverse RDP-attack functionality have appeared .
