Zero Day: A moment of opportunity for hackers.
"No one knows this vulnerability but me!", they cackle.
They launch their attack scripts, sit back, and have a Red Bull.
One by one, systems are added to their botnet. Until..
Traceback (most recent call last):
File "<stdin>", line 1, in ?
SocketError: Secondary Payload Failed
"What? How?"
Juniper Intrusion Detection and Prevention (IDP) saves the day. Again.
There are several classes of vulnerabilities that just keep cropping up. SQL Injection attacks. Cross-Site Scripting (XSS) attacks. Remote File Inclusion (RFI) attacks. It happens with so much frequency now that it's hard to keep track of it all.
And all of these are preventable with some simple user input sanity checks.
Let's use SQL Injection as a demonstration. The various ways SQL Injection can occur are well beyond the scope of this article, but let's take an overly simplfied example.
You have a website that accepts user input via web forms. A normal user would type some values into a form on a webpage and click the Submit button. That data comes back to your web code in an HTTP request, usually a "GET" or "POST". Form fields are indentified within the request and are passed to your web page code for handling. This is where things can go sideways.
This is a real SQL Injection attack from a real customer. In order for the SQL Injection attack to succeed, the query must be well-formed. This can be difficult if the attack doesn't know the schema of the target database they are attacking and must make a "Blind" attack against the table.
This example shown above is a sub-class known as a 'Comparison' attack. It's especially effective at performing Blind attacks due to the way most queries are coded inside the web page.
The original query might have looked something like this:
"SELECT * FROM Database WHERE `id_menu` = " . $_GET['id_menu'] . ";"
Which normally would just return information on the menu entry itself. Instead, what gets sent to the database is:
SELECT * FROM Database WHERE `id_menu` = 1 UNION ALL SELECT NULL, NULL, NULL, NULL, NULL, NULL AND 7823=7823;
The first bit essentially performs a dump of the entire database (depending on how the foriegn keys are configured) and the last part ensures the query is successful by making the database validate the comparison that 7823 indeed equals 7823.
Since the last part returns true, the query is successful and doesn't throw an error. Meanwhile, the webpage is now also displaying massive amounts of information from the database.
The bug here is that the id_menu is expecting just a number, and instead it gets a whole lot more. Were I to write a signature to cover this issue, I could do something like:
context: http-url-variable-parsed
direction: client-to-server
pattern: "id_menu=.*[^\d].*"
This uses the "parsed" context to decode any potential encoding techniques and then checks to see if something other than a digit was sent. It's a clean, efficient signature that detects any attempts to exploit the specific vulnerability. To write this kind of signature, however, requires knowledge about the issue ahead of time, and is useful only for this single vulnerability.
Looking at the attack case, however, you can see there's a lot going on here - more specifically, a lot of SQL going on - "UNION ALL SELECT" and "NULL, NULL, NULL, NULL" etc aren't normal web form submissions. We can use this to our advantage.
We have a large stable of such signatures that look for non-typical combinations (from a normal web application perspective) that could be used for SQL command injection - SELECT, FROM, WHERE, VARCHAR, NULL, etc. Most of these, in and of themselves, are used all the time in normal web form submissions (indeed, the very article I'm writing here will contain them!). But over the years we've seen quite a few tricks used by hackers to slip past, and we've tailored our signatures to detect their shenanigans wherever possible.
There's always a risk of false positives (triggering on something that's not malicious) when looking for "generic" activity. Indeed, there are some very poorly-designed web applications that actually work by passing SQL instructions via HTTP URL parameters. For those kinds of web applications, it's much harder to ensure that SQL injection isn't occuring.
It's important to realize that these behavioral signatures are designed to protect your web application servers from attack, so therefore, these should be used on IDP-enabled Juniper products that are monitoring incoming traffic from the Internet at large, and not from your clients going out to the Internet. You may need to 'tune' those signatures that false-trigger on your web application's normal day-to-day functions, but by-and-large these signatures should work very well.
We also really enjoy it when an attacker tries to get very aggressive and tries to thwart detection with heavy-handed evasion techniques like the following example:
These convoluted submissions shine like a beacon to our IDP that someone's doing something nafarious and should be stopped.
The benefit to these signatures, of course, is their broad applicability. We don't have to know if a particular web application is vulnerable - we don't even have to know what that vulnerability is - we can still detect the distinct patterns used by hackers to obtain data from web servers through SQL injection and block it, Zero Day.
This is a prime example of how IDP can add value, not just to the threats you know about, but also provide protection to new and unknown threats - it's an essential tool in your Defense-In-Depth security toolbox. Despite its power, don't be afraid to use it!