Just a note for me for later as other blogs have been tending to disappear lately and so I don't get unduly excited when I see a nagios NRPE exploit/bug as there are a few obstacles to overcome.
Very detailed writeup for my summarized notes below:
https://www.cryptobells.com/zomg-remote-shell-exploit-or-not/
Nagios NRPE has now had at least two separate issues.
for less than 2.14 there is a metasploit module:
http://www.rapid7.com/db/modules/exploit/linux/misc/nagios_nrpe_arguments
for 2.15 and below there is a newer exploit that came out in April 2014 here:
http://www.exploit-db.com/exploits/32925
as of 23 May 2014 this is unpatched.
stuff to remember on nagios:
Obstacle #1. You have to configure the host running the NRPE daemon to talk to a nagios server, your requests to try to exploit the client running NPRE must come from one of the hosted specfiically listed in the nrpe.config. The default is local host only. If you aren't on the list, the application will forcefully disconnect your connection. You can test this by telnetting to the host on 5666.
Obstacle #2. The NRPE daemon must be configured with the dont_blame_nrpe to 1. This is not the default setting. However, if people are using the daemon I've seen this set, otherwise I don't think anyone would be able to interact with it remotely, thus to use NRPE you have to enable it. Please correct me if i'm wrong.
Obstacle #3. You have to enable commands. However, it looks like pretty much any commands that take arguments is vulnerable.
Attack Path:
If you can gain access to any server that is allowed to access the hosts running NRPE (typically the nagios monitoring servers) and you can run the various nrpe plugins you can potentially gain access to the monitored hosts.
As always if i'm way off or there are other tricks please let me know via twitter or here in the comments and I'll update the post.
-CG
Subscribe to:
Post Comments (Atom)
2 comments:
Hi, I'm the author of https://www.cryptobells.com/zomg-remote-shell-exploit-or-not/. I wanted to clarify a point:
"However, if people are using the daemon I've seen this set, otherwise I don't think anyone would be able to interact with it remotely, thus to use NRPE you have to enable it."
This isn't quite true, you can indeed run NRPE without sending check arguments or setting dont_blame_nrpe to 1. It just means that all command parameters have to be defined within the NRPE config file, and not sent dynamically in the remote request from the Nagios server.
Enabling dont_blame_nrpe and defining checks that accept arbitrary remote params esentially go hand-in-hand- you can't have one without the other. It truly is a poorly designed monitoring architecture that would meet -all- of these criteria- unfortunately, there are several that I have found in real world examples that implementing monitoring in this style, and we were able to successfully leverage this as a proof-of-concept.
Thanks for checking my post! :D
I wrote some official
documentation for the testing of this on Unix. I can tell you that everything in this article is dead on most of the checks that are by scripts, especially with NRPE are ripe for exploitation.
I don't use this method of checking anymore, SSH is a lot more secure method of checking than NRPE.
Also, for anyone reading this Nagios has a much more secure method called NRDS. All your checks are schedule via Cron and there is no connection to the client from the server its all one way from client server only. Also, no SSH keys need to be exchanged, the security is token based, not entirely sure how it works yet but currently researching it.
Post a Comment