Email Flooding 2.0 | Insecure Design
Email Flooding, Email Bombing, or Email Bombarding is an attack affecting email resources, caused mainly due to Lack of Rate Limit vulnerability. This attack’s purpose is to overwhelm the email server and/or client, with a large number of spam or junk emails causing disruption, inconvenience and potentially leading to Denial of Service.
It is a fairly easy and common vulnerability to discover and exploit, However, it might not be Directly Exploitable in some cases even if there is no robust Rate Limiting mechanism on the application or API.
For example: Consider a web application with a subscription functionality which sends email only if the email address entered is not already subscribed, with no server-side rate limit on number of emails that can be sent and no client-side captcha. The application has only one security mechanism, i.e., before sending the email to the provided email address, it first confirms if the email subscriber already exists or not. If not, it sends the ‘subscription successful’ email.
As can be understood from the above example, even the absence of a rate limit can prove to be unfruitful sometimes. BUT SUCH FUNCTIONALITIES WITH NO ROBUST RATE LIMIT AND ‘INSECURE DESIGN’ CAN STILL BE EXPLOITED. Explained below is How?
‘abc@xyz.com’, ‘abc+1@xyz.com’, and ‘abc+test@xyz.com’ all points to the same email inbox, which means if you send an email to any of these emails it will go to ‘abc@xyz.com’ email inbox. You can try it with your Gmail account, just add ‘+’ followed by any string, and you will receive the email in your actual Gmail inbox with that modified email in the ‘To’ address.
Vulnerability Description
Now, while testing on a private program, I was specifically testing on a signup functionality. Once you enter your required information such as dealer code(any number that does not exist already in the system), email, name, and country in the signup input fields and submit the request, the application sends a signup email to the mentioned email address.
After I sent this request in Intruder, manipulated the email (as explained above), and repeated the request 200 times I confirmed application has no security checks for such type of attack as I received a large number of emails in my inbox.
Risk Description
This vulnerability wasn’t only leading to Email Flooding, it also allowed a single user to have multiple accounts in the application with a single email ID. Also the application have 10 day free trial of every functionality, which can also be exploited using this vulnerability, as a user will signup using these alias email addresses, causing the huge revenue loss and unfair resource consumption by the malicious user.
Mitigation
Mitigation Strategies
To remediate this vulnerability, secure coding practices should be implemented, including:
- Restricting special characters in email addresses
- Implementing rate limits on the server
- Adding CAPTCHA to prevent automated abuse
🙏🏼
