SQL / Command Injection Lab: Part 2 - Detection
Security Onion provides a complete Network Security Monitoring platform. I want to see just how much of the previous activity was detected by SO.
First let's have a look at the firewall logs from the nmap scanning. The 'nmap -sn victimsvr1' command caused a few log entries from the firewall. Security Onion is not configured to collect the syslog data from my Vyatta community eddition router/firewall, but the Bro IDS software in SO will collect any syslog traffic it sees on the wire. Bro formats the data and stores it in regular text files which makes it ideal for searching using any text processing tool you are familiar with (Perl, Python, Awk etc).
From the sample shown I can see that the ping sweep initiated by the nmap host discovery scan. Having the firewall log data available for analysis in SO gives further insight when investigating IDS alerts and other security events.
The next nmap scan used the -A option to invoke the scripting engine.
The screenshot shows the Emerging Threats rule identifying the 'user agent' string that is sent with the web scripts allowing the use of nmap to be detected. However, a stealthy attacker might change the 'user agent' identifier in nmap scripts. It would be worth checking the firewall logs to identify possible recon against the web server.
I can see a lot of connections from a single host to the web server with many requests in a short time period as nmap tries different scripts. As the only port that is open through the firewall is port 80 for web traffic it can be difficult to discern this kind of recon when it's mixed in with regular port 80 traffic. Running the same command above through unique and word count and looking at the start and end times could give insight when compared with a 'normal' web client browsing the site.
That's 64 connections started by the attacker in 13 seconds. Check out how long nmap took to run in part 1 - Attacks.
In the next part of the attack I used SQL injection, the Emerging Threats rules in snort on my SO sensor also picked this up.
There is however, another source of data regarding the attack. The mysql log when enabled will record each select statement run by the database:
Each of the SQL injection attempts is recorded if this level of logging is enabled. This is a multi-line log though, which makes it difficult to handle and parse into OSSEC. That's not the only problem, the section below shows the relevant stanza from the /etc/my.cnf file for MySQL:
# Be aware that this log type is a performance killer.So this isn't an option for production environments. Although it's great for the test lab and particularly useful if you want to practice SQL injection as you can see exactly what statements get executed and the end results of each attempt. There is a great blog entry here which describes how you can use triggers with user defined functions in MySQL to create a similar log without the performance hit and read the subsequent data into OSSEC.
log = /var/log/mysql/mysql.log
Ah, that'll be none then. You can see the ping activity firing ET *nix ping informational rules but nothing else. I think it would be quite difficult to write such rules unless it's for a specific known vulnerable page. Unlike SQL injection that has a number of defined commands and syntax options some of which are fairly typical in SQL injection attacks, command injection is simply too varied. All is not lost however, there is an OSSEC rule that fired for command injection.
I created this rule by using the audit daemon to monitor execve process creation for the www-data user. The www-data user is the user that the Apache2 process runs under. Under normal operation this user does not create any additional processes, so by definition any command it runs would be suspicious. I started by installing the open source Snare agent for Linux, this provides a really easy to use interface to configure audit daemon rules. Crucially, it also provides a single line log output which the audit daemon doesn't (multi-line). Then I configured the OSSEC agent on the victimsvr1 to read the log file from the snare agent. Finally I added rules into the OSSEC server running on my SO virtual machine to trigger when www-data created a process other than 'ping'.
As I was using Ubuntu JeOS for my victim server it was necessary to install the Snare Agent for Linux from source code.
The installations steps I used are shown below:
After the install is complete you should be able to use a browser to configure Snare on port 6161.
Configure snare to write to a local file as shown. Then configure the audit rule for www-data.
The OSSEC server on my SO box needs to be configured to decode the log entries sent from victimsvr1. Add or edit the file /var/ossec/etc/local_decoder.xml as shown below.
The rules can then be added to the /var/ossec/rules/local_rules.xml file as shown below:
As DVWA allows the use of 'ping' we don't want an alert when a user only uses expected functionality, the level=0 in the last two rules prevent the alert from being shown in the sguil console and remove false positives. If you want to understand the rule syntax the OSSEC documentation on the web site ossec.net is really good. Even if the web app being monitored is well secured against command injection it could still be worth monitoring for it; after all a web app goes through many changes and releases and it could become vulnerable to command injection at some point in the future.
It should be noted that if it were normal practice for administrators of this server to 'su' to www-data for any reason then this rule would create a lot of false positives, but as that's not normally the case it should be fairly safe to deploy. It's always a good idea to do plenty of testing before use in production though.
Using the Linux or Windows for that matter, audit capability is frequently overlooked as a good source of data for protective monitoring.
Nice info Andy! Glad you sorted out the change token / XSS protection issue.
ReplyDeleteIt's always good to see Snare getting a guernsey when it comes to analysing the audit log data.