# Linux Remote Management Protocols ## SSH [Secure Shell](https://en.wikipedia.org/wiki/Secure_Shell) (`SSH`) enables two computers to establish an encrypted and direct connection within a possibly insecure network on the standard port `TCP 22`. Therefore, we need to connect to it using the SSH protocol and authenticate ourselves to it. In total, OpenSSH has six different authentication methods: 1. Password authentication 2. Public-key authentication 3. Host-based authentication 4. Keyboard authentication 5. Challenge-response authentication 6. GSSAPI authentication We will take a closer look at and discuss one of the most commonly used authentication methods. In addition, we can learn more about the other authentication methods [here](https://www.golinuxcloud.com/openssh-authentication-methods-sshd-config/) among others. ### **SSH-Audit** ```shell-session eldeim@htb[/htb]$ git clone https://github.com/jtesta/ssh-audit.git && cd ssh-audit eldeim@htb[/htb]$ ./ssh-audit.py 10.129.14.132 # general (gen) banner: SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3 (gen) software: OpenSSH 8.2p1 (gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+ (gen) compression: enabled (zlib@openssh.com) # key exchange algorithms (kex) curve25519-sha256 -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76 (kex) curve25519-sha256@libssh.org -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62 (kex) ecdh-sha2-nistp256 -- [fail] using weak elliptic curves `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) ecdh-sha2-nistp384 -- [fail] using weak elliptic curves `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) ecdh-sha2-nistp521 -- [fail] using weak elliptic curves `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (kex) diffie-hellman-group-exchange-sha256 (2048-bit) -- [info] available since OpenSSH 4.4 (kex) diffie-hellman-group16-sha512 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73 (kex) diffie-hellman-group18-sha512 -- [info] available since OpenSSH 7.3 (kex) diffie-hellman-group14-sha256 -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73 # host-key algorithms (key) rsa-sha2-512 (3072-bit) -- [info] available since OpenSSH 7.2 (key) rsa-sha2-256 (3072-bit) -- [info] available since OpenSSH 7.2 (key) ssh-rsa (3072-bit) -- [fail] using weak hashing algorithm `- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28 `- [info] a future deprecation notice has been issued in OpenSSH 8.2: https://www.openssh.com/txt/release-8.2 (key) ecdsa-sha2-nistp256 -- [fail] using weak elliptic curves `- [warn] using weak random number generator could reveal the key `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62 (key) ssh-ed25519 -- [info] available since OpenSSH 6.5 ...SNIP... ``` 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](https://www.cvedetails.com/cve/CVE-2020-14145/), which allowed the attacker the capability to Man-In-The-Middle and attack the initial connection attempt. The detailed output of the connection setup with the OpenSSH server can also often provide important information, such as which authentication methods the server can use. ### **Change Authentication Method** ```shell-session eldeim@htb[/htb]$ ssh -v cry0l1t3@10.129.14.132 OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f 31 Mar 2020 debug1: Reading configuration data /etc/ssh/ssh_config ...SNIP... debug1: Authentications that can continue: publickey,password,keyboard-interactive ``` For potential brute-force attacks, we can specify the authentication method with the SSH client option `PreferredAuthentications`. ```shell-session eldeim@htb[/htb]$ ssh -v cry0l1t3@10.129.14.132 -o PreferredAuthentications=password OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f 31 Mar 2020 debug1: Reading configuration data /etc/ssh/ssh_config ...SNIP... debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: password cry0l1t3@10.129.14.132's password: ``` > Even with this obvious and secure service, we recommend setting up our own OpenSSH server on our VM, experimenting with it, and familiarizing ourselves with the different settings and options. We may encounter various banners for the SSH server during our penetration tests. 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`, we know that we can use both protocol versions SSH-1 and SSH-2, and we are dealing with OpenSSH server version 3.9p1. On the other hand, for a banner with `SSH-2.0-OpenSSH_8.2p1`, we are dealing with an OpenSSH version 8.2p1 which only accepts the SSH-2 protocol version. *** ## Rsync [Rsync](https://linux.die.net/man/1/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. 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. ### **Scanning for Rsync** ```shell-session eldeim@htb[/htb]$ sudo nmap -sV -p 873 127.0.0.1 Starting Nmap 7.92 ( https://nmap.org ) at 2022-09-19 09:31 EDT Nmap scan report for localhost (127.0.0.1) Host is up (0.0058s latency). PORT STATE SERVICE VERSION 873/tcp open rsync (protocol version 31) Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 1.13 seconds ``` ### **Probing for Accessible Shares** We can next probe the service a bit to see what we can gain access to. ```shell-session eldeim@htb[/htb]$ nc -nv 127.0.0.1 873 (UNKNOWN) [127.0.0.1] 873 (rsync) open @RSYNCD: 31.0 @RSYNCD: 31.0 #list dev Dev Tools @RSYNCD: EXIT ``` ### **Enumerating an Open Share** Here we can see a share called `dev`, and we can enumerate it further. ```shell-session eldeim@htb[/htb]$ rsync -av --list-only rsync://127.0.0.1/dev receiving incremental file list drwxr-xr-x 48 2022/09/19 09:43:10 . -rw-r--r-- 0 2022/09/19 09:34:50 build.sh -rw-r--r-- 0 2022/09/19 09:36:02 secrets.yaml drwx------ 54 2022/09/19 09:43:10 .ssh sent 25 bytes received 221 bytes 492.00 bytes/sec total size is 0 speedup is 0.00 ``` From the above output, we can see a few interesting files that may be worth pulling down to investigate further. We can also see that a directory likely containing SSH keys is accessible. 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](https://phoenixnap.com/kb/how-to-rsync-over-ssh) is helpful for understanding the syntax for using Rsync over SSH. *** ## R-Services R-Services are a suite of services hosted to enable remote access or issue commands between Unix hosts over TCP/IP. `R-services` span across the ports `512`, `513`, and `514` and are only accessible through a suite of programs known as `r-commands`. ### Commands
CommandService DaemonPortTransport ProtocolDescription
rcprshd514TCPCopy 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.
rshrshd514TCPOpens 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.
rexecrexecd512TCPEnables 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.
rloginrlogind513TCPEnables 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.
### **Scanning for R-Services** ```shell-session eldeim@htb[/htb]$ sudo nmap -sV -p 512,513,514 10.0.17.2 Starting Nmap 7.80 ( https://nmap.org ) at 2022-12-02 15:02 EST Nmap scan report for 10.0.17.2 Host is up (0.11s latency). PORT STATE SERVICE VERSION 512/tcp open exec? 513/tcp open login? 514/tcp open tcpwrapped Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 145.54 seconds ``` ### **Access Control & Trusted Relationships** 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)](https://debathena.mit.edu/trac/wiki/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. ### **Sample .rhosts File** ```shell-session eldeim@htb[/htb]$ cat .rhosts htb-student 10.0.17.5 + 10.0.17.10 + + ``` As we can see from this example, both files follow the specific syntax of ` ` or ` ` pairs. Additionally, the `+` modifier can be used within these files as a wildcard to specify anything. In this example, the `+` modifier allows any external user to access r-commands from the `htb-student` user account via the host with the IP address `10.0.17.10`. ### **Logging in Using Rlogin** ```shell-session eldeim@htb[/htb]$ rlogin 10.0.17.2 -l htb-student Last login: Fri Dec 2 16:11:21 from localhost [htb-student@localhost ~]$ ``` We have successfully logged in under the `htb-student` account on the remote host due to the misconfigurations in the `.rhosts` file. Once successfully logged in, we can also abuse the `rwho` command to list all interactive sessions on the local network by sending requests to the UDP port 513. ### **Listing Authenticated Users Using Rwho** ```shell-session eldeim@htb[/htb]$ rwho root web01:pts/0 Dec 2 21:34 htb-student workstn01:tty1 Dec 2 19:57 2:25 ``` From this information, 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. ### **Listing Authenticated Users Using Rusers** To provide additional information in conjunction with `rwho`, we can issue the `rusers` command. This will give us a more detailed account of all logged-in users over the network, including information such as the username, hostname of the accessed machine, TTY that the user is logged in to, the date and time the user logged in, the amount of time since the user typed on the keyboard, and the remote host they logged in from (if applicable). ```shell-session eldeim@htb[/htb]$ rusers -al 10.0.17.5 htb-student 10.0.17.5:console Dec 2 19:57 2:25 ``` As we can see, R-services are less frequently used nowadays due to their inherent security flaws and the availability of more secure protocols such as SSH. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://eldeim.gitbook.io/brain_fuck/notes/certifications/eastereggs/htb-cpts/footprinting/linux-remote-management-protocols.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.