Checkmk werks security June 2024

checkmk-werks-sec@lists.checkmk.com

1 participants
34 discussions

[2.3.0] Checkmk Werk 17056 adapted: Don't show automation secret in the audit log (addresses CVE-2024-28830)

by Checkmk security werks

Werk 17056 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # Don't show automation secret in the audit log (addresses CVE-2024-28830) key | value ---------- | --- date | 2024-06-19T12:10:00+00:00 version | 2.3.0p7 class | security edition | cre component | wato level | 2 compatible | no By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is copied to "~/audit_log_backup". If anything goes wrong during the update, you have to copy the files back to ~var/check_mk/wato/log and remove the automation secrets manually by running ``` sed -i 's/Value of "automation_secret" changed from "[^"]*" to "[^"]*".\\n//g' ~/var/check_mk/wato/log/wato_audit* sed -i 's/Attribute "automation_secret" with value "[^"]*" added.\\n//g' ~/var/check_mk/wato/log/wato_audit* ``` If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. *Affected Versions*: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 (EOL) *Mitigations*: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. *Vulnerability Management*: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE `CVE-2024-28830`. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Don't show automation secret in the audit log (addresses CVE-2024-28830) key | value ---------- | --- date | 2024-06-19T12:10:00+00:00 version | 2.3.0p7 class | security edition | cre component | wato level | 2 compatible | no By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is copied to "~/audit_log_backup". If anything goes wrong during the update, you have to copy the files back to ~var/check_mk/wato/log - and remove the automation secrets manually. If the update works as expected, - you can remove the backup files. + and remove the automation secrets manually by running + + ``` + sed -i 's/Value of "automation_secret" changed from "[^"]*" to "[^"]*".\\n//g' ~/var/check_mk/wato/log/wato_audit* + sed -i 's/Attribute "automation_secret" with value "[^"]*" added.\\n//g' ~/var/check_mk/wato/log/wato_audit* + ``` + + If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. *Affected Versions*: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 (EOL) *Mitigations*: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. *Vulnerability Management*: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE `CVE-2024-28830`.

3 months, 3 weeks

[2.1.0] Checkmk Werk 17056 created: Don't show automation secret in the audit log (addresses CVE-2024-28830)

by Checkmk security werks

Title: Don't show automation secret in the audit log (addresses CVE-2024-28830) Class: security Compatible: incomp Component: wato Date: 1718799000 Edition: cre Level: 2 Version: 2.1.0p45 By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is copied to "~/audit_log_backup". If anything goes wrong during the update, you have to copy the files back to ~var/check_mk/wato/log and remove the automation secrets manually. If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (EOL) Mitigations: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. Vulnerability Management: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N</code> and assigned CVE <code>CVE-2024-28830</code>.

3 months, 4 weeks

[2.2.0] Checkmk Werk 17056 adapted: Don't show automation secret in the audit log (addresses CVE-2024-28830)

by Checkmk security werks

Werk 17056 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Don't show automation secret in the audit log (addresses CVE-2024-28830) Class: security Compatible: incomp Component: wato Date: 1718799000 Edition: cre Level: 2 Version: 2.2.0p28 By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is copied to "~/audit_log_backup". If anything goes wrong during the update, you have to copy the files back to ~var/check_mk/wato/log and remove the automation secrets manually. If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (EOL) Mitigations: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. Vulnerability Management: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N</code> and assigned CVE <code>CVE-2024-28830</code>. ------------------------------------<diff>------------------------------------------- Title: Don't show automation secret in the audit log (addresses CVE-2024-28830) Class: security Compatible: incomp Component: wato Date: 1718799000 Edition: cre Level: 2 Version: 2.2.0p28 By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is - copied to "~/var/check_mk/wato/log/sanitize_backup". If anything goes wrong ? - ^^^^^^^ -------- --------- + copied to "~/audit_log_backup". If anything goes wrong ? ^^^^ during the update, you have to copy the files back to ~var/check_mk/wato/log and remove the automation secrets manually. If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (EOL) Mitigations: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. Vulnerability Management: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N</code> and assigned CVE <code>CVE-2024-28830</code>.

3 months, 4 weeks

[2.3.0] Checkmk Werk 17056 adapted: Don't show automation secret in the audit log (addresses CVE-2024-28830)

by Checkmk security werks

Werk 17056 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # Don't show automation secret in the audit log (addresses CVE-2024-28830) key | value ---------- | --- date | 2024-06-19T12:10:00+00:00 version | 2.3.0p7 class | security edition | cre component | wato level | 2 compatible | no By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is copied to "~/audit_log_backup". If anything goes wrong during the update, you have to copy the files back to ~var/check_mk/wato/log and remove the automation secrets manually. If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. *Affected Versions*: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 (EOL) *Mitigations*: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. *Vulnerability Management*: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE `CVE-2024-28830`. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Don't show automation secret in the audit log (addresses CVE-2024-28830) key | value ---------- | --- date | 2024-06-19T12:10:00+00:00 version | 2.3.0p7 class | security edition | cre component | wato level | 2 compatible | no By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is - copied to "~/var/check_mk/wato/log/sanitize_backup". If anything goes wrong ? - ^^^^^^^ -------- --------- + copied to "~/audit_log_backup". If anything goes wrong ? ^^^^ during the update, you have to copy the files back to ~var/check_mk/wato/log and remove the automation secrets manually. If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. *Affected Versions*: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 (EOL) *Mitigations*: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. *Vulnerability Management*: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE `CVE-2024-28830`.

3 months, 4 weeks

[2.4.0] Checkmk Werk 17089 created: Change Transaction ID Format

by Checkmk security werks

[//]: # (werk v2) # Change Transaction ID Format key | value ---------- | --- date | 2024-06-21T07:56:55+00:00 version | 2.4.0b1 class | security edition | cre component | wato level | 1 compatible | yes This Werk changes the format of transaction IDs and the way they are generated. Before this Werk transaction IDs used the format `<unix timestamp>/<number>`. The new format is `<unix timestamp>/<string>`, where the string component can contain any URL-safe character. Transaction IDs are now generated using a cryptographically secure random number generator. This security Werk does not address any exploitable vulnerability. 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`).

3 months, 4 weeks

[2.1.0] Checkmk Werk 17024 created: Fix XSS in Crash Report Page

by Checkmk security werks

Title: Fix XSS in Crash Report Page Class: security Compatible: compat Component: wato Date: 1717679856 Edition: cre Level: 1 Version: 2.1.0p45 Prior to this Werk, it was possible to inject HTML elements into Crash report URL in the Global settings, leading to an <code>XSS</code> vulnerability in the Crash reports page. This vulnerability was identified during 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 (EOL) Indicators of Compromise: Check the crash report HTTP URL in the Global settings for suspicious HTML elements. Vulnerability Management: We have rated the issue with a CVSS Score of 4.8 Medium with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N</code>. and assigned <code>CVE-2024-28832</code>.

3 months, 4 weeks

[2.2.0] Checkmk Werk 17056 created: Don't show automation secret in the audit log (addresses CVE-2024-28830)

by Checkmk security werks

Title: Don't show automation secret in the audit log (addresses CVE-2024-28830) Class: security Compatible: incomp Component: wato Date: 1718799000 Edition: cre Level: 2 Version: 2.2.0p28 By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is copied to "~/var/check_mk/wato/log/sanitize_backup". If anything goes wrong during the update, you have to copy the files back to ~var/check_mk/wato/log and remove the automation secrets manually. If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (EOL) Mitigations: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. Vulnerability Management: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N</code> and assigned CVE <code>CVE-2024-28830</code>.

3 months, 4 weeks

[2.2.0] Checkmk Werk 17025 created: Fix XSS in confirmation pop-up

by Checkmk security werks

Title: Fix XSS in confirmation pop-up Class: security Compatible: compat Component: wato Date: 1718016028 Edition: cre Level: 1 Version: 2.2.0p28 Prior to this Werk, there was a potential for HTML elements from user inputs to be rendered in certain confirmation pop-ups, leading to an XSS vulnerability. This vulnerability was identified during a commissioned penetration test conducted by PS Positive Security GmbH. Affected Versions: LI: 2.3.0 LI: 2.2.0 Indicators of Compromise: Injected HTML elements in some specific user input fields with no proper escaping that are displayed in the confirmation pop-up. Vulnerability Management: We have rated the issue with a CVSS Score of 5.4 Medium with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N</code>, and assigned <code>CVE-2024-28831</code>.

3 months, 4 weeks

[2.2.0] Checkmk Werk 17024 created: Fix XSS in Crash Report Page

by Checkmk security werks

Title: Fix XSS in Crash Report Page Class: security Compatible: compat Component: wato Date: 1717679856 Edition: cre Level: 1 Version: 2.2.0p28 Prior to this Werk, it was possible to inject HTML elements into Crash report URL in the Global settings, leading to an <code>XSS</code> vulnerability in the Crash reports page. This vulnerability was identified during 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 (EOL) Indicators of Compromise: Check the crash report HTTP URL in the Global settings for suspicious HTML elements. Vulnerability Management: We have rated the issue with a CVSS Score of 4.8 Medium with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N</code>. and assigned <code>CVE-2024-28832</code>.

3 months, 4 weeks

[2.3.0] Checkmk Werk 17056 created: Don't show automation secret in the audit log (addresses CVE-2024-28830)

by Checkmk security werks

[//]: # (werk v2) # Don't show automation secret in the audit log (addresses CVE-2024-28830) key | value ---------- | --- date | 2024-06-19T12:10:00+00:00 version | 2.3.0p7 class | security edition | cre component | wato level | 2 compatible | no By default only admin users are able to see the audit log. Guests and normal monitoring users do not have acces to the audit log. Werk #13330 already fixed a problem where passwords were shown in the audit log. This werk now addresses the problem, that still automation secrets of automation user were logged in clear text to the audit log, e.g. on change of the automation secret via REST-API or the user interface. Existing automation secrets in the audit log should be removed automatically during the update but please double check that no automation secrets remain in the log (see next paragraph for details). A backup of the original audit log (before automation secrets were removed) is copied to "~/var/check_mk/wato/log/sanitize_backup". If anything goes wrong during the update, you have to copy the files back to ~var/check_mk/wato/log and remove the automation secrets manually. If the update works as expected, you can remove the backup files. In distributed setups which do not replicate the configuration, automation secrets are replaced during the update of each site. In setups which replicate the configuration from central to remote sites no automation secrets should be present in the logs of the remote site, since only information about the activation is logged. Only if you switched to a replicated setup after the upgrade to the 2.0, automation secrets can be present in the logs. Since automation secrets may be in this scenario as well, the steps described before also apply. *Affected Versions*: * 2.3.0 * 2.2.0 * 2.1.0 * 2.0.0 (EOL) *Mitigations*: Remove automation secrets manually within the files located in ~var/check_mk/wato/log. *Vulnerability Management*: We have rated the issue with a CVSS Score of <2.7 (Low)> with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE `CVE-2024-28830`.

3 months, 4 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Checkmk werks security June 2024