Are you building features for phishers?

People expect companies/services to tell them when untoward things could be happening to their accounts:

• Their account has logged in on a new device
• Their password has been changed
• An export of their data was started

These examples are things you should probably be notified about. But, if you go overboard with these warnings, you might find phishers triggering them intentionally.

A bad security warning

Imagine receiving this warning email:

There was a failed login attempt from $Country on your $eShop account.

Eek. Well, you’re not in $Country, and you weren’t just logging into your account… Is someone trying to credential-stuff you?

As you’re trying to remember whether you actually used a unique password on this account, your phone rings. The caller introduces themselves as from the $eShop security team where they’ve just blocked a takeover of your account. To secure your account, they need to walk you through the reset process over the phone.

Hopefully, you’re suspicious—this is a common phishing lure—but everything seems to check out:

• The email is from the real company domain name, and it passes DMARC.
• The caller knows all the details of the email exactly.

So you oblige and go through an account reset process with them. They assure you they’ve successfully stopped the attack and your account is now secure. Phew!

But, later, you check your account and find a bunch of fraudulent purchases 😣

What happened here?

The caller was of course not from the $eShop security team. Instead, they were compromising your account using the details you gave them over the phone.

But, the failed login email—the key part of their believability—was completely genuine. How? Simple:

1. The phisher somehow learned your email, phone number, and that you were an $eShop customer. (Often not a difficult task given the number of data breaches available to correlate together.)
2. The phisher used a bogus password to try to log into your account, intentionally generating the failed login email. They can use a VPN so that a suitably worrying country gets reported as the source.
3. Then they called you and could be incredibly convincing because they knew the contents of the email you just received.

This perfectly sensible sounding security feature (warning that someone might be trying to log into your account) is easily abused by a phisher to attack your account.

And can you blame them? The ability to send a scary-sounding warning to any user sounds like a feature built for phishers.

As a phisher

I want to be able to send scary-sounding, legitimate-looking emails to my targets

So that they’re more likely to believe my pretense and give me their credentials

How to avoid building abusable security warnings

Why was this a bad security warning? Because it had all the properties that make it easy to abuse.

It was easy to trigger by attackers.
“You’ve logged in on a new device” isn’t very abusable—by that point, the attacker already has control over your account. But a failed login email is extremely abusable—attackers can trigger it without knowing anything more than your username or email address.

It contained predictable, and worse, controllable content.
The phisher was so believable because they could control (and hence know the value of) the country from which the failed login was attempted. Including more details, like the IP address of the failed login, would only make them more believable.

The timing was predictable.
Would the phisher have been so believable if they called before the warning email arrived or hours afterwards? Probably not. Either they’d seem like every other tech support scam (with no warning email to back them up), or you’d have already checked out your account yourself, finding it perfectly safe.

(note: just adding a delay isn’t sufficient. A fixed one hour delay on the warning requires slightly more planning from attackers but is otherwise just as abusable.)

Things to consider when adding security warnings

• Is the warning essential? A warning that doesn’t exist can’t be abused.
• What knowledge is required to trigger it? If all a phisher needs is an email to trigger the warning, they’ve got a huge pool of potential victims. Even simple knowledge-based challenges will make large scale abuse harder.
• What’s the minimum amount of information you need to include? The less detail in the warning, the less insider knowledge a phisher can appear to possess.
• Does the warning need to be immediate? Unless the user needs to respond immediately, adding a random delay could make it much harder to abuse.