Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Active response tools allow arbitrary code execution #10858

Closed
vikman90 opened this issue Nov 16, 2021 · 13 comments
Closed

Active response tools allow arbitrary code execution #10858

vikman90 opened this issue Nov 16, 2021 · 13 comments
Assignees
Labels

Comments

@vikman90
Copy link
Member

vikman90 commented Nov 16, 2021

Wazuh version Component Install type Install method Platform Fix
4.2.0 Active-response script Manager/Agent Packages CentOS 7 #10809

This issue was reported by @rk700.

We found a command injection bug in the active-response script wazuh-slack.

The alert JSON data is put in the shell command line as POST body for curl:

snprintf(system_command, OS_MAXSTR -1, "curl -H \"Accept: application/json\" -H \"Content-Type: application/json\" -d '%s' %s", output_str, site_url);

However, the raw log line which could be partially controlled by an attacker is also included in the JSON data. Single quote in JSON is not escaped and therefore could be used to truncate the command:

-d '<json data that could be partially controlled>'

Remediation

  1. Prevent default Active Response tools from executing arbitrary code. Replace system() function call with wpopenv(), which executes subprocesses without a shell.
Active response tool Platform
disable-account UNIX
firewalld-drop Linux
netsh Windows
route-null Windows
wazuh-slack UNIX
  1. Sanitize the AR payload by the manager for agents between 4.2.0 and 4.2.4, in order to prevent this hazard in outdated agents. Convert control characters into their hexadecimal notation:
Character Conversion
Exclamation mark (!) \x21
Dollar ($) \x24
Single quote (') \x27
Backtick (`) \x60
@ajakk
Copy link

ajakk commented Nov 16, 2021

Has a CVE been requested for this issue?

It also seems like 4.2.5-rc1 was rewritten to be the 4.2.5 release, meaning that people watching the releases in the repository didn't get a notification for it. What happened here?

@vikman90
Copy link
Member Author

@ajakk yes, that is CVE-2021-44079.

Regarding your second question, we marked v4.2.5-rc1 as a pre-release, then we published v4.2.5 as a stable release. Is there anything wrong?

Best regards.

@ajakk
Copy link

ajakk commented Nov 22, 2021

@ajakk yes, that is CVE-2021-44079.

I requested that CVE and they seem to have used the suggested description that I wrote. Did you independently also request it? I think it's a bit strange to make a security release without a CVE, since CVEs are picked up by others who might not follow Wazuh releases closely. I only noticed this issue because I watch releases in this repository.

Regarding your second question, we marked v4.2.5-rc1 as a pre-release, then we published v4.2.5 as a stable release. Is there anything wrong?

I don't pretend to be familiar with how Github package releases work, but I only ever got a release notification for v4.2.5-rc1 so I think there's something a bit off here?

@vikman90
Copy link
Member Author

Hi. Thank you for your feedback, which will help us to define a procedure for vulnerabilities.

If you didn't receive a notification for v4.2.5, maybe it was because we created the pre-release (v4.2.5-rc1) and then modified it. With this in mind, next time we will do a new release.

Thank you.

@ajakk
Copy link

ajakk commented Nov 22, 2021

Thank you!

@torataks
Copy link

torataks commented Nov 30, 2021

Hi, does this issue exist in Wazuh versions before 4.2? It appears previous versions used shell-based AR scripts instead of C-based executables. At least for ossec-slack.sh it appears to sanitize the alert data by removing any double-quotes before passing it to wget or curl.

It's a bit confusing since CVE-2021-44079 states all Wazuh versions before 4.2.5 are affected.

On a related note, please consider explicitly mentioning security fixes in Wazuh's emails that announce new releases, and in the release notes --- 4.2.5's note just states it "includes new features or enhancements." Wazuh administrators shouldn't have to learn about security fixes via third-parties like CERT.

Thanks!

@Dageron
Copy link

Dageron commented Dec 1, 2021

Good morning, tell me when the next system upgrade is expected, so that you know when to start the upgrade to fix the vulnerability

@BABAgala00
Copy link

Hi @vikman90 , in wazuh 4.1.5 those scripts .sh , not python.
How should we edit it ?

@zetahoq
Copy link

zetahoq commented Dec 9, 2021

When is the update that patches this issue planned to roll out?

@ajakk
Copy link

ajakk commented Dec 9, 2021

When is the update that patches this issue planned to roll out?

The fix commit is in 4.2.5 and later:
a121e73

@vikman90
Copy link
Member Author

Hi all,

To clarify your concerns, this bug appeared in 4.2.0, as stated in the table above. It was produced by PR #7317 (issue #6954), where we translated the shell scripts (such as ossec-slack.sh) into C programs (like wazuh-slack.c). We are not aware of the shell version is vulnerable. Thus, this vulnerability affects Wazuh versions from 4.2.0 to 4.2.4 (included).

The patch for this bug (#10809) was released in v4.2.5, with a double fix:

  1. The agent (as of v4.2.5) now avoids arbitrary code execution by filtering escape characters properly.
  2. The manager (as of v4.2.5) replaces escape characters with their hexadecimal notation in Active response requests for agents with versions between 4.2.0 and 4.2.4 (vulnerable).

That's why upgrading either the agent or the manager will mitigate the vulnerability. However, we recommend upgrading both.

@torataks thank you for your comment, we will follow your suggestion to mention security fixes in upcoming releases.

On the other hand, @ajakk I would kindly ask you to request a change in the CVE to more precisely indicate the affected versions, in order to prevent confusion.

Should you have further questions or concerns, please let me know.

Regards.

@ajakk
Copy link

ajakk commented Dec 10, 2021

Done, but if you want a change to a CVE it can be done by anyone, there's nothing special about me with respect to the CVE.

@vikman90
Copy link
Member Author

Thank you @ajakk, I appreciate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants