Message-ID: <F431B9A0925EB54789AB192CE6A35EFF3679881CFA@HE111649.emea1.cds.t-internal.com>
Date: Mon, 24 Mar 2014 16:46:14 +0100
From: <CERT@...ekom.de>
To: <BugTraq@...urityfocus.com>
CC: <CERT@...ekom.de>
Subject: Deutsche Telekom CERT Advisory [DTC-A-20140324-002] vulnerabilities
 in check_mk

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@...ekom.de
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.

Powered by blists - more mailing lists