Home page logo
/

bugtraq logo Bugtraq mailing list archives

Deutsche Telekom CERT Advisory [DTC-A-20140324-002] update140328 - vulnerabilities in check_mk
From: <CERT () telekom de>
Date: Fri, 28 Mar 2014 17:56:24 +0100

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

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

Update to original advisory:
Corrected: vulnerability 5 and 6 (not 4 and 5) are currently not fixed.

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, 4 and 7. 
Vulnerabilities 5 and 6 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 () telekom 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.

  By Date           By Thread  

Current thread:
  • Deutsche Telekom CERT Advisory [DTC-A-20140324-002] update140328 - vulnerabilities in check_mk CERT (Mar 28)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault