Signatures no good at protecting databases, says Juniper
A cookie, a box, a stick and a string can trap attackers
One of the most common forms of attack is the SQL injection, and although the vector is ancient and well-understood, it's notoriously difficult to defend against.
Kevin Kennedy, senior director of product management for Juniper Networks' security business unit, is in Australia to demonstrate Juniper's latest shot at defeating SQL injection – not with block-by-signature, but by trapping attackers. Spotlight Secure was first launched globally in February, 2013.
The idea behind Spotlight Secure is that signatures in web-application firewalls are no longer effective against the patient attacker, and input validation only goes so far.
Kennedy said it's been proven that input validation must fail at some point. There will inevitably be a collision between a genuine input that should be passed, and a malicious input that should be blocked.
It's also inevitable that even with a Web application firewall standing between the SQL server and the Internet, a patient attacker will find a combination of inputs that doesn't trigger a signature alert on the firewall – but does give an attacker an SQL injection vector.
It's not perfect – nothing is – but the idea is to make attacks slower and more expensive, while at the same time, using super-cookies to fingerprint the attacker.
To take a simple example of an attack on SQL, an attacker might first try changing parameters in a URL with the aim of generating errors that tell them things about the database behind the Website. From that starting point, the attacker then starts passing increasingly sophisticated parameters to the SQL engine with the ultimate aim of retrieving user Ids and passwords.
Rather than trying to create a perfect validation list, Juniper is instead slotting fake parameters into the URL – for example, offering database parameters such as columns that don't exist.
If someone tries to access a “trap” parameter, the system starts treating the user as a likely attacker. Rather than simply blocking that user's IP (which isn't particularly useful long-term), there are a number of actions available to the system administrator.
One is to slow down system responses to that user – a very simple way to make the attack more expensive. Another is the super-cookie mentioned earlier. The principles of super-cookies will already be well-known to regular readers of El Reg, but in short, they're harder to detect than the “standard” (for want of a better word) cookie, and they collect information to more accurately profile the machine they're installed on.
With enough data captured – the browser, the installed fonts, timezone, screen resolution, pointer device, camera type and so on – the system can capture a fingerprint of the attacking machine that might not be unique, but is a pretty useful characterisation of the attacker. Rather than watching for something easily changed, like the IP address, the system is now looking for the fingerprint of the super-cookie, and acting accordingly.
The aim, Kennedy said, is to track attackers rather than merely blocking them. “We want to change the economics of the attack,” he said. “Slow them down, waste their time, plant the cookie so we can recognise them.”
In most circumstances, Kennedy said, the characteristics that the super-cookie uses to build its fingerprint change incrementally and slowly. It's far more common for someone to replace a keyboard or buy a new screen than to configure a whole new machine.
And at the same time, since the ordinary user of a site is never going to try to get the SQL server to display the contents of the fake field, the company also hopes to address the false positive problem that makes even owners of Web application firewalls under-use the technology.
Is it perfect? Of course not: an experienced attacker will know how to protect themselves against super-cookies. However, Kennedy said, this doesn't invalidate the trap, since the attack will still be identified and logged.
Another example: you can't plant a super-cookie on a Linux machine booted from a USB stick with no write privileges. However, Kennedy said, the failure of the cookie will flag the machine as a likely attacker.
The Register asked Kennedy if the fingerprints collected by super-cookies wouldn't be more useful if they could be shared between security vendors. The answer: yes – if the challenges involved could be overcome.
“The model of sharing fingerprints is not useful in isolation,” he said. “But we believe that sharing is very important – this industry does not share well together.”
As a start, he said, Juniper Networks has a partnership announced with RSA, but broader sharing is “hard, because it requires that you have an active proxy using the fingerprints.” That, he said, is more complex than scoring the reputation of IP addresses.
“What should be shared is granular, enforceable information. But what we need is for other vendors to say 'yes, this is something we could do.' We're open to having that conversation.” ®
Sponsored: Customer Identity and Access Management