In a remarkably short period of time, “the cloud” has become the defining paradigm for the way that both individuals and businesses use the Internet. In fact, the cloud has become so ingrained in our way of thinking about the modern web that few of us give any real thought to the profound implications of any sustained hacker attack aimed at public cloud infrastructure. We implicitly trust companies like Amazon, Google and Microsoft – three of the largest public cloud infrastructure vendors – to put in place the strongest possible security protections. But a recent sustained DDoS attack on Amazon Web Services (AWS) shows just how vulnerable the cloud might really be.
Details of the DDoS attack on Amazon Web Services
The basic premise of any DDoS attack is to generate so much “junk” network traffic for a particular system that it causes the target – such as a corporate website or network – to crash or halt operations. This type of sustained attack on an IP address is routine by now, and is mainly successful when carried out against smaller companies or enterprises without the ability to defend against these DDoS attacks. However, it takes an overwhelming amount of traffic to take down a large system, and especially one as large as Amazon Web Services, which is why they are so rare. And yet that is exactly what appeared to happen in mid-October, when AWS Domain Name System (DNS) servers were hit by a sustained DDoS attack.
For a nearly eight-hour period, Amazon now says, it experienced “intermittent errors with resolution of some AWS DNS names.” If corporate clients headed over to the main AWS status page, they found a message proclaiming the existence of “intermittent DNS resolution errors.” And, in private communication with AWS clients, Amazon customer support agents were even more direct about what was happening, specifically telling clients that Amazon was under a DDoS attack, and advising them how to reconfigure their IT systems and web applications to deal with the disruption of the company’s Route 53 DNS system.
As a result of the DDoS attack, customers couldn’t access Amazon Web Services’ S3 services. Amazon’s DNS servers were essentially jammed, and even some of Amazon’s basic mitigations appeared to have little or no effect. In fact, some legitimate domain name queries were inadvertently dropped as part of the mitigations. Since many AWS services rely on external DNS queries, this was bad news for clients using AWS services such as Relational Database Service (RDS) or Elastic Load Balancing (ELB). In practical terms, it meant that many AWS customers along the East Coast of the United States couldn’t get their cloud-based services to work. And, predictably, they took to Twitter to complain. One AWS user, for example, simply tweeted out, “AWS DNS came under some kind of DDoS attack today.”
Amazon, for its part, was trying to do everything it could to bring everyone back online. In a message sent out to clients, for example, it simply noted, “Our DDoS mitigations are absorbing the vast majority of this traffic, but they are also flagging some legitimate customer queries at this time.” In other words, as a result of this DDoS attack, Amazon was unable to distinguish between legitimate and illegitimate traffic, at least to some degree.
Google Cloud Platform also hit with outages
And Amazon Web Services was not the only public cloud infrastructure vendor dealing with outages. At nearly the same time, Google Cloud Platform acknowledged that it suffered an outage of its own – but was quick to point out that it was “unrelated” to the AWS outage. As a result, multiple Google Cloud products – including Google Compute Engine and Google Cloud Storage – were unavailable to clients. Unlike the DDoS attack targeting Amazon, which mainly impacted clients on the U.S. East Coast, the attack targeting Google mainly impacted clients on the U.S. West Coast.
The myth of 100 percent uptime
As some Amazon Web Services customers were quick to point out on social media, the AWS Route 53 Service Level Agreement (SLA) is the only one for an AWS service that promises 100 percent uptime. This makes the disruption to the Amazon cloud platform all the more embarrassing. If the DDoS had persisted for more than the 8-hour period, Amazon might very well be facing a major PR nightmare, if not something far worse.
The recent cloud outages at both Amazon and Google raises the inevitable question: Is there really any way to guarantee 100 percent uptime to clients? White hat and black hat hackers are engaged in a perpetual battle, with both sides finding new ways to gain an upper hand. It now appears as if hackers have found a way to exploit vulnerabilities in Amazon Web Services’ own DDoS attack mitigation service, known as Shield Advanced.
Implications for major cloud vendors
In today’s cyber threat landscape, companies such as Google, Amazon and Microsoft make for highly visible targets. For example, Amazon has nearly half of the market share for public cloud infrastructure, and is one of the most trusted cloud vendors. In fact, so powerful is Amazon in the enterprise cloud market that it’s now quite common to see Amazon Web Services commercials on U.S. TV. In the same way that Silicon Valley giant Intel used to run commercials for “Intel Inside,” Amazon is now running TV commercials letting everyone know how many of the world’s most popular services, websites and platforms now run on AWS.
Many AWS services that rely on external DNS queries could not work when AWS DNS servers were under DDoS attack. #cyberattacks #respectdata
Click to Tweet
So what happens when hackers are able to take down all of these services, websites and platforms simply by launching a mega-DDoS attack against a company like Amazon? As might be expected, Amazon says it is actively working on additional mitigations, as well as tracking down the source of the attack. It is now imperative for Amazon to figure out how a massive DDoS attack had the potential to drag down half of the web, and what it can do to boost its own cyber defenses to prevent a similar type of attack from ever occurring again.