vADC Docs

The "Contact Us" attack against mail servers

by on ‎02-21-2013 08:13 AM - edited on ‎06-01-2015 09:52 AM by PaulWallace (3,365 Views)

"The 'contact us' feature on many websites is often insecure, and makes it easy to launch denial of service (DoS) attacks on corporate mail servers," according to UK-based security consultancy SecureTest, as reported in The Register.

 

This article describes how such an attack might be launched, and how it can be easily mitigated against by using a traffic manager like Stingray.

 

Mounting an Attack

 

Many websites contain a "Contact Us" web-based form that generates an internal email. An attacker can use a benchmarking program like ApacheBench to easily submit a large number of requests to the form, bombarding the target organization's mail servers with large volumes of traffic.

 

Step 1. Identify the target web form and deduce the POST request

 

email_form.png

 

An appropriate POST request for the http://www.site.com/cgi-bin/mail.aspx page would contain the form parameters and desired values as an application/x-www-form-urlencoded file (ignore line breaks):

 

email_subject=Site+Feedback&mailto=target%40noname.org&

email_name=John+Doe&email_from=target%40noname.org&email_country=US&

email_comments=Ha%2C+Ha%2C+Ha%21%0D%0ADon%27t+try+this+at+home

 

Step 2. Mount the attack

 

The following example uses ApacheBench to submit the POST request data in postfile.txt. ApacheBench creates 10 users who send 10,000 requests to the target system.

 

# ab -p postfile.txt -c 10 -n 10000 -T application/x-www-form-urlencoded http://www.site.com/cgi-bin/mail.aspx

 

The attack is worsened because the web server typically resides inside the trusted DMZ and is not subject to the filtering that untrusted external clients must face. Additionally, this direct attack bypasses any security or validation that is built into the web form.

 

Ken Munro of SecureTest described the results of the firm's penetration testing work with clients. "By explicit agreement we conduct a 'contact us' DoS, and in every case we've tried so far, the client's mail server stops responding during the test window."

 

Defending against the Attack

 

There is a variety of ways to defend against this form of attack, but one of the easiest ways would be to rate-limit requests to the web-based form.

 

In Stingray, you can create a 'Rate Shaping Class'; we'll create one named 'mail limit' that restricts traffic to 2 requests per minute:

 

rate_shape.png

 

Using TrafficScript, we rate-limit traffic to the mail.aspx page to 2 requests per minute in total:

 

if( http.getPath() == "/cgi-bin/mail.aspx" ) {  
   rate.use( "mail limit" );  
} 

 

In this case, one attacker could dominate the form and prevent other legitimate users from using it. So, we could instead limit each individual user (identified by source IP address) to 2 requests per minute:

 

if( http.getPath() == "/cgi-bin/mail.aspx" ) {  
   rate.use( "mail limit", request.getRemoteIP() );  
} 

 

In the case of a distributed denial of service attack, we can rate limit on other criteria. For example, we could extract the 'name' field from the submitted data and rate-shape on that basis:

 

if( http.getPath() == "/cgi-bin/mail.aspx" ) {  
   $name = http.getFormParam( "name" );  
   rate.use( "mail limit", $name );  
} 

 

Stingray gives you a very quick, simple and non-disruptive method to limit accesses to a vulnerable or resource-heavy web-based form like this. This solution illustrates one of the many ways that Stingray's traffic inspection and control can be used to help secure your public facing services.

Contributors