Problematic denial of service attacks

If you are a regular reader of any relatively large Swedish newspaper, the recent attack on Swedish media this weekend probably have not escaped your notice.

At approximately 20:00 Saturday evening on the 19th of March, a number of denial of service attacks began towards Swedish media websites.

Just nu är det problem att komma in på Aftonbladet.se. Vi arbetar på att lösa problemet.

— Aftonbladet (@Aftonbladet) March 19, 2016

Det är just nu problem med att komma in på Expressen.se. Vi jobbar på att lösa det så snabbt vi kan.

— Expressen (@Expressen) March 19, 2016

Shortly before the attacks started a threat was made via a twitter account, saying that attacks were going to be aimed towards Swedish media and government websites in the following days.

The reason for the attacks being “spreading false propaganda” is pretty vague but I’m not writing this article to speculate on that. A lot of people are speculating that the attacks originated from Russia since most (if not all) of the abusive traffic seemed to come from there. I don’t think we should focus too much on the Russian angle. It might as well be someone from inside Sweden who bought a botnet and want to test Its capacity. Think about it, if you wanted to buy a large amount of infected computers that are close to your targets in Sweden, where would you turn to first? I know where I would go at least.

Russia is a large country with a lot of Internet users (103,147,691) and there is a culture of selling botnets with infected Russian machines. This makes it ideal for someone looking to buy cheap bots. It’s also important to remember that there are no borders on the Internet. If you are an American wanting to attack a Russian server, you might as well use Russian bots simply because they are easy to acquire and are less hops away from the target machine. But it might of course also be a botnet from other countries, and not just Russia. It’s just that in this case it happened to come mostly from there.

Personally I find the low bandwidth types of denial of service very interesting, where you use a flaw in the application to either exhaust the server’s resources or to cause a crash via some sort of bug. I’m not too much of a fan of the regular distributed denial of service attacks where, if you scream loud enough, the infrastructure will give in to the pressure. But there are high traffic attacks that can be quite fascinating, like an NTP amplification attack. While I’m at it I would also like to mention the THC SSL DoS attack that was released in 2011 and is still usable today for stressing an SSL endpoint on a server.

I don’t know of the exact nature of the attack against the media websites but one could speculate that it could be a combination where a botnet would attack a resource on the target system that consumes a lot of resources, which could then effectively take down the server. One thought that crossed my mind was that some of these systems handle a large amount of traffic every day and was still taken down what seemed to be fairly simple.

Play with the thought of the perpetrators finding a page on these sites that either takes relatively lot of time to load because it has to make a large amount of queries to a database. Or let’s say they found a debug page that only says “hello world” and then does a bunch of background processing to test the back end server. It might not output any interesting data that an attacker can make use of (thus it being a low priority for the site maintainer to remove), but it can still be very useful in a denial of service attack.

Protecting against denial of service is not just as “one package” solution (even though there are packaged solutions that would surely help these sites a lot). The fact that these systems were taken down on a weekend, in the evening as well when. One would expect the traffic to be low, only shows how vulnerable these systems are. And it can also be seen as a message from the perpetrators saying that “we can do this whenever we want”, which then of course also messages other evil villains on the Internet that the Swedish media systems are easy targets.

Depending on the exact nature of the attack the solution to these problems will need some serious planning and dedication. Some of the solutions to denial of service issues are just a patch away, some not. If a large organisation with services that need to stay online wants to protect against these problems, they will also have to test against them. And I’m not only talking about the regular DDoS attack that overflows the infrastructure with too much data, but also the low bandwidth sneak attacks like Slowloris, slowpost, slowget, slowread and all other kinds of similar attacks (slow loading pages, crash flaws, SQL-injecting sleep calls, etc) that would need a security review to be discovered and properly taken care of. One solution that comes to mind is decentralization like Akamai has to offer, where a service can be spread out geographically so that a user accessing the service will get a node that is fewer hops away. This kind of setup also helps to mitigate denial of service attacks.

In this case it doesn’t really matter to me who actually carried out the attacks. It’s bad enough that the systems were all taken down, and the people responsible for those infrastructures need to learn from this and take action soon so that it won’t happen again. And this also makes you think about other critical infrastructure in the country, government websites, hospitals etc. Is it all just a catastrophe waiting to happen? Even if we were to find the one(s) responsible for these attacks the fact remains that a lot of sytems are vulnerable to some type of denial of service. The most future proof solution, generally, would be to build software architecture and infrastructure that solves these problems.

As of writing this the only attack so far was the one during Saturday night. The twitter account that made the initial threat has been removed (by whom is uncertain). Although it’s not confirmed that the attacks are actually linked to that specific account, the timing was just too good for it to be rejected as pure coincidence.

I would like to thank Emil Kvarnhammar, Marcus Murray, Stefan Ivarsson and Simon Strandberg for insightful input when writing this article.