SSH and RDP: Remote Access solutions and vulnerabilities.
Remote access has increased in use over the last several months. We see an increase in the use of Remote Desktop Protocol (RDP) and Secure Shell (SSH) within mainstream uses in a variety of fields and industries. However, alongside the increase of Remote Access, we also see the exposure of vulnerabilities. Whenever a remote access connection occurs, it needs to hold solid security foundations to mitigate risks and allow for a secure connection between the user and the workstation/endpoint. One factor of remote access taken into account is the authentication of users. Upon granting users specific access from anywhere around the world, the connection needs to be secured not to expose or exploit vulnerable resources within your organization. Another factor is endpoint security. Recent studies show a 127 % increase in RDP endpoint security, where unsecured RDP endpoints are the main target within online services. Increase IT systems to be more prone to attacks and vulnerabilities.
Whether you’re using RDP or SSH, your procedure needs to be secure. To compromise a solution, we must first understand what these protocols are and how they work. From there, we can pinpoint vulnerabilities and create an adaptive solution for the specific infrastructure used within your company.
What is SSH?
Secure Shell protocol or simply SSH runs secured network services over insecure networks. The SSH concept is the protocol to run as an application on top of the TCP/IP layer and implemented through the separate client and server application. Enabling authentication and negotiation of protocols before establishing a secure connection. SSH, in essence, provides:
– Cryptographic host authentication.
– User authentication.
– Strong encryption.
– Solid data integrity protection.
– Multi tunneling of data channels.
SSH can be used for secure remote (SR) logins, SR command execution, and SR file transfer with such features. As well as cryptographic key control, TCP port forwarding, and authentication agents, with several other components from data compression and access control.
SSH Breakdown – How does it Work?
In this example, we will show how the SSH protocol authentication and encryption works.
Step 1.
The client host connects to the server hosts. During the exchange, both swap protocol versions they support.
Step 2.
The Server sends the authentication information and the session parameters to the Client; this includes the Server’s public key components of public and private key pairs and a list of encryptions, compressions, and authentications modes that the Server supports.
Step 3.
The client host checks the Server’s public key against the client key it holds in the public key library. After identifying the Server, the secret session key is generated.
Step 4.
Once the secret session key is both on the server and client host, the encryption and integrity check is enabled during this stage.
Step 5.
The client host and the user can now be authenticated to the server host without interception of the transmission between the two. After authentication, the appropriate access t the Server is granted to the user, and the two machines are connected under a secure and encrypted connection. Enabling a secure tunnel for transmissions through the internet gateway.
What is RDP?
Remote Desktop Protocol is used within Windows OS. It is used to access physical or virtual servers. Unlike SSH, RDP has a graphical user interface. RDP is designed to connect over the internet to another machine. Its functionality is to transmit data from the output device, e.g., monitor screen/display, mouse, and keyboard logs, to the input device (local machine).
RDP Breakdown – How does it Work?
The RDP protocol stack consists of ISO Transport Serice (TKPT), connection-Oriented Transport Protocol (X.224), and the Multipoint Communication Service (T.125 MCS). TPKT enables the exchange of information units, while X.224 provides the connection-mode transport service used in the initial connection request and response within the RDP. The sending and receiving process is quite similar to that of the Seven-Layer OSI model, where we see data from an application or service being transmitted and passed through the protocol stack.
The RDP connection goes through several stages between the Client and the Server. Here is a short broken-down example of how the connection occurs.
1. Connection – occurs by using the X.224 Connection request PDU (protocol data unit). The Client sends a X.224 connection request to the Server where the packet sent contains RDP Negotiation Request and the security protocols that the Client supports, i.e., RSA RC4 encryption, TLS, RDSTLS, or CredSSP. Once the Server confirms the connection, it chooses the security protocol from the Client’s protocol selection. All subsequent data is wrapped in X.224 Data PDU from this point.
2. Basic Setting Exchange – After connecting with the Server, an exchange of basic settings occurs between the Client and the Server using MSC Connect Initial and Connect Response PDU. Information such as Core Data, Security Data, and Network Data fall under the basic settings category.
Core Data – Version of RDP, keyboard information, hostname, client software information, Desktop resolution, etc.
Security Data – encryption methods, size of session keys, server certificate, and Server random for session key creation.
Network Data – holds information regarding the allocated virtual channels and requested channels, along with details of the request type, IDs, responses, etc.
3. Channel Connection – Once basic settings have been exchanged and a list of virtual channels has been established, the following stage makes sure that all channels connection occurs.
MCS Erect Domain Request
MCS Attach User Request
MCS Attach User Confirm
MSC Channel Join Request and Confirmations
4. Security Commencement
The security commencement stage initiates the Security Exchange PDU, which contains the random encrypted public key from the Client with the Server. Both use random numbers to create encrypted session keys, where the subsequent RDP traffic can be encrypted in further stages.
5. Security Settings Exchange
Enables encrypted client Info PDU data to be sent from the Client to the Server. The data consists of user domain, username, password, working directory, compression types, etc.
6. Licensing
Licensing stage allows for authorized users to connect to the terminal server.
7. Capabilities Exchange
The Server sends Demand Active PDU where supported capabilities are sent to the Client. This usually covers OS version, compression input, bitmap codecs, virtual channels, etc. Then the Server can send a Monitor Layout PDU to understand the display monitors on the Server. At this stage, the Client responds with a Confirm Active PDU.
8. Connection Finalization
The second to last stage finalizes the connection between the Client and the Server. At this stage, the Client sends specific PDUs to the Server and vice versa.
The following PDUS are:
Client/Server synchronize PDU – syncs user identifiers between Client and Server
Client/Server Control PDU: send the following PDU to indicate the shared control over a session.
Client Control PDU (request/grant Control): The Client sends a request for control while the Server grants the request.
Persistent Key List PDU/PDUs: an optional stage where the Client sends a list of keys, each identifying the cached bitmap, allowing more graphical output from the Server to the Client.
9. Data Exchange
After all the stages and PDU exchanges, the primary data is sent between the Client and the Server, where the Server will input data and graphic data. RDP connection is now ready to be used by the end-user.
SSH and RDP: Comparison, Security, and Vulnerability
As we now understand how RDP and SSH work, let’s focus on the security and vulnerability of the two protocols. Both RDP and SSH are used to gain access to a specific machine remotely. We now know that we can use RDP and SSH to connect securely into an on-premise infrastructure and cloud-based servers. Though they are quite similar, there are fundamental differences between them. SSH is considered more secure because it does not require additional tools such as a Virtual Private Network (VPN) or Multi-factor authentication (MFA) as RDP does. Moreover, SSH is operated within the terminal, making it hard for non-IT personnel to conduct operations with SSH. While RDP is based on a Graphical User Interface (GUI), allowing for easier use and operations for any beginner. Despite the differences, both still hold vulnerabilities increasing the risk of exploitation. Choosing the right connection method is crucial for any organization and understanding these vulnerabilities helps to secure your organization from cyber threats and mitigate future risks.
SSH and RDP: Common Vulnerability and Exposures
CVE-2019-0708: Enabled remote code execution within the RDP protocol. An unauthenticated attack could connect to the target system using RDP and send crafted requests. Allowing for the attack to execute arbitrary code on the target system.
CVE-2021-34718: Found within the SSH Server process in Cisco IOS XR software, it allows an authenticated user to overwrite and read arbitrary files on the local device. Based on the insufficient validation arguments. An attack with lower-level privileged could elevate their privileges and retrieve and upload files on the device when successfully exploited.
Though this is just the surface of the vulnerabilities for RDP and SSH, some tools help prevent attacks from exposed or vulnerable protocols. Solutions/tools like Privileged Access Management (PAM) help to establish a secure connection with both RDP and SSH protocols and assist in preventing attacks based on protocol exposure with a grid-like environment to valuable resources within the organizations. Suppose a protocol vulnerability is found based on policies and access of the user set by PAM. The attacker won’t be able to move laterally within the company’s infrastructure or alter any system data. PAM solutions are great for privileged and non-privileged users and help safeguard your administrators while preventing any data breaches or misuses of access.
