#readwise # Linux Fundamentals - Remote Desktop Protocols in Linux ![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article0.00998d930354.png) ## Metadata - Author: [[Hack The Box]] - Full Title: Linux Fundamentals - Remote Desktop Protocols in Linux - URL: https://academy.hackthebox.com/module/18/section/1776 ## Summary Remote desktop protocols enable remote graphical access to systems in Windows, Linux, and macOS. Common protocols include Remote Desktop Protocol (RDP) for Windows and Virtual Network Computing (VNC) for Linux. The XServer is a part of the X Window System, allowing graphical communication on Unix systems. VNC is widely used for remote access and collaboration, offering various tools for secure connections. ## Highlights Two of the most common protocols for this type of access are: - `Remote Desktop Protocol` (`RDP`): Primarily used in Windows environments. RDP allows administrators to connect remotely and interact with the desktop of a Windows machine as if they were sitting right in front of it. ^4ogjdy - `Virtual Network Computing` (`VNC`): A popular protocol in Linux environments, although it is also cross-platform. VNC provides graphical access to remote desktops, allowing administrators to perform tasks on Linux systems in a similar way to RDP on Windows. ([View Highlight](https://read.readwise.io/read/01jn9br0pbwrp8ra6xa42cfdzx)) --- ### XServer The XServer is the user-side part of the `X Window System network protocol` (`X11` / `X`). The `X11` is a fixed system that consists of a collection of protocols and applications that allow us to call application windows on displays in a graphical user interface. X11 is predominant on Unix systems, but X servers are also available for other operating systems. Nowadays, the XServer is a part of almost every desktop installation of Ubuntu and its derivatives and does not need to be installed separately. When a desktop is started on a Linux computer, the communication of the graphical user interface with the operating system happens via an X server. The computer's internal network is used, even if the computer should not be in a network. The practical thing about the X protocol is network transparency. This protocol mainly uses TCP/IP as a transport base but can also be used on pure Unix sockets. The ports that are utilized for X server are typically located in the range of `TCP/6001-6009`, allowing communication between the client and server. When starting a new desktop session via X server the `TCP port 6000` would be opened for the first X display `:0`. This range of ports enables the server to perform its tasks such as hosting applications, as well as providing services to clients. They are often used to provide remote access to a system, allowing users to access applications and data from anywhere in the world. Additionally, these ports are also essential for the secure sharing of files and data, making them an integral part of the Open X Server. Thus an X server is not dependent on the local computer, it can be used to access other computers, and other computers can use the local X server. Provided that both local and remote computers contain Unix/Linux systems, additional protocols such as VNC and RDP are superfluous. VNC and RDP generate the graphical output on the remote computer and transport it over the network. Whereas with X11, it is rendered on the local computer. This saves traffic and a load on the remote computer. However, X11's significant disadvantage is the unencrypted data transmission. However, this can be overcome by tunneling the SSH protocol. For this, we have to allow X11 forwarding in the SSH configuration file (`/etc/ssh/sshd_config`) on the server that provides the application by changing this option to `yes`. ```sh cat /etc/ssh/sshd_config | grep X11Forwarding ``` > X11Forwarding yes With this we can start the application from our client with the following command: ```sh ssh -X [email protected] /usr/bin/firefox ``` ([View Highlight](https://read.readwise.io/read/01jn9c1jkvdcjvcq0mvm3qgmtj)) --- As we mentioned earlier, X11 is not a secure protocol by default because its communication is unencrypted. As such, we should pay attention and look for the those TCP ports (6000-6010) when we deal with Linux-based targets. Without proper security measures, an open `X server` can expose sensitive data over the network. For example, an attacker on the same network could read the contents of the `X server's` windows without the user's knowledge, making it unnecessary to them even perform traditional network sniffing. This vulnerability allows for serious security breaches. An attacker could potentially intercept sensitive information, such as passwords or personal data, by simply using standard X11 tools like `xwd` (which captures screenshots of X windows) and `xgrabsc`. On top of this, there have been other security vulnerabilities discovered over the years, relating to XServer libraries and the software itself. For example, in 2017, a collection of vulnerabilities were found in XOrg Server, an open source implementation of the X Window System. Stemming from weak, predictable, or brute-forceable session keys, the exploitation of which could allow an attacker to execute arbitrary code in another user’s Xorg session. A wide range of systems were affected, such as Unix, Red Hat Enterprise Linux, Ubuntu Linux, and SUSE Linux. These vulnerabilities became known as as CVE-2017-2624, CVE-2017-2625, and CVE-2017-2626. [This](https://www.x41-dsec.de/lab/advisories/x41-2017-001-xorg/) article provides an excellent summary. ([View Highlight](https://read.readwise.io/read/01jn9c4gp5pt30q2wbpzzxc2b7)) --- ### XDMCP The `X Display Manager Control Protocol` (`XDMCP`) protocol is used by the `X Display Manager` for communication through UDP port 177 between X terminals and computers operating under Unix/Linux. It is used to manage remote X Window sessions on other machines and is often used by Linux system administrators to provide access to remote desktops. XDMCP is an insecure protocol and should not be used in any environment that requires high levels of security. With this, it is possible to redirect an entire graphical user interface (`GUI`) (such as KDE or Gnome) to a corresponding client. For a Linux system to act as an XDMCP server, an X system with a GUI must be installed and configured on the server. After starting the computer, a graphical interface should be available locally to the user. One potential way that XDMCP could be exploited is through a man-in-the-middle attack. In this type of attack, an attacker intercepts the communication between the remote computer and the X Window System server, and impersonates one of the parties in order to gain unauthorized access to the server. ([View Highlight](https://read.readwise.io/read/01jn9c940qwk196v3zt3dnjcp6)) --- ### VNC `Virtual Network Computing` (`VNC`) is a remote desktop sharing system based on the RFB protocol that allows users to control a computer remotely. ([View Highlight](https://read.readwise.io/read/01jn9caqst41yqrpgsnwca52v1)) --- VNC is generally considered to be secure. It uses encryption to ensure the data is safe while in transit and requires authentication before a user can gain access. ([View Highlight](https://read.readwise.io/read/01jn9cbdyn893dkqdzbwgghhda)) --- Traditionally, the VNC server listens on TCP port 5900. So it offers its `display 0` there. Other displays can be offered via additional ports, mostly `590[x]`, where `x` is the display number. Adding multiple connections would be assigned to a higher TCP port like 5901, 5902, 5903, etc. ([View Highlight](https://read.readwise.io/read/01jn9cd11h2ys8ff9dwfyyvnkd)) --- For these VNC connections, many different tools are used. Among them are for example: - [TigerVNC](https://tigervnc.org/) - [TightVNC](https://www.tightvnc.com/) - [RealVNC](https://www.realvnc.com/en/) - [UltraVNC](https://uvnc.com/) The most used tools for such kinds of connections are UltraVNC and RealVNC because of their encryption and higher security. ([View Highlight](https://read.readwise.io/read/01jn9cd9y3yx09ndkyb6d98kt9)) --- To encrypt the connection and make it more secure, we can create an SSH tunnel over which the whole connection is tunneled. How tunneling works in detail we will learn in the [Pivoting, Tunneling, and Port Forwarding](https://academy.hackthebox.com/module/details/158) module. ```sh ssh -L 5901:127.0.0.1:5901 -N -f -l htb-student 10.129.14.130 ``` ([View Highlight](https://read.readwise.io/read/01jn9cfvrcwgtr01hn5tkpvf5d)) ---