Rajesh Sethumadhavan just sent me an interesting one. It looks like Google’s version of social networking, Orkut, discloses email address information for friends, regardless if they are friends or not. Looks like a pretty quick way to buy yourself a massive spam list. Here is his advisory:

Overview:
Orkut is an Internet social network service run by Google and named after its creator, Orkut Büyükkökten. It claims to be designed to help users meet new friends and maintain existing relationships with pictures and messages, and establish new ones by reaching out to people you’ve never met before.

Orkut service is vulnerable to email address disclosure vulnerabilities. Due to this It is possible to get email address of any users in orkut. This is caused due to improper designing of orkut portal.

Description:
A remote attacker can get the email address of anyone in the orkut as demonstrated below. The victim interaction is not required at all.

Demonstration:
Note: Demonstration leads to email address information disclosure
- Login to your orkut account
- Add any user as your friend (Person you want to get email address)
- Click ‘friends’ tab
- Click ‘open friend requests’ tab
- Click edit button the email address of the user will be displayed
as in the screenshot
Same way your can find your friends email address also

That’s a pretty nasty information disclosure issue and brings home what I was talking about before about companies using email addresses as half factor authentication, and since that may not be as secure as some people think it is, disclosing usernames in combination with email addresses can be part of the fatal flaw. It’s not the information in particular that’s valuable (other than for spam or phishing email lists) it’s how that information is used in combination.

In case you hadn’t heard MySpace has been hit by a number of worms recently. The most recent two have used the QuickTime Vulnerability that pdp found that allows users to back door the movie file with XSS. Billy Hoffman from SPI Dynamics has a good writeup on the worm and how it functions as first described by Websense here. Billy also included along with it the source code to the worm.

His writeup is pretty accurate. I’d only make one more comment. One of the major issues with these types of worms is that they cannot move with the victim. That’s not entirely true with things like the data: directive, but for the most part, moving the file from page to page is not possible, requiring that the attacker stores it on a remote server. Finding and killing those servers is significantly easier than something that has no centralized command and control structure (which also makes it way harder to stop if you are a bad-guy).

Understanding command and control structure is pretty critical to understanding how these worms propagate. Good writeup and I’m glad people are paying attention to this, as it’s nasty. Too bad MySpace has so many issues, but it looks like at least QuickTime has taken notice of these issues.

I ran into some bizarre issues a while ago that I couldn’t replicate and I couldn’t log because of the issue itself - which is that I couldn’t properly cut and paste the information out of a textarea. This evening I finally had a chance to run ethereal and dump the packets and after quite a bit of testing I found the real problem. STX control characters (0×02) cause some pretty random issues within Firefox both with cutting and pasting as well as viewing source. STX stands for start of text. Click here for the ASCII chart

After about 5 minutes messing around with bvi I was able to come up with a working example. Click here in Firefox to see the STX control character issue. Then try to cut and paste from the text area. Then view source. Then try to select all the text within the source. Not looking so good is it? It really feels like there may be more here, but without more tests it would be hard to isolate the problem.

I’m actually surprised I’ve never noticed this before during my tests with my fuzzer. Click here to find out more about control characters. Anyway, like I said, it’s weirdness. I’m not sure what other implications it may have but I’m eager to hear other people’s opinions.

This may seem very trivial but for some reason I think there is more here. In some tests I did this morning I realized that IE doesn’t handle URL encoded strings very well if they aren’t encoded properly. A normal URL encoding for a quote (") might look like %22. If you substitute the numbers with non-numbers IE freaks out and doesn’t even attempt to load the page in question.

Instead it responds with an error message saying something like “Windows cannot find ‘http://ha.ckers.org/%--’. Please check the spelling and try again.” Okay, error messages are interesting but noisy. How can we suppress them? We’ll get to that in a sec. Before we get there, let’s create a URL to a valid image on my server: http://ha.ckers.org/%--/../images/kcpimp.jpg and throw that into IE’s URI field. Weird, it works, even though it doesn’t work if you use the smaller string: http://ha.ckers.org/%--

Okay, but let’s try throwing that string into an image tag: <IMG SRC="http://ha.ckers.org/%--/../images/kcpimp.jpg">

Hmm… it doesn’t render, and doesn’t pop up an alert. Let’s check burp proxy. Nope, nothing there either. IE isn’t even trying to pull the image down. Firefox and Opera do though. Looks like we’ve found a fingerprint. IE won’t try to pull an image URL that is malformed, allowing us to detect if the user is spoofing IE or not in their User-Agent (and all without using JavaScript). Voila. Fingerprinting without the use of JavaScript is an interesting concept when you are trying to keep the Internet noise level to a minimum.

Whelp, V-Wall is at it again - finding more XSS vulnerabilities in MySpace. This is a pretty interesting one, because I think it proves a few points that are worth discussing. First of all, let’s just show the exploits in action:

* Photo of v-wall entering the primary vector.

* Photo of v-wall viewing source and seeing that MySpace has modified the vector.

* Photo of v-wall using the vector as modified.

So here’s the deal. MySpace sees his vector which is onload\_= which uses the non-alpha-non-digit XSS vector. That works in FireFox. Now, MySpace decides to modify the forward slash and turn it into “..” which they think will break his vector. Oh contrare! It then looks like onload.._= which doesn’t change the vector one bit!

Lessons learned? 1) Don’t modify vectors if you don’t know what you’re doing. 2) Make certain you have checked all vectors with your conversion filters and 3) Don’t accept HTML, duh!. Well that last one is mine, but really, if you can help it, don’t allow users to enter stuff that can execute code. This would allow MySpace to be vulnerable to another worm, account take-overs or worse. Ouch. Thanks to V-Wall for the info!

I’m actually impressed. I hadn’t had an opportunity to look at Microsoft’s Anti-Cross Site Scripting library (version 1.5) until today. It’s pretty cool. To save anyone time in looking at this it takes anything outside of the normal A-Za-z0-9 ASCII range and changes it into it’s HEX HTML equivalents in an HTML environment and a \x00 type JavaScript encoding for the JavaScript environments. It looks pretty bullet proof because they encode everything that could feasibly be used for malicious activities.

Although I’m pretty impressed by the variety of tests that this succeeds in stopping, I’m still not certain that this is the right place to be fixing this particular issue. To me this has always felt like a browser issue more than an application issue to solve, because there are lots of different ways to execute this type of issue, beyond server side code that a developer produces, including web server vulnerabilities and DOM based XSS, et al.

Anyway, it’s still cool. Big thanks to Kyran for letting me have access to test this in a real world environment.

Romain Gaucher published a pretty interesting tool this weekend called Grabber. Grabber is a tool written in Python (also has a .exe version) to do some of the attack vectors written on the XSS Cheat Sheet amongst others. I’m really excited to see this sort of development.

You know what I’d really like though? I’ve been dying to get my hands on something like Burp-proxy (preferably tied into it?) that allows me to auto-inject vectors based on a series of regex’s. Also the ability to automatically perform a number of the obfuscation functions programmatically - like automatically transform HTML into UTF-7, etc… I know the FishNetSecurity folks were working on something like this (and holy crap was it cool) but I really think it needs to be built into a proxy to be really effective for manual testing.

Anyway, cool stuff, and I hope to see more tools being produced to do this type of testing. The more we can automate this stuff the faster and more accurate it will get to do manual testing.

Billy Hoffman sent a link to the WASC list pointing to a link on the Spywareguide discussing a new Quicktime XSS worm that hit MySpace. I have a feeling there are more to come but this is pretty bad.

The basic premise is that a porn site was set up with links to movies with pdp’s Quicktime backdoor in them. When people get infected it changes their MySpace pages to include the movie and so it propagates. Nasty. As I said, I think there are more of these things to come.

Sorry I was MIA the last few days. Lots of stuff going on. It’s too long of a story to write into the blog post but I was visiting a friend and also doing some light business. While I was gone it looks like there was a bevy of posts about various technologies that help enable some of the port scanning issues that Jeremiah and I were facing when we first started working on the original JavaScript port scanner. Where to start?

Stefan Esser posted two blog posts the other day that are worth mentioning. The first was a way to portscan by injecting an arbitrary percent tag to avoid the 401 Basic Auth popup. That might not seem like a big deal but when the victim sees a popup they are a whole lot more likely to know their browser is doing something weird.

The second post was another way to bypass the 401 basic auth dialog but this time he actually shows how to brute force it without causing the popup in Firefox. This is way more powerful than the former technique because it allows you to actually try multiple usernames and passwords against the victim host using favicons (the little black box in the URL field that says “RS” on this very site is an example of one).

Lastly, Jeremiah mentioned something I came up with nearly a year ago On a way to bypass Firefox’s port restrictions on Windows using alternate protocols (namely ftp: instead of http:). “Anonymous” had a snarky comment on Jeremiah’s blog post about me not coming up with this first, and that it rather was probably thought of first by the person who built it, but I seriously doubt they had JavaScript port scanning in mind when they built it. Oh well, you can’t please every Anonymous poster out there. Jeremiah has been on a bit of a binge publishing some of his older previously unpublished hacks. I can’t to see what else he’s got up his sleeves.

So wow, a lot of good stuff coming out this week. I’m glad people are starting to think about this again. I can’t wait to see what happens next.