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 vunerable 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` and requested a CVE.
------------------------------------<diff>-------------------------------------------
[//]: # (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 vunerable 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` and requested a CVE.
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`.
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.4.0b1
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 vunerable 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` and requested a CVE.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Synthetic Monitoring: Privilege Escalation
key | value
---------- | ---
date | 2024-06-24T14:56:31+00:00
version | 2.4.0b1
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 vunerable 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` and requested a CVE.
[//]: # (werk v2)
# global_settings: enable 'Hide Checkmk version' per default
key | value
---------- | ---
date | 2024-06-26T09:01:06+00:00
version | 2.4.0b1
class | security
edition | cre
component | wato
level | 1
compatible | yes
Displaying the version number on the login screen is generally regarded
as a security risk because it can enable attackers to identify potential
vulnerabilities associated with that specific version. Consequently, we
have changed the default setting to hide the version number. Users who wish
to view the version number can manually enable this option through the
Global Settings. It should be highlighted that users who have previously set
this option to show the version will not be affected by this change.
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`).
[//]: # (werk v2)
# Mitigate timing-unsafe comparisons to prevent byte-by-byte brute forcing attack
key | value
---------- | ---
date | 2024-06-25T10:10:15+00:00
version | 2.3.0p8
class | security
edition | cee
component | agents
level | 1
compatible | yes
A theorical brute force attack could be performed due to timing-unsafe secrets comparison.
This fix changes the way secrets are verified in communication with the agent.
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).
[//]: # (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 vunerable 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` and requested a CVE.
[//]: # (werk v2)
# Mitigate timing-unsafe comparisons to prevent byte-by-byte brute forcing attack
key | value
---------- | ---
date | 2024-06-25T10:10:15+00:00
version | 2.4.0b1
class | security
edition | cee
component | agents
level | 1
compatible | yes
A theorical brute force attack could be performed due to timing-unsafe secrets comparison.
This fix changes the way secrets are verified in communication with the agent.
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).
[//]: # (werk v2)
# Synthetic Monitoring: Privilege Escalation
key | value
---------- | ---
date | 2024-06-24T14:56:31+00:00
version | 2.4.0b1
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 vunerable 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` and requested a CVE.
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.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Mitigations</em>:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
<em>Vulnerability Management</em>:
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.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Mitigations</em>:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
<em>Vulnerability Management</em>:
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>.
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.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Mitigations</em>:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
<em>Vulnerability Management</em>:
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.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Mitigations</em>:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
<em>Vulnerability Management</em>:
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>.