Remote access tools were created to allow dumb terminals to remotely access centrally located mainframe computers. With these remote access tools, users could access their data and compute resources concurrently and without having to walk up to the mainframe room.
Common remote access tools used today include Microsoft Remote Desktop, TeamViewer, Telnet, Citrix XenDesktop and VNC. Now the raison d'être of these remote access tools is not mainframe access, but to allow one user to control another user’s desktop. Typical use cases are:
- IT support asks for permission to control a user’s desktop to troubleshoot an issue.
- A user leaves the remote access tools running on the work desktop so that she can access the desktop to work from home or while traveling.
- A lab administrator runs remote access tools on desktops so that trainees can access these desktops remotely during their training.
- Quality testing team runs remote access tools on their lab workstations to perform quality assurance tests.
- Workstations running in the public or private cloud have remote access software installed because by definition these workstations are running in the cloud, where users cannot physically access them.
The question then is, when remote access tools enable so many valid use cases, which are especially relevant in this any device anywhere productivity-focused world, what is all this fuss about security issues? And if there indeed are security issues, don’t vendors address them, for example, Microsoft, Citrix and Amazon Web Services?
Security issues with remote access tools
All kinds of software, including remote access tools, may have potential vulnerabilities that can be exploited by attackers. Such vulnerabilities do not make the remote access tools any more a threat vector than other software; rather, what makes remote access tools a unique challenge is the potential for giving complete control of the desktop to another user. If the user at the other end is benign, these tools can enable a vast variety of helpful use cases. However, if the user controlling the desktop happens to be an adversary, he now has a very powerful tool at his disposal from which he can launch a multitude of attacks in the network. So in that sense, think of remote access tools as the equivalent of nuclear energy. Harnessed correctly, it can be a huge energy source that can reduce pressure on non-renewable sources of energy, such as coal. However, in the hands of a savvy and malicious user, they can be used to wreak havoc.
Addressing the security issues: vendor versus user responsibility
Vendors (like Microsoft for Microsoft Remote Desktop) are responsible for addressing security vulnerabilities with their tools. But that’s not the same as security challenges created by giving these tools free rein on your network. The biggest security issues arise from unrestricted access to use the tools, which means a higher potential for malicious actors to abuse them.
Here are two examples that show how remote access tools can fall into the wrong hands. The first example is a made-up scenario for illustration purposes, while the second is a real-life example.
Hypothetical scenario: Employee uses remote access tools for enhanced productivity
Derek is a web designer in the marketing department of a manufacturing organization. He uses tools like Adobe Photoshop to design banners and flyers. The software he uses is installed on his work desktop, and so he cannot use it from home.
To get around this issue, Derek installs a RealVNC Server on his desktop. Derek’s organization’s perimeter firewall permits incoming connections on port 5900, the default RealVNC Server port. From home, Derek is able to log in to the RealVNC Server, and now he is able use the software installed on his work machine, like Adobe Photoshop.
To keep his life simple, Derek uses the same password for social media, his VPN connection, and his RealVNC Server login.
We all know that passwords get stolen. The Verizon Data Breach Investigation Report (DBIR) 2016, which investigated more than 100,000 security incidents, noted that “63% of confirmed data breaches involved weak, default or stolen passwords.”
So the risk to Derek’s organization is that if Derek’s credentials get stolen, a malicious actor can take control of Derek’s machine remotely, and download data, infect the machine for future use, or snoop around the network to gather valuable information.
Here’s an example of how this happened in real life.
Real-life attack: The Carbanak Cybergang Attack
This is how The New York Times reported the story last year:
“An A.T.M. in Kiev started dispensing cash at seemingly random times of day. No one had put in a card or touched a button. Cameras showed that the piles of money had been swept up by customers who appeared lucky to be there at the right moment.”
But there was much more than luck at play. A detailed analysis revealed that this was the result of a well-coordinated and sophisticated attack on banks, with the following modus operandi.
The attackers started by sending bank employees emails with an attachment. The attachment was a CPL file compressed using the Roshal Archive (.rar) format, which exploited vulnerabilities in Microsoft Office and Microsoft Word. After the vulnerability was successfully exploited, it installed Carbanak on the victim's system. Carbanak is a remote backdoor designed for espionage, data exfiltration and to provide remote access to infected machines. The attackers then installed additional software, such as the Ammyy Remote Administration Tool.
Once the attackers successfully compromised the victim´s network, the primary internal destinations were money processing services, ATMs and financial accounts. For example, the ATM network was used to dispense cash from certain ATMs at certain times where money mules were ready to collect it.
As part of the attack´s reconnaissance phase, video recordings of the activities of bank employees, particularly system administrators, were made. The videos were sent to the command and control (C2) server.
The attackers abused these services by impersonating legitimate local users who had the permissions to perform the actions later reproduced by the cybercriminals.
How much did this cost? The Times report said:
“The scope of this attack on more than 100 banks and other financial institutions in 30 nations could make it one of the largest bank thefts ever. [There is] evidence of $300 million in theft through clients, and the total could be triple that.”
Preventing the Carbanak Cybergang Attack
As you saw above, modern attacks can be very sophisticated. They cannot be prevented with a simplistic approach. The Palo Alto Networks whitepaper Disrupting The Attack Lifecycle At Every Stage says:
“When cyberattackers strategize their way to infiltrate an organization’s network and exfiltrate data, they follow the series of stages that comprise the attack lifecycle. For attackers to successfully complete an attack, they must progress through each stage. Blocking adversaries at any point in the cycle breaks the chain of attack. To protect a company’s network and data from attack, prevention must occur at each stage to block the attackers’ ability to access and move laterally within the organization or steal sensitive data.”
Gaining visibility into and preventing unauthorized usage of remote administration tools would have helped tremendously in preventing this attack. Here are some questions that the security team could have asked:
- Which remote administration tools are being used on our network?
- Why shouldn’t we block all users from using these tools? If an exception is needed, let’s say for IT administrators, we will let them raise a request and allow justification-based controlled access.
- Do we see any anomalies in the usage of these tools, for example, access at unusual times of day, unusual frequency of access, and so on?
Palo Alto Networks Next-Generation Firewall uses App-ID to provide complete visibility into and control over all traffic, including encrypted traffic. Close to 100 remote access applications are identified and can be controlled. Use these capabilities in your breach prevention toolkit.
What should I do about the current remote access tools on my network?
- Step 1: Find out if remote access tools are being used on your network. A next-generation firewall provides such reports on-demand.
- Step 2: Discuss with your security team members if these remote access tools must be allowed. Help create awareness and a business policy for the usage of these tools.
- Step 3: Block access to remote access tools in general. Allow justification-based access to select users who need it.
Additional Resources
- Disrupting The Attack Lifecycle
- 10 Things Your Next Firewall Must Do
- App-ID Tech Brief
- Register for the “Let Application Controls Do Their Job and Prevent Breaches” webinar on June 6, 2017