Account Lockout DDoS

Webmail with no CAPTCHA + authentication based on Active Directory + strict account lockout policy + publicly available organization email addresses = recipe for a fairly brutal DDoS attack on an organization.

The account lockout denial of service attack is not a new concept. There already exists several white papers describing the dangers of these attacks and possible solutions. But unfortunately the solutions are a bit shortsighted. They describe ways to prevent an "attacker" (read singular) often by blocking her IP address from attempting to log in as a user. They miss the fact that putting together a vicious DDoS attack, using innocent computers as slaves over the web (using multiple IP addresses of the innocent), is but a trivial matter.

All one needs to do to put together such an attack is place an iframe or several iframes on a popular webpage on any server that points to the target organization's webmail form processor script with a valid user account placed in the user field, with a bad password, and use javascript to submit the form. Every time an innocent person visits the "popular webpage" they are inadvertently submitting the form with a real organization user and bad password (purposely). Because the webpage has high traffic, this in effect will cause the user account to lock out based on the organization's lockout policy (sometimes only after 3 missed attempts within an hour). Now imagine placing 100 iframes on that page all pointing to unique users of that target organization. That would be 100 locked out accounts almost instantly, depending on how many people visit that webpage with the dangerous code placed within.

Additionally, after the IT department goes in and unlocks the account so the user can work at their desk or check their email, it happens all over again, because the code is still on the webpage working to lock the same user accounts.

More research should be conducted on how to mitigate this form of attack, especially because it's so easy to pull off. A couple ways to help prevent the problem now would be to prevent publishing organization email addresses that those within organizations would use to log in to their webmail accounts, create aliases that users could log into their account with when their regular account becomes locked out, and possibly the best solution would be to use a good CAPTCHA on their webmail login pages so that this form of automated attack could not easily be accomplished.