Cenzic 232 Patent
Paid Advertising
web application security lab

Security Issues in Zone Alarm Online Anti-Fraud Prevention

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.

12 Responses to “Security Issues in Zone Alarm Online Anti-Fraud Prevention”

  1. maluc Says:

    clever.. and i’m sure it will never even stop a rot-13. seems like snake oil for marketing purposes. and if it only stops the scripts in one frame .. you could probably significantly reduce the time (or increase the passwords tested) with a two tiered approach.

    With 5 requests a record .. you could test 100 passwords per request. Which works out to 30,000 per minute. Once the script gets stopped by zone labs interruption, the second iframe can take those 100 that were stopped and run a second brute on that shortlist.

  2. Legionnaire Says:

    Indeed this is very disturbing. A piece of software, claiming to provide security, in fact misdirects the users and leaves them with a false sense of security which is much worse than a sense of insecurity.

    Some quick ideas on how these programs can demonstrate a more vague attitude:

    - A “safe” list of servers is maintained and if the plaintext submission is to a server outside that list, then an alert is raised. That list includes all the servers the security software is handling. So when an error pops up you don’t really know that the transmitted plaintext is the one for the specified server. You simply know that you have hit a plaintext for one of the servers in the list and that the current session is with a server outside that list.

    - To scramble a predictive behavior (used by attackers to find your password by brute forcing - just like RS described), when an alert is raised, the security software sends garbage instead of the password but still sends something. So the attacker does not notice a change in his brute force efforts.
    e.g. if by brute force you hit the (correct) password “demo3D!” but the server verification fails, the software will submit “klopp3d7″ (just random alphanumerical string).

    - In general, a security software must NEVER give out information about a failed authentication. So it must never say “the information A is not correct”. It must say “there has been an error. goodbye”.

  3. RSnake Says:

    e.g. if by brute force you hit the (correct) password “demo3D!” but the server verification fails, the software will submit “klopp3d7″ (just random alphanumerical string).

    That one probably won’t help you in the case of brute force. If I know that the user’s security application did that I’d just look to see if the password didn’t match the order of the passwords I expected (I have to know the order anyway, because I have to know what would have been sent next had they not had the security installed).

    There really is no way around it, they either have to send it or not send it at all in the case of brute force. In the case of manually typing the password though, I think your idea is worth some thinking.

  4. maluc Says:

    indeed .. a random string would probably help such bruteforcing.. as it clearly shows whether it stopped because they navigated away, or because zonealarm blocked it.

  5. nopsledgs Says:

    what the f*** are you guys taking about? It seems like some bunch of jockers talking without any clue.

  6. id Says:

    hey nopsledgs,

    I’m guessing you don’t know wtf you are talking about eh? Are you a jocker without a clue? hmm…something about glass houses and stones comes to mind…

    BusyBox v1.00 (2006.06.14-14:54+0000) Built-in shell (msh)
    Enter ‘help’ for a list of built-in commands.

    #

  7. maluc Says:

    watch out for id, he bites back _-_

  8. nopsledgs Says:

    id - I will not be surprised to know that you are Gaurav yourself. Anyway the statement “Zone Alarm “Online Fraud Prevention” is severely flawed.” by Gaurav just made laugh like anything. Take care id, if you have not yet understood what can be called as a bug or not then do get some idea before you bites back.

  9. id Says:

    Before this post the word “bug” appeared one place, your post.

  10. nopsledgs Says:

    and what does that mean??

  11. maluc Says:

    it’s not a bug .. it’s a logic flaw. and i’m not sure what you don’t comprehend about it, but maybe it wasn’t expressed well enough _-_

    basically it has a protection which prevents a page request from being sent to a different domain - should it contain your password. So you just send a long wordlist full of possible passwords - a couple at a time- and wait for one to be stopped by Zone Alarm. The one that gets stopped contains the password. how hard is that?

    So although it’s meant to protect it’s users from having their passwords stolen .. it’s actually providing a method to steal them. don’t attack something just because you don’t understand it

  12. nopsledgs Says:

    Maluc,

    Amen to - “don’t attack something just because you don’t understand it” :)

    you got the point right ..