Re: [PLUG] Malware Webshell Infection.

Here's a visual demonstration.

[bts@dawid ~]$ systemctl status rsyncd.service | grep -E '^\s*(Active|Loaded):'
Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; disabled; preset: disabled)

Active: inactive (dead)
[bts@dawid ~]$ systemctl cat rsyncd.service | grep -E '^ExecStart='
ExecStart=/usr/bin/rsync --daemon --no-detach
[bts@dawid ~]$ pgrep rsync
[bts@dawid ~]$ echo $?
1

As shown, rsync -- specifically, rsyncd.service, rsync --daemon -- is not running whatsoever.

So let's make a 10GiB test file filled with junk data:

[bts@dawid ~]$ cd /tmp
[bts@dawid tmp]$ mkdir dest src
[bts@dawid tmp]$ dd if=/dev/urandom of=src/10gb.dat bs=1073741824 count=10 # create a 10GiB test file
10+0 records in
10+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 27.2001 s, 395 MB/s

Start the rsync over ssh...

[bts@dawid tmp]$ rsync --info=progress2 src/10gb.dat localhost:/tmp/dest/.
BBBBBBBBBBBBBBBBBBBBBBBBBBB
BMB---------------------B B
BBB---------------------BBB
BBB---------------------BBB
BBB---------------------BBB
BBB---------------------BBB
BBB---------------------BBB
BBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBB++++++++++++++++BBBBBB
BBBBB++BBBBB+++++++++BBBBBB
BBBBB++BBBBB+++++++++BBBBBB
BBBBB++BBBBB+++++++++BBBBBB
BBBBB++++++++++++++++BBBBBB
5,130,256,384 47% 614.05MB/s 0:00:08

[bts@dawid ~]$ systemctl status rsyncd.service | grep -E '^\s*(Active|Loaded):' ; pgrep rsync
Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; disabled; preset: disabled)
Active: inactive (dead)
281839
281850
281851
[bts@dawid ~]$ ps auxf|grep rsync
bts 281850 0.0 0.0 10612 5760 ? Ss 14:50 0:00 \_ rsync --server -e.LsfxCIvu . /tmp/dest/.
bts 281851 47.4 0.0 10872 2076 ? S 14:50 0:04 \_ rsync --server -e.LsfxCIvu . /tmp/dest/.
bts 281892 0.0 0.0 7300 2592 pts/1 S+ 14:50 0:00 | | \_ grep --color rsync
bts 281839 35.0 0.0 14320 6048 pts/2 S+ 14:50 0:03 | \_ rsync --info=progress2 src/10gb.dat localhost:/tmp/dest/.
bts 281840 90.3 0.0 18688 10952 pts/2 R+ 14:50 0:08 | \_ ssh localhost rsync --server -e.LsfxCIvu . /tmp/dest/.

And lo! and behold, rsyncd.service is still dead, but rsync is running (twice, because it spawns on the client and server, and I'm obviously rsyncing to localhost here).

Note that:

PID 281839 starts with the arguments I specify at the prompt, and
spawned PID 281840 as an SSH connection to localhost, with the remote command rsync --server -e.LsfxCIvu . /tmp/dest/.
And, as shown, I also have PID 281850 running on the destination I specified with the arguments passed to SSH by my invoked rsync.
Note also, rsync --server ... and not rsync --daemon:

INTERNAL OPTIONS
The options --server and --sender are used internally by rsync, and should never be typed by a user
under normal circumstances. Some awareness of these options may be needed in certain scenarios, such
as when setting up a login that can only run an rsync command. For instance, the support directory of
the rsync distribution has an example script named rrsync (for restricted rsync) that can be used with
a restricted ssh login.

(info rsync)

On Mon, Sep 4, 2023 at 2:40 PM brent saner <brent.saner@gmail.com> wrote:

On Mon, Sep 4, 2023 at 11:34 AM Casey Bralla via plug <plug@lists.phillylinux.org> wrote:

(SNIP)

As some have mentioned, I have had a passwordless rsync daemon running on the compromised server.

AAAAAnd there's your problem.

(I have my public key stored in the .ssh/authorized_keys file.)
That's great and all, but the rsync daemon does not use SSH. Whatsoever.

When you do

rsync my/local/path/. someuser@somehost:/some/path/.

It uses an SSH tunnel, and spawns rsync on the remote, and uses that for the file transfer - essentially tunneling the RSYNC protocol over SSH. Which is the "right" way to do this for your use case.

The rsync daemon, on the other hand, uses the RSYNC protocol (rsync://) with no SSH tunneling whatsoever. Because you disabled authentication/authorization in the rsync daemon config, it is indeed wide open to the entire world. (Or whatever the firewall to port 873 allows.) From recollection, you CAN do TLS authentication/authorization/tunneling for rsync --daemon, but you are not doing that here.

Don't run rsyncd/rsync --daemon unless you know what you're doing, why you're doing it, and why you would need it instead of just plain ol' SSH-tunneled RSYNC. You do not need the rsync daemon to run to use RSYNC over SSH whatsoever.