No rate limit on email triggering during "resend email" action results in email flooding or a spam attack or a financial loss to the company itself in ikus060/rdiffweb
Reported on
Sep 29th 2022
Description
When a user is setting up 2FA , a verification code will be sent to the registered email . There is no rate limit on email triggering that will result in an email flood / does attack or will also increase the expenses on your mail server as an attacker can send 1 million emails through this vulnerability which will add up to your cost as well
Proof of Concept
1) Go to https://rdiffweb-dev.ikus-soft.com/prefs/mfa
2) Click on enable 2FA . A verification link will be sent to your email
3) You will see a "Resend code to my email button" click on it and capture the request using the burpsuite proxy
4) Send this request to your burpsuite intuder and fire the same payload 1000 times
5) The registered email will receive 1000 email with verification codes
# Impact
An attacker can abuse this bug by :
1)Causing an impact to the user - Scenario: The user left his account open in a library , he can perform the above steps to cause an email spam
2) Adding an extra cost to the company mail server
@admin @maintainer can we assign a CVE for this issue as well?
@nehalr777 Seams their is a ratelimit on this endpoint. 30 request per minute then 429 is raise.
The threshold seams a bit high considering. I might reduce this default to a sane value. Do you have any recommendation ?
Sir,I was successfully able to trigger 100 emails without any problem
Yes reducing the the threshold to 10 maybe a great idea
The issue here is that an attacker is able to send 30 requests per minute(60 secs) ~1 request per 2 seconds . Burpsuite is an Amazing tool that allows you to configure the time between each request, an attacker can easily carry out an attack .
Now we could allow 10-15 email triggers every 10 mins(6000 secs) I believe that should be enough to get this issue fixed
Sorry , i mistyped the value 10 mins(600 seconds)
So an attacker will be able to trigger at max just 10-15 requests in the span of 600 seconds that limits this issue from occurring.
@admin could we please assign a CVE for this as requested by the @maintainer?