The goals of this post are:
1. To show how analysts could detect the attack occurring using a SIEM
2. To show what the attack/walkthrough would look like in a SIEM
3. To learn about additional tools that you can use to conduct or mitigate the attack.
Lab
1. In the previous post I walked through setting up a docker image called splunk/splunk and installing a Splunk Forwarder on the vulnerable image I was working with. I am going to conduct the same with the Seattle 0.0.3 vulnhub VM.
2. My setup quickly is a VM running Kali Linux (172.16.216.130) with docker running. I am running the docker image for Splunk (172.17.0.2) on Kali. The networking on the Kali VM is setup to be host-only. From my linux host I can reach the 172.16.216.130 VM. I am going to use the hosts IP Address and NAT the ports I need for Splunk. On the Kali VM I have ssh enabled and connecting with the "-X" option to be able to X11 forward everything to my host.
Command on Kali to Start SSH: /etc/init.d/ssh start
Command on Host to Forward X11: ssh -X root@172.16.216.130
4. Then I started the docker service and loaded the splunk image.
Command: service docker start
Command: docker run -it -p 172.16.216.130:8000:8000 -p 172.16.216.130:9997:9997 splunk/splunk
5. Then I load as a second VM the Seattle 0.0.3 (172.16.230.131). Observe that this VM is 64 bit. I need to transfer the Splunk Forwarder to this VM. In the previous post I used Secure Copy using SSH. In this post I am going to use a Python SimpleHTTP Web Server to host the files and then pull them from the Seattle VM. I use this method to transfer or load files occasionally when I am working on vulnerable images.
First: Navigate to the directory of where the files are that you need to host in a simple web server. In the below example I have a folder called Splunk with the 32 and 64 bit splunk forwarders. Observe that this VM is built on Fedora 64bit so you need the rpm package of the Splunk Universal Forwarder. The Simple Server will serve all of the files in the given directory.
Command: python -m SimpleHTTPServer
Note: You can follow the command with a specific port number. By default it serves the files on port 8000.
6. Pull the file that you need from the Seattle 0.0.3 virtual machine using bash. Assuming you have root on the Seattle VM through SSH. I built a script in bash to demonstrate using native bash commands to download the file. You can really simplify the below script if you need to...
Challenge: Create the script, change permissions, execute it, and download the Splunk Universal Forwarder for Fedora/Red Hat.
7. The VM has a keyboard layout is for a GB keyboard layout. You can change this by modifying 2 files listed below, however as an attacker if you do make the change make sure you change it back. I often find that attackers do a fair job in cleaning-up but often miss these small things that they change. Google how to change the keyboard layout in Fedora as part of the challenge.
/etc/locale.conf
/etc/vconsole.conf
8. Install the Splunk Universal Forwarder.
Command: rpm -ivh sf.rpm
9. After Splunk is installed setup the forwarding server to the Splunk docker image on the Kali VM (172.16.216.130) that has the ports NATed.
10. Enable logging for queries in the MariaDB server that is running.
11. Then restart the service in Fedora for the mariadb server.
Command: systemctl restart mariadb.service
12. Now add the following files so that the Splunk Universal Forwarder can send them to the Splunk server running on the Kali VM.
/var/log/mariadb/error.log
/var/log/mariadb/query.log
/var/log/httpd/access_log
13. Before we move on, let's work with the iptables firewall that is running to generate logs of the activity. On this VM in the /root home directory is a script called "shieldsup.sh". We are going to copy and then modify that script to keep it simple.
Command: cp shieldsup.sh v2.sh
14. Modify the v2.sh file with adding logging into the script that will configure the iptables firewall. Below is how I modified it. The firewall could be simplified both by consolidating the logging policies and using bash foor loops.
15. The logs for the firewall will show inside of the file /var/log/messages. If you were to capture a few of them, below is a screenshot of what you would see.
16. Setup the Splunk Universal Forwarder to also read and send these logs to the Splunk server: /var/log/messages. Below is a scrennshot of the monitors I have enabled for the Seattle 0.0.3 VM.
17. Run a nmap scan on the Seattle VM to verify you are receiving logs. Also verify the script you wrote for the firewall logging is executed.
18. Verfiy in Splunk that you are receiving the iptables, httpd and mysql logs.
19. Now going to the walkthrough, let's start by scanning with netcat.
20. Use the Splunk Search like you would conduct a google search. Run the following search:
Search: index=main DPT=76
Search the main index of Splunk and then search for the string DPT=76 amongst the logs. DPT is an abbreviation of destination port. You should see the results of the search similar to what is below. In step 19 we scanned destination port 76.
21. You can also do conditional statements in your searches. For example if I wanted to see the logs that were generated of scans going to the destination ports of 76 and 77.
Search: index=main (DPT=76 OR DPT=77)
22. Now we are going to request the home page of the web site using netcat.
Command: nc 172.16.216.131 80
String: GET / HTTP/1.0
23. Looking in Splunk we see the following logs. After we search specifically for the log source of /var/log/httpd/access_log
Search: index=main source="/var/log/httpd/access_log"
Looking closer at the log normally where the user-agent is you see a "-". If you have a web application firewall or another method to filter by a <blank> user-agent you could block this scan. (Apache Web Server has filtering capabilities that could be utilized also.)
24. Now we are going to use OWASP dirbuster and hit the home page. Observe that each hit records a log entry. Also in the user-agent you can see, we are utilizing OWASP Dirbuster.
Challenge: Identify how to change the user-agent in dirbuster.
25. Let's configure iptables to observe the new connections coming into the firewall on port 80. If the connection is NEW and hits the firewall 5 times within 120 seconds then log and drop the connection.
Change the firewall script on the Seattle 0.0.3 VM and set it. Pay particular attention to how the LOG-ACCEPT-INPUT-NEW policies are created. I copied the previous firewall script to a new one, so if I had to I could revert to it.
Note: If you make changes to the firewall script, you need to run ./shieldsdown.sh and then ./v3.sh to reset the counters maintained by iptables that the IP Address should be blocked.
26. If the firewall is setup and functioning correctly you should see that dirbuster observed multiple timeouts while it was scanning, due to it being blocked. Dirbuster will now pause and wait.
27. If you search in Splunk you will see the behavior of the connection to change from LOG ACCEPT INPUT NEW to LOG DROP INPUT.
Search: index=main DPT=80
28. Let's specifically look at the Splunk logs for /var/log/httpd/access_log. I modified the user-agent to have a unique user-agent. Notice the search only returns a scan that resulted in 303 logs verses a potential of thousands of logs. Also in the search I specified the log source and a string to search for that would be unique in the logs.
Search: index=main source="/var/log/httpd/access_log" "DirBuster-1.0-RC1-iptables-test2"
Being able to search using an attackers IP Address, a unique user-agent or other information that you can find is unique about an attack is worth gold in finding an attacker and what they have done. You can also associate multiple IP Addresses to an attack that is occurring.
On the attackers side, you should try and stay hidden. Learn how to decrease the amount of generated traffic and learn how to fit in with existing traffic. I have heard this called "flying beneath the radar" or trying not to draw attention to yourself.
29. The next step in attacking the Seattle 0.0.3 VM was to fuzz the password of the user.
Challenge: Fuzz the password for the admin user and observe if the iptables rules that we put in-place above will mitigate this attack also.
30. The next item was to create stored XSS in a post to the blog after you log in as admin.
Challenge: Create a search in Splunk to identify XSS by searching for the keyword script or alert.
No comments:
Post a Comment