Paid Advertising
web application security lab

Archive for May, 2007

Style Injection Phishing

Saturday, May 5th, 2007

This is certainly not new, but I happened across an interesting link to a bunch of phishing sites built into MySpace. Instead of being a normal phishing site that rely on JavaScript injection or email, the MySpace phishing sites rely only on injecting a form that overlays over the page itself. The URL to find these is a simple Google dork.

At the time of writing there were 56 phishing sites on MySpace. Obviously not huge as a percentage, but it’s scary that there are any at all. It’s unclear what they want to do with these urls, however, I spent a few minutes mapping out the URLs used by the phishers:

  • 5 x hur.be
  • 4 x willgle.com
  • 2 x r3voluti0n.com
  • 1 x m3rm.org
  • 1 x spaceadder.info
  • 1 x coolton.dajoob.com
  • 1 x www.profilespider.com
  • 1 x www.itfailz.net
  • 1 x artexstudios.com
  • 1 x members.lycos.co.uk
  • 1 x login-myspace.logindotspace.com
  • 1 x www.googleidols.com

So only 20 were working/alive as I checked. I was able to find one example of the PHP script used (almost all of them were written in PHP). This one was simply wildly mis-configured. A number of them appeared to be old and were hobbled by MySpace who changed the URL to a “..” which had the effect of breaking the script, but the pages were still messed up (as if MySpace pages aren’t already messed up enough to begin with). Pretty ugly.

Where is/was RSnake?

Saturday, May 5th, 2007

This is a non-technical post, just to let everyone know what’s going on. It’s been a crazy last few weeks and it only gets more crazy. After moving to Texas, I’ve been working really hard on a client of ours, getting our office set up, and learning my way around. It’s been a lot of fun but a lot of hard work. But over the next week it’s going to get more interesting.

Next week I am going to be doing a lot of talks. Firstly I’m doing three talks (two short ones for executives and one long one for the developers) at Microsoft’s Bluehat conference. I’m doing a talk on Death by 1000 cuts (well, not entirely, but similar concept - on how small holes become a big deal). Here’s the overview:

Web application security is the new security frontier. Firewalls, IDSs, and IPSs have become all but commodities. Today’s threats completely circumvent the whole concept of network security, attacking websites, web browsers and the victim’s themselves. Many modern threats don’t damage websites at all, but they can have drastically bad effects on users and corporate perception. Phishing, cross-site scripting, cross site request forgeries and dozens of technologies tied together greatly increase the threat landscape. This talk will do a deep dive into the technical aspects of the threat, while keeping a steady eye on the consumer issues that drive large-scale website design.

That’ll be fun, and I’m sure I’ll have a lot more stories once I get back. After that I’ll be doing a very short talk at Toorcon’s Seattle Beta conference. It’s an invite-only conference with 150 people or so (not on their website). Here’s the overview on my “Master Recon Tool” talk:

A 5 minute power presentation that just discusses a new tool that helps combine many known browser based information disclosure issues into one (hence the word “Master”). It also turns into a cool acronym when you spell it out. MR-T (Mr. T - as in, “I pity the foo who uses JavaScript”). When combined they can tell a lot about the target, or multiple targets who visit the website under an attacker’s control. Since we know 80% of websites are XSS-able, 99% of users use JavaScript and 100% of web users use more than one website it provides a good framework for knowing more about your or other people’s web users.

So if anyone is going to be at either of those, drop me a line if you want to meet up at some point. So if I don’t do a lot of posting over the next week that’s what’s going on.

OpS Opera Weirdness

Thursday, May 3rd, 2007

I got an interesting email from an anonymous lurker who works for a big company dealing with XSS. He started seeing some weird stuff in his logs - specifically in the cookies. In looking into it he found the problem.

After changing filtering rules to catch some specific type of XSS attack, I started getting strange results in the logs. Some users had a cookie filled with many words concatenated together. Suddenly, I realized some of them were actually logins and passwords. What the hell - do we set cookies with passwords?!

Quick check in the documentation - no, there is no such cookie. Grepping the code - still nothing. So, it’s not our cookie. I started digging deeper in the subject, and found out:
http://userjs.org/scripts/browser/enhancements/ops It’s an auto-completion script for Opera, storing the data inside cookies. In current Opera version it does not store values from password inputs, but clearly in older it does, causing the browser to send plain text password with each request. Yeah, Opera is the secure browser - but the users…

Indeed… this is one of those situations where you really don’t loose any major security benefits by having this, as the only way to read it is through an XSS attack, but it certainly adds weirdness that could eventually lead to insecure things. While it’s not directly exploitable, now your usernames and passwords are on your drive in cookie form. Anyone with notepad can go and retrieve them. That may not be a problem for most people, but some people don’t trust their spouses, kid brothers or creepy uncles. This is just another situation where the security model is changed by people who aren’t directly responsible for the browser.

Potential Use For the Java XST

Tuesday, May 1st, 2007

Jeremiah and I were talking about more potential uses for the XST stuff he came up with. Although it’s not particularly useful for the original purpose he came up with it for (due to the fact that it is using Java and Java doesn’t send the cookies necessary for real credential theft) it does have one other interesting potential use. Because it connects out of bounds of the client (and pretty much ignores the client in general) it’s a pretty slick way to de-anonymize users.

Although it doesn’t use the browser’s normal credentials it does bypass proxies pretty nicely. So unless the client is set up to send all TCP packets through another host, this would do a nice job of allowing the website to know the real address of the user. I will say, however, that due to it’s buggy nature and the fact it basically causes my browser to hang, it may not be optimal, but rarely things are with these sorts of hacks. Interesting anyway!