Aaron Weaver has taken the concept of Inter protocol XSS hacking to the next annoying level. That’s right folks, he has figured out that you can do cross site printing. That is, when you visit a malicious website, it can attempt to connect to and send data to your printer on your local network. The obvious use? You got it, spam!

So now, when you visit sites, there is a potential for them to spam you, similar to the way some people receive FAX spam. While he has only gone so far as to show how you can send ASCII art, it would be interesting to see if a PostScript formatted file could be sent in a way that the printer would understand and print. For the time being, however, we are limited to low def ASCII art spam.

However, there are some fairly complicated programs that do analysis on and generate ASCII art from photos. What will be more nasty is once this turns into actual exploits against the printers themselves - as many printers contain copies of printed materials for weeks or years afterwards. Also, depending on what the spammers put on your printer, it’s possible this could get people fired, depending on the content of the print job (no pun intended). Very interesting research by Aaron Weaver!

If you remember last year, Jeremiah, Zeno and I threw together the list for the top web hacks for 2006. It was a glorious age, where I had lots more spare time on my hands than I do now. Alas… Anyhow, instead of us giving our opinions to you, we felt it was far better for you to give your opinions to us. So Jeremiah threw up an abbreviated list of potential candidates for 2007.

Jeremiah will cull them all together and then we’ll put it to a vote. This doesn’t include hacks against websites, but rather new techniques that further the webappsec field. Anyway, it should be fun to see the results! No hacking the polling booth now, kids!

This actually comes a few months late, but I’ve read enough about it that I think it’s worth talking about. There’s an article on the Silicon Insider talking about the newest integration between Facebook and Blockbuster, Fandago and others. Had I not already heard all the details and fallout I probably would have said, “Sounds like a complicated threat model. I hope someone did their homework.” Alas, they did not.

What’s fallen out from this is a privacy issue that’s complex and fascinating. Firstly, the title of the Silicon Insider article is pretty telling, “Do You Want Your Grandmother to Know You Bought Porn? Well Learn to Opt Out” Facebook has taken an interesting stance towards your privacy. You can opt out of them giving it to people you are friends with. The opt out process is in question as is the concept in general. One of the best examples of why this was a problem I’ve heard is that it ruined people’s x-mas presents, because it was displayed on their friend’s Facebook profile.

It’s clear that this is just another way to monetize their users, and not a use feature that consumers typically feel comfortable with. Of course, if you aren’t buying anything bad, you have nothing to worry about. But even still, do you really feel comfortable with your friends knowing everything you’re buying? Do we have any privacy anymore? This is getting to be a pretty voyeuristic society - because it’s easy to monetize people’s privacy by taking it away from them.

I’m not particularly upset with Facebook, in particular - they are hardly the first company to forsake people’s private information for monetary gain. But I think this sort of behavior is only making people distrust social networking. It should be noted that some of the people who built some of the largest social networking sites in the world are also data mining experts - it’s not a leap to figure out why those two are a dangerous combination for privacy. So while I’m not upset with Facebook - you won’t find me building a profile there anytime soon.

Well, so far this week has probably been one of the most interesting I’ve had in running this site in a long time, not only from a technical perspective, but the ethical debate on whether I am sheer evil or contributing to the greater good rose it’s ugly head once again. This was in regards to the diminutive XSS worm contest. One of my favorites was where I was being compared to arming people with nuclear weapons. Clearly, and admittedly most of these people have no background in the issue and have never read this site or the rest of sla.ckers, as there is lots of samples of existing worm code in lots of places on the Internet now. Just because they don’t know about it doesn’t mean it’s not there.

The existing samples of code that we have are always plagued by three things though, which makes them difficult to work with and which I don’t care about. Each contain obfuscation for filter evasion, which we’ve already researched to death, payloads, which we have also researched heavily and lastly site specific code, which really is uninteresting to me, unless I were trying to help out that company in particular solve an existing problem. So the goal is to remove those things and focus on the actual XSS propagation, for which there has been little research done to date.

I’ve always said, you don’t understand a problem until you see it and play with it. This is why having experience is always more valuable than schooling in a topic. It’s like trying to get in a fist fight with a professional boxer having never sparred before and expecting to win. If working to help the understanding of worm propagation makes me evil, so be it. I’d rather be evil and be able to help solve problems than be good and be useless at solving the problem (as are most of the nay-sayers, I’ve found). That’s why people like Giorgio Maone (the author of the noscript plugin) chipped in to help the contest. People like him are solving the problem in their own ways as well. It’s in everyone’s best interest to understand all the vectors. Will this empower bad guys? I’d be nieve to say there’s no chance of that. However, the goal here is to understand why the propagation methods were chosen so we can build defenses against them. We actually had tons of interesting findings that will help us narrow down the most dangerous strains, and start making suggestions to browser companies and security companies that are in development of security technologies so that they can build tools to prevent this.

For people who liken me to an anti-virus company writing viruses, I’d like to point out the fact of the matter which is that I don’t get paid to consult with browser companies on browser security (at least I haven’t in the last several years that I’ve been doing this). In the spirit of full disclosure, I have gotten paid to help out with other things, but not browser security. That’s right, I give advice in the browser security arena for free (for which I have actually been chastised by other executives who feel like I’m wasting my time since I’m not making any money on it). I do it because I’m actually interested in solving the problem. To date I also have never been paid by any company who has ever been hit by an XSS worm. I have, however, on several occasions given them intel and advice, pro-bono. Also, unlike an anti-virus company, I don’t have a security product in development. So, yes, tin foil hat wearers can rest easy - this actually is academic. I know, crazy talk! That’s why this is an web app security lab. People visit this site (or should, at least) with the knowledge that we are pushing the boundaries of what’s know about web application security. We aren’t talking about yesterday’s problems. Think the bad guys are going to stop their own research if we stop talking about it? In this profit driven malicious ecosystem, there’s no chance of that anymore. At least in an open format we can come up with solutions, and see the results of each other’s work.

Another interesting point of view, by Kurt Wismer was that I was that by creating diminutive code I will always get an output of obfuscated code (which I have said a number of times I was trying to avoid) because of the coding tricks necessary to make it that small. He’s absolutely right, of course, but that’s a red herring. See, there are two types of obfuscation, which may be beyond the grasp of people who don’t actually work in this field. The first type is obfuscation to create short/lean code. The second is obfuscation for filter evasion (MD5ing something, hex encoding something, making something polymorphic, not using the word “eval” but “ev”+”al” to beat some regex or string matching, etc…). I’m sorry I didn’t clarify - that’s probably non obvious for people who don’t understand webappsec. So unfortunately, for the most part that’s actually not an interesting comment, although there are some tidbits in some of the variants of code that actually do cause some problems that I will need to disregard for the sake of research, which I’ll talk about after the contest is over.

Anyway, over the last few days I’ve been called a moron, an idiot and probably a half dozen other things. But through it all, I’m 100% confident that this will lead to previously non-published/understood results about worm propagation (I’m confident, because it’s already yielded some various interesting problems that we have had to clarify using rules that I didn’t even think would come up). And I’m also confident that this will lead to ways in which we can protect ourselves from them - not today, certainly, but over time as we as a community start building tools to prevent these issues based, in part, on the results of this contest. I wouldn’t guess that everyone reading this will “get it” as most people don’t really understand how the security world works. I would, however, hope that everyone sits tight and holds their dramatic postings for the results, or at least asks me what I think instead of jumping to wild conclusions. Christmas is already over though, and I already got my wishes granted so I won’t be surprised if it doesn’t happen.

So that’s the drama! Gotta love it, huh? Where would I be without the under-educated rants and conspiracy theories? The good news is that there is a lot of really interesting research coming out of the contest, and numbers are approaching the 150-170 byte range. We’re already seeing some trends emerge about the most size efficient ways to write the code, and the ways in which the code must work for best propagation results and portability. The two methods of actual spread that appear to be building to a consensus among the submissions are XMLHttpRequest and submit events. We’ll see how things turn out, but I’m quickly getting a feeling these are by far the two most likely candidates for worm propagation. My question is what sort of valid reasons can people come up with on why the browser should automatically submit a form without user interaction? More detailed analysis to come once we get closer to the cutoff. Amazing stuff!

Pandora is already out of the box, folks, and for good or bad Samy was the culprit, not me. Time to start working on solutions, rather than trying to keep the research quiet.

For those of you who are familiar with the RSA diminutive munitions project from ages ago, back when it was illegal to export certain crypto systems, and the diminutive PERL contests I’ve enacted a similar contest to write a diminutive self replicating XSS worm (with a non-dangerous payload).

The diminutive XSS worm replication contest is a week long contest to get some good samples of the smallest amount of code necessary for XSS worm propagation. I’m not interested in payloads for this contest, but rather, the actual methods of propagation themselves. We’ve seen the live worm code and all of it is muddied by obfuscation, individual site issues, and the payload itself. I’d rather think cleanly about the most efficient method for propagation where every character matters.

digi7al64 has already posted a sample piece of code, setting the baseline. His code is an impressively small 292 characters. There’s no prize here, however, I will definitely be talking about the winner’s code. The winner will be announced on the 10th after all submissions are in and posted. Visit the thread for more details. This should be interesting for anyone looking at worm propagation issues!

There’s an interesting site called Subvert and Profit where the owner claims to sell diggs and votes on stumbleupon for traffic generation. Selling at $1 per vote/digg the goal is to monetize that traffic through various marketing campaigns or traffic arbitraging. Pretty interesting business model, and at worst it’s against the ToS of the various companies - it’s probably not illegal in any way. Blackhat SEM at it’s finest. It’s really not much different than buying paid links on websites if you think about it.

Some of the testimonials on the Subvert and Profit blog are pretty telling, such as, “the mind-boggling barrage of traffic which comes next, is nothing less than euphoric”. I can definitely agree that the volume of traffic from digg and stumbleupon, as well as reddit dwarfs slashdotting in our experience. Traffic arbitrage is here to stay, as long as the margins stay there. Pretty interesting!

There is some interesting commentary on The Register and even better detail on Light Blue Touch Paper about a proposed ban in the UK against dissemination and the eventual use of hacking tools. So if you run a site out of the UK with worm code on your site, that can be used to commit a crime, you should pay attention to whether this law is passed or not.

I suppose it’s not dissimilar from putting a handgun in a schoolyard although it’s really hard to tell intent in either case. Often times the research done on this site and others of it’s kind are academic and are helping to solve the problems. Granted that same information can empower less scrupulous types, so that’s at least partially the intent of the law. However, I would bet money that this does little, if anything, to stop the proliferation of exploitation materials. This will no doubt simply force hackers to move their equipment offshore or go more underground - which could be bad for investigators, and for researchers alike.

I actually had to read this email several times before I got it - paranoia taking over - I thought I was being told my site was hacked. No no, just another interesting way to abuse people that people find when visiting my site. This time, this email comes from Alex who found that pre-fetching can be used to phish users in certain circumstances.

When I’m visiting http://ha.ckers.org/blog/20070608/cross-domain-basic-auth-phishing-tactics/

my Firefox showed up the HTTP-Auth dialog immediately, which I placed on my subdomain testing.bitsploit.de But why I asked myself.

I looked into your HTML source to find a hidden image or something like this, but I didn’t found anything but the link. I haven’t clicked on the link, so why does it pop up ? Than I figured out, that the FasterFox-Extension for Firefox prefetches that link and that’s why the HTTP-Auth dialog pops up.

So there’s another chance to trick FasterFox-users (in forums) without having to use HTML/BBcode for embedding images.

Alex is absolutely right. In fact, this is the exact reason I never used to use Opera (it turns out this is not the same kind of prefetching that Opera does, I only just learned). Sure you can turn it off, but pre-fetching has always been a dangerous thing to me. It can speed things up because it pre-fetches and caches the results, but if it pre-fetches and triggers something, like auto-deletion of your account, or automatically adds something to a shopping cart or anything else, you run into some pretty serious problems. Think CSRF. So yes, this apparently can also be used for phishing in FasterFox. But either way, it’s a very cool example of why pre-fetching can be nasty.

In the wake of the disclosure of Flash vulnerabilities found in thousands of websites, I felt I should probably post something about it. I have read the section of the upcoming book by Rich Cannings and Himanshu Dwivedi, and won’t disclose it, as promised to the person who sent it to me until I hear otherwise (if ever - since it’s a book and you can just buy it). Today I got an email and a call from Adobe with details that they wanted to present to people who may be concerned about it:

Adobe is developing a solution in an update to Flash Player that will prevent these attacks on existing vulnerable SWFs.

Flash Player bulletin released on 12/18 (http://www.adobe.com/support/security/bulletins/apsb07-20.html) includes a solution to a portion of these vulnerabilities and the next update in early 2008 will mitigate the remaining issues.

In the meantime, developers can mitigate cross site scripting attacks in their SWFs by coding them following guidelines for secure Flash development as described in the whitepaper at http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html, and by using data validation libraries available at http://code.google.com/p/flash-validators/.

Adobe is also applying these guidelines to SWF templates that are commonly deployed, which will be available as updates in early January, and we are working with other software vendors to update their templates.

Together, these strategies provide a complete solution to the potential vulnerabilities.

So if you have flash on your site, it is highly recommended that you take these precautionary steps to protect yourself. It’s nice to see Adobe taking this seriously and working so quickly. I certainly wasn’t expecting a phone call - way to go guys!

When I saw Mike Rothman’s name on the San Diego ISSA meeting speaker list, I tried to be the first person in the room. Yes, there were more technical talks I could have attended, but why would I want to? If you have never seen or talked to Mike, he is gruff, funny, and knowledgeable about security. I consider Mike to be a friend, so it wasn’t a surprise that he would send me an autographed copy of his self published book (which you will not find on Amazon or B&N). Trust me, that didn’t influence my opinion one way or another, but the inscription was definitely nice. What did influence my opinion of the book was that the content between it’s covers. Once I start reading it, I actually put down the other half dozen books I got until I finished every last word. Me? Finishing a book? I know, as crazy as it sounds, I managed to finish this one last night on a flight home.

Where to start? I think the thing I like about this book is that it’s attempting to be relevant, not just to today’s problems, but all future problems. It’s trying to drop the techno-babble that we all tend to get stuck on, and start talking about how to run a business - a security business no less. He takes a tongue in cheek approach to his lesson, which is that of the CSO as an addict. CSOs have a tendency to live on the edge. Closer to that of a life of a fire fighter than that of an executive. He tries to break the bad habits by discouraging the old school attitude that the security community tends to have - forgetting the modern day reality of monetary gain as a key motivator for malicious hacking.

At first I thought I’d like the book, with quotes like, “I’ve got two dogs at home. I don’t need any more friends.” Then I thought I’d hate the book when the main character, “Mike” said that his tests came back almost completely clean (because they almost never are, unless you really don’t know what you’re doing). But then, almost at the end of the book he pulled it out for me. He really ripped into why vulnerability assessments are critical to understanding your security and then the main character, “Mike” explained that he too had a laundry list of vulnerabilities. Whew! Mike Rothman gets it. One of the best quotes in the book for me was “Good Security = Compliance (but not vice versa)”. Oh, he so got me there. I fell in love with this book.

Not only did he manage to cover a very complex topic, which is that of a troubled CSO in a changing world, but he also managed to make it clear that certain types of testing were critical to business success (including application testing). He also had an interesting take on using actual exploits, and social engineering during the penetration test. He said a number of times that the people who feel that you shouldn’t use those or that it is unethical to do to your staff are wrong. No, I’m not oversimplifying his words. He says they are “wrong”. Bad guys do not follow a code of ethics and neither should anyone who wants to test their security as if they were a bad guy. Bad guys do whatever it takes to break in (understanding, of course, that your data may or may not be valuable enough to risk their freedom for).

Similarly, I loved his comments about not following best practices and not using the same thing as everyone else is. He’s hinting at some of the things I’ve discussed before regarding bio-diversity in networking and applications. It’s an interesting topic to see in a book like this, but I’m glad to see it in there.

Throughout the book Mike puts in statements like, “use common sense”, which I often think are missing from books like this. He’s absolutely right, of course. I think that thread echos throughout his book. It’s not a technical book, it’s a book on changing your thinking to get you ahead of the assailant, in the good graces of your executive staff and into auditory compliance. I’ve run into countless people in the industry who desperately need to read this book so that they too can get a clue. It’s not rocket science. It’s the art of running security like a business. Five stars, Mike!