The Radware ERT Encounters Another Reflection Attack

The effectiveness of DNS Reflective attacks over the past two years has raised the popularity of other reflective attacks, such as CHARGEN and Network Time Protocol (NTP) attacks.  In the case of CHARGEN attacks, service is spoofed into sending data from one service on one computer to another service on another computer creating an infinite loop that results in a denial of service attack.  Similarly with NTP attacks, an attacker sends a specially crafted query that ultimately redirects large volumes of traffic.  The traffic is sent with a spoofed source address with the intention of having the NTP servers return responses to the spoofed address. 

These attacks consume increasing amounts of network bandwidth, can cause a loss of performance, or even a total shutdown of the affected network segments.  There are two common patterns in these reflection attacks:

1. The attacker does not send traffic directly to the victim, but uses a third party.

2. The attacks use an amplification effect, meaning the amount of traffic the attacker generates is much smaller then the traffic the victim receives.  DNS responses can be 5, 10 and even 100 times bigger than the original request, an NTP Monlist reply is 600 times bigger than the request and CHARGEN replies can be from 100 to 1000 times larger than the request.

The Radware Emergency Response Team (ERT) recently encountered an incident that may fall into the same pattern – a reflective amplification DoS attack.  The event began when a customer reported an alleged SMTP DoS attack. The customer claimed its SMTP server was overwhelmed by a connection far above normal rates. The initial investigation revealed no pattern indicating malicious traffic, but a deeper analysis showed that more than 50% of the SMTP transactions where bounced messages.

Bounced messages, also known as Non-Delivery Notifications (NDN), are sent when an email server accepts an email but later finds out that it is unable to deliver it for whatever reason (spam, recipient not exist).  In this case, the attacker spoofed the sender’s email and a bounce message was generated to the original sender (specified in the ‘From:’ command line).  Using spam attacks or worm propagation, the attacker managed to have a huge amount of bounce messages directed to the email addresses that were spoofed. This effect is known as “Email Backscatter.”

The question the ERT aimed to answer when analyzing this specific attack was whether this Email Backscatter was a side effect of spam or worm propagation, or whether it was a deliberate DoS attack.  An attacker can indeed send emails to various mail servers and spoof the senders’ address to those of its real target. This makes the attack reflective but unlike DNS, NTP and CHARGEN, this attack is carried over TCP rather than UDP.

An Email Backscatter effect, when carried out as a deliberate DDoS attack, can create an amplification effect.  It depends on the implementation of the mail server acting as the reflector.  Some mail servers will send bounce messages that include the entire original email, while others will further send it to each and every recipient that was accepted during the original sent.  This means that if the attacker was sending the email to 50 recipients, certain mail servers will generate 50 bounce messages.  This will produce a 50 time amplification effect. 

During the investigation the ERT also found that more than 25% of the bounce messages were coming from Amazon email servers and they have confirmed that indeed the IPs belonged to Amazon.  The rest of the bounce messages arrived from other familiar mail servers such as LinkedIn.  However, it was not possible to determine if this was a deliberate DoS attack or just a side effect of spam or worm propagation.

When an organization realizes it is under such an attack it should identify the event as an Email Backscatter as soon as possible.  How is that done?  Bounce messages exist in normal traffic, however, their extreme ratio and in most cases, the usage of non-existing users, will indicate an Email Backscatter. Once identified, there are several ways to mitigate such an attack, for example, rejecting or rate-limiting bounce email during the attack period.