This isn’t truly a new referral spam tactic, but it it’s probably not well known, especially amongst people who don’t run their own websites. I got an email from someone who thought that somehow some porn site had inadvertently linked to them and started to send them tons of traffic. In fact it was quite a few sites that they had thought were sending them traffic. He thought someone had mis-configured something and it was working to his advantage. As a result he put up a link back to their sites, thinking he could get more traffic. It turns out he was playing completely into their hands. He had been social engineered.

The URLs are pretty sneaky: http://search.msn.com/results.aspx?srch=105&FORM=AS5&q=pr0nsitename (obviously the string itself has been changed). So I searched for pr0nsitename and found that dozens of hits were coming in from msn and live.com. Each one of them were cloaking and sending indexing themselves really high. When you actually went to that msn or live.com page you can see the URL linking back to me (something like this): www.pr0nsite.com/cgi-bin/blah.cgi?cmd=out&url=http://sla.ckers.org/forum/somepage.php Upon inspection you can see it’s a simple rediction to detect that I, in fact, started sending them traffic if I post a link pointing to them.

After some more digging I found that if you take any one of the IPs you can find that it comes from more than one different porn search. Hmm… what are the chances that a single IP address found it’s way to my site through two completely different redirects from porn sites? Uhm… I’ll give you a hint, it’s zero. The point is you cannot trust referring URLs. I barely look at them anymore, except to diagnose issues. You should not trust referring URLs from porn sites, you should definitely not click on them and you should absolutely definitely not post them on your site thinking you’ll get more traffic from it. It turns out that every single hit that both he and I got from this particular porn site was robotic. Yup, that’s bad.

Hong has been coming up with some really interesting research, including something he found where you can use HTML entities inside event handlers to jump outside of certain types of encapsulation to use a cross site scripting attack. He even has a demo page set up here. Nasty, but how common is this? Well using event handlers (onmouseover, onload, onunload, etc…) are pretty common, but how many people actually use it, that’s the question. Well it turns out at least one company is - Yahoo.

Hong found that you can use this technique to exploit Yahoo Mail. It does require user interaction (as do many event handlers) but in this case, it’s using the next and previous buttons, which is pretty commonly used by the consumer. So while extremely obscure it could be pretty effective in many cases where users thought they were stuck in encapsulation. Very nice work Hong!

Fayte sent me this Bindshell link today that discusses a way to bypass port blocking in Firefox, Opera and Konqueror. The obvious implications for this attack are to circumvent the restrictions built into Firefox in particular. This restriction makes it hard to do things like attack non HTTP ports due to a restriction build into default versions of Firefox. That really does put a crimp into port scanning, but this is a clever way to circumvent it using a malicious FTP server.

The basic concept is if you send a header like so: 227 Entering Passive Mode (192,168,0,1,84,149) your browser will be redirected if it supports the PASV command (which Firefox, Opera and Konqueror do). Very clever implementation and nice work from Mark at Bindshell!

I just had a really interesting lunch meeting that lasted the better part of the day with Samy Kamkar and Matt Austin. If you aren’t familiar with the name Samy you should probably go read his story on releasing the most successfully virulent worm in the history of the Internet to date. Anyway, I met them and I got the whole story. Some of it is still a tad confidential, but most of it he authorized me to talk about. So here’s the whole story that he was willing to share.

He started off by explaining that he absolutely did not mean to write a worm of any sort. He actually wanted to do something very simple. He just wanted to change his relationship status on his MySpace page to say “In a hot relationship” instead of “In a relationship” as a joke for his girlfriend (which incidentally reminds me a lot of how I hacked my girlfriend). The very first comment out of my mouth was why he didn’t just use a div overlay with absolute positioning and he said only that he didn’t want to bother with pixel shifting and cross browser support. That seemed like more effort than it’s worth, so he tried to find some JavaScript injection to do the job. After toying around he figured out that you could do the expression exploit by breaking it up with newlines.

As a side note, he did NOT use my XSS Cheat Sheet to perform this part of the attack, despite my being convinced that he had (sorry if I mislead anyone on this matter, but I wanted to set the record straight). He said he actually wrote a similar program to my fuzzer on his own and came up with it by himself - if it wasn’t already clear, he is a very smart guy. Sorry, anyway, back to the meat of the story.

So he modified the code, to simply to get his friends to add comments on his behalf. That was funny. Later he revised it to attempt to do POST requests to add himself as their hero. That too was funny and you can read his site for the detail on how the code actually worked for that part and how he had to deal with the cross domain policy issues by forcing a redirection to another cname on MySpace. Samy is a funny guy. Samy doesn’t think this is wrong, because these are only his friends.

Then Samy writes the full worm, which actually takes some work to reduce it to the right size that can fit in the space he is alloted. He goes to bed thinking it might work with one or two people. He knew it was exponential but he was thinking more like 2 people this month 4 people the month after and so on. I encourage you to re-read the saga he wrote on his page at this point as far as the time lines. He did inform the admins anonymously what was going on and told them a shortcut to fixing the issue in an attempt to stop the monster he had inadvertantly created.

It took MySpace over 20 hours to fix it after he disclosed it to them and the worm managed to infect more than one million users. He smiled and sat back in his chair at this point while telling me the story, and said that he was impressed at the notoriety he got as a result of it. I had to remind him that he had single handedly written the largest worm in the history of the Internet - by a factor of 10. He laughed. Then I also reminded him that it was the single best example of an XMLHTTPRequest based worm out there. He smiled and nodded. Samy is clearly amused.

This, however, is when things started going bad for Samy. After over one million infections MySpace was taken off-line. The DA’s office got involved. Although MySpace was only tangentially interested in nailing Samy (for publicity’s sake from what he can tell) the DA’s office was far more interested (for their own publicity). At some point they actually began to follow him - for what they told him was about a two week period of time - before finally serving a warrant. The only amusing part of that story was that they had to tail his every move to watch his behavior. I guess it was a pain for them because he worked a lot of hours at that point and they were having to shadow him until late into the evening. Samy smirked at this - at least it hadn’t been all fun and games for them to screw with him.

They took all of his computers from his home and from his office (30 people in all, spread evenly across the two raids) and managed to scare the wits out of his girlfriend and his room mate. The prosecutor even said at one point that he had seen murder trials that had been handled less formally. How did they catch him? Instead of looking at his own profile (that had his home address on it) they tracked him down through a partial photograph of a license plate in a photo. Not exactly your high tech sleuths working on that case, I’d say.

Samy eventually plead to a minor sentence, including some monetary restitution and one year’s probation where he can only use supervised computers for work. Samy openly said, although it was great press and a lot of amusing things happened during the last two years since the code was released, it was clear he never meant to do anything like what had happened, and certainly would advise anyone against doing something similar in the future. We also did talk about where he went wrong in the command and control infrastructure, where he could have used his own account as the single point for command and control or other similar ideas. Samy admitted that there was probably a lot of things he could have done different, not the least of which would have been not having released it in the first place.

So what was my take-away? I really don’t believe Samy had any criminally malicious intent. He’s a laid back guy, who is way too smart for his own good, who thought he might have a little fun with his friends. It was far more of a practical joke than anything malicious in his eyes, it’s clear to me now. In the aftermath, he and Matt are a couple of great guys to grab beers with, both of whom I’ll definitely keep in touch with, and if all goes well I think there may be some interesting stuff in the future there as there is a lot of ideas pent up in that brain of his and while he can’t use a computer, there’s a lot left to talk about. I’ll keep you all posted.

This sounds a lot sexier than it actually is, although it was interesting to find that only Firefox was vulnerable to this (tried IE and Opera with no results). However, if you perform a timed redirection from within the HTTP headers and instead of redirecting to a URL you redirect to a JavaScript function you can execute JavaScript. The only upside to this technique is if you must do response splitting and you are limited in what you can do, or if you want to obfuscate where and how the JavaScript is firing that performs the malicious activity.

Click here for an example (only works in Firefox). Like I said, this isn’t that particularly interesting, but it could be somewhat useful in some obscure circumstances. Nothing to see here, move along….

In yet another article that discusses Firefox’s password manager flaw, it appears that only a handful of variants of this bug are fixed, leaving a majority unfixed. That’s bad news for something we sort of thought was a done issue. I supposed it was possible this wasn’t fixed, but never bothered to look into it - it just goes to show that we need to keep pounding on these things until we can no longer find any way around the fixes.

As a side note, Robert Chapin is credited for the original vulnerability in this article, even though he was not the first person to think of it or even exploit it. Although I don’t get much credit for this one Secunia, at least, did update their advisory to at least point to my original post about this, although they still say the original advisory (months later) was found by Robert Chapin. Worse yet, that stupid RCSR (Reverse Cross Site Request) acronym lives on! Why wont it just die? It’s called XSS folks! I am doomed to disclosure obscurity on this one.

Update: Please read the comment by Gavin for more details about this. Apparently Robert Chapin’s analysis could be innacurate or at the very least mis-representing the issue. Thanks for the clarification, Gavin!

HD Moore claims to have broken Tor’s privacy model using a series of known tools. Basically he claims to be able to “poison” the exit nodes to have them send more information back to him than is safe - thereby de-anonymizing users. If you don’t know who HD Moore is, he’s the founder of the Metasploit project and he was the mastermind behind the month of browser bugs so I doubt this is a joke. The toolset is called Torment, and it uses a large number of known issues in Tor and does require that the user “performs some risky actions” like running JavaScript.

Anyone who has been reading this site for a while can probably tell where this is going. Not that I’ll claim to know exactly what he’s got up his sleeve, but we all know how difficult it is for any proxy to stop leaking information once the browser’s DOM gets involved. There are so many ways to fingerprint users, it’s ridiculous. So while this won’t actually help you stop bad guys from performing actions it will allow you to detect who they are - or so the article hints. I’ll be very interested to hear the details once it comes out.

I saw this today and I had to laugh - where people thought this was all theoretical, we now have proof that attackers are actually using Anti-DNS pinning. .::t3rmin4t0r::. (a Yahoo! employee his website proclaims) actually used this attack successfully to own a router of the victim. More importantly he actually goes into some pretty good detail about how he actually performed the attack itself (which webserver, how he logged the victim, how he performed the XMLHTTPRequest, etc…).

Just because it’s not obvious doesn’t mean attackers don’t use it. It may not be prevalent, but if people are starting to use it, it will only be a matter of time before any local webservers or intranet webservers are attacked using this method. Anyway, it’s a very good writeup by .::t3rmin4t0r::. if you aren’t already familiar with the nuances of anti-DNS pinning, which I’m told most people aren’t.

And by the way, if things aren’t clear the only way I know that is if someone says, “wtf are you talking about RSnake?” If you guys want to know more about something about whatever it is I’m talking about, please let me know, because otherwise I sort of assume everyone pretty much gets it.

I’ve been meaning to do this for a lonnnng time, but I finally got around to building a map of vulnerable charsets (that I know of). This is nowhere near complete, and lots of this has yet to be tested but what I have mapped out I do know to have at least one vulnerability (variable width encoding, or some other selected encoding attack against normal anti-XSS filters). Click here for the list. I must stress that not nearly enough work has been done in this area.

From the results I’ve found thus far (and again, lots more to do) it appears that Opera is the least vulnerable, Firefox second, and IE7.0 coming in a distant third. Just because something isn’t marked doesn’t mean it’s secure, I just haven’t found anything that immediately worked. I welcome other people to help out on anything else I’ve missed because I know there’s more out there. Every time I look at this I find more. Anyway, I wanted to share it with everyone, let me know what you think.

I know most of you haven’t seen it (I probably wouldn’t have either unless a few separate people had emailed it to me) but Riva Richmond interviewed me for the Wall Street Journal about the Google Desktop hack and the few issues found in Yahoo over the last few weeks. The article was pretty critical of Google’s take on security, which doesn’t surprise me too much given Google’s troubling past with security and privacy issues (it’s tough being an advertising company). However one quote from the article really struck me like a ton of bricks (Douglas Merrill is the CIO of Google):

Regarding security-flaw disclosure, Mr. Merrill says Google hasn’t provided much because consumers, its primary users to date, often aren’t tech-savvy enough to understand security bulletins and find them “distracting and confusing.” Also, because fixes Google makes on its servers are invisible to the user, notification hasn’t seemed necessary, he says.

I don’t know about you but the words “security flaw in Google Desktop” are pretty understandable by anyone I’ve ever met. Sure they don’t know or even care about the specifics of anything we work on, but I think they have a right to know when they are using an insecure platform. Consumers need to be armed with the information so they can make decisions, not so that Google can make another billion. Google feels otherwise (is that any surprise)? More than that, they feel consumers are incapable of understanding. That may be true regarding the nuances, but if they knew all their email was at risk (even at slight risk) they would feel differently about installing Google products. But I dare say that Google employees would have a tough time explaining what anti-anti-anti DNS Pinning is. Does that mean I shouldn’t tell them since they would find it confusing and distracting? That’s just ridiculous!

I had drinks with a newbie webappsec guy in the area last night and I told him how the Google Desktop exploit works. He’s pretty new to webappsec, so he wasn’t aware of how lots of the exploits out there worked. After ten minutes he was worried enough that he too said he would be uninstalling Google Desktop when he got home. Like it or not, he was a consumer. He was uninformed before I met him and after I met him he made an informed decision (I even warned him about how incredibly rare this type of attack is). When consumers are armed they can make informed decisions, even if that is against Google’s business model. Do no evil, Google. Follow your own mantra, Mr. Merrill!