Secure your rsync shares, please.

13 February 2014 21:50

Recently I started doing a internet-wide scan for rsync servers, thinking it might be fun to write a toy search-engine/indexer.

Even the basics such as searching against the names of exported shares would be interesting, I thought.

Today I abandoned that after exploring some of the results, (created with zmap), because there's just too much private data out there, wide open

IP redacted for obvious reason:

shelob ~ $ rsync  rsync://xx.xx.xx.xx/
ginevra        	Ginevra backup
krsna          	Alberto Laptop Backup
franziska      	Franz Laptop Backup
genoveffa      	Franz Laptop Backup 2

Some nice shares there. Lets see if they're as open as they appear to be:

shelob ~ $ rsync  rsync://xx.xx.xx.xx/ginevra/home/
drwxrwsr-x        4096 2013/10/30 13:42:29 .
drwxr-sr-x        4096 2009/02/03 10:32:27 abl
drwxr-s---       12288 2014/02/12 20:05:22 alberto
drwxr-xr-x        4096 2011/12/13 17:12:46 alessandra
drwxr-sr-x       20480 2014/02/12 22:55:01 backup
drwxr-xr-x        4096 2008/10/03 14:51:29 bertacci
..

Yup. Backups of /home, /etc/, and more.

I found numerous examples of this, along with a significant number of hosts that exported "www" + "sql", as a pair, and a large number of hosts that just exported "squid/". I assume they must be some cpanel-like system, because I can't understand why thousands of people would export the same shares with the same comments otherwise.

I still would like to run the indexer, but with so much easy content to steal, well I think the liability would kill me.

I considered not posting this, but I suspect "bad people" already know..,

Tags: nmap, rsync, zmap | 13 comments

Comments on this entry

Franco at 18:22 on 13 February 2014

I hope the names were changed, or this could give a potential attacker an edge (or an unscrupulous person an indication of target).
If not, please change them.

Daniel at 22:21 on 13 February 2014
http://claw.triple6.org

Franco, if Steve was able to find those by scanning the default rsync port with z/nmap "potential attackers" likely will be able to do same without knowing the exact share names.

Edgar at 01:30 on 14 February 2014
http://pithyphrase.net

cPanel itself doesn't do anything with rsync or squid. I also haven't heard of a panel which does use those. However it's possible that admins at a web host have set up their own system.

Martin at 03:32 on 14 February 2014

Would it be unreasonable to suspect that some of the findings are honeypots?

Steve Kemp at 08:23 on 14 February 2014
http://www.steve.org.uk/

Daniel, exactly.

If you have to scan the whole network, and connect to every server, to find that host you've probably found a million others already.

Honeypots? Good point, entirely possible. I tried to connect to a few and was denied, others let me right in, but I didn't try to connect to all of them.

Here's an example of one of the "standard" results I found:

shelob ~ $ rsync rsync://a.b.c.d/
www            	websites' folder
sql            	databases' folder
dotsql         	dotsql' folder

The host was running Sendmail, and showing Apache's standard "Installation test page". Which made me think of some kind of control-panel / or hosting-in-a-box solution.

I found hundreds of IPs running those exact same three shares, with the exact same comments. (All the ones I probed had them ACL'd so that was good :)

mirabilos at 08:45 on 15 February 2014
https://www.mirbsd.org/jupp.htm

Why are you using rsync:// in the first place?
rsync works much better with ssh, anyway.

I fully blame Debian's insane default of starting any
and all dÃ¦mons contained in packages installed, when
I never used/needed an rsync dÃ¦mon, only the executable
for calling it via ssh.

mirabilos at 08:46 on 15 February 2014
https://www.mirbsd.org/mksh.htm

By the way, your website is broken: blog.steve.org.uk
has got an AAAA record, but no IP connectivity (neither
web nor ping respond), only Legacy IP. This does break.

Steve Kemp at 09:57 on 15 February 2014
http://www.steve.org.uk/

I personally am not using rsync, except in sensible fashions! In the general case I use rsync over ssh, to ensure that I get encryption and avoid issues with authentication.

However I will say that Debian is not to blame here, by default rsync is not started as a service, not unless you set RSYNC_ENABLE in /etc/default/rsync.

As for the IPv6 there does seem to be something wrong, but I'm thinking it is ISP-related rather specific with my host. Annoying though, thanks for reporting it.

mirabilos at 11:59 on 17 February 2014
https://www.mirbsd.org/

The RSYNC_ENABLE option is pretty recent, thoughâ€¦ it used
to be (not too long ago) that it was automatically started.

Ewen at 15:02 on 17 February 2014

No, mirabilos, you are lying.

Martin at 20:57 on 17 February 2014
http://blog.mdosch.de

I tried it and after 5 min I found the first server with a backup public available. That's alarming. But the positive effect was: After writing to the webmaster it took approx. 10 minutes until user_auth got enabled. ;)

Have you told the webmasters directly?
I guess not everyone is reading your blog. ;o)

Steve Kemp at 21:01 on 17 February 2014
http://www.steve.org.uk/

Martin, sadly I could only find one IP which exposed private data and had an obvious contact address.

As per my prior comment too often they were just associated with residential ISPs, and couldn't be pinned to a specific individual.

Daniel at 21:10 on 17 February 2014
http://claw.triple6.org

Added init.d script for those who want to start rsync in daemon mode
automatically. You'll need to edit /etc/default/rsync and create an appropriate rsyncd.conf file to actually get it to start. closes:#211007

-- Paul Slootman <[email protected]> Mon, 5 Jan 2004 16:00:22 +0100

The /etc/default was added in the beginning of 2004. It is very likely that rsync was disabled by default even before that change.

Secure your rsync shares, please.

Comments on this entry

Recent Posts