Menu

Subscribe

How the Huffington Post got "Hacked"

While I was scrolling through my Twitter feed today I spotted a tweet by Matthew Inman which caught my eye. For those of you who aren't familiar with Matthew Inman, he's a cartoonist based out of Seattle who's well known for his comic strip "The Oatmeal". The reason his tweet caught my eye was because he mentioned that the Huffington Post, a UK newspaper, had published his comic without his consent.

A few moments later, a clearly frustrated Matthew Inman took matters into his own hands and decided to take advantage of a crucial mistake the Huffington Post made when publishing his comic - hotlinking. Instead of copying the content to their own servers and referencing it from there, they simply sourced the content from Inman's servers. This would turn into a hilarious yet educational blunder that the Huffington Post clearly hadn't expected. First, he changed the top most images to screenshots of his Amazon AWS bill, as seen below.

If that weren't enough, moments later he got a little more creative and changed the last image of his comic strip to a picture of a bare butt and a phallus - captioned "lol I drew a butt and a pee pee!".

Once the Huffington Post caught up with what happened, they took down the content, issued an apology, and properly attributed Inman's original comic.

While Inman's story was more about intellectual property rights and attribution, this story also provides an effective and visual example of why organizations developing security sensitive web applications put themselves at risk when using third-party content delivery networks (or CDNs).

What is a CDN?

Back when the Internet was still young, innovative network engineers were trying to figure out ways of making the surfing experience more enjoyable - specifically faster. They came up with this seemingly brilliant idea at the time that involved bringing the content geographically closer to users by caching it on servers that were close to the user (i.e. ISP servers). Some of the well known players in this space include Akamai, Amazon CloudFront, and CloudFlare, to name a few. These services were largely transparent and the primary clientele were large ISPs and online streaming media companies like YouTube and friends.

However, at one point, when jQuery became the next best thing since sliced bread, the concept of content delivery extended to other things like hosting third-party web fonts, style sheets, and JavaScript libraries for the world to use. The advantage of using these services was that web application developers would no longer have to worry about hosting common JavaScript libraries such as jQuery on their own servers. Instead, they could take advantage of the CDN's speedy network facilities to serve up these libraries to users in a snap - and this is where it all goes downhill.

Web application developers in various industries, including healthcare, government, and financial services, were starting to take advantage of these CDNs for their own web applications. In our experience as penetration testers, we've seen this practice widely adopted in all sorts of online portals carrying really sensitive information. This practice is worrying, not because Matthew Inman may include a picture of a phallus in your web page, but because of the nature of the content web developers are relying on - JavaScript and cascading style sheets (CSS).

The Consequences

Unlike web imagery, JavaScript and CSS content can be used to explicitly execute instructions in your browser. For example, we can use it to instruct the browser to send your username and password to a remote server, or collect all your health information and send it to an insurance company. This is why penetration testers get all excited when they find a cross-site scripting (XSS) bug in your web application. If successfully leveraged, XSS can provide an attacker a means of escalating their privileges or exfiltrating sensitive information to a malicious server.

In other words, using JavaScript and CSS libraries from CDNs is kind of like having this massive potential XSS bug - except it affects almost the entire web because everyone's using it. By putting your trust in a CDN you are implicitly accepting the risk that if they get hacked, you get hacked. Unlike public certificate authorities, CDNs do not have to comply to a strict and rigorous set of security standards - virtually anybody can throw up a CDN and host jQuery. Also, with the ever-growing NSA/five-eyes surveillance program in place, I would imagine that partnering with CDNs would be a fantastic way to ensure they have access to millions of private records on web servers around the world.

In addition to it being a good attack vector for malicious code injection, CDNs can also be a significant denial of service vector. If your content can no longer be served due to a CDN outage, then your website will probably not render correctly. With today's prevalent use of JavaScript to render dynamic and interactive pages to its users, this becomes a huge usability problem. In some cases, some web applications are completely unusable if you don't have JavaScript enabled.

Moral of the Story

Hopefully, many of the issues highlighted above should convince you to move away from public CDN hosting or migrate to private CDN services, instead, where you can actually control the content you source. The Huffington Post debacle was a great visual example of how things can go wrong for an organization if the third-party decides to compromise the integrity of the content you're sourcing. The moral of the story is, if you're using a public CDN for JavaScript or CSS then you're providing the same level of assurance to your customers as that provided by the CDN to you.

If your web application hosts sensitive data such as personal health information, financial information (i.e. credit cards), or intellectual property, then it is strongly recommended that you maintain and source private copies of third-party libraries on your private servers. Finally, we strongly recommend performing an independent security review of these libraries to help identify potential backdoors or malicious code.