Is it possible to exploit this Zookeeper instance?

Question

I was performing a security test for a client when I came across a Zookeeper installation on xx.x.x.xx:2181. Trying NetCat revealed that I'm able to all the following commands:

dump: Lists the outstanding sessions and ephemeral nodes. This only works on the leader.

envi: Print details about serving environment

kill: Shuts down the server. This must be issued from the machine the ZooKeeper server is running on. (Haven't tried this one)

reqs: List outstanding requests

ruok: Tests if server is running in a non-error state. The server will respond with imok if it is running. Otherwise it will not respond at all.

srst: Reset statistics returned by stat command.

stat: Lists statistics about performance and connected clients.

I'm not familiar with Zookeeper so please excuse me if this sounds like a stupid question but is Zookeeper supposed to be accessible without authentication? and also what are the implications of having this application exposed?

Any help is really appreciated, Thank you

Answer 1

First of all, I'm also not familiar with Zookeeper at all but I could give you some general advice from a security perspective.

The Zookeeper commands you listed sounds like administrative functions, that means that they probably should only be accessible after authentication or should, for example, be only accessible inside a private network or accessible from certain IP addresses only.

If you are testing a controlled testing environment I'd suggest to contact the administrator and plan a moment to test the kill command, this will verify if it will really work in such a way. If it does I can imagine something like locating all Zookeeper servers in a cluster and kill them all, causing a shutdown of the service. Security professionals will likely call that an availability risk. Ethical hackers and script-kiddies will likely call that a defacement.

Again I don't have any knowledge of Zookeeper but I could imagine the following theoretical risks.

1. dump shows the sessions, depending on the exact session information that is exposed, you might be able to confuse the system when trying to spoof such a session. Possibly affecting integrity.
2. envi depending on the information showed you could use that to get a better view of your target and possibly widen the scope if other related systems are found by that information.
3. kill as noticed before, availability risk and probably the biggest risk of this list of commands.
4. reqs information disclosure and depending on the information a possibility of confusing processes by spoofing things.
5. ruok simple information disclosure, I can't imagine any risk unless there are some Zookeeper specific vulnerabilities known that will only work when it's running in a non-error state. Again error-state/non-error-state is a 50% chance that a "state specific" vulnerability will work. Knowing the actual state increases that theoretically to 100% when the versions and everything match.
6. srst depending on what statistics it resets exactly, you might be able to clean traces after a hacking attempt. Erasing your tracks.
7. stat information disclosure. Giving unnecessary insights in the system and possibly infrastructure and can possibility be used to widen the scope.

My general advice would be. Prevent this system from accepting that kind of commands from anyone. Possibly adding an authentication layer like VPN and/or IP restrictions or enabling authentication features within Zookeeper (if they exist). This will make sure that information is not unnecessary disclosed and mitigates the possible availability risk caused by of the kill command.

While kill itself is not a vulnerability, it is a risk. Using the CVSS scoring system, if kill actually works and depending on your exact attack background and factors I'd estimate a CVSS of the availability risk on something like 7.1 (high), (AV:N/AC:M/Au:N/C:N/I:N/A:C).

Also, you might want to check out this:

• http://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-27453/Apache-Zookeeper.html
• https://nmap.org/nsedoc/scripts/hbase-master-info.html

Answer 2

ZooKeeper is a cluster management tool. I would first see if you can connect a client node to it as it appears you have already penetrated the internal network (most cluster tools are secured at the network level). If you can connect a client node then you can literally getData. In short, yes this may be a vulnerability.

To connect a client node, turn on your own server and install the client ZooKeeper dependencies and follow the install guide. You will see a list of commands you can use once (if) your node connects.

If your client nodes do not connect straight up, dont fret, there is hope... See if you can connect to the master itself and change some settings in particular the skipACL command. Also note that at any time you can try some buffer overflow attacks (not just on the master but the client nodes too).

You can submit work/commands to the master in a few languages (Java/C) so I'd suggest testing all of this out on your own instance first as whoever is managing the cluster is going to see some increased usage.

Additionally, most big data clusters use some kind of NFS or distributed FS like Lustre. Lustre is inherently insecure as well (secured at the firewall/network level) so feel free to attempt to exploit that as well.

Some other softwares that may be running on the same node as your Zookeeper master are: Spark, Hadoop, Mesos, Ganglia, Pig, Hue, Hive, and many other big data analytic software so I'd write some discovery exploits for those as well...

The commands you listed are documented as "The Four Letter Words" and are not inherently dangerous (although that intel could lead to other attacks) however they may be indicative of configuration exploits as listed above.