Linux Remote Management Protocols
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.
Therefore, we need to connect to it using the SSH protocol and authenticate ourselves to it. In total, OpenSSH has six different authentication methods:
Password authentication
Public-key authentication
Host-based authentication
Keyboard authentication
Challenge-response authentication
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 among others.
SSH-Audit
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, 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
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-interactiveFor potential brute-force attacks, we can specify the authentication method with the SSH client option PreferredAuthentications.
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 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
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 secondsProbing for Accessible Shares
We can next probe the service a bit to see what we can gain access to.
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: EXITEnumerating an Open Share
Here we can see a share called dev, and we can enumerate it further.
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.00From 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 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
Command
Service Daemon
Port
Transport Protocol
Description
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.
Scanning for R-Services
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 secondsAccess 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) 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.equivfile is recognized as the global configuration regarding all users on a system, whereas.rhostsprovides a per-user configuration.
Sample .rhosts File
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 <username> <ip address> or <username> <hostname> 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
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
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).
eldeim@htb[/htb]$ rusers -al 10.0.17.5
htb-student 10.0.17.5:console Dec 2 19:57 2:25As 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.
Last updated