I got an email today from Gaurav Kumar regarding Zone Alarm’s “Identity Protection” product. It is designed to keep passwords safe from being sent to servers other than the correct one. So you store your password with them and if they detect the plaintext password in transit being sent to a server other than the one you want it to be sent to it alerts you. Here’s his email:
Zone Alarm “Online Fraud Prevention” is severely flawed. Since I knew that Yahoo Mail sends password as MD5 hash, i entered the same password as i had provided to Online Fraud Prevention option. And bingo! no alarms, nothing. Password just went through.
Now i entered the password in other web application and it was caught as expected. So the i thought that best way to bypass Online Fraud Prevention is to scramble the password using JS and send it….but wait, Online Fraud Prevention doesn’t work for HTTPS pages
So next time if someone wants to bypass Online Fraud Prevention, just use HTTPS or scramble the password.
Online Fraud Prevention is nothing more than marketing gimmick.
I have actually not played with this specific product although I have played with similar technology before. There is actually a much larger hole here, depending on the implementation. There are two possible methods for alerting the user. They can alert the user before the password is sent or they can alert the user without interrupting the session. Most people would argue that it is better to interrupt the user before the password is sent, but therein lies a security flaw.
Let’s say I know the username of the victim. If I am able to get him to a site that I control I can create a script to enumerate through passwords. It can simply refresh to itself with a new query string containing possible/common passwords. When the user hits the correct password the dialog pops up and alerts the user that they don’t want to sent their password to a remote site. The user stops, reads the thing and does one of two things. They allow their password to be sent (highly unlikely) or they click cancel and the script stops refreshing to itself.
Now if you look at the logs for that user (you can base user sessions on cookies or IP or whatever you want) you’ll see a huge list of possible but not-bad passwords streaming over your site. Then it will stop at some point or it will never succeed and will run out of passwords. In the case where it stops one of two things happened. Either the user surfed away from the page, or you found the correct password. It’s not the last password in the logs, it’s the next one - the password that was never sent.
This can be further sped up by sending many passwords at the same time (most likely three or more). It stands to reason that one of three passwords is a small enough number that the attacker could log in two times and fail before getting the right password without alerting the website in question. So if the user can create five requests a second and can send three passwords at a time you are talking about 900 passwords a minute. That’s easily enough to test the most common passwords.
In this way you can enumerate/brute force the most sensitive passwords a user has for any customer who uses this product who visits your web-page. It’s only useful if you know their user account too, so the practicality of this attack is rather low. The real risk would be in situations where it was highly targeted against a particular user. I have no idea if Zone Alarm’s product has this particular hole as I’ve never tried it. But yes, Gaurav is correct, looking for plaintext passwords can be easily circumvented by phishers if they chose to. I think the only reason they haven’t is because the market is so small for consumers who use these types of products it’s simply not worth the bother.