TL;DR

Synced is a Tier 0 box that teaches rsync enumeration from scratch. A full TCP sweep finds only one open port: 873/tcp (rsync). Listing rsync modules reveals a single public share with anonymous access and no password. Inside it: flag.txt in 33 bytes. Attempts to write to the share, traverse outside its root, and brute-force other module names all fail cleanly. The lesson: rsync, like FTP, can be configured for anonymous read access — and that makes it an excellent data-exfiltration target when sensitive files are placed inside the share.

Recon

1. Liveness check

$ ping -c 2 10.129.228.37
64 bytes from 10.129.228.37: icmp_seq=0 ttl=63 time=35.050 ms
64 bytes from 10.129.228.37: icmp_seq=1 ttl=63 time=50.741 ms

Host is alive, TTL=63 → Linux. ICMP not filtered here.

2. Quick scan of common ports — nothing

$ nmap -sT -sV -sC -p 21,22,23,25,53,80,443,445,3306 10.129.228.37
All scanned ports are closed.

None of the usual suspects. Proceed to full sweep.

3. Full TCP SYN sweep

$ sudo nmap -sS -p- --min-rate 10000 -T5 10.129.228.37
PORT    STATE    SERVICE
873/tcp open     rsync

873/tcp — rsync daemon. All other 65532 ports are closed or filtered.

4. Service version detection

$ sudo nmap -sV -p 873 10.129.228.37
PORT    STATE SERVICE VERSION
873/tcp open  rsync   (protocol version 31)

rsync protocol version 31 — corresponds to rsync 3.1.x. No known authentication bypass CVEs. The risk here is operational (anonymous access configured), not a software vulnerability.

Foothold

Dead end #1 — brute-forcing rsync module names

Before using the clean path, tried to discover additional (possibly password-protected) modules:

for mod in private backup home data share files root www admin web tmp etc; do
    result=$(rsync rsync://10.129.228.37/$mod 2>&1)
    echo "$mod: $result"
done

Result for every name except public: @ERROR: Unknown module 'X'. Only public exists. No hidden modules with authentication.

Dead end #2 — writing to the share

echo "test" > /tmp/test.txt
rsync /tmp/test.txt rsync://10.129.228.37/public/test.txt
# rsync: error: read: Connection reset by peer

The server immediately resets the connection on any write attempt. The public module is configured read only = true in rsyncd.conf.

Dead end #3 — path traversal

rsync rsync://10.129.228.37/public/../etc/passwd
# rsync: change_dir "/etc" (in public) failed: No such file or directory (2)

Path traversal is sanitized. The module root is a chroot-equivalent; .. traversal is mapped to within the module directory which has no etc subdirectory.

Working approach — enumerate and download

List the module’s contents:

$ rsync rsync://10.129.228.37/
public         	Anonymous Share

$ rsync -av --list-only rsync://10.129.228.37/public/
drwxr-xr-x         4096 2022/10/25 00:02:23 .
-rw-r--r--           33 2022/10/24 23:32:03 flag.txt

Flags:

  • rsync:// — rsync daemon URI scheme (as opposed to SSH-based user@host:path)
  • -av — archive mode (preserves permissions) and verbose
  • --list-only — show file listing without downloading

Download the flag:

rsync rsync://10.129.228.37/public/flag.txt ./flag.txt
cat ./flag.txt
[REDACTED]

Why this works: rsync modules can be configured with auth users = (empty) or no authentication directive at all, allowing any connecting client to access the share without a password. This is analogous to anonymous FTP.

Privilege Escalation

N/A — Starting Point Tier 0 box. The rsync module is read-only; there is no SSH service reachable, and no path to a shell exists from rsync alone. The flag is the objective and it is directly accessible from the anonymous share.

What’s actually broken

  1. Anonymous rsync module with no authentication. The rsyncd.conf module has no auth users or secrets file directive, making it world-readable. Anyone who can reach port 873 can list and download all files in the module.
  2. Flag (sensitive file) placed in the anonymous module root. In production this would be backup archives, configuration files, or source code.
  3. rsync daemon exposed on a publicly routable IP. The rsync daemon (rsyncd) is a synchronization service meant for trusted networks. It should never be directly Internet-facing without authentication and strict IP allowlisting.

Remediation (the boring half)

Add authentication to the rsync module in /etc/rsyncd.conf:

[public]
    path = /srv/rsync/public
    comment = Public Share
    read only = yes
    auth users = rsync_user
    secrets file = /etc/rsyncd.secrets

Create the secrets file (mode 600):

echo "rsync_user:StrongPassphrase2024!" > /etc/rsyncd.secrets
chmod 600 /etc/rsyncd.secrets

Or block access entirely and use SFTP over SSH instead:

# Disable rsyncd
systemctl disable rsync
systemctl stop rsync

Firewall:

ufw deny 873
ufw allow from 10.0.1.0/24 to any port 873  # only if needed for internal backups

Lessons learned

  • rsync protocol version in nmap tells you the tool version range. Protocol version 31 corresponds to rsync 3.1.x. This helps quickly check if known CVEs apply before going further.
  • rsync rsync://IP/ lists available modules. The most important rsync command to remember — enumerate modules first. Module names are the access points; some may have no auth, some may require a password.
  • Port 873 is not in nmap’s top-1000. Like Redis on 6379 and MongoDB on 27017, rsync on 873 requires a full -p- sweep to discover. Always run the full scan.
  • Read-only + no auth is still dangerous. “They can’t write, only read” is not a security argument for a network service containing backups or configs. Read access to your backup archive means the attacker has your data.

References