While playing with a redirection issue on a pretty major website I found a pretty weird HTTP response splitting issue, where forward slashes were not allowed (or rather, once you entered a forward slash it caused the whole redirection to be removed). Clearly the website was trying to protect itself from something, although I’m not exactly sure how or why. Here’s what I ended up doing.

Normally it would just do something like Location: http://somesite.com/ where whatever you typed in the URL field would end up in the Location header. Pretty typical response splitting I’d think, except I can’t inject a slash, so ending HTML tags are out (shouldn’t be a problem) but now I can’t get it from plaintext format into HTML making any HTML injection pointless.

So I ended up shortening the response splitting by instead of typing in Content-Type: text/html I just put in Content-Type: html (I removed “text/” which isn’t important to the attack. So it ended up looking like:

%0AContent-Type:html%0A%0A%3Cbody%20onload=alert(%22XSS%22)%3E

I can’t help but think there are nearly as many variants of response splitting as there are traditional XSS attacks. Just another reason not to have open redirection on your site.

I spent a little time this weekend playing with my XSS fuzzer, which I am trying to get to a point where I can release it, for other researchers to play with. In doing some preliminary testing I’ve found a number of issues worth mentioning to anyone doing this form of research. Cheng Pang Su and I have been working on some of the more advanced variable width encoding, and I’ll release more on that later, as I’ve found a number of additional issues. In doing that, I have expanded the fuzzer to look at additional character encoding methods, which is how I began finding these.

In the mean time I thought I’d release some additional research I’ve been doing around injecting characters into HTML tags to see their outcome in various encoding methods. Here is the string I started with:

<[CHAR]IMG SRC="" onerror='XSS_ME(CHAR)'>

Where [CHAR] is the actual character, and CHAR is the numerical representation of that character and XSS_ME is a function to log the character. Anyway, after removing false positives (60 = <) I came up with this list in the various encoding methods I am testing in Internet Explorer:

US-ASCII: 0, 128, 188, 1788, 1852, 1916, 1980, 2044, 2108, 2172, 2236, 2300, 2364, 2428, 2492, 2556, 2620, 2684, 2748, 2812, 2876, 2940, 3004, 3068, 3132, 3196, 3260, 3324, 3388, 3452, 3516, 3580, 3644, 3708, 3772, 3836, 3840, 8124, 12220, 16316, 20412, 24508, 28604, 32700, 36796, 40892, 44988, 49084, 53180, 57276, 61372, 65468

EUC-JP: 0, 142

The 0 char (null) is not particuarly interesting, as it’s been known for a while (as documented on the XSS Cheat Sheet). The others however, I’ve never seen documented properly. These wide chars are not straight forward to inject as are any below 255, but it’s still possible (especially if it’s stored verses reflected).

Lots more to come, but I wanted to give you all something so you could see what I was up to. In the mean-time it might be interesting to start writing a scanner to get the various encoding methods of different websites to see how statistically interesting these methods are. From one scan I’ve seen it was less than 1% use US-ASCII, but as far as EUC-JP it would require scanning Japanese domains to get a better understanding of the possibilities of these attack vectors.

While looking at Jaimie Sirovich’s site, I “found” an interesting link to an XSS vulnerability scanner he’s building. I don’t think it’s public yet, and I don’t know exactly how it works but it appears to only work in Internet Explorer at the moment and only checks form submissions as possible injection points. Still, pretty interesting. For instance, if you input:

http://www.internic.net/whois.html

You end up seeing, “UH OH; pontentially viable injection on: http://www.internic.net/whois.html; form 1″ pointing to the actual injection point. Pretty cool! It’s probably a hell of a liability to have a scanner on your site, so I don’t know how long this will be there, but it’s still interesting for some lightweight pen-testing.

In all the recent waves of RSS hacks, I thought I’d toss in another. This isn’t breaking in using RSS, but it is a method to get people to add your feed automatically. Yahoo is vulnerable to cross site request forgeries (CSRF) for logged in users to automatically add your RSS feed to their page:

Here are the steps, make sure you are logged into my.yahoo.com, then go to this page to automatically add sla.ckers.org (our new forums site) to your RSS feeds in my.yahoo.com (it may take a few seconds to show up in your account).

CSRF can enable a lot of things, and combined with additional exploitation it could be really nasty. At a minimum you can get your content on their pages, which could be very interesting. This could also help build up more traffic over time in organic traffic if you happen to run a news site or something that looks like it should belong there. It’s pretty easy to detect this and stop it, but at the moment it works.

I ran into this article about Bypassing Firewall Restrictions Via SSH Tunneling which is actually pretty similar to something I wrote on tunneling Trillian Pro and then id rewrote to more broadly cover the topic. Whatever the case, this is a really invaluable technique if you aren’t already aware of it for bypassing content filters.

I’ve run into this all over the place - schools, libraries, offices, internet cafes, all of them are the same. They may have different reasons for it (protecting intellectual property or protecting kids from the evils of the Internet) but the technique is all the same. They all use content filters that rely on direct regular expressions. Regex is great for some things. For detecting abuse traveling over a network while watching only on the network? Not so much. SSH is a great way to proxy your connection through a network without being stopped. Actually in some rough initial tests, I played with some simple content filters and they couldn’t even “decrypt” rot13. Then I just got silly and started using piglatin. Anything you do will go right through, unless of course, you are trying to get to an IP address that you can’t obfuscate and they have a pattern for.

That’s when proxying your connection comes into play. Now you just load up your ssh client, connect to your external host with the web proxy server (serving only localhost traffic) and you port forward your connection and poof, you’re now bypassing anything you like. It’s really practical for when you are going out to a customer premise and you need to connect outbound but everything under the sun is blocked. Maybe even outbound port 22 is blocked, but if you put your external SSH port on port 80 you can walk right through those primitive network defenses. I mean, if content filters can’t stop pig latin, what hope do they have against AES or Triple DES?

Well, I’m somewhere hovering around a third of the way through the new version of Hacking Web Applications Exposed 2 and I ran across a section talking about how you can measure the time it takes for pages to return as a measurement of the logic overhead. Wow. I credit Arian Evans with this idea personally, but I’m not sure if the origins pre-date him. As a result of this function you can actually tell what is going on within the internal server logic.

Here’s how it works. Let’s say, to make this easy, there are two paths of logic within a sign-in application. The first path is a valid username with an invalid password and the second is an invalid username with an invalid password. Either way the application logic ends up in a sign-in failure and if the user interface designers built it correctly it gives an anonymous error state that says something like, “Either your username and/or your password is incorrect. Please try again.” That is to not tell the attacker anything about what happened if they happened to have found a valid username or not to begin their attack against.

From the outside this should provide you no information about the account from an attacker perspective but if you measure the time difference between the two application logic paths they can easily provide you with more information than they intend to. Let’s take the first path. 1) It has to make a query to the database first to insure that the user name exists. 2) Then perhaps to check if it is in a valid state. 3) Then maybe it checks to make sure that the user has not tried logging in too many times with failed attempts. 4) Then lastly it hashes the password using the same salt as the hash for the appropriate password and does a string compare. 5) After this it errors out as you would expect.

Now let’s contrast that with the second path. 1) It has to make a query to the database first to insure that the user name exists. 2) Upon finding no password, it errors out immediately.

Of course this is a simplistic example but you can plainly see that the first path is far more complex and requires more CPU cycles and database lookups than the second path, meaning that it will take far less time. With a known userid you can test the difference between that user and one that is highly statistically unlikely to exist like “189hdjhnt2h1″

Measuring the difference between the first and second paths of a single function will let you know information about the internal application logic that the presentation layer does not disclose. Pretty interesting stuff, and I hadn’t heard it anywhere else. So far, it’s a pretty good book. I can’t wait to find enough time to sit down and read the rest of it.

Well if there was ever any doubt that Google SRPs (search results page) could be gamed, the doubt should officially be gone now. Not only that, it can be gamed in order. This is a pretty hilarious link to a Google SRP showing an advertizement by a SEO company and if it goes away, here is a screenshot of Google’s SRP.

To me this is actually a little alarming, as you’d expect a search engine to be able to notice this form of blatant advertizing, but I guess the Googleplex is taking a coffee break or something. Pretty cool to see how it ranked in order like that where the cnames line up where when spelled out one by one they say, “you should switch to virante” Cute!

There’s a rather unfortunate article at webability talking about web bots and how they attack computers. The article is pretty confusing for any actual security person because what they are defining as bots are really scanners or worms. It actually gets much more unfortunate as you actually read the paper and supporting material.

If you follow the link they provide for mitigation techniques you end up on this page which is almost completely unhelpful for anyone actually looking to protect themselves from these forms of attacks. First of all it mentions SQL injection and says you need to filter out back and forward slashes and the star operator. That won’t at all protect against SQL injection and I’m not exactly sure where they got that information. It can prevent some certain vectors but it’s definitely not a panacea.

Then they say to prevent code execution you should sanitize user input and don’t use shell commands. That’s also not much of a mitigating factor if you don’t know what to santitize against. Also it doesn’t mention the actual configuration changes that really could help in lots of situations around PHP remote includes. Eesh!

Then come my two favorites. For format string injection and XSS you are simply to “Edit the source code so that the input is properly verified.” and “Edit code to avoid XSS attacks.” That’s like me saying, “To prevent accidents, make sure you avoid collisions.” How is that helping anyone?

I think part of the problem with lots of these types of articles is that developers who know nothing about any of these attacks read these things and either get a small peice of information which is entirely wrong or they get nothing out of it at all. It’s pretty painful. I’ll give the author credit for adding in a source for their findings which is an article by Sumit Siddharth and Pratiksha Doshi around five common attacks against web application security. The problem is that the article itself doesn’t really go into any depth around the mitigation factors or really even most of the attack vectors themselves. It’s really more of an editorial peice for people who have never heard of them before - which again, is not really helping anyone actually mitigate these risks.

I’m not saying don’t write about security, really, that’s not my intention, I’m saying stick to what you can actually inform people about. One of the reasons I don’t write about XSS mitigation very much is because it’s a terribly complex issue, and it’s constantly evolving at the same rate as the vectors themselves. To make a blanket statement that I’ve heard dozens of times in homebrew advisories like, “To protect against XSS remove angle brackets.” and other inane or completely mis-informed mitigation techniques is to hurt anyone who reads the article who isn’t already well informed. Clearly this isn’t the author’s target audience anyway, given the name of the original article.

Jeremiah Grossman sent me an interesting link yesterday to BindShell’s tool they released called BeEF. This is an interesting take on a problem I’ve had for ages - how do you test the effectiveness of exploits against multiple browsers? Typically I have to test all browsers against the cross-site scripting vectors one at a time. It’s tedious and error prone.

Writing a fuzzer has helped the process somewhat, but it’s still a very manual process, that I’ve been unable to escape from. Then you have browser revisions, plugins, and settings it’s nearly a runaway effect of testing that is difficult at best to get in front of (and I’m doing it alone). What BeEF offers is a framework for using multiple browsers at the same time. I am actually very cautious about running more than one browser at once, because it confuses the results, but this allows you to run multiple browsers on multiple machines at the same time all executing the same function.

Great idea, but there are a few major issues with it from my perspective. Things like HTTP injection are not covered in this, and sometimes the diagnostics are pretty in depth, and not something that you can just issue a blind command against. Many of the vectors require some sort of human interaction to fire (I don’t post these for the most part, because that’s not the point of the XSS Cheat Sheet, but I do test them thoroughly to make sure there isn’t any way to do automatic execution). Also, a number of the XSS vectors I have on the page really mess up the browser. They overwrite the page, they redirect the user away from the origin host into a sort of browser no-man’s land (I’m probably going to write something about this later, actually) or worse yet, they send the browser into an infinite loop.

So, you can probably see why I’ve opted towards a more manual approach given these limitations. BeEF, however, should not be discounted, as I think it does solve one issue rather well. For a known vector with known results, version control is a major pain. When the browsers uprev, not only do I need to install the new version but I need to test it against every single vector for regression purposes as well as to see if it has closed anything since the previous version. Given the fact that I generally wait for two or more of the browsers to uprev so I can do them all at once, I end up being pretty slow at this task (the number of browsers tested times the number of tests). BeEF does provide that framework to make that otherwise insanely monotonus task rather simple in comparison.

Update: Apparently this wasn’t ready for prime time, I was actually getting a sneak peek. My appologies entirely. If any of you reading this want me to look at something and don’t intend to publish it yet, please let me know so I don’t go blowing anything. Again, sorry!

Our innocent little Warhol worm has begun making it’s rounds. There are some serious additional implications that have not been thought through completely. One thing that unsticky brought to my attention was the use of a Warhol work for spamming. He correctly diagnoses a problem in myyearbook.com but takes it to the next step and describes what it would take to build a Warhol XSS worm.

This is actually a pretty interesting read if you aren’t already familiar with how it would work:

While I was once again wasting my time and life on myyearbook, I found that their forum software, XMB, accepted GET requests to make replies or new threads, which can be forced via an image tag. So I played around with it, and forced some random and useless spam, from unsuspecting users, all the while thinking about how it could truely be exploited. Then it hit me, why not point an image tag to a remote php script, instead of just to the posting script. That way, you can have your script generate new code and forward the viewer to back to the posting script, creating a post containing the code to repost once again. So now I’ve created a forum worm that can do wonders like spam… and advertise. So I started thinking about what else I could do, then once again, an epiphany. What if that technique were coupled with another image tag pointing to a separate php script. This time, the script would redirrect the viewer’s GET request to a large page on a victim site. For every X views the ‘infected’ threads got, the victim page got just the same. On a single forum, this wouldn’t be a problem, really in any sense of the word. But after a quick google search, I found there were over 2 million forums running the same vulnerable forum software. Even with the far under-estimated guess of a total of 10 views for each forum, that’s still a good 20 million requests sent to the victim site in a very short ammount of time, basicly within hours. But, keep in mind this is a worm, and won’t be making just one post, it’ll be making as many posts as it gets views. An exponential increase of requests sent to our victim page. I severly doubt there’s really a single server running that would be able to handle that kind of traffic. Once the origional target goes down, we’re left with dead links in all our posts… or so you’d think. Back to that idea on using a PHP script to dirrect the users. This would allow you to have a list of targets, and cycle through them, as long as your scripts and ‘infected’ threads remained up. Of course, all this raises the problem of getting servers that would be able to handle the traffic generated by both the spreading of the worm, and the requests for the script to divy out the DoS traffic. This could easily be taken care of with a large number of hosted scripts, and checks inside each of them to see which scripts were still up and which weren’t. If a script died, no more posts pointing to it would be made. Sort of scarey to think such a realitively small flaw could be turned into something so much larger and far more destructive. In a sense, an attacker could use this to knock out any sites of his or her choosing, and keep them down…

unsticky is correct, the possiblities for exploitation of a Warhol worm using nothing but CSRF and JavaScript could easily build a denial of service platform, a spam gateway for whatever purpose or something even more malicious. It’s really up to the author’s imagination, and it’s pretty scary thinking about. And he also makes a good point that such a relatively small hole increases in power dramatically with the number of users who use the application.