Hack Like a Pro: An Introduction to Regular Expressions, Part 2

Welcome back, my hacker novitiates!

A short while ago, I introduced you to regular expressions. Regular expressions are a language that is particularly useful for finding complex text patterns in streams of data.

Although first developed for Perl, regular expressions are used throughout the IT industry (but more so in UNIX/Linux environments), and you can find them implemented in databases, Perl, Java, Ruby, Python, C++, .NET, and other programming languages.

For our purposes here, we want to focus on their implementation in Snort, the world's most widely used Intrusion Detection System (IDS). Snort is open source, but owned by Sourcefire, which was recently purchased by Cisco. As a result, Snort will likely become even more widespread than it is today, so I strongly recommend learning its ins and outs.

Regular Expressions in Snort

As hackers, the more we know about Snort and how it operates, the better we can evade it. As security professionals, the more we know about Snort, the better we can detect attempts at intruding into our system.

One variety of regular expressions is the Perl Compatible Regular Expressions (PCRE). Due to the strength PCRE, Snort uses it in many of its rules to detect the signature of intrusions. PCRE can be implemented to find specific signatures of known exploits.

In this tutorial, we will examine a Snort rule that will detect and alert us of a particular type of FTP DOS attack and, by doing so, hopefully, we will learn a bit of PCRE along the way.

Step 1: Getting Started

If you have not already done so, download and install Snort on your Kali system. If you are still using BackTrack, it is already installed.

In Kali, simply type the following command to download the Snort package from the Kali repository.

• apt-get install snort

Or, you can download it and compile it as I've shown in this tutorial.

Step 2: Examine an Exploit

Some versions of Google Chrome are prone to a remote denial-of-service vulnerability because it fails to handle user-supplied input properly. To find more information on this vulnerability/exploit, let's go to my favorite vulnerability database, SecurityFocus, and look at BugTraq ID 39183. It is described there as:

• Attackers can exploit this issue to crash the application, denying service to legitimate users. Google Chrome 4.1.249.1042 is vulnerable; other versions may also be affected.

In its description of the exploit, it says:

• To exploit this issue, an attacker must entice an unsuspecting user into visiting a malicious website or FTP server.

This is one of the thousands of exploits Snort is designed to identify that uses PCRE. Because the signature of this attack is relatively simple, we will use it here to learn more about PCRE and how it is implemented in Snort for exploit signature identification.

Step 3: PCRE Shorthands

Before we examine this rule and its PCRE, we need to delve a bit deeper into some PCRE notation. In my previous article on PCRE, I introduced you to some basic PCRE notation. To understand this rule, we need to look at what PCRE refers to as "shorthands." These are single letters preceded by a "\" that tell the system to look for something very specific. Here is short list of a few.

• \b - This indicates a word boundary
• \d - This is any digit shorthand
• \s - This is whitespace shorthand
• \w - This is shorthand for any alpha, numeric, or underscore character
• \x - This shorthand references a hexadecimal character when followed by a hex number
• \n - This shorthand indicates a new line

Step 4: Examine a Rule

Now, that we have expanded our knowledge a bit, let's look at that single rule in Snort and see whether we can decipher what the PCRE is looking for that denotes the signature of this Chrome FTP DOS attack.

Now that you have downloaded and installed Snort, change directories to:

• kali > cd /etc/snort/rules

Then the DOS rules file and open it in your favorite text editor.

• kali > leafpad dos.rules

Now that you have that file open, find "39183." This is the BugTraq identifier for a DOS attack that uses Google Chrome to DOS an FTP server. It dates back to 2010 and has been patched in the newer versions of Google Chrome. Here we will be using it as an example of how PCRE can be used to identify the signature of this attack.

The rule looks like this:

• alert tcp $EXTERNAL_NET 21 -> $HOME_NET any (msg:"DOS Google Chrome FTP handling out-of-bounds array index denial of service attempt"; flow:to_client,established; content:"|22 22|"; pcre:"/^2\d{2}^\n_*?\x22{2}/"; metadata:service ftp; reference:bugtraq,39183; classtype:attempted-dos; sid:16795; rev:3;)

For information on the what all this rule means, see my previous articles on Snort and its rules. Here we will be focusing exclusively on the PCRE signature embedded within this rule:

• pcre:"/^2\d{2}^\n_*?\x22{2}/"

Step 5: Dissect the PCRE

Now that we have extracted the PCRE signature identifying segment of this rule, let's dissect it piece by piece to see what it is looking for to identify this attack. The "pcre:" simply tells Snort that what follows should be interpreted as a Perl Compatible Regular Expression and the " character starts the PCRE.

Now let's take apart each piece of the PCRE clause starting with:

• / - This opens the PCRE clause
• ^2 - This indicates that digit 2 must start the string
• \d {2} - This indicates that next any digit must appear twice
• ^\n_ - Then, look for the start of a new line
• * - Then, any number of the items
• ? - Then, any single item of what is front of it
• \x22{2} - Matches hex character (22) appearing twice {2}
• / - This closes the PCRE clause

So, if I can summarize in plain English what this PCRE clause is looking for, it would be:

• "Look for a string that begins with the digit 2, followed by two digits, then the start of a new line and then any number of items, followed by a single item, then the two hexidecimal characters 22 and 22."

PCRE is one of the critical skills to be effective in many different areas of IT, but particularly IT security. Here we can see how PCRE was implemented to identify the signature of a DOS attack. In some cases, as a IT security engineer, you may be required to write your own rules, so the more you know, the more effective you will become. As a hacker, the more you know, the better you can evade these systems and hit your pot of gold.