DDos attacks: worse always?

The DDoS attacks are becoming more and more vehement, because the botnets behind them are getting bigger and new attacks are multiplying their clout. How long will that continue? And what can you do about it?

Let’s take a look at the individual factors: First there are the botnets, which are now used for most DDoS attacks. Then the various attacks that try to paralyze their goals. And last but not least, the possibilities for warding off these attacks – which nowadays usually only consist in commissioning a service provider with the defense. This could be either a Content Delivery Network or a specialized service to defend against DDoS attacks.

The attackers: Botnets

Initially, compromised desktop computers were used for DDoS attacks. At some point, however, the cybercriminals realized that the devices of the IoT were also suitable for this purpose. It finally got off the ground in the fall of 2016, when the Mirai botnet paralyzed, among other things, the website of IT security specialist journalist and journalist Brian Krebs, KrebsOnSecurity.com. You can read the backgrounds in the developer magazine 1.2017 , here we are only interested in the attacks themselves. Table 1 shows an overview of them.

September 20, 2016: The first attack on Brian Krebs

On the evening of September 20, www.krebsonsecurity.com was the first victim of a DDoS attack by the Mirai Botnet. The site was protected from such attacks by the Akamai and the attack went nowhere, so there were no big failures. But according to Akamai, the attack, at around 620 gigabits per second, was nearly twice the size of the largest attack ever seen (363 Gbps) and was one of the biggest attacks of its kind the Internet has ever seen would have. What’s also unusual is that so far, DDoS attacks have mostly used techniques to further increase the traffic of the attacker (for example, through DNS Reflection, which redirects replies to spoofed DNS requests to the attacked server). But this attack was based solely on a very large botnet. A large number of requests were simply sent to the web server, including SYN, GET, and POST floods.

September 20, 2016: DDoS attack on OVH

Also on 20 September there was a DDoS attack on the French web host OVH , which even outshines the attack on www.krebsonsecurity.com : It was up to a total of 1.1 terabits per second measured. OVH founder Octave Klaba has been reporting on Twitter on the attacks that started on September 18 and ran for several days, peaking on September 20 (Table 1 shows only a selection). The attacks seem to have originated from the same botnet used for the attacks on Brian Krebs’ website.

September 22, 2016: Further attacks force Akamai to give up

After the DDoS attacks on Brian Krebs’s website continued to grow , Akamai gave up on September 22, 2016, and ceased protection . What did not resent Brian Krebs Akamai, however, as they had successfully protected his server for four years for free and the defense of the current attacks was very expensive.

September 25, 2016: Google jumps in cancer

On September 25, 2016, the Brian Krebs website was back online, now protected by Google’s Project Shield . This is a free program from Google to protect journalists and news sites from DDoS attacks designed to suppress unwanted opinions.

September 28, 2016: The source code of the botnet is published

On September 28, 2016, the source code for the attacking IoT bot called “Mirai” was published by the user “Anna-Senpai” on Hack Forums . Meanwhile, the source code is hosted on GitHub so researchers can examine it.

October 21, 2016: DDoS attack on dyn

On October 21, 2016, there were multiple DDoS attacks on Dyn’s managed DNS infrastructure . As a result of the attacks, Dyn’s name servers were unreachable, causing DNS requests for domain-managed Dyn names to fail. As a result, the websites of some major vendors such as Amazon, GitHub, Netflix, PayPal, Reddit, Spotify, and Twitter were temporarily unavailable in parts of the US and Europe on October 21. Most of the attacks were from a Mirai botnet , but it is not known exactly which, because there were several botnets based on the published Mirai source code .

November 24, 2016: Mirai-Botnet for rent

On November 24, 2016, BleepingComputer reported that cybercriminals were offering to rent the services of a Mirai botnet from at least 400,000 compromised IoT devices via XMPP / Jabber. The devices should be infected with an improved Mirai version.

March 28, 2017: Mirai attacks at the application layer

So far, the DDoS attacks i. A. on the network layer. On March 28, 2017, a DDoS attack launched on an Imperva-protected US college . The special thing about this attack:

• It took place on the application layer. Details were unfortunately not published, it became known only that it was “more elaborate application layer attacks”.
• At 54 hours, it ran significantly longer than most previously observed DDoS attacks on the application layer (of which ninety percent lasted less than six hours).

Crime is worth it …

Since the release of the Mirai Source Code (see timeline), improved versions of Mirai have surfaced. For example, in August 2018. At that time, a version was released using the cross-compiler Aboriginal Linux to make new sacrifices in both architecture and operating systems . In addition, parts of the Mirai source code were used in other IoT bots , which can then perform attacks other than DDoS attacks. For example, you can use the compromised IoT devices to create cryptocurrencies or to redirect user-created currencies into your own wallet. The familiar problem: if anything succeeds, it will be imitated immediately. It does not matter if it’s good or bad.

… just wondering, for whom

In this case, however, the imitators should first have a look at what happened to the Mirai developers after the attacks and the publication of the source code. After discovering the identity of “Anna-Senpai” and two other Mirai developers, they landed outside a US district court in Alaska, where they pleaded guilty . They were each sentenced to five years probation and 2,500 hours of community service, as well as compensation of $ 127,000. In addition, they voluntarily renounced a large portion of the cryptocurrency seized during the investigation before the trial. Part of the ruling is also that they must continue their collaboration with the FBI and other law enforcement agencies that began during the investigation.

Overall, the three but still got away with it cheap. For “Anna-Senpai” was also accused of an attack on Ruttgers University in a district court in New Jersey, the verdict there came him significantly more expensive: He was sentenced to six months house arrest and also has 8.6 million US dollars Pay compensation. His partners may be happy that the whole thing ended for them in Alaska.

Even smartphones and Co. can DDoSen

As mentioned earlier, cybercriminals switched from desktop computers to IoT devices as the point of departure for their DDoS attacks. But even smartphones and other mobile devices are suitable for DDoS attacks, as the example of the WireX botnet shows. It was deployed in August 2017 for DDoS attacks on content delivery networks (CDNs) and content providers. The botnet consisted mostly of Android devices running malicious apps from Google’s Play Store. After Google was informed about these approximately 300 malicious apps, they were first deleted from the store and then from the affected devices. As you can see, DDoS attacks can now come from anywhere.

But let’s get from the execution of the attacks to the actual attacks. An appropriately large botnet can distress a normal web server by flooding it with normal HTTP requests, but usually other attacks are also started.

The attacks

Typical examples of DDoS attacks can be those deployed in Mirai. These as well as the Mirai source code were examined by a multiplicity of researchers, z. From F5 and Imperva .

Flooding attacks

Mirai can attack both at the network layers and at the application layer. The network layers are largely based on the long-standing flooding attacks, in which the destination is flooded with certain packets. This ultimately leads to its overload, so that regular requests can no longer be answered. And also on the application layer, as already mentioned, an HTTP flooding attack (GET / POST flooding) can be successful if the botnet is large enough. Some examples of flooding attacks:

• SYN Flooding : The destination is flooded with SYN packets for which the server reserves a TCP connection and to which it responds with a SYN / ACK packet. The attacker does not respond to the SYN / ACK packets, so TCP’s 3-way handshake is not completed. The resulting half-open TCP connections occupy resources at the destination, so that after a while no further connections can be accepted.
• UDP flooding : The destination is flooded with User Datagram Protocol (UDP) packets to random ports, so that the affected server always has to look up which application is listening on that port and, if none is found, with an ICMP destination -Unreachable package must respond.
• ICMP (Ping) Flooding : The destination is flooded with ICMP Echo Request (Ping) packets sent as fast as possible and without waiting for a response. This attack burdens both inbound and outbound bandwidth because the server wants to respond with ICMP Echo Reply packets. One possibility for ICMP flooding are the so-called Smurf attacks .
• STOMP flooding : Simple Text-Oriented Message Protocol (STOMP) is a simple, text-based protocol on the application layer that communicates with message brokers. During the DDoS attack, the attacker uses STOMP to open an authenticated TCP handshake with the target application and then flooding the target with data trash disguised as STOMP Tcl requests. This overloads the network connection and, if the destination parses the STOMP data, it may also overload the server.
• DNS Flooding and DNS Amplification Attacks : Generally, in an Amplification Attack, the attacker sends a large number of DNS requests with the counterfeit sender address of the target so that the answer is as large as possible. Mirai, however, uses the previously observed, but little-used DNS Water Torture technique.
• There are also the so far not yet observed flooding attacks with GRE packets on the network layer.

The DNA water torture

With the DNS Water Torture, the bot has the ISP’s recursive name server do the main work of attacking the authoritative name servers of the attack target. The bot sends a well-formed DNS request for the domain name of the destination for resolution to the name server of its ISP. Actually, the name resolution would be no problem, the domain exists yes. The bot places a randomly generated prefix in front of the domain name, so that the name server of the attack target stores the address for z. Qayxsw.name.example, cderfv.name.example, …. The search for these non-existent names takes a while, and the amount of queries causes the first authoritative name server to not respond fast enough. The requesting name servers therefore send their request to the next authoritative name server, which eventually becomes overloaded too and does not reply in time, so that the next authoritative name server comes into its own. Gradually, all authoritative name servers become overloaded and legitimate requests can no longer be answered: the domain is no longer reachable. This attack is also known as DNS Cache Busting because it can never be answered from the cache of recursive name servers, so any request must be routed to an authoritative name server, which will eventually become overloaded.

The GRE flooding

Generic Routing Encapsulation (GRE) is a tunneling protocol that can encapsulate a variety of network protocols into point-to-point virtual connections. The GRE packets are transmitted via UDP. The researchers at F5 suspect that GRE is being used because it can carry large payloads that add extra work to the target.

Mirai’s attack on the application layer

In addition to these attacks, another attack is implemented in Mirai, which was initially neither observed nor invoked at all by the code. This “cfnull” attack is at the application layer and is similar to a GET / POST flooding, but uses a large POST payload of 80 MB of randomly generated alphabetic strings. This would consume large amounts of resources in the attacked web server.

Cloudflare observed attacks in 2016 that matched the pattern implemented in Mirai . There it is assumed that the attack did not emanate from a Mirai botnet, as the published source code should not be able to do so. The similarity with the cfnull attack of Mirai is extremely noticeable, the size of the payload and their structure are consistent. Either there was then already a Mirai version in which the cfnull attack could be used, or the attack came from one of the predecessors of Mirai.

Namely, “Anna-Senpai” and his colleagues operated a DDoS protection for Minecraft servers and used Mirai and several previously developed DDoS bots, among others, to paralyze servers protected by the competition . The question then would be why the developers did not fully implement this attack in Mirai.

February 2018: New flooding attack over Memcached

End of February 2018, flooding attacks were observed that were not previously known in the wild: memcached amplification or memcrashed attacks . The concept was first reported in 2017 at the PowerOfCommunity (POC) conference .

Memcached is used to store arbitrary data in the memory of a system in order to accelerate the access to this data, because then they no longer have to be read by hard disks or SSDs. Memcached is z. For example, it is used to speed up the database backend of dynamic web pages. The memcrashed attack sends a request to a memcached server that responds to queries from any server. The server’s response is directed to the destination by a fake sender address, which is overloaded by incoming data. On February 28, GitHub was the victim of an attack that hit the GitHub servers at up to 1.35 terabits per second . Tools for conducting such attacks have recently been published on the Internet.

So far, so bad. Let’s move on to the question of how to protect against DDoS attacks.

Protect both sides of the coin!

It is important to look at the problem from two angles: First and foremost, the defense against DDoS attacks will be on their own systems. Just as important, but usually easier to achieve, is protecting your systems from engaging in DDoS attacks. And this is not limited to preventing the malware infection. If you For example, if you are running a DNS server, you should ensure that it can not be misused for DNS reflection or DNS amplification attacks. The Federal Office for Information Security (BSI) proposed some safeguards in July 2018 due to the increase in attacks : ISPs should prevent the manipulation of the sender address in UDP packets (IP spoofing) at their gateways, DNS caching resolvers should only request from and do not work as an “open resolver”, and all DNS servers should be monitored for conspicuous behavior in order to intervene in the event of an attack. Likewise, it is important to protect other vulnerable systems. So you have z. For example, make sure that the memcached server is not accessible from the Internet and / or only responds to requests that you want.

Protection against DDoS attacks

And with that we come to the protection against DDoS attacks. There are three options according to BSI :

• Operating a DDoS Mitigation Appliance
• Content Delivery Networks
• DDoS Mitigation as a Service

The idea that you could implement that yourself, you probably did not come. However, having its own solution would have the same disadvantages as operating a DDoS Mitigation Appliance: if the attack overburdens the line to its own data center, it will succeed, no matter how hard the DDoS solution is in the data center. It looks a bit better when the appliance is at the upstream provider. The current attacks could also force their connection to their knees.

In the past, when the botnets were much smaller, you might have said, “We’re not that important, we’re not that popular, etc., you do not attack us with the power of a big botnet, and we get along with the little ones “. Today, this is no longer true, because today there are basically only large botnets. And some of them are very easy to use. “Crime as a Service” providers provide corresponding services along with a comfortable web interface . So it is enough that someone displeases the commas in your current press release and he wants to show it to you. Already he has clicked on an attack, invested a few euros, and your server waves the white flag.

Content Delivery Networks distribute the data across multiple servers in multiple locations, most of which are distributed around the world. Its primary purpose is and was the rapid provision of data such as software including updates and multimedia data. But this distribution also protects against DDoS attacks: instead of a single server, several have to be paralyzed in several locations – and of course they are also protected against DDoS attacks.

DDoS Mitigation as a Service providers route incoming network traffic through their own servers, where unwanted requests etc. are filtered out. The BSI has defined criteria for the selection of such a service provider in order to facilitate the selection of operators of critical infrastructures. After reviewing the complete documentation of the services provided and several hours of specialist interviews, BSI recommended the following service providers as appropriate :

• Akamai
• Arbor Networks
• Deutsche Telekom
• Link11
• Myra Security
• Vodafone

The BSI also provides assistance in the prevention and defense of DDoS attacks . Here are of course particularly interested in the measures to ward off an ongoing attack. These include

• Hardening the server (to run the attacks, if possible, into the void),
• the filtering for source and destination addresses (where the source addresses are quickly the whole world in the filter, because the bots of the IoT botnets are widely distributed),
• Filtering according to specific criteria (eg HTTP headers typical for the attack) and
• the use of a DDoS mitigation appliance or the services of a DDoS mitigation as a service provider.

ISPs also have separate instructions on how to protect their networks and their customers’ systems.

DDoS protection in use

If you want to know how the defense of a DDoS attack in the Wild is done: Damian Menscher, Security Reliability Engineer at Google, has reported on the security conference Enigma 2017 on the defense against DDoS attacks, and as an example the defense against the attacks Website by Brian Krebs. There are reports on this with Brian Krebs: “How Google Took on Mirai, CancerOnSecurity” and Dan Goodin: “How Google fought back against a crippling IoT-powered botnet and won” .

Once Google decided to take the protection of www.krebsonsecurity.com , they faced organizational problems: One of the most important requirements for being included in Project Shield is that the person requesting protection proves that they are has control of the website in question. However, because www.krebsonsecurity.com was offline at the time, Brian Krebs could not meet this requirement. The problem was aggravated by the fact that the DNS records for www.krebsonsecurity.com were blocked to prevent domain hijacking. Corresponding attempts had been made again and again, but now the protection prevented Brian Krebs from proving that he has control of the entries. Therefore, his host had to help, which was complicated by the fact that the takeover should take place on a weekend. In the end, all the problems were solved, and Brian Krebs’ website was back online under the Google shield.

Attacks en masse

After that, it took another fourteen minutes for the DDoS attacks to continue. It started with a flood of 130 million SYN packets per second, combined with 60 million RESETs per second. That’s enough to paralyze many websites, but compared to Google’s capacity it was not worth mentioning.

About a minute later, the attack changed to a torrent of 250,000 HTTP queries per second. Since those came from around 145 000 different IP addresses it was clear that the Mirai botnet was the culprit. Since the load balancers were initially not configured properly, the servers got something to do, but the oversight was corrected quickly.

An hour after launch, the attacks had increased to a 40Gbps TCP flood, a 140Gbps DNS amplification attack, and a 4Mbps SYN-ACK flood. Four hours after launch, a major attack with more than 450,000 HTTP queries per second started from around 175,000 different IP addresses, but it did not pose any threat to www.krebsonsecurity.com or Google’s resources to protect it.

The strongest attacks were observed in the first two weeks, but after that was not the end. And the attackers tried again and again other attacks, z. For example, WordPress pingbacks, where a large number of servers sent pingbacks to www.krebsonsecurity.com to overload the server. Which failed because Google was able to detect and block the attacks by the user-agent header WordPress pingback . There were also cache busting attacks, all kinds of flooding attacks, and so on.

Big websites, little worries – small websites, big worries

When protecting www.krebsonsecurity.com , Google engineers had to find that protecting a small website was pretty hard. Big websites like Google’s services do not need a few thousand additional queries, but Brian Krebs’s server could handle only about twenty requests per second. An attack with up to 450,000 requests then becomes a problem – what should happen to it?

One way is to limit the malicious traffic, but for that it has to be recognized first. On the positive side, it is noticeable that benign queries can be answered from the cache, which relieves the original server. And even if the original server goes down, the regular requests can still be answered from the cache so that the outage is not visible. And that’s not only true for DDoS attacks, but also for normal problems such. Example, a power failure at the host of the original server or a hardware error in this server.

However, one problem is debugging this configuration from an original server that provides the data and Google’s shield servers that keep the data in the cache. After three months of hassle-free operation, users reported errors. Google’s engineers checked the Shield servers and found no mistake, and even Brian Krebs could not find a fault on the original server. The cause of the problem was configuration errors after the integration of additional virtual servers.

Conclusion

For botnets, there is a kind of “natural border”: at some point, they have infected all the IT systems they can infect, and then they can no longer grow. With normal IT systems, the number of potential victims will decrease if the exploited vulnerabilities are addressed. The devices of the IoT it looks different, for which there are hardly any updates – and even if they are installed rather rare. The IoT botnets should therefore be preserved for some time. And as the IoT continues to grow, as predicted, the IoT botnets will continue to grow. No nice views, right? The only ones who are looking forward to it are the providers of DDoS defenses.

Incidentally, the attacks on the website of Brian Krebs began after he reported on the links between DDoS attacks and DDoS defense providers. And the Mirai developers also offered a DDoS protection and laid down the server protected by the competition via DDoS attacks. Great, what?

Then let’s hope that the IoT devices will become more secure in the future and that the botnets will run out of living space.