Tales of the Unexpected: How Hackers Trick Web Sites into Sharing Your Data

Featured article By Paul Wallace, Director of Product Marketing at Riverbed

Recent months have seen a run of high-profile security breaches: social media sites losing phone numbers, retail stores skimming credit cards, healthcare organizations leaking patient records, and even celebrity voicemails and photo streams being hacked.

But there is a change in the way these are being reported in the media: it used to be that the headlines were about the major brands losing our personal data, about celebrity stories being exposed. The victims were being highlighted, often implying that such organizations were not taking our privacy seriously, as if the victim was somehow complicit in the crime.

Now, we are seeing different headlines: the story is about the means, not about the end. Whole news programs are devoted to public awareness of “Heartbleed” and “ShellShock” and millions of passwords and identities being posted for sale on the black market.

Heartbleed, ShellShock and Injection Attacks

Many of the latest hacker techniques share a common method: that web sites can be tricked into exposing private data, often by “injecting” malicious commands or parameters where they are least expected. In the case of “Heartbleed” a hacker could request a chunk of data, which could reveal security credentials, simply by switching a parameter and requesting far more data than expected. Hit and miss, but it was easy for an attacker to try again and again until they caught something interesting.

But “ShellShock” highlighted a much more systematic and targeted tool for hackers to use. Instead of fishing for random data, an attacker can inject very specific commands to extract data. In fact, in the case of “ShellShock” it is possible to execute an arbitrary command on behalf of the attacker, who could potentially upload or extract any data from the system.

This trick of injecting unwanted commands into a web application is well-known in the security profession. Many applications use databases to check user names and passwords, or to look up records of past orders. And databases helpfully provide a way to execute queries efficiently, and an attacker can use the same trick to inject SQL commands into an application, and download the entire database of customer data including passwords and identities.

Databases are powerful things – they keep an index of key data like emails and user IDs: it is quite common for a personal email or login in to a social media profile to use the same login for an online store. So if a hacker can harvest both sets of data, they can connect the dots, and match the personal details in one application against the home address and phone number in the other – now the data is twice as valuable.

Unbelievable as it may seem, thousands of web applications are vulnerable to this kind of attack, and many organizations struggle to keep pace with the latest threats.

Have you left your front door unlocked?

Surely web applications can be designed to watch out for these tricks, and catch attempts to inject unwanted commands? Is it that difficult to write secure code? Why would developers leave the front door unlocked and wide open?

The hard truth is that modern applications are made up of a wide variety of components, drawn from different places, linked together in unique and complex ways. A typical Linux OS includes thousands of separate packages, each of which needs to be audited separately, while a Java or .NET application might draw from a similar number of components.

The “Heartbleed” bug was found in a piece of code called “OpenSSL” which was used in millions of applications on the Internet. Luckily, only certain versions were affected, but it was still a surprise to discover that OpenSSL, the very component that was used to protect applications, was itself hiding one of the biggest security holes.

Even worse, the “ShellShock” vulnerability stems from a single piece of code (known as “bash”) that has been used in millions of systems around the world. In the never-ending arms race between hackers and security professionals, all it took was a little ingenuity to break into a piece of code which was assumed to have been secure for almost 25 years.

Should we be surprised?

It doesn’t matter where your application code comes from, it could still hold surprises. “Heartbleed” and “ShellShock” were both found in open source software, freely available for anyone to download. Philosophically, open source software is open to scrutiny by developers all over the world – but this is no guarantee of security.

On the other hand, proprietary software is no less susceptible, and less open to scrutiny. In one case, a media organization found that their web site, based on an industry-leading content management system, was vulnerable to attack. Their vendor needed three months to schedule a fix – three months of anxiety and potential for loss of revenue.

But even if organizations do have a fix available, it can still take a long time to make applications secure in production. Complex applications need to be tested with new components, and organizations always try to avoid making changes at peak times – no-one wants to suffer downtime during peak periods, no-one wants to lose revenue. In a recent survey, White Hat Security found that the average time between identifying security problems, and implementing a solution in production was 193 days.

What steps can you take to protect your applications and data? Below are four best practices to help ensure your applications and data are secure:

1. Secure coding and development

Secure coding is an important skill, but is often not given a high priority in engineering qualifications. However, research organizations such as the Open Source Web Application Security Project (OWASP) publish guidance and training for engineers to help identify and solve weaknesses in applications, and act as a focus for reviewing the latest tools and techniques.

2. Stronger governance and accountability

Not only do engineers need to adopt secure coding techniques, they also need to work within a framework with strong governance and auditing. This is especially true where an application draws from a range of external components. Where is this piece of code come from? Can it be trusted? What other dependencies are there?

3. Continuous monitoring and real-time intelligence

Even if you believe your application is secure, it is important to measure and detect attempts to hack into the application, because it gives an indication of the likelihood of further targeting when new vulnerabilities are publicized. Almost all attacks leave some kind of trace – even “Heartbleed” left footprints in packet traces, and tools are available to sniff out and search for historical attacks.

4. Continuous protection of global applications

Remember that an attacker has all the time in the world, and only has to be successful once. Meanwhile, you need to keep watching 24/7, and tools such as Web Application Firewalls can provide round-the-clock protection against injection attacks, with detailed logging and alerting with real-time policy enforcement, even in cloud applications.