I really was dumbfounded when I read that Microsoft confirmed that the NSA had helped them develop Windows Vista. Not so much because I didn’t think it was possible (I’ve heard it all at this point) but that they admitted it. First of all, most of the reason you have a spy agency help develop something is so it will be better at spying, second of all telling someone how you intend to spy on them pretty much kills the whole concept of it. It’s not like I’m talking out of school here either, Microsoft fully admitted it to the press.

There are two possible backlashes from this. 1) The backdoor will be found and either used against the US government or used against it’s citizens. 2) Foreign governments and security/privacy experts will avoid using Vista for anything sensitive. Either way it could completely defeat the purpose of the collaboration. You’d think after the NSAKEY issue that came up several years back they would have learned how people react to hearing this kind of thing.

The only thing I can say now is if you are concerned that a rogue Microsoft user or the government have access to your computer systems, you probably shouldn’t use Vista. I hate having that opinion without even having tried it, but what else can I say? I guess I can’t really have much of an opinion, seeing as how the details of their cooperation are obviously very guarded, other than I think in this particular case insecurity through obscurity would have been a better option.

Okay, no more theories, no more guesswork, I finally have proof that Alexa data does not jive with actual real internet traffic patterns. Well, at minimum it doesn’t match what they claim it matches - it does prove other interesting facts, but I’ll get to that in a minute. My Alexa rating is pretty high. Ha.ckers.org does tend to get quite a bit of traffic (somewhere around 11k-14k unique users a day visit the site). Most of my traffic is comprised of the security industry, but I do have quite a few SEO readers - especially the blackhat SEO crowd. That comes from a long standing bridge between web application security and SEO and it also happens to be that I’m one of the few security people who talks about both. For whatever reason I have a lot of webmasters who aren’t particularly interested in security who read my blog as a result of that bridge.

One thing that most SEO people (and indeed webmasters in general) have in common is that they happen to all have Alexa (or here for Firefox users) installed on their browser. It could easily be seen a spyware because it does report on where you are visiting but it also gives you the relative page rank of the page for your troubles. This can easily help you assess if a site is new, or if it’s old, if it’s got a real following of people, or not, etc… It can also tell you if the domain gets traffic to other cnames (if that’s interesting).

But there’s been a long standing theory that Alexa data does not actually indicate true ranking. Finally I was able to prove it (at least to myself - maybe other people proved it to themselves before now, but I haven’t seen any hard and fast stats until today). So here’s what the current graph of my Alexa ranking is over the last several months:

Click to enlarge

You’ll notice the two biggest spikes on July 30th and January 16th (just a few days ago). So you would naturally assume those are huge spikes in traffic, right? Well let’s look at the significant events of those two days in particular. On July 30th 2006, the site was Slashdotted. To most people that’s probably a pretty significant event and you’d expect to see a huge jump in traffic. Let’s look at what it really did:

Click to enlarge

You can plainly see very little traffic change for the 30th. Sure it was up a great deal for the average weekend, but it was really not much of a spike, and nothing like the traffic levels you’d expect for the 4,000th biggest website on the planet, right? Could it be that SEOs also tend to read Slashdot? Okay, that’s really just a theory, so let’s put it aside for now. Now let’s look at the events of just a few days ago (the 16th).

Click to enlarge

You can see that I did get a fair amount of traffic but it was nowhere near my highest day this month and I certainly didn’t jump up by more than a few percent of my normal traffic load (the 17th proved to be a much higher traffic day and the 8th was the day the firewall died on us). Where did all the Alexa traffic come from that made next to no increase in the number of users we get in a day? Well as you will remember, just a few days ago a self proclaimed Whithat SEO said he intended to hack a bunch of sites. Ha.ckers.org was named in that list of sites (despite the fact that I really do not consider ha.ckers.org to be an SEO website). Ha.ckers.org was linked to by his website, and many other SEO’s picked up the list as well. In essence, every SEO that would possibly click on a link to a site named “ha.ckers.org” did click - and all in one day. Thus you can see only a minor increase in traffic on the 16th but a huge spike in Alexa ranking.

Quod erat demonstrandum.

It is interesting to note how many SEOs use the Alexa toolbar. I bet that database would give away a lot of SEO secrets if it were ever compromised. Spyware never sounded so good.

I had an interesting conversation with a co-worker today. It was actually not security related initially but a side tangent really caught my attention. A friend of a friend does industrial espionage for a living (what a weird job, huh?). One of the tactics that he employs is to pretend he is an executive recruiter trying to hire away someone from the target in question. So he calls the person up, claiming to have a great job with a good company, and he basically sits, asks questions and listens. The people spill their guts. It makes you sick doesn’t it? Social engineering at it’s finest.

But it occurred to me, there is really nothing stopping any social engineer from doing the same thing. Outside of the scope of industrial espionage, of course. There’s no reason I couldn’t call an employee of some big company and claim I am some hotshot recruiter, giving them just enough information to get them enticed and ask exactly the types of questions I need to know. Thus providing me enough, as an attacker, to penetrate the system given the known vulnerabilities that the employee has given me information into. Verrrrrry interesting. Makes you think back to all those recruiter’s phone calls you’ve taken, huh?

There is a concept in web application security that I’ve been toying with for a few years, based off of a common consumer feedback mechanism called waterfall analysis. Typical waterfall analysis is the rate of drop-off from page to page. The easiest way to think about it is a flow that has multiple pages in that flow. Each page represents some user interaction that is required (a registration flow is a perfect example). On each page, the ratio of users is calculated to help diagnose drop-off ratios. If you start with 100% of your userbase, some amount less than that will go to the next page, and some amount less than that will go to the second page and so on.

Now think about it from an attacker’s point of view. Let’s say you were able to separate your good traffic and bad traffic into two distinct buckets perfectly. Let’s also assume we only care about users who completed the flow (causing the function to fire) and so we are only looking at those users. 100% of both good and bad traffic make it to the function, each in their respective buckets. Here’s what it might look like:

When you put it like this it looks pretty obvious (this doesn’t account for users who hit errors and have to re-submit, or multiple path flows, but you get the idea). Using an inverse waterfall you can see that attackers tend not to enter your page through a normal page-flow. They don’t act like normal users because they don’t have to. They simply attack the critical infrastructure directly, performing the malicious function.

This might sound familiar because looking at flow analysis is an old trick used by products like AppShield and used in lots of anti-CSRF functions. But none of them look at it from quite this angle. They look at it from the opposite side, which is that you must have a credential to move on, which is good, because the inverse waterfall can be broken by the attacker simply following all the steps. But because an inverse waterfall does not give off any signals (no obvious cookies/credentials beyond what is required for the flow itself) it becomes far more passive. It is also easy to do regression analysis against your logs to identify possible fraud that has taken place after the fact, which you can’t do with a credential system since credentials are rarely logged. So while it does have flaws, it certainly does have some benefits too.

Anyway, just a thought.

I know I don’t often talk about network security (that’s really more id’s domain than mine anyway), but I got sent this link this morning that I thought I’d share. It’s the small business primer on network security threats. It’s a pretty good brief overview on what you want to do as a small company to make sure you are secure from the more common security threats out there. It’s a pretty good high level read. There are a few things I’d probably have added if I had written it.

Anti-Spyware: spyware is really really nasty, I don’t care what people say, it’s one of the nastiest things out there today. Not just because it can read what you are doing, but because with minor changes they can force your system to download viruses, keyloggers or whatever else they want. It’s nearly impossible to stop without a good anti-spyware program. People may confuse this with a Trojan, but a trojan is something with an implicit back door. With spyware or adware the administrators can inadvertently land you on a site that will make them a few bucks but the other server in question gives you something malicious. It’s not a Trojan by design, but it can act as one.

Network segregation: id could probably go off on this one bullet alone, but by separating your networks (wireless is separate from corporate, etc…) you hugely reduce the liability of having one machine compromised.

Local admin genie: Don’t let the local admin genie out of the bottle. If you give your users local admin rights, they will do way more with the computer than you would want them to. The second you give them higher privileges to install anything, you have opened yourself up to attack. It makes it hugely inconvenient for your users who want to install their favorite MMORPG on your work computers, but it’ll save you tons of hassles.

SSL/SSH/VPN: Encrypt your traffic, even if someone can ARP spoof a switch, they’ll be reading garbage. Don’t let them see your traffic. This is in response to their WiFi honeypot (I think they meant MITM bridge, but you get the idea).

Turn off all unneeded services: It’s a simple one, but this is one of the most important to corporate security. There’s no reason to keep FTP open, if you have SSH - you can SCP things over SSH, so shut down that exploitable outdated WuFTP service.

Email separation: Keep your work and your personal email separate, that way if they get an email from their bank at their work address they’ll be more likely to know it’s fraud. Further, don’t click on links in emails - ever! That’s what we call, bad. If you really want to cause a revolt ban all access to all freemail services, because really, what are you paying them for?

Backups: If you aren’t backing your data up, something as simple as a misplaced cup of coffee can bring your business to a halt. Network security involves good application security as well, and disaster recovery is a key component of that.

Anyway, I’m sure there are dozens of other simple things you can do, but that stuff definitely will help. Interesting read for the IT novices.

On the sla.ckers.org board Lobas asked a question regarding stealing clicks. The short answer is you cannot force a click inside of an iframe on another domain. The cross domain policy prohibits that, especially since inside banner advertizers you never know what the links will be. However, there is another way that Jeremiah Grossman mentioned a while back that I thought was pretty clever. You can actually move the banner ad to be placed immediately below the mouse so that when it’s clicked the user is tricked into sending their click event to the iframe beneath the cursor.

I wrote a sample code off of one of those annoying cursor following scripts to show that you can force text in a div (what could be an iframe to the banner ad) to be placed immediately below the image. What I haven’t shown is that the onclick event handler can be used to make the div appear at the right moment, or that you can make it semi-transparent or any of the other fun tricks. But this proof of concept proves that iframes are not really a particularly good way of protecting from click events. Banner advertisers beware!

I can’t say this really surprises me too much give my own results of other high profile domains, but x90 (NOP) was able to locate MySpace’s administration console. That just sounds like a bad idea - leaving the gateway to your administration publically facing. He was able to get it to error out which provided some interesting results as well.

Fierce is a good first-pass reconnaissance tool, and as you can tell it shows you thinks that aren’t obvious at first blush when you aren’t sure what is hosted at the domain. In just a few minutes of testing you can uncover huge swaths of vulnerable targets to exploit. This is no exception. It’s neat seeing people try it out and see what it can find for you. Let me know if anyone else finds interesting results or case studies. In the meantime, I hope MySpace knows enough to take this server off-line until they can harden it or at minimum move it to a less obvious place.

I got this email from a client today and I burst out laughing. When Mythbusters is teaching you about access controls you know you need help:

So probably best to not install a world facing thumb scanner after a TV show about how simple it is to defeat. I was watching TV and as it would turn out you can just take a finger print lift off the face of the scanner which more often than not would be a valid user. Then you can scan that in to a computer, print it, lick it, put it on your finger and your in. It is in too noticeable a place and I know that is something I would want to test out if i saw it. I actually kinda do. I am shocked that I didn’t know you could do that. Better safe than sorry we wouldn’t want the data center to become a club house for some dungeons and dragons gang.

The origins of this attack were the gummi bear attack that was proven to work in certain scenarios. A scanner and some paper is far easier. Why not?

I got an email from B10m today pointing me to a very interesting blog post he wrote about destroying a botnet. This is actually pretty interesting because he takes it from the very first step (detecting the attack) to logging into the IRC server, to communicating with the OPs, trying to get himself banned to prevent his IP of his server from communicating with the IRC server, to taking down the individual servers that were hosting the files as well as taking down the IRC server.

Although it was a relatively small botnet in the grand scheme of things it’s still pretty interesting to see this happen. I always wondered if the operators simply told the bots to listen to another IRC server elsewhere and log off, it’s still a fascinating story. The economics of creating a robot to follow the links and do automatics submissions to abuse@ the ISP in question aren’t that terrible. If there were money in it, I’m sure other people would be interested in doing this. Beyond that it’s an oddity. Although it may be interesting to write an Apache module to do this on your behalf. It might make the botnets stop scanning your network for fear of reprisal.

Someone named Fuckingpirate posted a very new blog today stating that he intended to hack a lot of the biggest SEO sites out there. Funny that I am somehow considered one of the biggest SEO sites since I rarely post about SEO (yes this is the second post today on it, but today has been the first in months).

Edit: Site is already down… so much for that game!

Edit: Site has moved to blogspot and there is a copy of the old site here. Additionally wolf-howl has been compromised.