The site is down now, but I got yet another phishing email using Google redirection to hide the real address that the user is being forwarded to. Sorry for the super long line (had to break it up): http://www.google.com/pagead/iclk?sa=l&ai=Br3ycNQz5Q-
fXBJGSiQLU0eDSAueHkArnhtWZAu-FmQWgjlkQAxgFKAg4AEDKEUiFOVD-
4r2f-P____8BoAGyqor_A8gBAZUCCapCCqkCxU7NLQH0sz4&num=
5&adurl=http://211.240.79.30:2006/www.paypal.com/webscrr/index.php

Google has been notoriously bad about fixing these issues, even after admitting a few times that it was an issue. As a matter of fact I don’t know of a single example of where they really have fixed these issues at all, other than blocking a single URL. Not a great track record. The reason being it’s far too difficult to fix them than to leave them there, even if it hurts their consumers, and their own brand in the process. Anything for a buck, I guess.

I ran across this article today on 99 ways to secure your email. Largely it’s email etiquette and efficiency fluff and there are really only a small handful of actual ways to secure your email in it (numbers 78-99). There are a few tips that I’d tell people that are definitely not mentioned on their list. Here are a few from my personal list:

1) Turn off preview panes. When you click an email and it shows up in the preview you are rendering the remote images and the click-tracking that spammers use to verify the email lists executes. That alerts them to the fact that you a) are a real user and b) are a user who reads spam. Having your email automatically open also increases the likelihood of email client automatic exploitation. None of those are good, so turn off the preview pane.

2) Don’t put email addresses or sensitive corporate information into out of office emails. If you are out of office, just tell them the name of who to get in contact with. If they know anything about your company they’ll know how to get in touch with the front desk and use the person’s name to get in touch with them. A number of times people have set out of office messages with stuff like, “If you need information on super secret project x please contact….” Firstly, that’s bad if it’s someone who doesn’t really know you (sales people, etc…) secondly, if it contains email addresses those too can be scraped by the spammers who watch the return addresses for bounces.

3) Use domain keys, SPF (sender policy framework) records or other tools to reduce spoofing. If you want to allow people to know if you are legitimately sending email from all users on your domain without causing them too much grief, install domain keys or use SPF records to reduce the likelihood of people successfully spoofing your email. PGP signing is great but it only works for the one person using it, unlike domain keys.

4) Unlike what the article says do NOT use Yahoo or Hotmail as methods to send anonymous emails. Both send headers showing the recipient where you are originating from. Use something like hushmail instead.

5) Create custom email accounts for specific applications. I’ve seen a number of people who have begun building out vanity email addresses based on the specific site they are visiting, EG: ha.ckers.org@mysite.com

6) Validate users who are allowed to send email to you. This is an ugly one but by only allowing people who you have authorized to email you you can significantly reduce unsolicited email. You had better not use one of these accounts for anything you want to get electronic receipts for, but for personal accounts it’s a pretty decent solution.

7) Use a fake or modified name on each site you visit. If my name is “John Smith” I could use something like John Petsmart Smith will allow me to know that Petsmart has sold my email information when I get spam or phishing emails in the future.

Anyway, there are dozens of ways to secure your email. I’m sure everyone can contribute to this list. It’s a huge topic, that they really only scratched the surface of.

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.

AJAX and dynamic HTML in general is such a new technology that most people really don’t get it’s true security implications. It’s nice to see a few articles being written that address the web application security issues found with the various types of dynamic code out there. Today I ran across an article on Help Net Security talking about the “Top 10 Ajax Security Holes and driving factors”. Pretty impressive sounding, but the title is kinda misleading.

Of the actual holes there are only three mentioned, Phishing, XSS and CSRF. He actually misses one of the other major holes like the one Jeremiah found in Google for instance where you can steal any data inside JSON if you visit a malicious web-page (yes, you heard me right, don’t put sensitive information in JSON). But even still, what he does discuss, even if it’s not 10 holes, is 10 ways to create those three holes. Some of them are going to be fairly obvious or impossible to create without some other hole and others are a tad more creative, but still, it’s nice seeing people think about this.

However, I’d like to point out, as I have before that really users should not consider AJAX to be another security risk. It is the same old risk that we have always faced, except there is more client side code that can be circumvented now. The more logic you create on the browser for parsing and security the more you must insure that your backend also protects you at the same time, since all client side security can be circumvented in one way or another.

I’ve said it a number of times but this is tantamount to muddying the security waters. Instead of knowing your single choke point for security issues you now have two or more places that require security thought. Not that that makes you less secure, it simply increases the attack surface area. Anyway, it’s kind of an interesting read.

Over the last several years I’ve noticed a disturbing trend in web application security - the use of email as a form of authentication. Once upon a time web application security was a very obscure concept, and as such it made sense to rely on a simple (although largely inaccurate) assumption which is that users have complete control over their email address. Let’s think about this for a second. How are emails being used today?

According to MAAWG between 80-85% of all email is abusive. Okay, so the user is inundated with spam, viruses, trojans, phishing emails and other scams and that represents the vast majority of email they will receive. That means a pathetic 15-20% of email is actually “good” or non-abusive.

I don’t have any real data to back up how many email accounts worldwide have been compromised but I do have statistics on how many of the top two web mail servers have been compromised with some form of attack. Both Hotmail and Yahoo mail have had issues, but let’s not forget Gmail too. At one point I met with an AOL business person and they told me that the number of account takeovers they had were “in the percentage” range. He was unwilling to tell me how many percent, but even if it’s 1% of users that represents over 500,000 accounts.

Okay, so email is both insecure and highly targeted for malicious activities. Now let’s look at how companies are using it. Many companies still require that users use an email address as the primary username for their accounts for logging in. Companies reference the accounts as such. That makes it extremely easy to identify users, and potentially difficult to guess since there are billions of email addresses out there. However (and here’s the fatal flaw) the servers allow access to their websites by using email as a forgot password function.

So an attacker can get access to your email, (given the flaws in the webmail systems) they can look through the email, (since they have access to it) they can connect to the websites (which you have kept information on), they can use the forgot password function, (which generally asks for nothing more than an email address) and now they have access to your account.

Websites use email as a form of half-factor authentication. While it isn’t something you have, it is something you know that is not normally out of your control. In this way it is very easy to gain access to websites given access to an email account. People don’t generally think of their web mail as being a critical asset. That’s where they sign up for random websites since they don’t want to use their work account while shopping for lingerie. But by putting so much faith in the webmail application they now have risked whatever can be done on any website they they have an account with. A disturbing trend, to be sure.

Jungsonn has only been a member of the forums for one day and he hits big with IP encoding that evades Firefox’s anti-phishing filter. This isn’t the first time I’ve seen this sort of thing, but it’s the first time I’ve seen it in a commercial browser. What Firefox is doing is doing a direct compare against the URL. Using the IP obfuscation calculator you can create IP addresses that don’t match what is in the anti-phishing list. But it’s worse than Jungsonn reported even.

That’s right, go to any phishing site and add in a QUERY_STRING to the end of the URL and poof, no more popup. What a bummer. I was really hoping they would do something a little smarter with this. Unfortunately with this knowledge it is extremely easy to defeat the anti-phishing detection built into Firefox’s newest browser.

The QUERY_STRING issue is a tough one to solve, because where do you know to compare against? The IP address issue that Jungsonn came up with really bothers me. Why would you use the URI field to do comparisons instead of the IP address that it is normalized to? Is it an oversight? Oh well, I hope they fix this soon.

Coming quick on the heels of my last post comes an advisory from Secunia around address bar spoofing in Internet Explorer 7.0. This is pretty straight forward, just adding some %0A’s (hex for linebreaks) as padding in the URL in a popup window. It should be pretty trivial to fix, but I can never figure out why browsers allow the URL field to be removed at all. Suppression of URL fields should never be allowed unless the user permits it as a power user function.

That’s a few big holes in just a few days for the newest version of Internet Explorer. The score card isn’t looking so hot at this point. Anyone keeping score?

I keep hearing about this idea and every time I hear it I kind of cringe. In a recent blog post the folks at Internet Explorer talk about high assurance SSL certificates for Internet Explorer, Firefox, Opera, and Konqueror (I guess Netscape was left out?). The concept is pretty simple and I encourage you to read the IE blog for more details. Webmasters buy a high assurance SSL certificate which shows the public that they are trustworthy and for their troubles the browser community thanks them with a nice green URI field.

So I have to go out and buy updated SSL certs for every single SSL server I have so that we are actually trusted - because only phishers use that normal SSL stuff I guess. Now everyone has these high assurance SSL certs and only the chumps who are doing dev work or just can’t afford it have the snakeoil or non-assured SSL certs. And now there will have to be a lowered bar so that everyone can buy them (quickly too). And lastly you end up with SSL certs all over again, only this time you’re paying 10x more for them.

And let’s not forget our dear friend XSS which totally obviates the need for me building my own phishing site or buying my own SSL cert. Oh, and don’t forget that MOST phishers don’t use SSL enabled sites, since users don’t know the difference anyway.

Okay, I get it… they’re trying to build a whitelist and they can’t think of any “fair” way to do that. Using that whitelist they want to educate the users (I’d argue that that hasn’t worked super well in the past so I don’t know how this will help). There’s just got to be a better way to do it that doesn’t make us end up with the same thing we all started with in the first place.

Well, technically Firefox 2.0 has been ready for a while now, but tomorrow is really the big day that it gets pushed out. But Firefox 2.0 is available today for download. And download I did. Almost the first thing I noticed was the spell check in text areas. I almost didn’t notice it at first because it was so intuitive, but there it was. Very cool feature. Next I tried the anti-phishing filter:

Click to enlarge

Picked up the very first site I threw at it. So all of that appears to be great for the consumer and great from a security perspective. Now here’s the bad. Upon install it broke a number of installed plugins. Namely:

• Fasterfox (oh well, who needs speed)
  
• Switch Proxy (ugh! this is one of the most useful plugins I have for switching back and forth between burp suite)
  
• Server switcher (not particularly useful anyway - useful when switching back and forth between QA environments seamlessly but nothing really lost)
  
• Firefox View (never used it anyway so it’s okay)
  
• SEOopen (I don’t use it much anymore since I got Search Status so that’s okay too)
  
• Safe History (I guess the CSS history hack is back in force again)

So if you can handle that annoyance I’d say upgrade. It handles about the same, but only time will tell what major differences lay under the nice new exterior. Also, I was amazed that Firefox still hasn’t implemented HTTPOnly. I think it’s just getting ridiculous. I know it’s a Microsoft non-standard convention, but it’s a good idea, and I’m amazed that it’s still not implemented. Overall though I’m pretty happy except for the switch proxy plugin being broken. That one is going to hurt bad since that simple plugin is one of the major reasons I use Firefox for testing more than Internet Explorer. Oh well, back to doing things by hand.

This is right on the cusp of what I think is worth talking about since the volume is so low. It’s not particularly interesting that Nordea.se was phished (article in Swedish). The part that’s interesting is that a relatively small market segment is being attacked. This is common behavior for phishers, but in this case I think it’s more interesting than most for a few reasons. The bank is small compared to most of the more common attacked banks and it’s non-english.

Nordea.se is what I like to call a phishing probe. Phishers often attempt smaller regional banks to see if they can get a spike in returns. Either they buy spam lists of users or find other ways to attempt more targeted demographics but in the end the attack is the same. Phishers like to try these types of things because it costs them next to nothing to attempt, and it can be a huge return on investment.

The economics are pretty simple. Let’s say 100,000 emails were sent. For a pretty targeted list that might cost anywhere from $100 to $1000. It may cost $100 to get somoene to break into a server for you and throw up your PHP kit that you probably already had if you are a regular phisher. It might cost several hundred for the card blanks and the card writer for making the fake cards but that’s a one time cost. Setting up the email drop for the passwords is free. So once the card number has been stolen what can you get for it?

Typically you can only pull out $300 per card. It’s dangerous to try more than once. But it’s not unusual for phishers to sell the numbers after they’ve been used. They can get up to $75 for a card number with pin. So a max of $375 if they do all the work themselves. $375 x 100 users = $37,500. When you subtract expenses you’re still well above $30,000 for a single haul. That’s not a bad haul for someone who is probably living in a country where that is far higher than the annual average income.

Even though Nordea.se is a small bank in comparison, the yield is still high enough to make the economics worthwhile. These probing techniques are not just worthwhile from an experimentation perspective but even if the yield is remarkably low (0.1% of users really is not much) the potential revenue is dramatic.