Deutsche Telekom CERT Advisory [DTC-A-20140324-002] update140328=20
Summary:=20
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, n=
o link necessary)
5 - Missing CSRF (Cross-Site Request Forgery) token allows execution of arb=
itrary 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 th=
e vulnerabilities 1, 2, 3, 4 and 7.=20
Vulnerabilities 5 and 6 are currently not fixed by the developer. To mitiga=
te these issues, deactivate the WATO feature. Deletion of =84wato.py=93 sho=
uld 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 a=
ccess 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 trig=
gered by sending a malicious URL to a user of the check_mk application. Onc=
e 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 th=
e check_mk application visits the check_mk website, the attack will be trig=
gered. Once the XSS attack is triggered, the attacker has access to the ful=
l 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 th=
e check_mk application visits the check_mk website, the attack will be trig=
gered. Once the XSS attack is triggered, the attacker has access to the ful=
l 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 d=
oes 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 soft=
ware module, which can be installed on monitored systems to extract data fr=
om 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 opera=
ting 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 encod=
ing, resulting in a stored XSS. This attack can be used to gain access to t=
he 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, n=
o 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 th=
e check_mk application visits the check_mk website, the attack will be trig=
gered. Once the XSS attack is triggered, the attacker has access to the ful=
l 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 d=
oes 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 monitore=
d system (not the check_mk or nagios host) to a service port, which is bein=
g logged by the "logwatch" functionality of check_mk. This module allows th=
e monitoring of logfiles for hosts monitored by check_mk. It is a very regu=
lar task for system administrators to monitor any anomalies and react to it=
accordingly by monitoring logfiles. Check_mk delivers this functionality b=
y 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 th=
at not the check_mk system or the administrator is attacked, but a system w=
hich is being monitored by check_mk. Usually those systems have a much grea=
ter attack surface than the monitoring systems such as check_mk - Both syst=
ems may even be separated by firewall, allowing only access from check_mk t=
o 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 net=
work 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 th=
e logwatch module, once installed. This setting allows the compromise of a =
check_mk host by initiating a specially crafted ssh connection to the targe=
ted host.
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
------------------------------
a5) check_mk v1.2.2p2 [CVE-2014-2330]
b5) Missing CSRF (Cross-Site Request Forgery) token allows execution of arb=
itrary 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/Cr=
oss-Site_Request_Forgery_(CSRF). This attack has a vast impact on the secur=
ity of the check_mk application, as multiple configuration parameters can b=
e changed using a CSRF attack. One very critical attack vector is the uploa=
d 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 att=
ack, 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 py=
thon 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 codeba=
se. A proof of concept attack has been developed, which exploits this fact.=
Uploading a snapshot file for instance with a modified "rules.mk" file res=
ulted in execution of this file as a python script. An attacker may impleme=
nt attacks (rather complex, as the full functionality of the Python scripti=
ng language including all standard modules can be utilized) in this file, w=
hich will be executed on the check_mk host, once the snapshot file is extra=
cted. 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 ha=
ve the proper access rights (usually the user under which the web applicati=
on is running), can be deleted. This may result in unexpected behavior and/=
or DoS of the application. More information about direct object/file refere=
nce can be found here: https://www.owasp.org/index.php/Top_10_2013-A4-Insec=
ure_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.
=20
Deutsche Telekom AG
Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman)
Board of Management: Timotheus H=F6ttges (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
=20
Big changes start small =96 conserve resources by not printing every e-mail=
..=