Friday, April 15, 2011

Active Defense for web server - Part 4

The following is based on my experiences and (limited) knowledge. I am not an expert in anything, nor will I likely ever be one. My hope is that this might help someone, somewhere, sometime. If nothing else, it might be a good start for discussion.

Preamble
This series is for meant for educational use only, and is intended to be used in a lab environment. These have not been tested in the real world and may cause more problems then they help. It will by no means be an in depth discussion.

Background
Today, a very quick introduction to logparser and how we can use it to actively defend against offensive attacks.

Process
Logparser is a very versatile tool from Microsoft. It can chew it's way through all sorts of data, from text files to event logs, very quickly.

The very wise Professor Windows explains some of the background and usage at http://technet.microsoft.com/en-us/library/bb878032.aspx.

For this series, we are going to strictly focus on the reading of the IIS logs we setup in part 2.

The general concepts for this series came about from reading http://www.symantec.com/connect/articles/forensic-log-parsing-microsofts-logparser, and some of the topics covering blue team tactics on pauldotcom.com.

Once you have downloaded and installed the latest version of logparser from Microsoft onto your webserver, do a basic Nikto scan of your test website to generate some entries in the logs.

If your using Bactrack simply open a shell and type
   /pentest/scanners/nikto/nikto.pl -host http://yourip/

Once that is done, let's use loparser to check the logs on the webserver using the following command
C:\Program Files\Log Parser 2.2>logparser -o:xml "SELECT c-ip AS ClientIP, cs(user-agent) AS ClientUserAgent, cs-uri-stem as URIStem, cs-uri-query as URIQuery,COUNT(*) AS [Requests] INTO attacker.xml FROM C:\WINDOWS\system32\LogFiles\wherever your logs are WHERE cs-uri-stem LIKE '%cmd.exe%' OR cs-uri-stem LIKE '%...%' OR cs-uri-stem LIKE '%\%' OR cs-uri-query LIKE '%\%3c%' OR cs-uri-query LIKE '%\%3e%' OR cs-uri-query LIKE '%\"%' OR cs-uri-query LIKE '%\'%' OR cs-uri-query LIKE '%#%' OR cs-uri-query LIKE '%\%' GROUP BY ClientIp, ClientUserAgent, URIStem, URIQuery ORDER BY Requests DESC"
 
 
 Explanation
  -o specifies the output type
  SELECT is saying which log entries we are interested in. Refer back to part 2 for more details on the logging.
  AS says we are going to treat each line as a whole
  WHERE is now going trough each of the fields and looking for matches. For example, cs-uri-stem LIKE '%cmd.exe%' is looking in the cs-uri-stem field in each log entry for   the word cmd.exe in the request.
NOTE: I highly encourage you to look into other types of attack data that can be gleaned from the logs and add searches for them in your logparser query. There are lot's of good examples in the Symantec/Security Focus article above, or in the hacker sample script included with the logparser install.
  GROUP BY is used to select what we will write in our output
  ORDER BY is used to sort the output. In this case it will be the same order as the logs.

Since we didn't specify a location for the output of the file the xml will be in the logparser directory. Open it up and look through the results.

You should see lots of entries like
 - <ROW>
  <ClientIP>192.168.100.129</ClientIP>
  <ClientUserAgent>Mozilla/4.75+(Nikto/2.1.3)+(Evasions:None)+(Test:003295)</ClientUserAgent>
  <URIStem>/cgi-bin/..%5c..%5c..%5cwinnt/system32/cmd.exe</URIStem>
  <URIQuery>/c+dir</URIQuery>
  <Requests>1</Requests>
  </ROW>
- <ROW>
  <ClientIP>192.168.100.129</ClientIP>
  <ClientUserAgent>Mozilla/4.75+(Nikto/2.1.3)+(Evasions:None)+(Test:003296)</ClientUserAgent>
  <URIStem>/iisadmpwd/..%5c..%5cwinnt/system32/cmd.exe</URIStem>
  <URIQuery>/c+dir</URIQuery>
  <Requests>1</Requests>
  </ROW>

So that we know how to get some data out of the log files, what can we do with it?

Well, if we create a batch file
c:\scripts\parse.bat
C:\Program Files\Log Parser 2.2\logparserlogparser -i:iisw3c -o:csv -headers off "SELECT DISTINCT c-ip INTO c:\block\badguys.txt FROM %1 WHERE TO_LOWERCASE(cs-uri-stem) LIKE '%%cmd.exe' OR TO_LOWERCASE(cs-uri-stem) LIKE '%%.exe%%' OR TO_LOWERCASE(cs-uri-stem) = '%%select' OR cs-uri-stem LIKE '%%&%%' OR cs-uri-stem LIKE 'select' OR cs-uri-stem LIKE '%' OR cs-uri-query LIKE '%%\%%3c%%'"
Explanation
 -i the input is going to be iis logs, -o the output will be csv turn off headers, select only distinct ips.

And run it and provide a logfile as an argument
c:\scripts\parse.bat c:\windows\system32\logfiles\specificlogfile
A file will be created with the attackers IP in it.
Then if we run a script like this one
c:\scripts\simplewaf.bat
@echo
cd c:\block
for /f %%i in (badguys.txt) do netsh ipsec static add filter filterlist="Banned IPs" srcaddr=%%i dstaddr=yourip description="Banned IPs" protocol=any srcport=0 dstport=0"

Explanation
 We are doing a simple for loop that will iterate through each "line" in the file presented in argument. For each IP it finds, it is adding the IP to the list of IPs in the IPSec policy that was created in part 3.

So, assuming that the IP of your attacker is different then the one you were using for testing in the previous post, or if you removed it, the IP that you ran the nikto scan from should be added to the IPSec rule and the attacker can no longer connect from that IP.

We can do something similar on a Windows 2008 server
c:\scripts\simplewaf.bat
for /f %i in (c:\block\badguys.txt) do netsh advfirewall firewall add rule name="Bad IP %i" protocol=TCP dir=in localport=80 remoteip=%i action=block ENABLE
Explanation
 This one, I'm not very happy with. It is creating a new firewall rule for each IP instead of just adding IPs to an existing rule. If I find a better way to do this in the future,  I will edit this post.

Next Steps
By scheduling the parse.bat and the simplewaf.bat to run daily/hourly or even more frequently you could have a very simple web application firewall that blocks attacking IPs, but you can  probably see we could run into some major problems. We will save that for next time....