Debian-LTS has issued an advisory on December 16: https://lwn.net/Alerts/709639/ Mageia 5 is also affected.
Whiteboard: (none) => MGA5TOO
nagios-4.2.4-1.mga6 uploaded for Cauldron by Guillaume to fix this.
Version: Cauldron => 5Whiteboard: MGA5TOO => (none)
More details on these issues: http://openwall.com/lists/oss-security/2016/12/20/4 http://openwall.com/lists/oss-security/2016/12/20/5
Severity: normal => major
I just submitted release 4.0.8-3.1 in update/testing for mageia 5, fixing both issues. Suggested advisory: =================== Nagios was found to be vulnerable to two security issues: - CVE-2016-9565: Improper sanitization of RSS feed input enables unauthenticated remote read and write of arbitrary files. - CVE-2016-9566: Unsafe logfile handling allows unprivileged users to escalate their privileges to root New release nagios-4.0.8-3.1 fixes both issues. References: http://openwall.com/lists/oss-security/2016/12/20/4 http://openwall.com/lists/oss-security/2016/12/20/5
Status: NEW => ASSIGNEDAssignee: guillomovitch => qa-bugs
Thanks Guillaume! Minor formatting adjustments... Advisory: ======================== Updated nagios packages fix security vulnerabilities: Improper sanitization of RSS feed input enables unauthenticated remote read and write of arbitrary files (CVE-2016-9565). Unsafe logfile handling allows unprivileged users to escalate their privileges to root (CVE-2016-9566). The nagios package has been patched to fix these issues. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9565 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9566 http://openwall.com/lists/oss-security/2016/12/20/4 http://openwall.com/lists/oss-security/2016/12/20/5 https://lwn.net/Alerts/709639/
A combined PoC for CVE-2016-9565/9566 is provided at Legal Hackers https://legalhackers.com/advisories/Nagios-Exploit-Command-Injection-CVE-2016-9565-2008-4796.html There is a link to a video to show the exploit(s) in operation. See also: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet Dawid Galunski, who discovered the vulnerability, has gone to a lot of trouble to provide the tools to reproduce the bug but I am having trouble understanding the language. It appears that it is necessary to establish a "reverse shell" and then run a specialised python script with the ip address of this shell. I was already lost at that point. There are many recipes for creating a reverse shell, some of which I tried, successfully I think, but I do not know how to use this construction in practice. Just running the script against an address of 10.0.0.1 gives a syntax error and the reverse shell eventually times out. I am attaching the script in the hope that somebody else might be able to understand what to do with it.
CC: (none) => tarazed25
Created attachment 8835 [details] Python script associated with CVE-2016-9565 and 9566 Using this script to demonstrate the two vulnerabilities may need knowledge of reverse shells and of python internals (possible syntax error).
It looks like the script actually handles the reverse shell for you, so you don't really need any special knowledge about it. As for the script not executing for you, what error are you getting? The main thing is it has some dependencies that need to be installed (at least python-tornado and netcat-traditional).
Thanks for pointing that out David. I have no time just now to follow this up but missing dependencies looks like a possibility for the error. The how to run it instruction indicates that an ip address needs to be supplied on the command line. I don't know what to put there; maybe an unused address on the LAN? Off out for the evening but shall get back to this as soon as.
Yes, the IP address is for the Nagios server that you are exploiting (so you'd probably want to run the script on a different machine on your LAN or make use of VMs). There was also mention of putting an entry in /etc/hosts. I'm not sure if it's necessary, but it sounds like it was mapping www.nagios.org to your public IP address (this would be on the machine where you run the script, presumably).
Testing on mga5 x86_64. On belexeuli (target system) Before updating nagios: $ sudo systemctl start nagios.service $ systemctl status nagios.service â nagios.service - Nagios network monitor Loaded: loaded (/usr/lib/systemd/system/nagios.service; enabled) Active: active (running) since Thu 2017-01-05 21:19:13 GMT; 10s ago Process: 20385 ExecStart=/usr/sbin/nagios -d /etc/nagios/nagios.cfg (code=exited, status=0/SUCCESS) Main PID: 20386 (nagios) CGroup: /system.slice/nagios.service ââ20386 /usr/sbin/nagios -d /etc/nagios/nagios.cfg ââ20387 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20388 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20389 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20390 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20391 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20392 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20393 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20394 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20395 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20396 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20397 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20398 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh ââ20399 /usr/sbin/nagios -d /etc/nagios/nagios.cfg On vega (hacker's system): python-curl and netcat traditional already installed. $ sudo urpmi python-tornado This pulled in python-backports-ssl_match_hostname. $ ./nagios_cmd_injection.py <IP_of_belexeuli> Nagios Core < 4.2.0 Curl Command Injection / Code Execution PoC Exploit CVE-2016-9565 ........ [+] Generating SSL certificate for our python HTTPS web server [+] Starting the web server on ports 80 & 443 Traceback (most recent call last): File "./nagios_cmd_injection.py", line 152, in <module> application.listen(80) File "/usr/lib64/python2.7/site-packages/tornado/web.py", line 1686, in listen server.listen(port, address) File "/usr/lib64/python2.7/site-packages/tornado/tcpserver.py", line 116, in listen sockets = bind_sockets(port, address=address) File "/usr/lib64/python2.7/site-packages/tornado/netutil.py", line 103, in bind_sockets sock.bind(sockaddr) File "/usr/lib64/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 13] Permission denied Specifically opening 80/tcp and 443/tcp in Shorewall but that did not help. Running the script via sudo returned a slightly different termination error: socket.error: [Errno 98] Address already in use
Len, getting closer :o). As demonstrated in the source document, you have to run the exploit as root. I think that's because it's trying to bind to ports 80 and 443 (which are < 1024 and thus require root privilege).
The following 10 packages are going to be installed: - nagios-4.0.8-3.1.mga5.x86_64 - nagios-check_disk-2.0.3-5.mga5.x86_64 - nagios-check_http-2.0.3-5.mga5.x86_64 - nagios-check_load-2.0.3-5.mga5.x86_64 - nagios-check_ping-2.0.3-5.mga5.x86_64 - nagios-check_procs-2.0.3-5.mga5.x86_64 - nagios-check_ssh-2.0.3-5.mga5.x86_64 - nagios-check_swap-2.0.3-5.mga5.x86_64 - nagios-check_users-2.0.3-5.mga5.x86_64 - nagios-plugins-2.0.3-5.mga5.x86_64 2.3MB of additional disk space will be used. 757KB of packages will be retrieved. After install I started the service # systemctl start nagios.service [root@localhost brian]# ps -ef | grep nagios nagios 3742 1 0 08:36 ? 00:00:00 /usr/sbin/nagios -d /etc/nagios/nagios.cfg nagios 3743 3742 0 08:36 ? 00:00:00 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh nagios 3744 3742 0 08:36 ? 00:00:00 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh nagios 3745 3742 0 08:36 ? 00:00:00 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh nagios 3746 3742 0 08:36 ? 00:00:00 /usr/sbin/nagios --worker /var/spool/nagios/nagios.qh nagios 3747 3742 0 08:36 ? 00:00:00 /usr/sbin/nagios -d /etc/nagios/nagios.cfg root 3780 3673 0 08:37 pts/1 00:00:00 grep --color nagios Well â at least it runs! I tried running the python script, but that really isn't my language. It seems to do interesting things to the UI and then crash.
CC: (none) => brtians1
Thanks Brian for taking up the cudgel. I had been trying to get back to the PoC for some time - other things got in the way. The PoC stuff is dangerous - it borked one of my machines and crippled part of my network. I shall have another go with at least one end in a VM, as David advised. .
Whiteboard: (none) => mga5-64-ok
CC: (none) => lewyssmithWhiteboard: mga5-64-ok => mga5-64-ok advisory
Back to square one on this one. Set up a vm as the attack machine with the host as target. nagios running on the target. target hosts file contains the address of the attacking machine <b>. Address of target is <a> Logged in as root and ran $ ./nagios_cmd_injection.py <a>Nagios Core < 4.2.0 Curl Command Injection / Code Execution PoC Exploit CVE-2016-9565 nagios_cmd_injection.py ver. 1.0 ..................... [+] Generating SSL certificate for our python HTTPS web server [+] Starting the web server on ports 80 & 443 Traceback (most recent call last): File "./nagios_cmd_injection.py", line 152, in <module> application.listen(80) File "/usr/lib/python2.7/site-packages/tornado/web.py", line 1686, in listen server.listen(port, address) File "/usr/lib/python2.7/site-packages/tornado/tcpserver.py", line 116, in listen sockets = bind_sockets(port, address=address) File "/usr/lib/python2.7/site-packages/tornado/netutil.py", line 103, in bind_sockets sock.bind(sockaddr) File "/usr/lib/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 98] Address already in use Nothing in dmesg and nothing but a fog of smbd messages in the journal. Finally realised that port 80 is already being used by httpd. Shut down httpd and tried again and saw these messages. [+] 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... ;) Duh?
I type ls, which was echoed in the terminal but nothing else. Nothing happened at the other end. As far as I can see the script has started tornado.ioloop The closedown sequence is not executed so the program is definitely waiting for user i/o at this end. 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" Completely out of my depth here.
Didn't get much farther than Len. The testing I did ... On a vb guest at 192.168.10.116 ... urpmi nagios nagios-www Uncomment and set default_user_name /etc/nagios/cgi.cfg ... default_user_name=nagiosadmin systemctl restart nagios.service systemctl restart httpd.service On the host ... # systemctl stop httpd.service # /home/dave/bin/nagios_cmd_injection.py 192.168.10.116 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... ;) -------------------------------------------------------------------------- From https://legalhackers.com/advisories/Nagios-Exploit-Command-Injection-CVE-2016-9565-2008-4796.html, the attacker has to be able to use dns poisoning, to impersonate the www.nagios.org domain, providing a specific response. While it isn't difficult to redirect the domain lookup to another system (with control of the target system), getting that system to then provide the proper dns response to exploit this bug is not a simple matter. Given the above, I feel just testing that nagios continues to work after installing the update will have to be enough, which I have done on both i586 and x86_64. Validating the update.
Keywords: (none) => validated_updateWhiteboard: mga5-64-ok advisory => mga5-64-ok advisory MGA5-32-OKCC: (none) => davidwhodgins, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2017-0045.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED