Snort lab: Payload detection rules (PCRE)
Until now, when we used Snort to look for certain content within the payload, we've always looked for some specific values. What if we wanted to look for something that we don't have as much information about? If we only know the format of the data we are looking for, PCRE (Perl Compatible Regular Expressions) would allow us to write snort rules looking for this data. In this lab, we are going to look at two of the possible uses for PCRE as payload detection tool.
What should you learn next?
Exercise 1: Detecting PII
PII (Personally Identifiable Information) is something you don't want to be leaking out of your network. Luckily, most of the PII data has a specific format, which allows us to write rules for its monitoring. In this exercise, we will write a rule that looks for Social Security Numbers transmitted in plain text.
First, let's create some sensitive data to be transmitted. On your Windows Server 2012 VM, go to the C:Tempftp folder and open the testfile.txt document we created earlier. It should be blank. Add a fake Social Security Number to it, in the following format: XXX-XX-XXXX. Any numbers would do. Save and close the file.
Now go to your Ubuntu Server VM and bring up the local.rules file, or, if it's closed, open it with a text editor as root:
sudo gedit /etc/snort/rules/local.rules
Add the following rule as a new line:
alert tcp any any -> any any (msg:"SSN in Clear Text"; pcre:"/[0-9]{3,3}-[0-9]{2,2}-[0-9]{4,4}/"; sid:1000016; rev:1;)
Take a look at the "pcre" keyword. The argument syntax is quite simple:
- we are looking for everything in-between the two forward slashes;
- the [] options indicate ranges of numeric values to look for;
- the {n,m} quantifiers tell Snort to match ate least n, but not more than m times;
- The - parts escape the dashes so they will be included in the search.
Save the file and start Snort as root in IDS mode:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
Now, on your Kali Linux VM, open a terminal shell and connect to the FTP server on your Windows Server 2012 R2. Remember, the credentials are infosec/password$$$. When logged on, transfer our file containing PII:
ftp 192.168.x.x
get testfile.txt
Check your Snort output. You will see an alert generated by our rule.
Press Ctrl+C to stop Snort. Can you write a rule looking for credit card numbers?
Exercise 2: Detecting SQL injection
Patterns and specific formats are used not only for data that we are trying to protect. Many common attacks use specific commands and code sequences that allow us to write Snort rules aimed at their detection. SQL injection is one of such attacks: entering 1'or'1'='1 into a field is a common way to test whether a Web application is vulnerable. So, you may ask, why not just use this value as "content" argument? Because a) this is just one of the many variations of the command, and b) attackers may try to obfuscate the code by using encoding or other techniques. This is where PCRE will help us again. Bring up our local.rules file and add the following rule on a new line:
alert tcp any any -> $HOME_NET any (msg:"SQL Injection Attempt"; pcre:"/w*((%27)|('))((%6F)|o|(%4F))((%72)|r|(%52))/ix"; sid:1000017; rev:1;)
The PCRE syntax here is a bit more complicated than we used in the previous exercise. Let's see what it does:
- w* looks for zero or more "word" characters (alphanumeric or underscore);
- (%27)|' looks for the ubiquitous single-quote or its hex equivalent;
- (%6F)|o|(%4F))((%72)|r|(%52) looks the word 'or' with various combinations of its upper and lower case hex equivalents;
- () identifies groups of characters, and | is used for alternation;
- i ignores the case and x ignores whitespace.
Save the file and start Snort in IDS mode. On your Kali Linux VM, open a web browser (go to Applications->Internet->Iceweasel Web Browser). In the address bar, enter the address of our HTTP server hosted on the Windows Server 2012 R2 VM:
192.168.x.x:8081
You should see Web interface for the HttpFileServer 2.3b. Enter our SQL injection code into the Search field and click "go":
You should see alerts generated by our rule.
Now try modifying the injection code, such as adding -- at the end or changing or to uppercase. You will see new alerts generated. Thus, PCRE allows us to search for many variations of some content, rather than writing separate rules for each instance.
What should you learn next?