Throughout 2019, Radware’s Threat Research Center (TRC) and Emergency Response Team (ERT) have been monitoring and defending against an increasing number of TCP reflection attacks.

TCP reflection attacks, such as SYN-ACK reflection attacks, have been less popular among attackers until recently. The lack of popularity was mainly due to the wrong assumption that TCP reflection attacks cannot generate enough amplification compared to UDP-based reflections. In general, TCP attacks are low bandwidth and less likely to saturate an internet link. Instead, TCP attacks are leveraged to generate high packet rates (increased volumes of Packets Per Second – PPS) that require large amounts of resources from network devices to process the traffic and cause outages.

Over the last two years, there has been a steady growth in attackers leveraging TCP reflection attacks. In a TCP SYN-ACK reflection attack, an attacker sends a spoofed SYN packet, with the original source IP replaced by the victim’s IP address, to a wide range of random or pre-selected reflection IP addresses. The services at the reflection addresses reply with a SYN-ACK packet to the victim of the spoofed attack. While your typical three-way handshake might assume for a single SYN-ACK packet to be delivered to the victim, when the victim does not respond with the last ACK packet the reflection service will continue to retransmit the SYN-ACK packet, resulting in amplification.

The amount of amplification depends on the number of SYN-ACK retransmits by the reflection service, which is typically governed by a configurable parameter. The default setting for Linux systems (net.ipv4.tcp_synack_retries kernel variable) is five while the documentation advises against settings higher than 255. Independent research in the behavior of a multitude of systems and devices on the internet exposed more than 4.8 million devices vulnerable to an average amplification factor of 112x and thousands of hosts that could be abused for amplification up to a factor of almost 80,000x, respectively, reflect more than 5,000 packets within 60 seconds, causing a serious impact on a victim’s network.

While there are different motivations and objectives behind these attack campaigns, there is a noticeably higher rate of collateral damage among the reflectors compared to UDP amplification attack campaigns, as recently demonstrated during attacks in Turkey, Italy and South Korea. Not only do the targeted victims, who are often large and well protected corporations, have to deal with floods of TCP traffic, but randomly selected reflectors ranging from smaller businesses to homeowners, have to process the spoofed requests and potential legitimate replies from the target of the attack. Those that are not prepared for these kinds of spikes in traffic suffer from secondary outages, with SYN floods one of the perceived side-effects by the collateral victims.

Background

In the spring of 2019, several events occurred that would begin drawing researchers’ attention towards an increased risk surrounding IP spoofing (the manufacturing of an internet protocol packet with an altered source address and IP blacklisting). Spoofing packets isn’t illegal and there are legitimate uses, such as testing how devices handle unexpected network events. However, someone spoofing to pretend to be someone else is generally agreed to be patently illegal.

In March 2019, several researchers began noticing their servers used for internet scanning got suspended due to blacklisting. Scanning the internet and creating internet surveys is a legitimate action which researchers do often to better understand the impact of certain vulnerabilities or to map out the threat surface of a new attack vector. Of course, criminals survey the internet as well and their intentions are less pure. There is such a high demand to understand the composition of devices and services on the internet that companies such as Shodan, Censys, and ZoomEye can comfortably make a living selling access to their collected and indexed scan information. The core problem behind the suspensions is that they are uncontrolled, unverified and unstructured at best. Who determines what scans originated from legitimate researchers? Who gets blacklisted because of it? As a consequence of this uncontrolled blacklisting, in April of 2019, two researchers set up an experiment to prove that spoofed scans could result in the blacklisting of any internet IP, even if that internet access or server does not generate outbound traffic related to that scan. The net result of the experiment is that unsuspecting victims can have their IP address added to real-time blacklists, thereby causing false positives in organizations and individuals that rely on those internet blacklists for protecting against SPAM and malicious servers.

Later that month, the financial services industry experienced a unique attack that would evolve into a level of sophistication not previously seen in TCP reflection campaigns. Financial institutions experienced a wave of attacks that could be observed externally, independently of the targeted network. These institutions became the target of multi-vector campaigns that produced bursts of high bandwidth and throughput with both UDP and TCP protocols. These two events targeting the financial industry were unique due to the volumes of TCP traffic that mimicked spoofed datagrams.  

Following the events in April, attack activity slowed down. In general, 2019 has been a relatively calm year in terms of reported DDoS attacks. But in the autumn of 2019, things have escalated. Following the takedown of several DDoS-for-hire services and Bulletproof hosting providers, a renewed increase in DDoS activity has been witnessed. In October, sizable amounts TCP SYN requests from what appears to be legitimate sources have appeared and indicate an ongoing blacklist spoofing or reflection DDoS campaign.

The first major event in October received headline attention as attacks crippled the network of Eurobet, an online sports gambling website. It was originally suspected that Eurobet was facing a ransom denial-of-service (RDoS) campaign due to a post on Twitter that surfaced requesting $80,000 in Bitcoin to stop the attack.

It is now suspected that this was a criminal opportunist, mainly because the campaign has persisted for nearly 30 days and impacted several other betting networks without mention of extortion demands. RDoS attackers rarely have social presence and typically request a fraction of what @ItDdos was asking for.

The attack on Eurobet lasted for days and was so noticeable that many smaller businesses began to assume that they were a target of SYN flood attacks resulting in a debate about blocking traffic from impacted networks.

Later in October, amid a flurry of DDoS attacks targeting companies in nearly every vertical around the world, another large-scale multi-vector campaign appeared targeting the financial and telecommunication industry in Turkey exhibiting the same patterns seen in previous campaigns. This attack was noticed by the security community due to the reflective nature of one of the attack vectors. In a period of 24 hours, millions of TCP-SYN packets from nearly 7,000 distinct source IP addresses part of AS12903 (Garanti Bilisim Teknolojisi ve Ticaret TR.A.S.) were sensed globally and specifically targeting ports 22, 25, 53, 80 and 443.

Over the last 30 days, Radware has observed a number of criminal campaigns that have been abusing the TCP implementation by performing TCP reflection attacks against large corporations. The attacks not only impacted the targeted networks, but also disrupted reflection networks across the world, creating a fallout of suspected SYN-flood attacks by many businesses. Below is the list of the source autonomous system number (victims) of the most notable TCP reflection attack campaigns recorded in the last 30 days by Radware’s deception network:

• Oct 8th: AS36351            
• Oct 10th: AS1267          
• Oct 13th: AS200944       
• Oct 18th: AS59711         
• Oct 19th: AS35574         
• Oct 22nd: AS35574         
• Oct 23rd: AS4766          
• Oct 24th: AS9318          
• Oct 25th: AS262254      
• Oct 25th: AS16509         
• Oct 27th: AS12903        
• Oct 29th: AS16509        
• Oct 31st: AS197014       
• Oct 31st: AS35574               
• Nov 1st: AS44066         
• Nov 1st: AS5532          
• Nov 1st: AS59711        
• Nov 3rd: AS16509        

The TCP Three-Way Handshake

When a computer attempts to establish a TCP connection with another device, a three-step method is required to establish the connection, referred to as the TCP three-way handshake. To initiate the handshake, a client must send a SYN packet to the server it wants to form a connection with. The server must be listening on the requested port and have the ability to accept new invitations to connect. The server will reply to the client with a SYN-ACK packet, which upon reception, will acknowledge the server with an ACK packet. Until the connection is closed, both client and server can exchange information using the TCP connection.

SYN Flood Attack

A SYN flood is a DoS attack that relies on resource exhausting rather than consuming available bandwidth or causing excessive CPU usage through high packet rates. The attack abuses the way in which a TCP connection is established by the server. When a client sends a SYN packet to a port on which the server is accepting new connections, the server will acknowledge the request with a SYN-ACK packet while keeping track of the half-open connection. Upon receiving the ACK packet from the client, the server allocates the memory resources associated with the half-open connection. A malicious client performing a SYN flood does not send the expected ACK. The server waits for an acknowledgement while keeping the record in the half-open connection table as network congestion and packet drops might cause missing ACK responses. However, in an attack, the ACK packet never comes and enough connection requests from a malicious client within the timeout period of the half-open connection will cause the server to exceed available resources and prohibit legitimate clients from initiating new connections.

Spoofed SYN Flood Attack

In a spoofed SYN attack, the client will overwhelm by rapidly sending falsified SYN packets that spoof the source IP address, thereby causing the server to send the SYN-ACK to the wrong IP address. The device at the spoofed IP address never sent the original SYN packet, so it will not respond with an ACK packet. By consequence, the number of half-open connections quickly grows on the server and will eventually exhaust the resources allocated for keeping track of the connection, causing the server to refuse new connection requests. By conducting a spoofed SYN attack, the attacker gains the ability to hide their true source IP address while exhausting the network resources of the victim device. It also allows the attacker to evade simple security measures based on limiting the number of active connections per host by using different spoofed IP addresses for each SYN request.

SYN Cookies

The SYN cookie is a technique used by servers to resist resource exhaustion from SYN flood attacks. By encoding information in the initial TCP sequence number of the SYN-ACK packet, a server can reconstruct information typically held in the connection table by decoding the SEQ field in the ACK reply from the client. The TCP protocol allows endpoints to freely choose the first sequence number; subsequent sequence numbers should add one to the received sequence number. The use of SYN cookies are a tradeoff. SYN cookies do not break protocol specifications and should be compatible with existing TCP stack implementations. However, because of the limited size of the 32-bit SEQ number, the number of unique numbers that can be encoded is limited, as will the number of half-open sessions that can be tracked using SYN cookies. Because of the way SYN cookies are constructed, the server must reject all TCP options, such as window size, which could impact the performance of the service. Finally, SYN cookies place an increased load on the server as they are computationally expensive. Use of SYN cookies also increases the ability of attackers to use random SEQ numbers in ACK packets and use brute force to bypass the security policy of a devices blocking packets through SYN cookies.

Another problem arising from SYN cookies are when the connection-finalizing ACK packet sent by the client is lost. In this case, the client assumes that the connection was established successfully and waits for the server to send its initial data, or resend the SYN-ACK packet. However, since the server is not aware of the half-open session, it will not resend the SYN-ACK because it discarded the entry that would enable it to do so. Eventually, the client will abort the connection due to an application layer timeout, but this may take a relatively long time.

Reflection Attacks

Reflection attacks use legitimate TCP/UDP services from third parties to reflect attack traffic to a targeted victim, ultimately hiding the attackers’ origin IP address. In a reflection attack, the attackers will send forged packets to a reflector service with a spoofed source IP address set to the intended victim’s IP address, therefore indirectly overwhelming the victim with the response packets generated by the reflectors. The reflector service used in this attack can be any legitimate server and not obviously compromised, which makes this kind of attack particularly difficult to mitigate. When the attack is distributed by leveraging multiple reflectors, the attack vector is called a distributed reflective denial-of-service (DRDoS) attack. A reflection attack gains amplification when the reply by the server is larger than the original request sent by the attacker.

TCP vs UDP Reflection

Until recently, TCP reflection attacks have been rarely observed or reported on. Typically, attackers leverage the UDP protocol for reflection and amplification attacks, mainly because UDP is a connection-less protocol which does not validate source IP like TCP inherently does through its three-way handshake. There are over a dozen well-known application layer protocols identified as top reflectors for UDP-based attacks.

The Network Time Protocol (NTP), for example, is a simple networking protocol designed for time synchronization over the internet. In an NTP reflection attack, an attacker sends spoofed NTP packets containing the ‘monlist’ request to a list of known open NTP servers. ‘monlist’ is a command that request the server to provide the list of the last 600 hosts that connected to the NTP service. Consequently, the NTP server responds with a large (amplified) reply to the source IP address of the requester, which is spoofed as the victim’s IP address.

Bandwidth Amplification Factor (BAF) is a measurement that compares the total size of the packet sent to a reflector versus the size of all packets received from the reflector. UDP reflection attacks leveraging NTP servers can generate a BAF greater than 500x the size of the original request. Other application-layer protocols, such as Memcached, can generate BAF up to 50,000x. Due to the large BAF in specific application protocols relying on UDP and the wide availability of attack source code samples, attackers have not invested time to research TCP reflection attacks. This is mainly due to a wrongful assumption that TCP reflection attacks do not generate enough amplification or bandwidth to make it worth their investment in time and resources.

The idea that TCP reflection attacks would be less effective than UDP-based reflective attacks is starting to shift. The old-world notion was that TCP-based attacks are too extensive in comparison to the volume-based attack landscape of today. There is also the assumption that only the application layer can generate large replies to create effective amplification levels. That combined with the need for a handshake to get access to the application layer of a TCP-based service eliminates the possibility of a spoofed identity. Those are often the reasons why TCP-based attack vectors in the DDoS landscape are less appealing to attackers. Times are changing.  

TCP Amplification

Referring to Figure 5, a three-way handshake in a perfect world is straight forward: SYN/SYN-ACK/ACK. The internet is not as perfect as we would like it to be, also one of the drivers behind TCP is to optimize and ensure delivery of payload between hosts on the internet. Devices communicating across the internet will have to retransmit data to account for packet loss. A 2014 presentation and white paper discusses how attackers can abuse the TCP implementations in devices and services on the internet, identifying thousands of amplifiers that allow amplification factors of 50x and higher.

In a TCP reflection attack, because of the use of the three different packets commonly used by the three-way handshake, the size of the packet delivered to the victim does not vary by much and is almost identical to the size of the original packet sent by the attacker. In a perfect world, there is very limited to no amplification gained from TCP reflection attacks. However, packets are lost, out-of-state (OOS) packets are treated as hostile and untrusted rather than being acknowledged with RST packets to swiftly resolve connection failures and prohibit long timeout wait periods. Device and OS implementations of TCP/IP communication stacks and how they handle retransmissions vary, some might even be considered broken. As a result, devices will retransmit packets in variable amounts of attempts and variable rates depending on the device and services. If accomplished at high enough rate and the reflecting device chosen wisely, TCP reflection attacks can reach amplification factors up to almost 80,000x, respectively, reflect more than 5,000 packets per minute.

Obtaining good amplification through TCP reflection is not an easy task though. The level of sophistication required by the attackers is fairly high compared to most DDoS attacks leveraging UDP. To be most effective, the attackers need to identify reflectors that respond the best for their attack and avoid RST or ICMP host prohibited/unreachable control messages from the victim which will limit the number of retries attempted by the reflector. By scanning the victim’s range with a SYN-ACK scan, the attacker can map out which parts of the IP address and port space of the victim will not respond with RST or ICMP. These are the most optimal target subset of the IP space of the victim that should be used by the attacker to spoof his victim through TCP reflection. This technique ensures retransmission of SYN-ACK packets from the reflector, with zero mitigation from the victim, resulting in an amplification factor dependent on the port that was leveraged for the reflection attack. However, the added level of sophistication through SYN-ACK scans is not practical, which leads us to believe that TCP reflection is combined with a technique called “carpet bombing”. Carpet bombing is used by attackers to evade DDoS mitigation systems by not targeting a single IP but the full CIDR of the victim. Attacking the largest IP space of the victim will optimize the hit ratio and amplification by hitting IPs that do not respond with RST or ICMP. Below are typical TCP amplification factors by port from the extensive research performed by the authors of the paper ‘Hell of a Handshake’.

In the paper, ‘Hell of a Handshake’, the authors detail three amplification types that can be expected during a TCP reflection attack when an RST packet is not received. The first involves the retransmission of SYN-ACK packets in response to a SYN packet. The second is the retransmission of payload data via PSH, even though the three-way handshake has not been completed some services are known to respond to PSH requests. The third and final form of amplification comes from triggering the target to send many RST packets to refuse the connection. Behavior between devices and implementations differ; some are better behaved than others.

Reasons for Concern

Recent Tactics Techniques and Procedures’ (TTP) used in the TCP reflection attacks have demonstrated that most of the targeted networks did not respond properly to spoofed requests using RST packets. This would have disabled the TCP retransmit amplification. As a result, the TCP reflection attacks had a major impact on the targeted network and also the reflectors used around the world. The level of sophistication witnessed during these campaigns was notable. During one of the first TCP reflection attacks, Radware observed attackers targeting over 30 TCP ports for reflection purposes. Two days later, the campaign targeted another company in the same vertical with only eight carefully chosen TCP ports for reflection. These ports were, 22 SSH, 25 SMTP, 53 DNS, 80 HTTP, 139 NetBIOS, 443 HTTPS, 445 SMB and 3389 RDP.

Over the last few months, carpet bombing has been used in a number of notable attacks against South African ISPs. This is becoming a popular trend among attackers due to the impact that it has on a targeted network. Most attackers now launch multi-vector attacks. These are DDoS attacks that use multiple vectors of attack to target a specific device or service. These multi-vector attacks are often directed at select IP addresses. Attackers have been utilizing the carpet-bombing technique and directing attacks at all IP addresses in the CIDR of the victim to bypass DDoS mitigation and elicit unexpected results by increasing the attack surface. In the case of TCP reflection attacks, this technique can be leveraged to increase the hit rate onto the victim’s services and devices that do not respond with RST or ICMP unreachable/host prohibited messages. In the case of the South African ISP attacks, it was used to sidestep DDoS mitigation and target ISP customers.   

Due to the nature of a TCP reflection attack, those abused as a reflector also experience network congestion and service degradation. Over the last few weeks, many companies, unaware they were being leveraged as reflectors in a spoofed attack, found themselves questioning why they were being targeted and flooded by networks owned by the gambling industry.

As a result, some companies who were severally impacted by the spoofed traffic began suggesting and implementing the process of blacklisting these networks in mass. While blacklisting does have a place in the security arena, in this event, blacklisting would only help accomplish the objective of the attackers. This reflects directly on the lessons learned in April 2019: blacklisting based on SYN packets received from an unconfirmed source is a risky maneuver. Often times, legitimate users are blocked from services because a bad actor is temporally impersonating their IP address.

In a UDP reflection attack, the attacker will reflect requests from a list of predefined IP addresses with exposed application layer services that are utilized in known amplification attack vectors. For example, when an NTP reflection attack is launched, most users do not notice the attack traffic because they are not being leveraged as a reflector. Attackers only need a list of a few thousand vulnerable NTP servers to generate attack traffic over 100Gbps. In the more recent TCP reflection attacks, it appears that the attackers leveraged a large majority of the internet IPv4 address space as reflector. This means the recent attackers, illustrated in Figure 13, used a rapid rate of falsified SYN packets to a wide range of the IPv4 address space with a spoofed source originating from either bots or servers hosted on subnets and by providers that do not implement BCP 38 to prevent IP source address spoofing on their servers or networks. The spoofed source in these attacks were the entire network ranges of the intended targets which resulted in the targeted reflectors retransmitting SYN-ACK packets in a carpet bombing attack as long as RST packets were not received. In the case that the target properly responded to an out-of-state packet with an RST or an ICMP host prohibited or unreachable message, the reflector would then become a victim of a RST or ICMP flood.

Effective DDoS Protection Essentials

• Hybrid DDoS Protection – On-premise and cloud DDoS protection for real-time DDoS attack prevention that also addresses high volume attacks and protects from pipe saturation
• Behavioral-Based Detection – Quickly and accurately identify and block anomalies while allowing legitimate traffic through
• Real-Time Signature Creation – Promptly protect from unknown threats and zero-day attacks
• A Cyber-Security Emergency Response Plan – A dedicated emergency team of experts who have experience with Internet of Things security and handling IoT outbreaks

For further network and application protection measures, Radware urges companies to inspect and patch their network in order to defend against risks and threats.

Effective Web Application Security Essentials

• Full OWASP Top-10 coverage against defacements, injections, etc.
• Low false positive rate – using negative and positive security models for maximum accuracy
• Auto policy generation capabilities for the widest coverage with the lowest operational effort
• Bot protection and device fingerprinting capabilities to overcome dynamic IP attacks and achieving improved bot detection and blocking
• Securing APIs by filtering paths, understanding XML and JSON schemas for enforcement, and activity tracking mechanisms to trace bots and guard internal resources
• Flexible deployment options – on-premise, out-of-path, virtual or cloud-based

Learn More at DDoS Warriors

To know more about today’s attack vector landscape, understand the business impact of cyber-attacks or learn more about emerging attack types and tools visit DDoSWarriors.com. Created by Radware’s Emergency Response Team (ERT), it is the ultimate resource for everything security professionals need to know about DDoS attacks and cyber security.