Showing results for 
Search instead for 
Did you mean: 

The "Contact Us" attack against mail servers

"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




An appropriate POST request for the page would contain the form parameters and desired values as an application/x-www-form-urlencoded file (ignore line breaks):






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


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:




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.

Version history
Revision #:
1 of 1
Last update:
‎02-21-2013 08:13:AM
Updated by:
Labels (1)