I’ve tried to explain how this works to a few reporters, but there are certain classes of phishers out there that seem to band together. Geographic dispersion is loose, as you might guess, but they are sort of basically chopped up into three groups of people, the Romanians/Eastern Europeans, the Chinese/Asians, and the Nigerians/North West Africans. Each have their own ways of attacking applications and phishing.

Romanians/Eastern Europeans: They tend to be the most skilled of the bunch. They think about scalability and they run their activities like a business. They use modern exploits, and tend to come up with most of the cutting edge scams. They tend to be on the bleeding edge of new issues, and tend to tie in things like malware, pharming, and server exploits. They tend to be the ones creating the phishing kits. Like the others they have strong ties to organized crime, and have actually resorted to kidnapping and (presumed) killing of at least one government official. Due to their technical nature they are highly scalable even though there are probably fewer in numbers. They require the most hardware, and are assumed to have ties with lots of botnets.

Chinese/Asians: They tend to be copy-cats. They watch what the other groups do and mimic the same tactics, only months or years later. What they lack in innovation of exploits they make up for in volume and brute force attacks. They are relative newcomers to the world of phishing in comparison but they are growing rapidly.

Nigerians/North West Africans: They tend to have the lowest sophistication of the three groups, and primarily focus on ways of coming up with new variants of 419 scams. They tend to use people instead of automation and focus only on high dollar scams. They are most likely to make contact with the victim and actually will resort to strong arm tactics if they find out where you live. Would you want this nigerian debt collector after you?

All three groups have technical requirements, and all three groups span across national boundaries. The lax laws around cybercrime and the difficultly in getting machines and operations shut down in these various countries make it particularly easy for them to operate with relative ease at the moment.

A school teacher was arrested for allowing children to look at porn. But, as you might expect, she had nothing to do with it. An innocent looking website (could have been any one anywhere) had a link to a site that some children followed that had pornography. Later on, the teacher noticed that she was getting porn popups - guess who has spyware? The best part is the litigators didn’t even bother to check for it. Let’s screw the consumer for their poor security.

Who loses? Children lose - they no longer have their teacher and they were exposed to pornography. The teacher loses - because she lost her job and may have to register as a sex offender if things don’t pan out well for her. We lose - yes, we lose when we cannot protect school teachers from innocent surfing of hair websites. If consumers don’t feel safe to use the internet because they are worried that they will lose their freedom and their livelihood, I think we have a serious problem here. Anyway, scary read and of course, the normal XSS implications apply, ad nauseam. Yes, this goes in to the scary implications of CSRF category.

Jake Reynolds alerted us to a link that I think is worth posting about. Apparently Joel Snyder bet Acunetix $1000 that they couldn’t steal personal information from 30% of the sites that they found. Wow… I WISH someone would bet me something like that. It’s one of the easiest challenges I’ve ever heard. Firstly, Joel is hugely missing the point. It’s not just about stealing databases (this is such an old-school way of thinking about security anyway - that information breaches have to involve penetration). It’s about users who visit the site being asked to do things or being forced to do things that will compromise their information. Oh, let me count the ways:

mhtml (IE only) as long as the site suffers from some XSS hole, I can steal any information from any website they have logged into. I would consider that a huge breach of security.

keystroke stealing: (both Firefox and IE versions) thank you, Michal Zalewski for showing us that we can steal information from user’s drive.

Clipboard stealing: (works in IE) there is all kinds of sensitive information on user’s clipboard.

Java Script port scanners: Let’s steal information about the user’s network, open up their network and see what they’ve got. You could argue this isn’t really an information breach, but if the people who work at the company view it, it could be a means to break into their company. Uh, yah, that’s bad.

phishing: Let’s not forget the old favorite. If users trust the site, they will happily input anything you ask them to. That definitely compromises user’s accounts, I’d say.

Let’s not forget about CSRF or other information leaks. Someone, bet me $1,000! Actually no, bet me $100,000, while you’re at it. Ah, hell, make it a cool million. I do get Joel’s point - there is a lot of snake oil out there these days, but saying that you cannot take people’s information from them is completely failing to understand modern security holes. Acunetix, if you want help taking Joel’s money, let me know.

Well I finally sat down and read the full 17 page report by Google on their analysis of click fraud. It’s not a terrible read, it’s not just telling the whole story, which was making me wince a lot. Sure, they have a point, users do hit refresh and they do click back on their browsers when they surf off a page. Yes, click fraud companies have a limited view of the world without being able to check against the actual click stats. But users also use Firefox. What’s that? How would a browser make a difference? It makes a ton of difference.

Google’s engineers obviously weren’t using Firefox when they wrote this report. When you click back on a browser in IE it will refresh any JavaScript on the page. So if JavaScript was used to output something it will get refreshed. In Firefox, however, the JavaScript does NOT get re-run, even if you tell Firefox to not cache the page with Pragma and Expires headers and meta tags. So while not technically complete or accurate, it’s an interesting document.

There’s an absolutely brilliant retort to one of Jeremiah’s post that was written by ntp about how we have lost sight of how the network security battle was (mostly) won. I was actually stunned that someone bothered to write all that down (it’s quite a read, I’m warning you). But I think he articulated a point that has up until now been very poorly thought through. Yes, we won the network security war. Our perimeters are mostly safe not because of Firewalls but because of all the access controls, protections at the server level, protections we’ve forced on the clients, etc… In fact I know a number of companies that have completely gotten rid of firewalls because they are both a single point of failure and they have rate limits that properly configured servers behind F5’s or SQUID boxes don’t.

And now with the advent of JavaScript port scanners we have broken the concept of firewalls again - yet here we are, talking about how to improve WAFs so they can be our new firewalls. For some reason people tend to think that if we try again it will work this time. IPSs were a cool idea… active rule based firewalls, and you could make the argument that IPSs are really no different than WAFs (even that they are one in the same). But that’s not how we won the war. IPSs were a nice afterthought that came about long after we had solved most of our problems at the individual servers themselves. Firewalls were mostly a convenient way to segment traffic at that point.

Anyway, before I dig myself too deeply (because I know this is a contentious topic) I’m going to ask that you read his comments. Prepare yourself for a ride - it’s a long one.

The NYT posted an article today posting some results from an Acunetix scan that says that 70% of websites are vulnerable. To quote the article, “On average 91% of these websites, contained some form of website vulnerability, ranging from the more serious such as SQL Injection and Cross Site Scripting to more minor ones such as local path disclosure or directory listing.” Glad to see that XSS is being tossed a bone in the article (it’s the little vulnerability that could!).

But for some reason these numbers seem WAY low to me. Given that Jeremiah has found about 70% of sites to be vulnerable to XSS alone, and I’ve found closer to 80% of them to be vulnerable in the one thousand or so sites I’ve manually looked at. And that’s not all of them either, that’s just what I found! I’d love to get a list of sites they say aren’t vulnerable and re-test a segment of them.

I have a feeling these numbers are understating the real problem. Just because you can’t find the problem doesn’t mean it’s not there. Still 70% is a scary enough number that most people can’t really comprehend anyway. Telling them that 80% or 90% or more is vulnerable wouldn’t change their perception much, I’d imagine. Even worse it could make them give up hope, “Well if everyone else is getting it wrong, what hope do I have?” Scary stuff.

I’ve been interested in password research for over a decade. One of my very first “hello world” type programs was a trojan horse that emulated a UNIX TTY session (figuring out how to suppress keyboard output “stty -echo” was the only tricky part). I’ve spent hundreds of hours looking at password uniqueness, entropy, etc… think of it as part of my passion. However, one aspect of passwords has eluded me for years, and simply because I don’t have the necessary data to test my theory.

Once upon a time I was talking with a female friend of mine and I told her I could probably guess her password. Of course I was completely kidding, but she thought I was serious. Playing along I said, “It is a word followed by a number, maybe two numbers.” Her eyes got big - maybe I was onto something, “It’s an effeminate word, no more than six characters” You should have seen her eyes at this point, “It’s not a word like pony, that’s too little-girl for you…” Of course I never guessed her password, and I had to admit at this point that I was full of crap, but herein lies my dilemma - was I full of crap?

If you look at user statistics you can often derive certain things about people. Younger people tend to like certain things that are different than older people. So too, do security people tend to pick harder passwords than non security people. By knowing a little bit of demographic information about users, you can quickly narrow down the possibilities (I think). Of course I have no proof of this. I would need a huge database of user interests, language type, age, sex, profession, and of course passwords… The more data the better. Including things like password policies of the sites the passwords came from.

Of course there will be significant anomalies, like the fact that people often use the password that mixes the name of the site they are on into it “myspace01″ and the common passwords like “password1″ and the obscenity passwords. And you’ll never guess if people use random numbers or pet names for their cat, but you can get close (I think). Has anyone done this sort of research before? I’d love to get my hands on some user data like this for testing (no usernames, where the passwords came from or email addresses required). Anyway, food for thought.

I’ll probably regret this post at some point, and I have to caveat this by saying I love adblockplus (it’s a dream). However, it is also flawed. Whenever you do straight string compare you are risking missing something. Well it just so happens, that the string comparison required when you are looking up something like ypn-js.overture.com you are missing one obvious way the client can request the JavaScript from the page - using the IP address. But that alone isn’t magic. Anyone can swap out an IP address… and by the way, that alone won’t work because of the way Overture’s ads are built. Not only do they use ypn-js.overture.com for the initial JS lookup, but also for the subsequent iframe that contains the ads themselves.

Okay, easy enough… first we take the JavaScript and look for any variables that are set by the Overture JavaScript. We find one and then we check to see if it has been set. If it has, you can see that the ad is already there. If it hasn’t, the ad is not there, and you can write your own work-around. The reason we do this in this order is to make sure we don’t end up with two ads on the page (and we’d rather use the DNS if we can since that has built in IP failover).

Here’s the demo. This could be very valuable to anyone who is plagued by their users who turn off ads in the SEO/SEM crowd. Hint, hint, whitelist this domain, so I don’t have to mess with you guys.

Checking through my logs today I found that someone was linking to my mailto: popup crash script. After checking the page out, I couldn’t find a single link to my site. Only a link to Google. Suspicious, I checked out where it was sending the consumer to: http://www.google.com/search?btnI=q&q=ha+-haha+mixed-bag-of+laughs+certaily (don’t click on that unless you want your computer to start spiraling out of control).

The words “ha” “laughs” “mixed bag” and “certainly” appear on the page. Because of the btnI=q it automatically redirects to the page in question to maliciously make people go to places they didn’t intend to go. This is pretty much exactly the use case I am worried about. Consumers have no idea that “ha+-haha+mixed-bag-of+laughs+certainly” is going to crash their computer. Nor would they understand if that were to give them a virus, or steal their bank account, etc… And yet this known hole is not yet fixed a year after first being reported….

Just something to brighten your day if you are one of the poor schleps having to code around every possibly security contingency. It’s also the concept behind “team rubber-hose cryptanalysis” that we started at DefCon several years ago. we figured we’d sweep up the hacking contest if we just bought some base-ball bats.

Click to enlarge.

Just because you have a secure system doesn’t mean the wet-ware is secure. Hope everyone is having a good weekend.