Paid Advertising
web application security lab

Archive for September, 2006

SafeHistory Stops CSS History Hack

Tuesday, September 26th, 2006

I found a pretty interesting tool surfing around some various websites (I wish I could cite the source) but I came across Stanford’s SafeHistory Firefox plugin. I’ve been testing it for the last day or so and it looks pretty good, despite a few issues with usability. It’s designed to stop Jeremiah’s CSS history hack by keeping not changing link color to other origins.

SafeHistory does change the links for same origins, so the hack is still possible if you are using it for your own domain, however for cross domains it appears pretty useful in stopping the attack. The major issue I see with this is that sometimes I really do like to know where I’ve clicked, and this changes the page in doing so. I haven’t tested how CSS effects this but I suspect it doesn’t change as a result of clicked on, which could actually change the layout of the page in some circumstances. It’ll be interesting to see any future bugs that this software introduces. However, it’s a pretty interesting take on the problem, and I’m glad to see people are working on it.

WordPress SEO CSRF

Tuesday, September 26th, 2006

Well, it’s with a bit of a saddened heart that in the first few minutes of checking through the WordPress code for CSRF I found my first vulnerability. I sat on it for a week or so until I had time to thoroughly test it, and sure enough, WordPress is vulnerable to SEO related CSRF. …and then the splogging community rejoiced. This isn’t such a bad issue from an XSS perspective because WordPress does a pretty good job of protecting it’s users from being able to inject malicious JavaScript, but it definitely does allow any content you desire to get indexed.

So here’s the scenario. I’m a webmaster with a blog (I actually am one, so it’s not a stretch) who happens to get lots of blog comment spam. Like a good webmaster I mark it as spam instead of deleting it because I don’t want them to be able to submit the exact same content again. The spammer themselves can actually see the unique identifier of the spam post by looking at the page. They see something like “comment-3182″. They file that away for later. On with the spamming they go. They can spam several thousand times just for good measure. When they’re ready to unleash the spam here’s the next trick.

When the spammer is good and ready they set up a realistic sounding post linking to them. It will show up in either technorati, or if they do a trackback it will actually show up as a comment as well. Stupidly, I’ll go and click on the link and end up at the spammer’s website. Ensuring that you only show the command to the right person can be done through IP delivery if you know their IP address, or using referring URLS. Embedded in the website is an invisible iframe with content that looks something like this:

<HTML>
<BODY>
<form name="f" method=’post’ action=’http://site.com/moderation.php?ignored=0&deleted=0&approved=2&spam=0′>
<input input=’text’ value=’update’ name=’action’>
<input input=’text’ value=’approve’ name=’comment[3182]’>
<input input=’text’ value=’approve’ name=’comment[3183]’>
<– Any other spam comments –>
<input input=’text’ value="Moderate Comments &raquo;" name=’submit’>
<input name="s" type=’submit’ value=’submit’ >
</form>
<script>
document.f.s.click();
</script>
</BODY>
</HTML>

While this isn’t particularly interesting from a web application security perspective it is interesting when you consider what it can be used for from the blackhat search engine optimization community. One of the things they are most interested in is persistant XSS, or rather links that will stay on the page indefinitely. While WordPress does add “rel=nofollow” to each tag, it doesn’t stop the actual text from being indexed. Splogging is not particularly effective due in parge part to the search engine’s respecting the rel=nofollow tag, as well as for moderation of comments (which we can now get around after the fact). Mitigating factors include deleting the content for good, and building better session/flow management.

From a web application security perspective things like changing the administrator password are vulnerable only if a referring URL can be spoofed (which is possible using the Flash header spoofing trick that Amit came up with). Because the state is dealt with by spoofable items (referring URLs) and CSRF susceptable tokens (cookies) WordPress is ultimately vulnerable to quite a bit more than just comment spam. (The same is true with submitting new posts, which by the way actually could enable XSS attacks as full HTML is allowed). So turn off Flash if you’re an blog administrator until something gets fixed.

CRSF in Google

Monday, September 25th, 2006

This is probably more amusing than anything. Click here to change your language preference from whatever it is now to Irish Gaelic. Highly useful language, I might add - but this was blogged by Philipp Lenssen describing the pretty innocuous setting change through a cross site request forgery.

While I don’t think this particular setting change is particularly devious, it is amusing and could have some unintended side effects on high volume websites where it was embedded in an image or a hidden iframe. Cross site request forgeries are really a fairly nasty attack, using the person’s own browser against itself. I have a feeling many more websites will be found to be vulnerable to this - in fact I’m sitting on a pretty nasty disclosure at the moment, that I’ll be vetting sometime this week after some testing.

Grazr using OPML Library For Testing

Monday, September 25th, 2006

I found this link today and it looked pretty interesting from an auditing standpoint. Grazr is using a OPML attack library based off the XSS Cheat Sheet. Grazr is a quick online RSS aggregator for webpages. Pretty slick tool, and probably has been prone to lots of the XSS vulnerabilities out there until recently.

But the Grazr team did something smart by attempting to use every attack string on the Cheat Sheet against themselves for regression testing. Slick! I’ve thought of this before - how can you include all the attacks against every variable passed to the application. It’s a tough job since most applications take lots of different forms of input. In this case Grazr only has one user facing input - the RSS feed itself, so it’s an easy choak point. Clever way to apply these toolsets that I’ve only seen in filter testing platforms before. It’s good to see people taking the time to find out the right way to do these sorts of tests.

PDP’s Work

Monday, September 25th, 2006

I feel a little delinquent in posting about some of PDP’s work. He’s been doing a lot of stuff lately that’s worth commenting on. I guess I was really waiting for some more fallout from some of the Quicktime stuff before I did comment, but it looks like it’s sorta died down so now’s the right time to give my two cents. This is in cronological order:

First, I did mention his JavaScript port scanner when it came out, but it’s worth mentioning again. He based it off of the various JavaScript port scanning talks at the time (Jeremiah and SPI Dynamic’s). PDP’s code doesn’t seem to have changed since he released it, but if you want the original version that Jeremiah wrote that’s got all the features in it you can get it from Jeremiah’s site that has all the other things built into it, like the CSS history hack, and the JavaScript shell, etc…

Next PDP released the FEX scanner based off a post I made about detecting Firefox plugins. Jeremiah released a full signature database later, which is probably worth looking at if you don’t want to do the work yourself. I’m still waiting for someone to do some more analysis on the plugins themselves as I think that’s where there will be some more interesting things.

Next in quick succession PDP had three posts about backdooring html, flash and mp3 files with JavaScript. I didn’t want to say anything about any of these at the time because most of them I think have been covered by the XSS Cheat Sheet, but the mp3 one is worth talking about in a little more lenth. Most people don’t allow embedded objects in webpages (Okay, MySpace is the odd duck here). While I do think it’s interesting that it’s possible, I’m not sure how relevant it is, because it still requires some social engineering in most cases to get the mp3 to be clicked on. Most of what I focus on is new attack vectors. I think (unless the server happens to allow embedded mp3 files) it’s more social engineering than anything, which I try to stay away from on this site - although it is interesting and I’m glad someone is doing the research on social engineering vectors because there’s no way I would.

Next PDP mentiond using the data directive as a new attack vector - unfortunately it’s not new, it’s been around for years and it’s not only obscure but difficult to use and not supported by most browsers. It’s basically using the data directive. While interesting, it’s not particularly a practical vector (or even a vector at all unless you can inject HTML around it or get something to redirect to it). Although it’s nice that’s he bringing up older vectors because I don’t think a lot of people know about this stuff - so as he’s learning he’s teaching other people.

Lastly, PDP wrapped my XSS attack library with AJAX functionality to make it easier to use. This is sorta lika a crippled version of CAL9000, but it is 100% web-based, so if you can’t figure out how to use the XSS Cheat Sheet and don’t want to download CAL9000, the xssdb is a good alternative.

Anyway, some cool stuff coming from PDP. As his understanding matures, I think we’re bound to see good stuff coming from him. Nice work, PDP!  I’m glad he’s on our side.

Sla.ckers.org Slashdotted

Monday, September 25th, 2006

Well, it was about that time - everything seemed pretty stable, so it was perfect timing to be surprised to log onto the sla.ckers.org web application security forums this morning and find that we’ve been slashdotted! Here’s the link to the article.

There were some interesting comments (or not informed as the case may be). Here’s one that was pointed out to me by one of our biggest fans:

Aren’t there any laws against these attacks? (Score:1) by r_bertram42 (976855) on Monday September 25, @12:27PM (#16186703) (http://www.777.com/) Where is the law in these cases? I’m sure there are ways to know who the hacker is, so why don’t they use the information to catch the criminals and put them on trial?

I don’t think understand (actually I know they don’t) that these aren’t vulnerabilities that anyone has actually exploited. Far from it. What people are demonstrating is the ability for someone who IS bad to perform malicious acts. I know it seems like semantics, but one is performing destructive acts (which I don’t condone) and the other is simply showing the issue is there and raising awareness.

Anyway, if you see problems on ha.ckers.org or sla.ckers.org today, that’s what’s going on.

XSS Vulnerability in Democracy Wordpress Plugin

Saturday, September 23rd, 2006

Aaron Brazell just published an interesting post talking about a cross site scripting vulnerability in the democracy plugin for Wordpress. Almost immediately after posting Democracy published a fix to the vulnerability. This is a pretty interesting flaw that I think needs a little more discussion.

Firstly, I think it’s important because Wordpress is not to blame for this issue. No, it’s an independant plugin author who is to blame. It’s very similar to the problems in Firefox that we’ve been exploring over the last few weeks - again, not Firefox’s issues, but the plugins themselves. It’s a little concerning that there is less and less information about system security as more addons are built on top of platforms. There’s next to no way to tell if you have hurt your security integrity without thorough code review of not just the plugin but how it interacts with other plugins, etc… A daunting task.

The other interesting part of this is that it isn’t reflected XSS, but rather it is persistant. This is also pretty useful for search engine optimization (SEO). Splogging isn’t particularly useful anymore (having spoken about the issue with one splogger about it). But XSS is in (if it’s persistant). In this case it isn’t exactly cross domain, but by including a simple <A HREF=http://spamsite.com>keyword</A> they suddenly get persistence on the front page of whatever domain they are interested in, giving them a high pagerank link to their domain from the main page. That’s one of the worst XSSs I’ve seen for that very reason, even if it’s not used as XSS but rather just straight HTML injection.

For SEO it is far more useful to be able to have stored links on the front page than sub pages. And while the author has suggested an upgrade, existing installs will be slow to upgrade most likely, so there is still a large opportunity of existing install base for blackhat SEO types to use this flaw to their advangage. For the blackhat hacker types, they can do cookie theft and log into the administrator account. Either way, it’s nasty.

Thanks to Aaron for helping me test this issue.

Webtickle Asks For Too Much Information

Friday, September 22nd, 2006

While cleaning out old email I found this email from Legionnare where he describes a service called webtickle that simply asks for way too much information. Frankly this kind of thing makes me very uncomfortable, but decide for yourself. Here’s his email:

Hey,

check this website out, http://web.tickle.com/. I haven’t really explored it but it seems to have a large collection of tests determined to figure out things about you or your friends.

I’m sending you this because when it comes to forwarding a test to your friends, the site asks for your hotmail/yahoo username and password in order to access your address book (omg). What is worse is that entire session in not encrypted.

OK, maybe this isn’t major-company.com but I’m guessing this is a popular site and a perfect trap for naive people who haven’t heard the words security, encryption and plaintext and are very likely to get an unpleasant surprise in the near future.

This is really a quick e-mail. To read more about this, check my blog entry at http://advancingsf.blogspot.com/2006/09/gimme-address-keys-to-your-house.html.

This is exactly the sort of thing that causes cascading security issues. Let’s take a hyptothetical situation where web.tickle.com had some sort of cross site scripting vulnerability in them. Next, let’s say someone were to use that same vulnerability to phish for the same information that web.tickle.com does. Next let’s say they get your username and password to hotmail and yahoo. Next let’s say you keep old email in there from your various accounts that require valid email addresses for authentication. Next let’s say the user goes to those websites and clicks the forgot password feature. Next the user takes the unique string and logs in as you. Next they change the email address on file and and confirm and delete and remnants to your old account and the email and password reset. Finally the user has permanant and final access to your account.

The problem here is the concept of a “half” factor authentication. Dual factor authentication is “something you have and something you know”. That is, a hardware device that is something you have, and the thing you know which is your password and when used in combination they give you access to something. In this case the thing you “have” isn’t really anything you have or anything you control. And because the relative state of password security is low (that is people don’t really secure their email address or their password that they also happen to use everywhere else) it is extremely easy to use them in combination to gain access to other (unrelated sites).

How do you tell a user that “You must protect your password on company-a’s website so that you don’t get hacked on company-b’s website through your email?” No one will understand that. Despite it being good for their business model, I think asking this sort of information is tantamount to phishing. No one should ever ask for your username or password other than the site that needs it for authentication purposes. The more people think this sort of thing is okay the more it will be used against them.

TWATECH XSS Podcast

Friday, September 22nd, 2006

TWATECH just released a podcast about cross site scripting. It’s really more funny than anything. Although, it sounds like it’s really designed for the real newbies. I actually laughed when they mentioned this page. Pretty cool stuff. I couldn’t stop laughing when they kept saying “evil hackers”.

But it’s interesting to see XSS enter more popculture type things. There is no way you would have heard something like this a year ago. It’s really more mainstream now than ever. Jeremiah and I were talking about this yesterday - how fast these issues are evolving. Pretty cool if you ask me.

Taking Your Password To The Grave

Friday, September 22nd, 2006

The title practically sounds like a movie plot, but indeed it’s true, when people die their passwords depart with them. There’s an article on com.com that talks about password security post-mortem. It’s a tough problem, but surprisingly I think I know a potential answer to it out of a joke my friend made.

Once upon a time my friend said he wanted to register the domain “istuckyourtoothbrushupmyassandnowimdead.com”. His theory was that he should go around and stick all of his friends and family member’s toothbrushes up his ass, and take pictures of it. Then he could set up a server to query the social security death index and when he died it would email everyone with said photos so they wouldn’t miss him so much after he was gone. Despite being a hell of a name and a pretty vile but amusing concept it actually might have some merit.

It’s not inconcievable that you could set up such a server with a social security death index query on a batch job with a private key for each individual user. Contained in it could be all of your secrets, etc… In a safety deposit box you could include the one password required to unlock all of that information. But before the encrypted information was made public for the loved ones, the person would have to die (social security index would need to be updated).

We’ve all thought about it. Once I was in an elevator with every single person who worked in security for a 36,000 employee multi-national company, and it occured to someone that if the elevator crashed no one would ever be able to get into any of the security devices for all of the customers. Theoretically this could be mitigated by having such a service. Would I sign up for it? Probably not, but it’s interesting to theorize about anyway.

As a side note, I did end up registering the domain istuckyourtoothbrushupmyassandnowimdead.com at one point as a joke. Then one day a year later (and long after I had forgotten I owned the domain) while I was vacationing in Colorado, InterNIC called me up on my cell and this nice sounding woman politely asked me, “Would you be interested in renewing your domain istuckyourtoothbrushupmyassandnowimdead.com?” I nearly died laughing.