☑️Linux Remote Management Protocols - 22,873,512,513,514
These protocols are most of the times exposed in the public network for the ease of remote management. (juicy targets)
Hacking RSync: https://book.hacktricks.xyz/network-services-pentesting/873-pentesting-rsync
SSH
Secure Shell (SSH) enables two computers to establish an encrypted and direct connection within a possibly insecure network on the standard port TCP 22. there are two competing protocols: SSH-1 and SSH-2.
SSH-2, also known as SSH version 2, is a more advanced protocol than SSH version 1 in encryption, speed, stability, and security. For example, SSH-1 is vulnerable to MITM attacks, whereas SSH-2 is not.
OpenSSH has six different authentication methods:
Password authentication
Public-key authentication
Host-based authentication
Keyboard authentication
Challenge-response authentication
GSSAPI authentication
Public Key Authentication
In a first step, the SSH server and client authenticate themselves to each other. The server sends a certificate to the client to verify that it is the correct server. Only when contact is first established is there a risk of a third party interposing itself between the two participants and thus intercepting the connection. Since the certificate itself is also encrypted, it cannot be imitated. Once the client knows the correct certificate, no one else can pretend to make contact via the corresponding server.
After server authentication, however, the client must also prove to the server that it has access authorization. However, the SSH server is already in possession of the encrypted hash value of the password set for the desired user. As a result, users have to enter the password every time they log on to another server during the same session. For this reason, an alternative option for client-side authentication is the use of a public key and private key pair.
The private key is created individually for the user's own computer and secured with a passphrase that should be longer than a typical password. The private key is stored exclusively on our own computer and always remains secret. If we want to establish an SSH connection, we first enter the passphrase and thus open access to the private key.
Public keys are also stored on the server. The server creates a cryptographic problem with the client's public key and sends it to the client. The client, in turn, decrypts the problem with its own private key, sends back the solution, and thus informs the server that it may establish a legitimate connection. During a session, users only need to enter the passphrase once to connect to any number of servers. At the end of the session, users log out of their local machines, ensuring that no third party who gains physical access to the local machine can connect to the server.
Default Configuration
sshd_config file is used to configure SSH server (we can also use GUI). The default configuration doesnt have much, but it includes X11 forwarding, which contained a command injection vulnerability in version 7.2p1 of OpenSSH in 2016.
Dangerous Settings
Even though SSH is very secure some mistakes in configuration can make it vulnerable.
PasswordAuthentication yes
Allows password-based authentication.
PermitEmptyPasswords yes
Allows the use of empty passwords.
PermitRootLogin yes
Allows to log in as the root user.
Protocol 1
Uses an outdated version of encryption.
X11Forwarding yes
Allows X11 forwarding for GUI applications.
AllowTcpForwarding yes
Allows forwarding of TCP ports.
PermitTunnel
Allows tunneling.
DebianBanner yes
Displays a specific banner when logging in.
Allowing password authentication allows us to brute-force a known username for possible passwords. Many different methods can be used to guess the passwords of users.
Footprinting SSH
One of the tools we can use to fingerprint the SSH server is ssh-audit. It checks the client-side and server-side configuration and shows some general information and which encryption algorithms are still used by the client and server. Of course, this could be exploited by attacking the server or client at the cryptic level later.
The first thing we can see in the first few lines of the output is the banner that reveals the version of the OpenSSH server. The previous versions had some vulnerabilities, such as CVE-2020-14145, which allowed the attacker the capability to Man-In-The-Middle and attack the initial connection attempt.
Changing Authentication Methods
For potential brute-force attacks, we can specify the authentication method with the SSH client option PreferredAuthentications.
By default, the banners start with the version of the protocol that can be applied and then the version of the server itself. For example, with SSH-1.99-OpenSSH_3.9p1.
Assessment
If we can get the private key somehow (specially useful when passwork authentication isn't allowed), lets say through ftp or other ways, we can log in with the private key using -i option in SSH.
RSync
Rsync is a fast and efficient tool for locally and remotely copying files. It can be used to copy files locally on a given machine and to/from remote hosts. It is highly versatile and well-known for its delta-transfer algorithm. It reduces data sent by sending only the differences between the source files and the older version of the files that reside on the destination server. It is often used for backups and mirroring.
By default, it uses port 873 and can be configured to use SSH for secure file transfers by piggybacking on top of an established SSH server connection.
This guide covers some of the ways Rsync can be abused, most notably by listing the contents of a shared folder on a target server and retrieving files. Pentesting RSync can be done without authentication and other time it will require credentials (try creds re-use).
If we know the port RSync is running we can probe for information:
Enumerating the dev share:
From here, we could sync all files to our attack host with the command rsync -av rsync://127.0.0.1/dev
If Rsync is configured to use SSH to transfer files, we could modify our commands to include the -e ssh flag, or -e "ssh -p2222" if a non-standard port is in use for SSH. This guide is helpful for understanding the syntax for using Rsync over SSH.
R-Services
It was a de facto method of client server communication before SSH. R-services span across the ports 512, 513, and 514 and are only accessible through a suite of programs known as r-commands.
They are most commonly used by commercial operating systems such as Solaris, HP-UX, and AIX. While less common nowadays, we do run into them from time to time during our internal penetration tests so it is worth understanding how to approach them.
The R-commands suite consists of the following programs:
rcp (remote copy)
rexec (remote execution)
rlogin (remote login)
rsh (remote shell)
rstat
ruptime
rwho (remote who)
The table below will provide a quick overview of the most frequently abused commands, including the service daemon they interact with, over what port and transport method to which they can be accessed, and a brief description of each.
rcp
rshd
514
TCP
Copy a file or directory bidirectionally from the local system to the remote system (or vice versa) or from one remote system to another. It works like the cp command on Linux but provides no warning to the user for overwriting existing files on a system.
rsh
rshd
514
TCP
Opens a shell on a remote machine without a login procedure. Relies upon the trusted entries in the /etc/hosts.equiv and .rhosts files for validation.
rexec
rexecd
512
TCP
Enables a user to run shell commands on a remote machine. Requires authentication through the use of a username and password through an unencrypted network socket. Authentication is overridden by the trusted entries in the /etc/hosts.equiv and .rhosts files.
rlogin
rlogind
513
TCP
Enables a user to log in to a remote host over the network. It works similarly to telnet but can only connect to Unix-like hosts. Authentication is overridden by the trusted entries in the /etc/hosts.equiv and .rhosts files.
The /etc/hosts.equiv file contains a list of trusted hosts and is used to grant access to other systems on the network. When users on one of these hosts attempt to access the system, they are automatically granted access without further authentication.
Footprinting R-Services
The primary concern for r-services, and one of the primary reasons SSH was introduced to replace it, is the inherent issues regarding access control for these protocols. R-services rely on trusted information sent from the remote client to the host machine they are attempting to authenticate to. By default, these services utilize Pluggable Authentication Modules (PAM) for user authentication onto a remote system; however, they also bypass this authentication through the use of the /etc/hosts.equiv and .rhosts files on the system. The hosts.equiv and .rhosts files contain a list of hosts (IPs or Hostnames) and users that are trusted by the local host when a connection attempt is made using r-commands. Entries in either file can appear like the following:
Note: The hosts.equiv file is recognized as the global configuration regarding all users on a system, whereas .rhosts provides a per-user configuration.
Using rlogin
we can see that the htb-student user is currently authenticated to the workstn01 host, whereas the root user is authenticated to the web01 host. We can use this to our advantage when scoping out potential usernames to use during further attacks on hosts over the network. However, the rwho daemon periodically broadcasts information about logged-on users, so it might be beneficial to watch the network traffic.
We can also use rusers to list all users
Last updated