BOFH Hunter

Nagios Security Updates

While most shops keep their nagios installs protected, folks with a publicly available nagios instance should update as soon as possible. There’s an interesting pair of security vulnerabilities which admins should be aware of. The first allows for users to submit commands to cmd.cgi that they would not ordinarily have permission to submit. This is basically a priviledge escalation issue and its severity depends on who has access to your nagios instance, and just how disgruntled they are.

The second is the more serious of the issues, and was described best by Andreas Ericsson, a major nagios contributor.  Quoting from Andreas:

Nagios CGI's are vulnerable to a Cross Site Request Forgery attack (csrf).
A CSRF attack requires a couple of things for it to work, and it relies
on the webs abilities (or rather, the browser's abilities) of posting
form-data to a site which is other than that of the site presenting the
form.

Here's how it works:
Unsuspecting Nagios Admin (UNA from now on) logs on to the Nagios server
and checks the status of his/her network. Since everything's ok, UNA
decides to leisurely browse evilsite.com, controlled by Dr Evil.

On evilsite.com, there's a page containing a bog-standard web form, but
with some hidden variables and an 'action' tag that points to UNA's
cmd.cgi on UNA's Nagios server. When UNA submits the form, Dr Evil has
all of a sudden sent data of his/her choice to the responding page
on UNA's site. It's important to note that UNA's browser is being used,
as it leads to a couple of interesting things:
* UNA sees the output from cmd.cgi. It's never sent to evilsite.com,
  which can only guess if the attack was successful or not.
* Firewalls can not be used to defend against this, as UNA requires
  access to the Nagios server in order to work.
* Cookies can't be used either, as they are helpfully sent to the
  Nagios server whenever the browser loads a page from it.

Why is this bad, then? Well, it's not so evil in itself, and the most
horrible thing that it should have lead to was Dr Evil being able to
enable / disable notifications or stuff like that, but in Nagios 3
we gained the ability to change checkcommand arguments and suchlike,
which, combined with the csrf above, ultimately led to Dr Evil being
able to run any command of his/her (who says girl's can't be evil?)
choice on UNA's preacious Nagios server as the Nagios user.

So what's the remedy?
Well, a proper remedy is to implement in-form session tokens, which
makes sure that the form submitted by the user came from the site we
would like it to have come from (namely our humble selves). I'm
working on that right now, and hope to have it done by this afternoon.
It's been loads of fun implementing that in super-paranoid C, by the
way. 

In the mean-time, we've blocked use of the CHANGE_ commands from the
CGI's, and also made sure that multiple commands can't be submitted
as one (fe by using comments with newlines). This interim remedy
brings the worst-case scenario down from remote command execution to
a more prank-like level (acknowledging problems, adding or deleting
comments, etc, etc).

A couple of things to note:
* Information disclosure is not possible. No remote user can see
  anything from your authentication-protected Nagios servers.
* Invalid commands read from the FIFO are always dropped flat by
  Nagios.
* Since commands must be valid, it's not very easy to submit a
  command that has all the information required. Social engineering
  is required.
* You *will* notice if this happens to you, since you all of a
  sudden will end up with cmd.cgi (not in a frame either) saying

  "Command submitted successfully" or some such.

For the full details of this,  you can follow the thread here.  Mostly, If you’re currently using nagios 3, you should update.