The reason I decided to write up this vulnerability is not the fact that this is a very popular system, or that there is a huge risk here. The main reason is that it struck me with a certain amount of sadness that we still have to deal with this problem in 2014. For example, I found an rsync configuration guide from 1999 that recommends the use of rsync over ssh [1].

F5 uses rsync to synchronize configurations if the BigIP load balancer is used in high availability mode. Sadly, the rsync server that is used for this does not require any authentication. As a result, an attacker can upload and download arbitrary files. The proof of concept exploit uploads an "authorized_keys" file permitting the attacker to ssh to the device and obtaining full shell access. In order to be vulnerable, the interface used to synchronize the devices has to be exposed [2].

F5 made a patch available [3].

But I think the lesson is larger then "Patch F5". This is about not forgetting history. In many of our classes, a complaint is why we include some older vulnerabilities. For example our "Securing Unix" class is going over some of the issues with "r" services like "rsh" and how to automate almost anything using ssh. 

What should you do? As a first step, a quick scan of your network for open rsync servers (port 873 tcp). Next, if you use ssh as you should, take a look at how you manage ssh keys as this is the next big problem. Are you keeping your secret keys in one (and only one) secure spot? Do you use different keys for different purposes? This can be a larger project to work out and implement correctly.

[1] http://everythinglinux.org/rsync/
[2] http://www.security-assessment.com/files/documents/advisory/F5_Unauthenticated_rsync_access_to_Remote_Root_Code_Execution.pdf
[3] http://support.f5.com/kb/en-us/solutions/public/15000/200/sol15236.html

---

Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn