Virtual Patching Part II: What Makes It So Darn Tricky?

In my last blog post I began a conversation about virtual patching. In this post, I’ll further the discussion by talking about why effective virtual patching at the network is so difficult.

The story really begins by considering context, or really, the lack thereof. If a vulnerability exists in an application (a web application, or a browser) there is a certain context associated with the application that is difficult to be aware of at a point outside of the application. The simplest example is a session. A web application may create a session when a user logs-in, destroying the session after a period of inactivity, or when a user logs-out (and when was the last time you logged-out instead of just closing the browser window?).

The browser sends cookies containing some sort of identifier that the web application uses to associate the browser request with a session – for example, showing you your bank account information instead of someone else’s. If someone in the middle figures-out how to grab those cookies, they can try to fool the web application into believing they are the end-user. However, the web application has its session context – and if the session is no longer valid at the web application, the cookies are useless.

It’s all about context

The problem is that something like a network intrusion detection system can’t access that session context unless it somehow tracks it on its own (creating its own context). From a performance perspective, that can be taxing,especially since network traffic is sensitive to latency. Robust web application firewalls often try to “learn” the application before enforcing rules, just by looking at “normal” network traffic.

That can be very complicated, and therefore prone to false positives, and also assumes that what it “learns” as normal isn’t actually bad behavior. Oh, and then the web application is updated… leading to another learning cycle.

Another web application example is SQL injection. SQL injection involves providing input, say – entries on a form that is submitted to the application, which trick the application into doing something that it shouldn’t. A classic example (and a very simple one) is if at login, a web application asks the database to:

SELECT * FROM “users” WHERE username=”johnd” and password=”p@ssword”;

Basically, if it returns something, there is an entry in the “users” table with that username and password. If when filling-in the form the data is tampered with, the application doesn’t normalize the input, and so on, the query may look like:
SELECT * FROM “users” WHERE username=”johnd” and password=”injection” or 1=1; -- “;

By putting ”injection” or 1=1; -- in the password field, the application is tricked into always returning true because one does equal one. Perhaps changing that behavior will take some time, so we’ll set-up a filter at the network to look for input that contains or 1=1; --. The attacker instead uses or 2=2; --, 3=3, 4=4… and so on. There are infinite variations, in other words. That makes filtering for SQL injection attacks at the network level difficult, and error-prone (false positives and false negatives).

On the other hand, going to where the web application is running, or even the database, can be much more effective because context is available. Should a login page be updating something in the database, or deleting something? Probably not – simple contextual awareness then eliminates swaths of SQL injection possibilities. 

Simple vulnerabilities, complex risks

On the client side, a straightforward example follows a dead-simple exploit vulnerability from a few years back. The vulnerability was in a JavaScript create.TextRange() bit of code (http://www.securityfocus.com/bid/17196/exploit). The details aren’t important, just know that a=r.createTextRange() is the important piece.

As with the simple SQL injection example, it’s tempting to declare it can be detected at the network by looking for that string heading toward a vulnerable IE browser. Well, without context, it’s difficult to know if it is a vulnerable IE browser, for starters. Second, because browsers are so helpful in their willingness to try to parse anything thrown at them, an attacker can split up that string, and ask the browser to combine the multiple strings to form a=r.createTextRange() when the code is executed at the browser. Again, there are nearly infinite ways to jumble it up, making the creation of a “specific enough, but not too specific” filter applied to network traffic impossible.

These very simple, but at one point real-world examples help explain why performing virtual patching at the network is so difficult. It all seems rather fatalistic, so in my next post, I’ll turn talk about the advantages of having context to brighten things up.

As a final note, if you are running a version of IE anywhere on your network that is vulnerable to the example I used, you’ve got far bigger problems to deal with than fiddling with virtual patching!

Stay tuned for more on this topic and our upcoming Paper about Active Virus Control (AVC), our approach to Host Intrusion Prevention (HIPS).