Several years ago I read a paper called Owning the Internet in your spare time. Besides being the single best security paper I’ve ever read coming out of a college, it opens the door to a new classification of viral propogation in the security community. The basic premise is this. Traditional viruses travel in a very innefficient manner. They scan a series of hosts either nearby their netblock or just start at a single point in the entire IP space and start scanning in one direction. Then when they find a vulnerable host they infect it and start scanning in the same place all over again. As I said, super innefficient. The concept of a Warhol worm is what Andy Warhol was famous for - “15 minutes of fame“. A virus that could propogate in 15 minutes globally.

Now in spite of the great premise of the paper above, it still lacks some reality (in talking with some viral genetic researchers). There are two things that make this paper infeasable. The first is that it requires users to have their computers on. Typically that is a follow the sun model. The fastest you can get a worm to travel is slightly less than the time it takes for every computer on the planet to turn on and be infected (approximately 24 hours). The other problem is network traffic. If you have every machine in the world probing for computers, it can take down huge sections of the network, so you have to have some mitigating factors to make sure only high bandwidth hosts are capable of scanning large chunks of the network and stay relatively geographically close to their origin until the next time zone is awake. The first example of a Warhol worm (or Flash worm) was the SQL Slammer worm which used a psuedo-random number generator for propagation.

So assuming you could figure these issues out (they aren’t that difficult - but I’ll leave it as an academic excersize) how does this affect cross site scripting (XSS)? Let’s take a look at the MySpace Samy worm for a second. That affected 1MM users, in a fairly non diverse location (mostly users in the United States). 1MM users is a LOT of infected machines, but still not enough. Let’s take it one step further. Let’s pretend for a second that there are users who have access to multiple websites that are similar to MySpace (it stands to reason that if a user is accessing MySpace they probably have other accounts elsewhere as well). Finding vulnerabilities in multiple platforms should be relatively easy (it has been historically anyway).

Now let’s say instead of simply just attacking MySpace, the worm also attacks MyYearBook.com or another similar social networking site with another significant amount of users. Suddenly you have an XSS worm that can jump from platform to platform. Now let’s take it one step further, and say you find multiple vulnerabilities in social networking platforms located in every time zone around the world. If you tie them together you now have a social networking XSS worm that can leap from platform to platform and infect huge chunks of the global population. Now, let’s take it still one step further and say that we can embed certain exploits in known open source applications like PHP nuke, etc… Scanning the local IP space, using a search engine with the keywords that match a likely candidate for exploit then connecting the browser to it and attempting to exploit the vulnerabilities could make a worm that could theoretically attack nearly every computer on the internet that was used by an internet facing user.

Instead of affecting 1MM users it could be 1 billion users, and it wouldn’t have to have much genetic diversity to do that, because it would only have to survive for one day. The ramifications of a worm like that propagating across the internet could be disasterous. The payload could be something as easy as a DDoS, or the largest phishing platform mankind has ever seen, or even as stupid as just flooding the global network for a day (anyone need a vacation day?). Critical infrastructures could not handle and additional billions of requests a day (and I doubt the search engines themselves could handle the billions of additional searches being performed), which could easily flood off tons of networks, particuarly the smaller ones, even with no payload. The cost to businesses could be in the billions.

It might not be 15 minutes of fame, but 24 hours of infamy is probably just as scary. I’m really trying to hold back on my fear-mongering, but this isn’t fiction - it just hasn’t been built (yet).

One of my readers (Andy) wrote a good question about the relative web application security strength of the site and the odds I would give ha.ckers.org. The blackbox security analysis is worth discussing further, since I don’t think I went into enough detail on my last post, so here it is:

Hypothetically speaking (no betting is taking place here, no sir) what odds would you put on your blog and why? Have you gone to any great lengths to harden WordPress here?

Hi, Andy, good questions, but I want to be very careful that I don’t confuse the two because they are very different questions.

What odds would I give on ha.ckers.org surviving a penetration test, verses some other website (say something large, like Google). Well, it’s hard for me to be objective and act like a bookie would on my own site because I know how it’s built, but let me try to pretend I know nothing about me as a person and the inner workings of the system and only use information that is already availible on the websites or from other sources gleaned from the web.

Firstly, it is pretty obvious I am using WordPress, as you mentioned. It’s a free software application written in PHP. It has already had bugs found in it, and it is open source. Given that information, It’s got a fairly high percentage of finding further vulnerabilities in it (not knowing anything about what I have done to it). However, the fact that it’s had bugs and fixed those bugs does make it slightly more hardened, theoretically. It also has a MySQL backend, making it subject to MySQL injection if a vulnerability is ever found to exploit it. Thankfully, it appears I have turned off user accounts, so that does mitigate the risk somewhat, but beyond that, it’s not clear what I have done to it.

Next, it appears I have some CGI scripts on the site. It’s not clear what language I wrote them in, but I do mention PERL a number of times throughout my site and various posts I have made, so it’s a safe assumption it’s either PERL or some sort of shell scripting (bash or ksh). Let’s assume PERL for a second. Clearly these are not open sourced applications that I’ve written, and given my background in security, it’s a fairly safe assumption that security is built into it.

There are approximately 5 boxes in which to input data on the entire site, no cookies are set for my users, and it doesn’t appear that any information is logged and then exposed to the site with the exception of my clipboard stealing application which has already been unsuccessfully attacked dozens of times, so that looks pretty good. Now let’s look at the network portion. It doesn’t appear that the website communicates over any other port, which is good.

It makes only one known outbound connection (WordPress’ ping). So far so good. Okay, on to the people who maintain it. There are only two people who appear to run the entire site (id and RSnake). Both are self-proclaimed experts in their fields (RSnake in web application security and id in network and OS security). I’d give this a fairly low liklihood of exploit given that simple fact alone. What about the site history? The site has been around in one form or another for 5 years, and has not yet suffered one sucessful attack. Pretty good!

Now what about Google?

Google uses all homegrown scripts, it looks like. They are, however, suffering from the problem that most big companies have, which is that they have absorbed a lot of legacy technology from other companies via acquisition. That right there scares the crap out of me as a security guy as this was the sole reason for The Largest Hack in the History of the Internet (TM). However, it looks like they run the gambit of languages. Everything from Python, to C. That makes them a candidate for all sorts of varying exploits against the various types of applications.

They appear to be a Linux shop (albeit a hacked up version) from their TCP signatures and from what we can gather from the various whitepapers. However, their corporate intranet is strewn with varying operating systems, with outdated versions of varying browsers. Ouch. Allowing access from the intranet out to the Internet is a recipie for disaster (banks have begun to disallow it, for a reason).

Google has just about every application a portal could want. Lots of them are tied in with databases. They have thousands of input boxes, they do set cookies, accept query strings, and god knows what else. They make outbound connections via translation services, their spider and mobile devices (among probably a dozen more). They speak a number of protocols, including HTTP, HTTPS, IMAP, + whatever Gtalk uses, among others. Plus they log and replay unmodified versions of webpages via Google cache (ever considered hosting a phishing site on Google?)! Also, almost all their applications are in beta mode, meaning they have not gone through the strict security quality assurance typically associated with productized applications (at least that’s what it looks like). What a mess!

Let’s look at their network now. Via aquisition they’ve ended up with this mass of websites. They have multiple data centers, and allow people to work remotely through VPNs from what I can tell from their network traffic. Yah, not so good.

Now, who maintains it? Well Google has literally thousands of employees, very few of whom have had formal security training. I don’t have any numbers on the size of their Trust and Safety arm, or infosec arm, but I’m picturing it in the sub 100 people range, if you discount Adwords ToS monkeys (which I don’t consider to be security). That means that for every thousand lines of code, maybe 1-10 sees the eyes of a security expert. The rest goes through automated scanning (I would presume), but we all know how effective that tends to be.

Lastly, let’s look at their history. They have had holes in nearly every application they have launched or aquired (Google Base, Gmail, Google Personalized Page) and at least two and maybe as many as 5 depending on how you count it have been found by ha.ckers.org (yours truely). The scariest one (not found by me) was an unpublished one where every Orkut user got their account information stolen. Not such a good history.

Given that both applications are heavily attacked by assailants, and that some of the holes found in Google were found by the webmasters at ha.ckers.org, I would give the odds 1:300 against ha.ckers.org getting hacked before Google.com was, given the same time and resources. If I were a bookie, my money would be on Google to loose. I’m not saying Google has shoddy security. I’m actually just going with what I can see from the outside trying to stay as objective as possible. That is completely trying to stay unbiased, pretending to not know the reality of ha.ckers.org and without knowing the inside of what Google really looks like.

Okay, I hope that answered your first question. Your second question is actually quite a bit harder. Wordpress is a crazy beast. Without going into lots of specifics about what I’ve done to it, let’s put it this way. I am more careful about protecting the server from Wordpress than getting WordPress to protect the server, if you catch my meaning. I have modified WordPress though and if I had more time I would do a complete re-write of certain sections of the code (maybe in the next few weeks I’ll find some time). Honestly, I know there are about a half dozen places that desperately need re-working, but I have’t had enough time to read the code thoroughly. I did do a rough first pass, and that’s why I bothered to install it at all (it passed the gloss over test), but it certainly doesn’t meet my needs as a hardened CMS (yet). That said, it’s by far the best I’ve seen.

Now, to the question you’re really after, would I consider ha.ckers.org to be 100% secure? Nope. Not even close. But security isn’t about 100% certainty. It’s about risk mitigation. If I got hacked into, what do I risk? I don’t make any money off of the site anyway (a few bucks but let’s be real). Maybe I get some of my readers laughing at me, but at the end of the day, it’s probably not going to be code that I wrote that caused it anyway - giving me some plausable deniability. But what I will say, is that given the nature of this site, for some reason people think it’s okay to attack it. Some days we can see up to hundreds of attacks against the site, and not once has anyone sucessfully penetrated. Not bad, I’d say. id is a bad-ass networking guru that keeps the network attacks at bay, and I keep the site’s front end exposure to vulnerability to a minimum. It’s a proactive game, and I modify the site on a daily basis when I see a problem arising. Will we get hacked into? Probably some day. But I’m not too worried about it.

Quadszilla ran an interesting article on betting on who you think the biggest blog in technorati’s ranking.  While that’s pretty damned interesting (and feels very game-able - and great press for Technorati as well) it got me thinking.  Why hasn’t there ever been anything like this for hacking?  I mean we’ve all said it, “I bet you a buck so and so is hackable”.  Well I proposition that we take the top 500 Alexa sites (that’s probably too many to do odds on, but you could pick and choose) and do something similar.

We could set up a pool, and do it right.  Taking odds on who is hackable has a unique problem that most gambling does not - in that the users who are betting can actually change the output of the game.  Let’s say I rank Yahoo at 1:5 above MSN at 1:10.  Now people would be more likely to bet MSN and then hack it first.  The challenges involved for a bookie in this would be tremendous, but I’m sure they could be figured out.  Just like anything, it’s there will be winners and losers.

Of course, I’m mostly kidding, (gambling is illegal where I live and the legalities involved are highly questionable) but wouldn’t that be interesting? You could base it off of all sorts of vectors, like how many form fields it has, or how long the site function has been live (tried and true variable), etc…  There are a ton of factors, that could actually go a long way towards classifying how vulnerable a site is, just by the looks of it, rather than by doing any in depth penetration testing.  You’d probably need to change it based on what types of vulnerabilities found (one for cross site scripting, one for full shell access, one for complete data theft, etc…).  Pretty crazy concept!

Phaithful sent me this link to Threadwatch talking about Netscape’s recent cross site scripting hole. This attack went beyond just a simple XSS proof of concept, but rather, changed the face of Netscape by creating a dialogue box with an obscenity in it. Pretty bad for your brand, I’d say. It appears to be fixed, but it just goes to show how serious these types of web application security issues can be for your branding, let alone what the attackers could have done, given how many people have that set to their homepage. The potential for disaster is tremendous, if it had been used in a more destructive manner, than a simple defacement.

The stored cross site scripting attack vector may not be the most common, but in this case it was probably one of the most dangerous. Here is David “Aesthetico” Vieira-Kurz’s explanation of the hack (I do not believe he was the one who defaced them, but he was the one to disclose).

There is a thread on the Webappsec mailing list regarding some statements I made about the blacklist approach to solving phishing that the browser companies are adopting. There are some things I think should be clarified for the people who are reading that list.

I respectfully disagree with the statement that there are programs that can solve phishing by authentication. I know exactly what he is talking about (domainkeys/SPF records, etc…). The problem is that the bad guys are already adopting it. But instead of using wellsfargo.com they are using wellfs4rg0.com. People read it too quickly. Sure it is properly authenticated to be from that user, but it doesn’t stop the user from thinking it’s from someone else. Also, you have the problem that no one can seem to settle on a standard. SPF is the easiest to use but it’s far from secure. DomainKeys verses SenderID verses SPF and varients of each all make this even more complex because you have different companies installing what they think is the best solution out there. And let’s not even go into the privatized versions of those same tools which completely messes this up.

Then you have companies that do direct marketing on behalf of huge clients, like these mega banks we’re talking about. Now they have to adopt the same methodology. And don’t get me started on the additional cost of server hardware due to the performance hit. It’s just not that cut and dry. Calling them “good” products means that they solve the problem. I don’t think they even address the problem directly. They are only designed to detect if the user who sent the email is the same user that is said to have sent the email. If the user is @wellfs4g0.com sure, it is them. How has that stopped the email from being delivered and stopped the user from clicking on it? Sure, now we have to rely on education. Read #5 about why educating users is the 5th dumbest idea in computer security: http://www.ranum.com/security/computer_security/editorials/dumb/index.html

To answer some of the previous comments, blacklists DO work. The problem is that no one is using them (well, Netscape is, and a few very poorly used toolbars do, but that hardly makes up a majority). If you had those blacklists in every peice of email software, and content filters at the network leverl, and browsers, the name of the game would simply be how fast could you get the blacklist updated and sent to the clients (same as anti-virus, only the signatures are way easier to build). Also, these aren’t just blacklists pulled out of thin air. They are either detected using heuristics engines, or there is a canary (read sacrificial user) who goes to the site, despite it’s perils, detects that it’s a phishing site and notifies one of the companies that deals with the blacklist. So literally as soon as the first person clicks on an email is when the clock starts ticking as far as when the blacklist can be updated (assuming that user doesn’t fall for it and either they can tell it’s a phishing site or the application they are using detects it on their behalf). IE7.0 has such a heuristics engine. As does WholeSecurity (now Symantec). Others are on their heels.

DoSing the lists wouldn’t work, they all go through a vetting process as to who can actually submit them - so unless you happen to be one of these companies who regularly gets phished, you don’t even have access to write to them. It’s dirt cheap to get added ($15k is nothing to most companies), and it’s very easy to get kicked off of it as well if they detect abuse. I’ve talked with Dave Jevans about this actually, when he was first starting the anti-phishing work group.

There was also a comment about stopping the ways in which money is laundered. Shutting down every strip club and laundromat in the world (all cash companies), isn’t going to solve phishing. Yes, they do have a fairly centralized command and control structure (fairly). But as we have seen from the dozens of arrets, this hasn’t put much of a dent in stopping them. They have been very resiliant - and they should be considering how valuable an attack this really is.

As I said in my original post, browsers adapting to this by including blacklists doesn’t solve everything, and the bad guys definitely will adapt, but it does put a major hurt in the current vector of phishing via email.

Lastly, I’d appreciate any feedback on this topic: I’ve batted around the concept of attempting to write some legistlation to make the ISPs liable for identity fraud via phishing unless the ISP makes reasonable attempts to protect it’s users (providing optional content filters using these blacklists).

Amit Klien is a web application security expert. He recently came up with an ingenious way to use flash to forge HTTP request headers. Wow. Up until now it has been impossible to do that. Normally, talking about referrers (since that is the most widly used application for request header spoofing) you could only remove them (with Meta refresh or JavaScript, etc…). But now you don’t have to just remove them. Now you can actually modify them.

This actually has some pretty scary applications. Now you can no longer trust that the referrer is even real at all. Previously you could at least tell if it wasn’t real (IE: it was there, but incorrect). That was one way people got around cross site request forgeries (CSRF). But now, the CSRF can be done with the correct HTTP referrer, and indeed all the correct information that you would expect (including cookies or otherwise). Up to this point, I’ve felt that referrers had limited use anyway, because they are absent too frequently (in the case of security applications like ZoneAlarm etc… that remove it) and you could intentionally remove the referrer.

Now, it’s just plain wrong. That could mean serious troubles for any application that relied on that information exclusively. Now this has other applications for XSS fuzzing, etc… where you can fuzz all of the information (including browser types, etc…) that are normally not available to the attacker in question. Amit uses the example of the expect HTTP variable, but anything is a potential target, including POST variables, Host variables, etc. The sky is the limit. I’ll be interested to hear if Macromedia comes out with a patch for this, as this has some serious implications for web application security.

There is an interesting link on Darkreading talking about Jeremiah Grossman’s upcoming talk at Blackhat. It looks like he is spilling a little bit of the beans so that people understand what the talk is about and why it is important to attend. So yes, this is something that I’ve been thinking about for a long time. How can you use cross site scripting to attack networked devices, instead of just attacking a stand alone user. Well, after he and I discussed it, he went off and built a working prototype off of the original idea.

The original idea was simply to brute force a password on a firewall or routing device that used a web based administration interface. The problem is that a huge percentage of those use basic type authentication, rather than a web form. Modern browsers all pop up a dialogue, and to my knowledge there is no way to suppress that (if anyone knows of a way I’d be very interested to hear it). Jeremiah took that idea and ran with it, attacking all sorts of other network appliances. I’ll abstain from going into more details until after his talk is over because I think it’s better to see it than have me explain it. But I would recommend you be there if you are at all interested in intranet security.

Insulong SEOPH published a follow on comic having to do with that SEO content thief a few weeks back. This time I apparently am getting him arrested for child pornography (something fairly easy to do, by the way - using XSS via browser caching no less). Also, I should probably comment on the last post as well, yes, I can turn people’s power off. That would have been a terrible idea though, as he already knew who I was. Federal time just isn’t worth it - I’d rather mess with him for a laugh to be honest. Anyway, enjoy:

Click here to enlarge

I just got wind of Mozilla’s next beta release of Firefox.  Firefox 2.0 will include, among other things an anti-phishing filter.  All I can say is bravo!  I have been talking about this with Rafael Ebron for almost two years now - since the very first time he walked into my office.  I can’t say what the impetus was for finally making the decision, but without actually getting confirmation, I think the fact that IE7.0 has an anti-phishing filter built into it (using among other things a feed from Mark Monitor), as well as Netscape’s built in tool (using a feed from the Phish Report Network - owned by WholeSecurity which is now owned by Symantec).

Some of the details of Firefox’s anti-phishing technology are found here, here and here for those who are curious.  I have not yet tried it out, but I’m eager to.  Ultimately, this will be a pretty massive blow to phishing, in my mind and it’s been long needed.  These companies who are getting phished have really no recourse.  They are the victims and they really have no way to fix the problem.  Education hasn’t worked, building toolbars hasn’t worked.  So what’s left?  The internet has to protect itself.  Content filters, email filters (like Thunderbird’s anti-phishing technology), and browser filters are going to provide a massive blow to email and HTTP based phishing vectors.  Of course, like anything, the attacks will evolve and move and probably evade all of this detection, but at least for a while it will really force the phishers to re-think their tactics.

I, for one, am really excited to see all this work finally coming to a head.  I think the next hurdle is getting a single repository set up for all of this phishing activity.  The anti-phishing work group has gotten really far with this, but we’ll have to see how Microsoft’s decision to use Mark Monitor might change that - while Netscape is using Cyota (a competitive take-down service).  It might not be perfect, but I think it has come a long way.

Quadszilla just sent me a link to a recent alledged unathorized hack into a medical college database by what is believed to be a salesman of all things.  He is a salesman for medical databases.  No doubt he was going to take the information he recieved and attempt to market to those people who were either near graduation or post graduates.

This is one of those weird things where blackhat hacking is getting to be far more mainstream.  Even sales guys can hack into a database.  And if he hadn’t gotten caught, it is very likely that this would have been a very profitable attack.  I remember at one point in my college career someone sold the school password file to spammers.  That was also pretty successful as there were far less people on the internet at that point, so email addresses were more scarce.

Thankfully the database in question in this particular hack was not a patient resource (and therefor not under HIPAA regulation), but the obvious damage that could be caused by something like this makes me shudder a little bit.  College servers hold a great deal of sensitive information.  Thankfully, normally they are fairly difficult to break into, as the colleges themselves have to protect against users who would attempt to break in and steal information or change grades, etc.