Checkmk werks security July 2024

checkmk-werks-sec@lists.checkmk.com

1 participants
48 discussions

[2.3.0] Checkmk Werk 16434 adapted: Synthetic Monitoring: Privilege Escalation

by Checkmk security werks

Werk 16434 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # Synthetic Monitoring: Privilege Escalation key | value ---------- | --- date | 2024-06-24T14:56:31+00:00 version | 2.3.0p8 class | security edition | cee component | agents level | 1 compatible | yes The Robotmk scheduler was affected by a privilege escalation issue. This issue affects users, which have configured the rule `Robotmk scheduler (Windows)`. Specifically, an attacker is able to exploit the issue, if 1. `Automated environment setup (via RCC)` was configured in the `Robotmk scheduler (Windows)` rule, 2. the same plan was configured without configuring `Execute plan as a specific user` 3. and a user on the host, onto which the scheduler has been deployed, was compromised. In this event, the attacker could gain SYSTEM privileges on the host. If `Execute plan as a specific user` _is_ configured, then the attacker could compromise that specific user, rather than SYSTEM. There is a second similar, but distinct issue. If - there are two or more plans configured with `Execute plan as a specific user` with distinct users - and one of the configured users was already compromised. The attacker could then compromise the other user. *Background*: The Robotmk scheduler is started by the Checkmk agent that runs with SYSTEM privileges. Moreover, Robotmk allows the user to automatically build Python environments via RCC. During setup the scheduler would enable a RCC feature called `shared holotree usage`. This feature allows all users on the host to edit these Python environments. Thus, any compromised user on the host is also able to compromise a user, which executes code from these shared environments. With this Werk, `shared holotree usage` will no longer be enabled. Affected users will have their access to the vulnerable Python environments revoked. Moreover, the permissions inside of the working directory of Robotmk have been reworked. Users now only have access to directories, which are required for their own executions. Note, you must update both Checkmk and redeploy the latest Robotmk Scheduler. *Affected Versions*: * 2.3.0 *Mitigations*: If updating is not possible: * Do not use the rule `Automated environment setup (via RCC)`. * Always use the same user for `Execute plan as a specific user`. *Vulnerability Management*: We have rated the issue with a CVSS Score of 7.8 (High) with the following CVSS vector: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`. CVE-2024-39934 has been assigned to this issue. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Synthetic Monitoring: Privilege Escalation key | value ---------- | --- date | 2024-06-24T14:56:31+00:00 - version | 2.3.0p11 ? ^^ + version | 2.3.0p8 ? ^ class | security edition | cee component | agents level | 1 compatible | yes The Robotmk scheduler was affected by a privilege escalation issue. This issue affects users, which have configured the rule `Robotmk scheduler (Windows)`. Specifically, an attacker is able to exploit the issue, if 1. `Automated environment setup (via RCC)` was configured in the `Robotmk scheduler (Windows)` rule, 2. the same plan was configured without configuring `Execute plan as a specific user` 3. and a user on the host, onto which the scheduler has been deployed, was compromised. In this event, the attacker could gain SYSTEM privileges on the host. If `Execute plan as a specific user` _is_ configured, then the attacker could compromise that specific user, rather than SYSTEM. There is a second similar, but distinct issue. If - there are two or more plans configured with `Execute plan as a specific user` with distinct users - and one of the configured users was already compromised. The attacker could then compromise the other user. *Background*: The Robotmk scheduler is started by the Checkmk agent that runs with SYSTEM privileges. Moreover, Robotmk allows the user to automatically build Python environments via RCC. During setup the scheduler would enable a RCC feature called `shared holotree usage`. This feature allows all users on the host to edit these Python environments. Thus, any compromised user on the host is also able to compromise a user, which executes code from these shared environments. With this Werk, `shared holotree usage` will no longer be enabled. Affected users will have their access to the vulnerable Python environments revoked. Moreover, the permissions inside of the working directory of Robotmk have been reworked. Users now only have access to directories, which are required for their own executions. Note, you must update both Checkmk and redeploy the latest Robotmk Scheduler. *Affected Versions*: * 2.3.0 *Mitigations*: If updating is not possible: * Do not use the rule `Automated environment setup (via RCC)`. * Always use the same user for `Execute plan as a specific user`. *Vulnerability Management*: We have rated the issue with a CVSS Score of 7.8 (High) with the following CVSS vector: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`. CVE-2024-39934 has been assigned to this issue.

1 month, 1 week

[2.3.0] Checkmk Werk 17010 adapted: XSS in SQL check parameters

by Checkmk security werks

Werk 17010 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # XSS in SQL check parameters key | value ---------- | --- date | 2024-06-17T10:08:19+00:00 version | 2.3.0p8 class | security edition | cre component | wato level | 1 compatible | yes Prior to this Werk an attacher could add HTML to one parameter of the *Check SQL database* rule which was executed on the overview page. We found this vulnerability internally. **Affected Versions**: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (probably older versions as well) **Indicators of Compromis**: The creation of such rules is logged in the audit log. You can therefore check the `wato_audit.log` either on the terminal or in the UI for entries that contain malicious HTML. **Vulnerability Management**: We have rated the issue with a CVSS Score of 6.5 (Medium) with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L` We assigned CVE-2024-6052 to this vulnerability. **Changes**: This Werk fixes the escaping. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # XSS in SQL check parameters key | value ---------- | --- date | 2024-06-17T10:08:19+00:00 - version | 2.3.0p11 ? ^^ + version | 2.3.0p8 ? ^ class | security edition | cre component | wato level | 1 compatible | yes Prior to this Werk an attacher could add HTML to one parameter of the *Check SQL database* rule which was executed on the overview page. We found this vulnerability internally. **Affected Versions**: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (probably older versions as well) **Indicators of Compromis**: The creation of such rules is logged in the audit log. You can therefore check the `wato_audit.log` either on the terminal or in the UI for entries that contain malicious HTML. **Vulnerability Management**: We have rated the issue with a CVSS Score of 6.5 (Medium) with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L` We assigned CVE-2024-6052 to this vulnerability. **Changes**: This Werk fixes the escaping. -

1 month, 1 week

[2.1.0] Checkmk Werk 17013 created: Livestatus injection in mknotifyd

by Checkmk security werks

Title: Livestatus injection in mknotifyd Class: security Compatible: compat Component: notifications Date: 1720439889 Edition: cee Level: 1 Version: 2.1.0p47 Before this Werk a malicious notification sent via mknotifyd could allow an attacker to send arbitrary livestatus commands. With this Werk livestatus escaping was added to the relevant functions. This issue was found during internal review. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (EOL) Vulnerability Management: We have rated the issue with a CVSS Score of 6.5 Medium (<code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L</code>) and assigned <code>CVE-2024-6542</code>.

1 month, 2 weeks

[2.2.0] Checkmk Werk 17013 created: Livestatus injection in mknotifyd

by Checkmk security werks

Title: Livestatus injection in mknotifyd Class: security Compatible: compat Component: notifications Date: 1720439889 Edition: cee Level: 1 Version: 2.2.0p32 Before this Werk a malicious notification sent via mknotifyd could allow an attacker to send arbitrary livestatus commands. With this Werk livestatus escaping was added to the relevant functions. This issue was found during internal review. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (EOL) Vulnerability Management: We have rated the issue with a CVSS Score of 6.5 Medium (<code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L</code>) and assigned <code>CVE-2024-6542</code>.

1 month, 3 weeks

[2.2.0] Checkmk Werk 17012 created: Check for predefined connections when deploying xinetd config

by Checkmk security werks

Title: Check for predefined connections when deploying xinetd config Class: security Compatible: incomp Component: checks Date: 1719818629 Edition: cce Level: 1 Version: 2.2.0p32 When an agent rule Agent controller auto-registration (Managed Services Edition, Cloud Edition) was configured for an agent package one might assume that when installing this package the agent encrypts its traffic. But when installing such a package on a system without systemd but with xinetd installed or a very old systemd versions, the agent was deployed without registration and encryption. With this Werk the deployment script for systemd/xinetd checks for predefined/preconfigured connections and if it finds any it refuses to configure the legacy mode. The agent is still installed though but will not be accessible via the network, so access with SSH will still be possible. Therefore you can no longer use baked packages with auto registration for systems without systemd or very old systemd versions where the legacy mode is desired. These systems need to be excluded from the Agent controller auto-registration (Managed Services Edition, Cloud Edition) rule. Vulnerability Management: We do not rate this as a exploitable vulnerability but a safe guard for unintended configurations, therefore no CVE was assigned. To aid automated scanning we assign a CVSS score of 0.0 None (<code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N</code>).

1 month, 3 weeks

[2.3.0] Checkmk Werk 17012 created: Check for predefined connections when deploying xinetd config

by Checkmk security werks

[//]: # (werk v2) # Check for predefined connections when deploying xinetd config key | value ---------- | --- date | 2024-07-01T07:23:49+00:00 version | 2.3.0p11 class | security edition | cce component | checks level | 1 compatible | no When an agent rule *Agent controller auto-registration (Managed Services Edition, Cloud Edition)* was configured for an agent package one might assume that when installing this package the agent encrypts its traffic. But when installing such a package on a system without systemd but with xinetd installed or a very old systemd versions, the agent was deployed without registration and encryption. With this Werk the deployment script for systemd/xinetd checks for predefined/preconfigured connections and if it finds any it refuses to configure the legacy mode. The agent is still installed though but will not be accessible via the network, so access with SSH will still be possible. Therefore you can no longer use baked packages with auto registration for systems without systemd or very old systemd versions where the legacy mode is desired. These systems need to be excluded from the *Agent controller auto-registration (Managed Services Edition, Cloud Edition)* rule. *Vulnerability Management*: We do not rate this as a exploitable vulnerability but a safe guard for unintended configurations, therefore no CVE was assigned. To aid automated scanning we assign a CVSS score of 0.0 None (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N`).

1 month, 3 weeks

[2.4.0] Checkmk Werk 17012 created: Check for predefined connections when deploying xinetd config

by Checkmk security werks

[//]: # (werk v2) # Check for predefined connections when deploying xinetd config key | value ---------- | --- date | 2024-07-01T07:23:49+00:00 version | 2.4.0b1 class | security edition | cce component | checks level | 1 compatible | no When an agent rule *Agent controller auto-registration (Managed Services Edition, Cloud Edition)* was configured for an agent package one might assume that when installing this package the agent encrypts its traffic. But when installing such a package on a system without systemd but with xinetd installed or a very old systemd versions, the agent was deployed without registration and encryption. With this Werk the deployment script for systemd/xinetd checks for predefined/preconfigured connections and if it finds any it refuses to configure the legacy mode. The agent is still installed though but will not be accessible via the network, so access with SSH will still be possible. Therefore you can no longer use baked packages with auto registration for systems without systemd or very old systemd versions where the legacy mode is desired. These systems need to be excluded from the *Agent controller auto-registration (Managed Services Edition, Cloud Edition)* rule. *Vulnerability Management*: We do not rate this as a exploitable vulnerability but a safe guard for unintended configurations, therefore no CVE was assigned. To aid automated scanning we assign a CVSS score of 0.0 None (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N`).

1 month, 3 weeks

[2.3.0] Checkmk Werk 17013 created: Livestatus injection in mknotifyd

by Checkmk security werks

[//]: # (werk v2) # Livestatus injection in mknotifyd key | value ---------- | --- date | 2024-07-08T11:58:09+00:00 version | 2.3.0p11 class | security edition | cee component | notifications level | 1 compatible | yes Before this Werk a malicious notification sent via mknotifyd could allow an attacker to send arbitrary livestatus commands. With this Werk livestatus escaping was added to the relevant functions. This issue was found during internal review. *Affected Versions*: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 (EOL) *Vulnerability Management*: We have rated the issue with a CVSS Score of 6.5 Medium (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L`) and assigned `CVE-2024-6542`.

1 month, 3 weeks

[2.1.0] Checkmk Werk 17011 adapted: Fix local IP restriction of internal HTTP endpoints

by Checkmk security werks

Werk 17011 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Fix local IP restriction of internal HTTP endpoints Class: security Compatible: compat Component: wato Date: 1718804769 Edition: cre Level: 1 Version: 2.1.0p47 Checkmk has some complex functionalities that are hidden behind an internal HTTP endpoint page. These pages are only meant to be accessed by internal processes, e.g. a cron runner or creating diagrams for notifications. Therefore these pages are protected to be only accessible locally. In order to recognize the client IP through the usage of a reverse proxy Checkmk uses the <code>X-Forwarded-For</code> header. That header is added and complemented by <code>mod_proxy</code> and usually trustworthy. When the site apache is exposed directly to the network though (e.g. the default docker setup) no proxy apache is there to curate this header. To mitigate this the site apache is supposed to filter these internal page URIs to be only accessible by localhost. This mitigation failed due to some outdated configuration and wrong configuration ordering. This only affects systems which expose the site apache port to the network typically 5000. If you run Checkmk behind a reverse proxy (the default if you installed a installation package) you are not affected! This vulnerability was identified in a commissioned penetration test conducted by PS Positive Security GmbH. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (probably older versions as well) Mitigations: You can add the following configuration to the site apache configuration, e.g. <code>etc/apache/conf.d/zzz_werk17011.conf</code>: C+: <Location "/###SITE###/check_mk/run_cron.py"> Order deny,allow Deny from all Require local Satisfy any </Location> # Webservice for graph images used by notifications <Location "/###SITE###/check_mk/ajax_graph_images.py"> Order deny,allow Deny from all Require local Satisfy any </Location> C-: Indicators of Compromise: You can check the apache access log <code>var/log/apache/access_log</code> for calls to <code>run_cron.py</code> or <code>ajax_graph_images.py</code> from network hosts. E.g. <code>grep --extended-regexp "^[^-].+(run_cron|ajax_graph_images.py)" var/log/apache/access_log</code> Vulnerability Management: We have rated the issue with a CVSS Score of 5.3 (Medium) with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N</code>. We assigned CVE-2024-6163 to this vulnerability. Changes: This Werk fixes the configuration syntax and ordering. ------------------------------------<diff>------------------------------------------- Title: Fix local IP restriction of internal HTTP endpoints Class: security Compatible: compat Component: wato Date: 1718804769 Edition: cre Level: 1 - Version: 2.1.0p46 ? ^ + Version: 2.1.0p47 ? ^ Checkmk has some complex functionalities that are hidden behind an internal HTTP endpoint page. These pages are only meant to be accessed by internal processes, e.g. a cron runner or creating diagrams for notifications. Therefore these pages are protected to be only accessible locally. In order to recognize the client IP through the usage of a reverse proxy Checkmk uses the <code>X-Forwarded-For</code> header. That header is added and complemented by <code>mod_proxy</code> and usually trustworthy. When the site apache is exposed directly to the network though (e.g. the default docker setup) no proxy apache is there to curate this header. To mitigate this the site apache is supposed to filter these internal page URIs to be only accessible by localhost. This mitigation failed due to some outdated configuration and wrong configuration ordering. This only affects systems which expose the site apache port to the network typically 5000. If you run Checkmk behind a reverse proxy (the default if you installed a installation package) you are not affected! This vulnerability was identified in a commissioned penetration test conducted by PS Positive Security GmbH. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (probably older versions as well) Mitigations: You can add the following configuration to the site apache configuration, e.g. <code>etc/apache/conf.d/zzz_werk17011.conf</code>: C+: <Location "/###SITE###/check_mk/run_cron.py"> Order deny,allow Deny from all Require local Satisfy any </Location> # Webservice for graph images used by notifications <Location "/###SITE###/check_mk/ajax_graph_images.py"> Order deny,allow Deny from all Require local Satisfy any </Location> C-: Indicators of Compromise: You can check the apache access log <code>var/log/apache/access_log</code> for calls to <code>run_cron.py</code> or <code>ajax_graph_images.py</code> from network hosts. E.g. <code>grep --extended-regexp "^[^-].+(run_cron|ajax_graph_images.py)" var/log/apache/access_log</code> Vulnerability Management: We have rated the issue with a CVSS Score of 5.3 (Medium) with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N</code>. We assigned CVE-2024-6163 to this vulnerability. Changes: This Werk fixes the configuration syntax and ordering.

1 month, 3 weeks

[2.1.0] Checkmk Werk 16990 created: NagVis: Updated to 1.9.42 (fix security issues)

by Checkmk security werks

Title: NagVis: Updated to 1.9.42 (fix security issues) Class: security Compatible: compat Component: packages Date: 1720609589 Edition: cre Level: 1 Version: 2.1.0p46 NagVis has been updated to version 1.9.42. This update fixes the following security issues: - Fix various XSS issues (CVSS score: 8.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) - Fix potential RCE - Fix insecure password hashing algorithm for dedicated NagVis users (CVSS score 5.1 CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) - Fix leak of installation path in error messages - Fix Make cookie hash comparison timing safe

1 month, 3 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Checkmk werks security July 2024