rsync over ssh - possible attack vectors

[Leen Besselink]

On 04/16/2010 02:16 AM, George Sullivan wrote:
> Hello everybody!
>
> First my setup:
> I connect from Debian Lenny to Ubuntu Karmic with a command like:
> user1 at localserver:$ rsync -rtcve ssh user1 at remoteserver:/.../ /local/.../
> (using default versions of ssh and rsync in the vendor repos,
> ssh with password authentication)
>
> As far as I understand if localserver got compromised an
> attacker could read the password and then get full access
> to remoteserver as user1.
> SSH protects against attacks from a 3rd system on the network.
> But what I'm interested in is what happens if remoteserver
> is compromised? Obviously it could feed bad data or trigger
> a remote vulnerability in rsync or ssh (0day buffer overflow, whatever)
> to get system access on localserver.
>
> I'm not worried about any of these vectors, the last one isn't very
> likely (and I can't do anything about it anyway) and the first doesn't
> concern me because localserver is a locked down backup server
> whereas remoteserver is an internet-facing server.
> Data corruption can be detected using the checksumming option.
> Now to my actual question:
> Have I missed one attack vector: Could attacker X on
> remoteserver alter the rsync binary in such a way so it can traverse
> and change or read arbitrary files on localserver? Does running above
> command execute remote code or give remoteserver any kind of system
> access to localserver  (does the ssh tunnel work both ways???)
> or is it "pumping" data through a dumb pipe just like for example rsync
> over a samba share would and leaving all control to local?
>
> Sorry if this sounds like a dumb question, I searched but couldn't
> find a definite answer. I'm also using rsync with "-c" as some kind
> of poor man's HIDS so security is paramount. remoteserver is
> as mentioned a webserver, it's question of when, not if, it gets
> compromised, localserver handles sensitive files. Maybe not that drastic,
> but you get the picture. To sum it up the question is, what's the risk
> connecting these two systems? I thought about alternatives but couldn't
> come up with anything practical (for example using two separate backup
> systems or using offline storage to transfer the data).
>    

Hello George,

I'm no regular rsync-developer, but I like you paranoia so I'll answer 
with what I know.

I'll start with 2 general tips:

1. if you want to know if a system is compromised, use something like: 
tiger. It can help.

2. use something like cron-apt to keep your system up to date, maybe you 
don't want it to automatically install, but atleast e-mail you with 
information about available updates

3. normally with rsync -e ssh it will use ssh to connect to the 
remote-system and run the local rsync-command there in --daemon-mode

4. if you want a backup of the whole system, with that method you 
probably want root-rights, maybe it's better to not use rsync -e ssh and 
ssh into the system as the root-user. But use a regular user (and use 
sshs-option: Allowgroups or Allowusers to restrict who can connect), but 
port-forward to a rsync-daemon running (and binded) to localhost on the 
remote system (I didn't see a script to automate it yet though)

5. I'm pretty sure you can use something like monit to keep an eye on 
the running rsync-daemon, if the pid doesn't change, the binary in 
memory isn't changed either (atleast I wouldn't expect them to go to 
such lenghts normally) as Linux uses copy-on-write of the 
in-memory-binary/running program when doing a fork, so it should be 
pretty save ? I'm no expert though.

6. don't forget to setup rsync with password-protected-module

7. when using SSH disable all options like tunneling

Some observations:

Although, I guess it's more likely they will change the sshd-binary 
instead of the rsync binary to capture passwords ? But you are not using 
a password, right ? you are gonna be using keys I guess.

I guess added an other attack-surface by running an extra process on the 
system with root-rights isn't a great idea either...

Even more likely they will just get in the kernel and change some system 
calls to hide their presence and most programs won't be able to see the 
difference.

So if you still want to ssh with root set it up with:

PermitRootLogin no
Match Host xx.xxx.xx.xx
     PermitRootLogin yes

Is something like that, helpfull to you ?

You will have to make your own choices.



> Please also tell me if I missed anything else.
> Thank you!
>
> George
>