How can I mitigate attacks that rely on poisoned data as a developer?

Question

A few years ago, there was a high-profile attack on a Wired editor, where the hackers added a credit card to the target's amazon account, then used that self-added credit card to gain access to the target's account. So they effectively poisoned Amazon's database for their attack, then social engineered their way through.

How can a developer mitigate this specific attack vector, namely the attacker using data they added themselves to gain access?

---

I had this idea that, for the above example, you would allow the credit card to be added, but the user wouldn't be able to use it for recovery purposes or payment until he clicked a link in his mail to confirm that he wanted to add it, kind of like we already require email verification to create an account. That way, an attacker would have to compromise a second account as well. And of course the customer care rep wouldn't be able to do this himself.

Answer 1

The attack you describe happens because the user account is a container of credit cards, and Amazon equated "knowledge of a contained object" with "knowledge of the container". It's not surprising, because everyone assumes that a credit card must be kept secret, therefore knowledge of the credit card was evidence that the attacker had knowledge of a secret.

To prevent this, you could verify a user based on their knowledge of information provided at the time of registration. That means when an agent is bringing up the screen to help someone who "can't remember their password", they should have access only to that limited data, not to all of the account data. Otherwise, you could make a similar attack by observing someone making a purchase, then calling Amazon and saying "Of course it's me, I bought a widget yesterday for $100 from widgets.com, you should see that in my account history."

Another option would be to require validation of all contained data. If the caller says "my card # is 123, it's my account", the agent should be able to ask "how many other cards are on the account? Please tell me all of the account numbers."

Of course a better approach might be to require validation of the user before allowing them to add items to the container. Why should you be able to add a credit card to an account unless you can prove it's your account? What business benefit does that serve?

Answer 2

There isn't really much you can do about the social engineering attacks apart from training you employees better who directly interact with the customers ( customer care reps) in this case. If they learn on how to ask more questions in case of suspicion, or update the whole security training program for them. Again as a dev there isn't much you can do.

Answer 3

This may seem trivial but awareness is probably the right answer. Many banks have strict guidelines about what information are allowed to be asked to a customer and the best approach is to make the customer aware of this guidelines with warnings during his navigation or inside the contract.

My suggestion would be to include a box which states "we will never ask you to tell us your password" or "we will never ask you to click on a link" or "we will never contact you over email to ask you to log in". I would also suggest to have a channel through customers can report unusual behaviours (phishing, scam, anomalies, etc).