Checkmk werks level2 June 2024

checkmk-werks-lvl2@lists.checkmk.com

1 participants
19 discussions

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

by Checkmk werks level 2

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 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 ? - - + 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`.

4 months, 2 weeks

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

by Checkmk werks level 2

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.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 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: 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.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 ? ----------------------- + copied to "~/audit_log_backup". If anything goes wrong - have to copy the files back to ~var/check_mk/wato/log and remove the automation + 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* + ``` + - secrets manually. If the update works as expected, you can remove the backup ? ------------------ + If the update works as expected, you can remove the backup files. ? +++++++ - 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>.

4 months, 2 weeks

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

by Checkmk werks level 2

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 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: 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 "~/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: 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>.

4 months, 2 weeks

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

by Checkmk werks level 2

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`.

4 months, 2 weeks

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

by Checkmk werks level 2

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>.

4 months, 2 weeks

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

by Checkmk werks level 2

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>.

4 months, 2 weeks

[2.3.0] Checkmk Werk 16841 created: mk-sql plugin produces backup section correctly

by Checkmk werks level 2

[//]: # (werk v2) # mk-sql plugin produces backup section correctly key | value ---------- | --- date | 2024-06-21T09:07:51+00:00 version | 2.3.0p7 class | fix edition | cre component | checks level | 2 compatible | yes Since this release the backup section content is identical to the expected one(from mssql.vbs)

4 months, 2 weeks

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

by Checkmk werks level 2

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`.

4 months, 2 weeks

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

by Checkmk werks level 2

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>.

4 months, 3 weeks

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

by Checkmk werks level 2

[//]: # (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`.

4 months, 3 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level2 June 2024