Deutsche Telekom CERT Advisory [DTC-A-20140324-002] vulnerabilities in check_mk

[<CERT@xxxxxxxxxx>]

Deutsche Telekom CERT Advisory [DTC-A-20140324-002] 

Summary: 
Several vulnerabilities were found in check_mk version 1.2.2p2.

The vulnerabilities are:
1 - Reflected Cross-Site Scripting (XSS)
2 - Stored Cross-Site Scripting (XSS) (via URL)
3 - Stored Cross-Site Scripting (XSS) (via external data, no link necessary)
4 - Stored Cross-Site Scripting (XSS) (via external data on service port, no 
link necessary)
5 - Missing CSRF (Cross-Site Request Forgery) token allows execution of 
arbitrary commands
6 - Multiple use of exec-like function calls which allow arbitrary commands
7 - Deletion of arbitrary files

Recommendations:
Install software release 1.2.2p3 or 1.2.3i5 or the latest release to fix the 
vulnerabilities 1, 2, 3 and 6. 
Vulnerabilities 4 and 5 are currently not fixed by the developer. To mitigate 
these issues, deactivate the WATO feature. Deletion of „wato.py“ should be 
preferred. Also review the permissions to the check_mk configuration and 
application files include folders. These must be set read only for the 
application user.
The client should be isolated from the internet connection (including web 
access over proxy server) to prevent additional threats concerning the open 
vulnerabilities.

Homepage: http://mathias-kettner.de/check_mk.html

Details:
a) application
b) problem
c) CVSS
d) detailed description
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
a1) check_mk v1.2.2p2 [CVE-2014-2329]
b1) Reflected Cross-Site Scripting (XSS)
c1) CVSS 8.5 AV:N/AC:M/Au:S/C:C/I:C/A:C
d1) The check_mk application is susceptible to reflected XSS attacks. This is 
mainly the result of improper output encoding. Reflected XSS can be triggered 
by sending a malicious URL to a user of the check_mk application. Once the XSS 
attack is triggered, the attacker has access to the full check_mk (and nagios) 
application with the access rights of the logged in victim.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
a2) check_mk v1.2.2p2 [CVE-2014-2329]
b2) Stored Cross-Site Scripting (XSS) (via URL)
c2) CVSS 8.5 AV:N/AC:M/Au:S/C:C/I:C/A:C
d2) The check_mk application is susceptible to stored XSS attacks. This is 
mainly the result of improper output encoding. Stored XSS can be triggered by 
sending a malicious input to the application. When an (admin) user of the 
check_mk application visits the check_mk website, the attack will be triggered. 
Once the XSS attack is triggered, the attacker has access to the full check_mk 
(and nagios) application with the access rights of the logged in victim.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
a3) check_mk v1.2.2p2 [CVE-2014-2329]
b3) Stored Cross-Site Scripting (XSS) (via external data, no link necessary)
c3) CVSS 8.5 AV:N/AC:M/Au:S/C:C/I:C/A:C
d3) The check_mk application is susceptible to stored XSS attacks. This is 
mainly the result of improper output encoding. Stored XSS can be triggered by 
sending a malicious input to the application. When an (admin) user of the 
check_mk application visits the check_mk website, the attack will be triggered. 
Once the XSS attack is triggered, the attacker has access to the full check_mk 
(and nagios) application with the access rights of the logged in victim. As 
opposed to the reflected or link-based stored XSS, the victim does not have to 
click any links or interact in any other way to trigger the exploit.
In this specific case, an attacker has to modify the check_mk agent, which may 
be installed on a monitored host. The check_mk agent is a separate software 
module, which can be installed on monitored systems to extract data from this 
host, which then should be used as data input for nagios/check_mk. Check_mk 
agents are an integral part of check_mk to monitor arbitrary operating systems. 
Once any of the monitored hosts was compromised, an attacker may change the 
check_mk configuration to include JavaScript code. Once this has been done, 
check_mk will display the agent string without proper encoding, resulting in a 
stored XSS. This attack can be used to gain access to the check_mk application, 
as mentioned before.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
a4) check_mk v1.2.2p2 [CVE-2014-2329]
b4) Stored Cross-Site Scripting (XSS) (via external data on service port, no 
link necessary)
c4) CVSS 8.5 AV:N/AC:M/Au:S/C:C/I:C/A:C
d4) The check_mk application is susceptible to stored XSS attacks. This is 
mainly the result of improper output encoding. Stored XSS can be triggered by 
sending a malicious input to the application. When an (admin) user of the 
check_mk application visits the check_mk website, the attack will be triggered. 
Once the XSS attack is triggered, the attacker has access to the full check_mk 
(and nagios) application with the access rights of the logged in victim. As 
opposed to the reflected or link-based stored XSS, the victim does not have to 
click any links or interact in any other way to trigger the exploit.
In this specific case, an attacker has to send malicious data to a monitored 
system (not the check_mk or nagios host) to a service port, which is being 
logged by the "logwatch" functionality of check_mk. This module allows the 
monitoring of logfiles for hosts monitored by check_mk. It is a very regular 
task for system administrators to monitor any anomalies and react to it 
accordingly by monitoring logfiles. Check_mk delivers this functionality by 
support of the logwatch module. The module is explained in detail on the 
check_mk website: http://mathias-kettner.de/checkmk_logfiles.html
What makes this attack more critical than a usual XSS attack is the fact that 
not the check_mk system or the administrator is attacked, but a system which is 
being monitored by check_mk. Usually those systems have a much greater attack 
surface than the monitoring systems such as check_mk - Both systems may even be 
separated by firewall, allowing only access from check_mk to the monitored host.
The JavaScript code is displayed in the dashboard without proper encoding, 
resulting in a XSS attack. As mentioned, the attacker does not need any network 
connection to the check_mk system itself  - only access to a monitored system 
is needed.
As a proof of concept attack, the ssh logfile of a host may be watched for any 
occurrence of invalid login attempts. This is a default setting with the 
logwatch module, once installed. This setting allows the compromise of a 
check_mk host by initiating a specially crafted ssh connection to the targeted 
host.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
a5) check_mk v1.2.2p2 [CVE-2014-2330]
b5) Missing CSRF (Cross-Site Request Forgery) token allows execution of 
arbitrary commands
c5) CVSS 8.5 AV:N/AC:M/Au:S/C:C/I:C/A:C
d5) The check_mk application does not implement any CSRF tokens. More about 
CSRF attacks, risks and mitigations see 
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF). This attack 
has a vast impact on the security of the check_mk application, as multiple 
configuration parameters can be changed using a CSRF attack. One very critical 
attack vector is the upload of arbitrary snapshot files, which may then be 
executed on the server. In combination with another security flaw (code 
execution of snapshot files) this results in full compromise of the check_mk 
host just by clicking a web link. A proof of concept exploit has been 
developed, which allows this attack, resulting in full (system level) access of 
the check_mk system.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
a6) check_mk v1.2.2p2 [CVE-2014-2331]
b6) Multiple use of exec-like function calls which allow arbitrary commands
c6) CVSS 8.5 AV:N/AC:M/Au:S/C:C/I:C/A:C
d6) check_mk makes use of multiple exec-like method calls, which execute python 
code without any safety checks in place. One such method is the Python built-in 
"execfile", which is called multiple times in the check_mk codebase. A proof of 
concept attack has been developed, which exploits this fact. Uploading a 
snapshot file for instance with a modified "rules.mk" file resulted in 
execution of this file as a python script. An attacker may implement attacks 
(rather complex, as the full functionality of the Python scripting language 
including all standard modules can be utilized) in this file, which will be 
executed on the check_mk host, once the snapshot file is extracted. In 
combination with a CSRF weakness this can be triggered without the knowledge of 
the check_mk user. Also, for more elaborate attacks, this can be combined with 
a XSS attack. Such an attack will result in full system (check_mk host) access 
without any interaction or knowledge of the check_mk admin.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
a7) check_mk v1.2.2p2 [CVE-2014-2332]
b7) Deletion of arbitrary files
c7) CVSS 4.3 AV:N/AC:M/Au:M/C:N/I:P/A:P (authentication is needed, although 
this flaw can be triggered using a CSRF attack, see above)
d) By visiting a link, arbitrary files can be deleted. Only files, which have 
the proper access rights (usually the user under which the web application is 
running), can be deleted. This may result in unexpected behavior and/or DoS of 
the application. More information about direct object/file reference can be 
found here: 
https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References

Deutsche Telekom CERT
Landgrabenweg 151, 53227 Bonn, Germany
+49 800 DTAG CERT (Tel.)
E-Mail: cert@xxxxxxxxxx
Life is for sharing.
 
Deutsche Telekom AG
Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman)
Board of Management: Timotheus Höttges (Chairman),
Dr. Thomas Kremer, Reinhard Clemens, Niek Jan van Damme,
Thomas Dannenfeldt, Claudia Nemat, Prof. Dr. Marion Schick
Commercial register: Amtsgericht Bonn HRB 6794
Registered office: Bonn
 
Big changes start small – conserve resources by not printing every e-mail.