Checkmk werks security July 2022

checkmk-werks-sec@lists.checkmk.com

3 participants
4 discussions

Checkmk Werk 14261: Manual enablement of login using HTTP GET to avoid unintentional leakage of user credentials in Apache's access logs

by Alei Salem

ID: 14261 Title: Manual enablement of login using HTTP GET to avoid unintentional leakage of user credentials in Apache's access logs Component: Setup Level: 1 Class: Security fix Version: 2.2.0i1 Using <tt>GET</tt> requests to <tt>login.py</tt> means that the credentials supplied in the query parameters will appear in the site's Apache logs. To avoid unintentional leakage of such credentials, we <b>by default</b> block login attempts via the <tt>GET</tt> method. If you used the <tt>GET</tt> method to, for example, export the data of views and dashboards in formats such as <tt>JSON</tt>, you can make use of the <tt>automation</tt> user as described in <a href="https://docs.checkmk.com/latest/en/wato_user.html#automation">documentation</a> article. For example, to display the view <i>allhosts</i> in <tt>JSON</tt> format, you can issue requests like this one <tt>curl -X GET 'http://localhost/heute/check_mk/view.py?_username=automation&_secret=[autom…'</tt>. However, if you <b>still need to use the <tt>GET</tt> method to login to WATO</b>, you can manually enable this method as follows: In the WATO interface, go to Setup > Global Settings > User interface, and switch on the <i>Enable login via GET requests</i> property.

1 year, 9 months

Checkmk Werk 14281: Fix local privilege escalation from site users

by Lars Michelsen

ID: 14281 Title: Fix local privilege escalation from site users Component: Site Management Level: 1 Class: Security fix Version: 2.2.0i1 Each Checkmk site provides it's HTTP services (UI, APIs) using it's own site Apache process. Global access to this site Apache is provided via the system Apache which is opening the 80 and 443 ports for external requests, depending on your system configuration. To learn about the site Apache, the system Apache reads a reverse proxy configuration provided by the site user. This could be used by a site user to make the system Apache execute code as root user, since the System Apache is typically started initially with root privileges. To close this gap, we now need to separate the system Apache configuration from the site user access. To eliminate the privilege escalation, you will have to execute the command <tt>omd update-apache-config [SITE]</tt> once for each of your sites after the <tt>omd update</tt> command. Besides the one-time fix, this change has a consequence for the use of <tt>omd config</tt> and <tt>omd update</tt>. There are two situations where this is relevant: a) If you change the options APACHE_TCP_ADDR, APACHE_TCP_PORT or APACHE_MODE You will have to call <tt>omd update-apache-config [SITE]</tt> as root user after changing one of the site configuration options APACHE_TCP_ADDR, APACHE_TCP_PORT or APACHE_MODE. This needs to be done to update and apply the system Apache configuration. If you don't do this and start your site, your UI may be not available anymore. The <tt>omd config</tt> command will output a warning to notify you about this necessary step in the future. b) If you execute <tt>omd update</tt> and the proxy configuration changes The update is performed as site user. Which means that, after this werk, we can not update and apply the system apache configuration anymore automatically. To apply the latest apache configuration, the command <tt>omd update-apache-config [SITE]</tt> needs to be executed after the update. The <tt>omd update</tt> will automatically detect the need for this additional step and show you a confirmation dialog before starting the update to notify you about this necessary step and giving you the chance to interrupt the procedure in case you don't have the option to execute the command as root user. All maintained versions (>=1.6) are subject to this vulnerability. It is likely that also previous versions were vulnerable. Users of previous versions are highly recommended to update or consider other mitigations. If you want to solve this issue for a site that is using an unpatched version, you can do it by replacing the file <tt>/omd/apache/[SITE].conf</tt> with a file like follows. Please note, that you will have to replace all occurrences <tt>[SITE]</tt> with the ID of your site and <tt>[PORT]</tt> with the port of the site apache. After you replaced the file, you will have to restart the system Apache. C+ # version: 0 # Make sure that symlink /omd does not make problems <Directory /> Options +FollowSymlinks </Directory> <IfModule mod_proxy_http.c> ProxyRequests Off ProxyPreserveHost On <Proxy http://127.0.0.1:[PORT]/[SITE]> Order allow,deny allow from all </Proxy> <Location /[SITE]> # Setting "retry=0" to prevent 60 second caching of problem states e.g. when # the site apache is down and someone tries to access the page. # "disablereuse=On" prevents the apache from keeping the connection which leads to # wrong devlivered pages sometimes ProxyPass http://127.0.0.1:[PORT]/[SITE] retry=0 disablereuse=On timeout=120 ProxyPassReverse http://127.0.0.1:[PORT]/[SITE] </Location> </IfModule> <IfModule !mod_proxy_http.c> Alias /[SITE] /omd/sites/[SITE] <Directory /omd/sites/[SITE]> Deny from all ErrorDocument 403 "<h1>Checkmk: Incomplete Apache Installation</h1>You need mod_proxy and mod_proxy_http in order to run the web interface of Checkmk." </Directory> </IfModule> <Location /[SITE]> ErrorDocument 503 "<meta http-equiv='refresh' content='60'><h1>Checkmk: Site Not Started</h1>You need to start this site in order to access the web interface." </Location> C-: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H 7.0 (https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/…) CVE will be added later. We thank Jan-Philipp Litza (PLUTEX GmbH) for reporting this issue!

1 year, 10 months

Checkmk Werk 14281: Fix local privilege escalation from site users

by Lars Michelsen

1 year, 10 months

Checkmk Werk 14378: Mask passwords in REST API responses

by Hannes Rantzsch

ID: 14378 Title: Mask passwords in REST API responses Component: REST API Level: 1 Class: Security fix Version: 2.2.0i1 Mask sensitive information when querying rules via the REST API.

1 year, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Checkmk werks security July 2022