I would like to show how misconfigured rsync protocol can lead to data breach or compromise company and how to secure yourself. To prove my point, I found 2000+ emails from one of the Czech University via unsecured rsync.
I was inspired by Upguard and their discoveries but haven’t believed that this is possible (on this scale), so I had to try by myself. Most of the today’s breaches are from publicly accessible Amazon S3 buckets, but first you need to find or bruteforce it’s name. It may be hard sometimes, considering complex names and suffixes or prefixes used by companies. Rsync from the other side works as a service and listens on port 873 by default.
Rsync is a widely-used utility to keep copies of a file on two computer systems the same.
Rsync is typically used for synchronizing files and directories between two different systems.
It’s also worth to mention that this protocol is more efficient that scp because it transfers whole file just for the first time, in case of next synchronization only missing blocks are downloaded. It’s mostly used for keeping backups or user’s files synchronization. It’s also useful for repos, logs, emails or even for transferring permissions. From security (researcher) perspective it’s similar to Amazon buckets, on both cases, access must be restricted and permissions properly set but rsync doesn’t require a bruteforcing step.
Zoomeye shows 489.067+ rsync services worldwide and Shodan 101,788.
I call this breach (or leak) because I haven’t hacked anything, there wasn’t any password or other authentication at all.
Two directories were discovered, first filled with spam emails and second with legitimate user’s emails. Unfortunately, I haven’t managed to download all but just part of them, and the newest is from 15th of August. For the record, I immediately reported issue and it’s already fixed but university did not respond to requests for comment.
Besides information from database, external and internal conversations were also among these emails containing addresses, private phone numbers, meetings, internal subdomains and paths — heaven for spear-phishers. In most cases content was base64 encoded as well as attachments. Regarding attachments, it was mostly orders and couple pictures.
Additionally, every mail has a lot of headers, which also disclose useful information.
My guess is that rsync (cooperating with anti-spam tool) was used to examine every mail and then take action based on email’s content and headers, but probably I will never find out.
Security & configuration
As you could see, even small mistake as unsecured rsync may be culprit of data breach. Of course, this is not a rocket science to set a password but I bet that was just a simple neglect from their side. However, the best practice (in my opinion) is to use “host allow/deny” parameter in rsync.conf and ssh for file transfer. It’s worth to think to run rsync on non-default port, thanks to this it wont’t be indexed on search engines as simple as when running on port 873.
This time I’m not publishing any script and to be clear, I am not a professional sysadmin so feel free to add something or correct me. Sorry that I couldn’t disclose more, but really do not know university’s position about whole incident.
Originally published on December 21st, 2017