Paid Advertising
web application security lab

Archive for August, 2006

Reducing CSRF Risk With Tiered Authentication

Friday, August 18th, 2006

One of the largest dangers with authentication is that once you are authenticated you’re free to visit any page that sits behind the authentication. That wouldn’t be such a huge risk for web application security except for the fact that cross site request forgeries (CSRF) can force you as a user to bounce around within a website without meaning to (at the mercy of your browser, really). So what should you to do mitigate that risk?

I’m not going to give you the full run down on how to stop CSRF because honestly, it’s a huge mess, and with things like the Expect vulnerability in Flash allowing you to read/write from a host, tons of those old methods are broken anyway. The one thing that hasn’t been broken is user interaction. CSRF works because in general it does not require user interaction. Things that rely on unique numbers outputted only work if you can’d get the user to do an XMLHTTPRequest to read the page and replay it, just like the browser would. Trust me, it works. If the site is cross site scriptable (and they almost all are) the method of using unique strings is pretty broken. But there is another way.

Why can’t we ask the user for something? Something that a scanner cannot scan for or know. A userid is too weak and a known entity, but what about their password? Why not stop them in the middle of the flow and say, “Hey, are you really sure you want to change your password?” It doesn’t require a lot from the user, and it’s something that is impossible to session ride without. Of course, you can phish for the username and password, and get the same effect, but that’s far more difficult than a simple image tag CSRF attack.

Yes, there are problems with this, but let’s think about what you are really trying to solve. The vast majority of your users could use a lower level of authentication for the day to day things they are doing (like posting to a web-board for instance). Maybe they have to log in again to change billing information or request information from other users (which could be used as spam). And maybe there is a third level of authentication that asks the user for a username and password when they are doing something like changing account information that could allow for a compromise (like their mother’s maiden name for instance).

You are talking now about the statistical liklihood that the user is in that state. Most of the time they are only in the first state where they cannot do anything but post. That way the statistical liklihood of being able to force the user to perform a malicious function is a factor of how likely it is that a user is in the appropriate level of authentication (which should be very uncommon). In this way you can reduce your overall attack surface to a vast minority of users without some other attack vector (like phishing or credential tampering). Security in layers could start with something as simple as reducing what your users can do without authenticating again.

Google Picasa Listening on Port 80

Friday, August 18th, 2006

You can probably already tell where this is going just by the title, but it’s got me thinking. There’s a recent post on bugtraq a few days ago about Google’s picasa opening up ports for the attacker. There are a lot of applications that bind to localhost port 80. And it just so happens that with JavaScript we have access to localhost:80. How cute! Using JavaScript malware we now can execute commands on those locally hosted webservers where they were never visible to us before. Not 127.0.0.1 even but localhost:80, which your bowser thankfully gives us access to.

There are a ton of applications that do this, that are normally outside of our control. Just because you have port 80 open doesn’t mean you can do anything about it if it’s not bound to an external interface, but in this case the browser acts as that cross domain restriction lifter using CSRF, and our cross RFC1918 JavaScript scanner at our disposal. So now things like Google Desktop and Picasa and other tools that bind only to localhost are up for grabs. It’s just a matter of time before this is turned into a remote compromise. Any bets on which one will be first? Time to get VMWare up and running again.

Bastille PHPNuke I Think Not

Friday, August 18th, 2006

My favorite application to pick on is PHP nuke, by far. It’s just one of the worst written applications I’ve ever seen. At one point several years back I audited it and found there was a 100 line function in the base php file that was never called by anything, anywhere. It’s just a total pile, and it took forever to get even just a few functions turned on. There’s an interesting article on evolution-security discussing the problems with PHPNuke

But I’ve always like the concept of making Bastille versions of different programs. One of the ones I attempted to harden was CGI.pm but it was one of those projects that went nowhere because of my severe lack of time. But the idea is not a bad one. According to the article there are several hardening scripts you can add to PHP Nuke. It makes me wonder if they aren’t actually great security experts releasing this so they can own a lot of machines.

Which brings up an interesting point. How easy would it be to create an interesting firefox plugin with the soal purpose of creating a backdoor in mind? It’s easy enough to create covert channels or at minimum having a reason to query a remote server once an hour (stock ticker/weather forcast, etc…) to build a centralized command and control structure. I know it’s a tangent, but why not? What’s stopping anyone from doing that? That’s probably 100k machines that you can own in just a few months for practically no work. Hrmmm…

How My Friend Got Laid

Friday, August 18th, 2006

I suddenly thought of a funny story last night that I regailed my girlfriend with about how my friend in college got himself laid. He was not a particularly attractive man, or particularly swave or funny or anything else you’d expect of a guy who got himself a new girl every week. But there he was, knee deep in the opposite sex. So one day a year or so later, I asked him how he did it. He used is brain, pure and simple.

First of all (this will date me) you have to remember that the internet wasn’t a happening place back then. There were probably only several thousand people on Yahoo instant messanger in the state at that point, and most of them were not female, and even fewer were cute. What he found was that he could sort people by city. So he took all the usernames and real names and sorted them by cities. Then he did a lookup on the cities and found all of the ones that were within 100 miles (I guess that’s his tolerance for driving when dealing with Internet girls - and he probably didn’t have enough money to be traveling long distance).

With the real names he took the first name and compared it against a list of female names he got off some baby naming website. He then sorted those by which ones had photos and stored them in some sort of lookup table. Then he went through them one by one, hot or not style and decided which ones he thought were cute enough to talk to. This was before the days of IM spam, so they were happy to talk to him. Sure enough he got himself a lot of girls just by doing a little data mining back when there were probably only a few hundred girls within that 100 mile radius with the chat client. You gotta give it to him, he used his smarts.

But it brings up an interesting point about correlation. There was that Yahoo vulnerability where one of the secret questions was your birthdate, but they also had a astrology section, so all you had to do was grab that information and within a few guesses you could get the answer. Taking seemingly uncorrelatable peices of information can open the hole (in my friend’s case no pun intended) so that you can exploit it. In the case of search engines, you can take completely unrelated peices of information and bring them together. In the day of social networking a lot of the heavy lifting is done for you.

Once you find one peice of information leading you to a MySpace profile you have a gold mine. Of course it gets scary when you are looking through the lense of what a pedophile may do what that same information. Once upon a time I put together a document for law enforcement about what they need to look for and the bits of information they need to leave to make it easier for a pedophile to stalk their persona. It works like a charm. Not that my friend was malicious, but he easily could have been an axe murderer. With the tools at our disposal, there’s no reason any one of us couldn’t use it for nefarious purposes, whether it be for penetration testing, industrial espionage, or something far worse.

I applaud my friend’s ingenuity, but at the same time, I’m concerned about what that means in the days of big brother data mining (guess where I won’t be storing my pictures?). All it takes is one person getting access to this type of information through intentional information disclosure or by accident. The responsibility must be ominous.

Phishing Checklist Of Doom

Thursday, August 17th, 2006

Normally I don’t just go down and lay the smack down on other people’s work, but this site really worries me. This is exactly what I was talking about with Leggionare about how education can actually hurt people rather than help them. Take this top ten things to help with anti-phishing for instance. Let me make some comments here:

#10 Anti Phishing Check Point Bookmark all valid sites you have a relationship to (eg, bankofamerica.com), and when you get an email, ignore the links and if you think it is valid, then just use your pre-exisiting bookmark to login at the main page.

One word - pharming. Another two words, trojan horse. This only works if your system and network is completely clean.

#9 Anti Phishing Check Point Identify trademarked logos or names and verify that the origins are of the host site.

Easy enough, the phishers can host them themselves. And how are most users going to know how to verify that anyway? Any tips? You didn’t even mention SSL!

#8 Anti Phishing Check Point Phishers often set up webpages which contain the @ symbol in the URL. For example: www.youraccount@paypall.com. URLs containing the @ symbol are phishers, beware!

That trick hasn’t worked in more than a year and is rarely used because browsers have killed it. The only time @ is in a URL anymore is when it’s part of the query string as a parameter. You’re just confusing users with this messaging.

#7 Anti Phishing Check Point Check to ensure the email is addressed to you PERSONALLY. For example, if the email is from a Phisher posing as Bank of America, you may be addressed as “Client” or “Customer.”

How many people’s email addresses are joe.smith@company.com? This is trivial to get around, and there are tons of data mining software that handle this. At least 1-5% of the spam I get is targeted in this way, that’s really not a reliable method unless you never use your email address for internet shopping or sign up for anything ever AND never have it published anywhere that a spider can find. Good luck on that one. And I should also mention, there are LOTS of companies that don’t put the consumer’s name in the email.

#6 Anti Phishing Check Point Often emails from a legitimate holder of personal/finiacial information will list a series of dates and serial number in a header above the emails body text. The header will often read similar to: Date: Jan. 01, 2006 Serial Number: 5122bc6 Our Last Email was on: Dec. 01, 2006 Our Next Serial Number: 898fjf098 Use these dates and serial numbers as reference numbers!

This is just confusing more than anything. I’ve never seen that, and it’s pretty easy to convince people that it’s right, and if it’s not right, well, they’re going to click the link to figure out what’s going on with their account, now aren’t they?

#5 Anti Phishing Check Point Protect Yourself With Anti-Spam/Anti-Spyware Software! We recommend Adaware NOT Adware

Ad ware has nothing to do with Trojans, and I still might have a hard time believing that spyware is the root of account theft. Trojans, yes, adware no.

#4 Anti Phishing Check Point Anti-Spyware and Anti-Spam filters work to omit the transmission of personal data to “copycat websites” by proving the authenticity of the website the user is transmitting data, use them!

Kay… any advice as to HOW to use them and which ones you are referring to? I’m not aware of any anti-spyware that does domain name validity, but maybe I’m not up on things. How about throwing the consumer a bone and providing some links? Even I don’t know what you’re talking about and I’ve worked in the industry for over a decade.

#3 Anti Phishing Check Point Take Action!! Turn in the phishing scoundrels and clean up the web!! So you have received an email from an apparent Phisher/Spamer, now what?

Turn them in to whom? Where? Again, toss the consumer a bone. Clearly they don’t know this stuff or they wouldn’t be reading this document.

#2 Anti Phishing Check Point Forward, without opening, all unsolicited emails to spam@uce.gov. Report all phishing emails to reportphishing@antiphishing.org . Forward all emails from “copycat” websites to the authentic website.

Wait, how is this different from #3? Anyway, how are they going to report it as spam or phishing if they haven’t opened it to know that it’s spam or phishing? Half of the bullets above require them to open the email to verify that it’s a phishing email.

#1 Anti Phishing Check Point Avoid being a victim of Phishers and Spamers: Identify, Reduce and Respond. Contact your local internet security expert for consultation.

I love the concept, but who is my “local internet security expert”? Is there a phonebook for such things? “Hello, operator, can you give me the number for my local internet security expert, please?” Come on. This link is partly why education is ranked as the fifth dumbest concept in computer security. I don’t mean to pick on this author directly, but this is exactly what I’m talking about. We cannot ask our consumers to fix our security burdens for us. We have to supply them with the tools without their knowledge. Slipping content filters in on the network layer, or into their browsers or email clients is way more productive than giving them crazy conflicting messaging which is far more likely to get them into trouble than not.

Image Leaching Just Got A New Tool

Thursday, August 17th, 2006

Welp, I finally had it. Someone was using my stupid redirect finder for too long. I closed down access to the cgi logging portion for about a month, I explained it on the blog post for anyone who was interested and STILL I was getting spam in my logs. You’d think I would have built some failsafe into my own GreaseMonkey script to automatically shut it off, but no, I had to be secure, and make it completely invulerable to outside influence. I’m such an ass sometimes! The problem is it was spamming my logs like crazy. And yes, I can grep -v but I really don’t want to have to do that. I’d rather people just not spam my damned logs when I turn off access to the script anyway. So I had to think of a new way to get rid of that crap from my logs forever.

First we have to consider exactly what that tool was doing. Everytime it saw a potential redirect hole it queried an image on my server (which was really a CGI script). That script then logs the information for eventual retrieval (primarily for use in blackhat SEO actually, but also redirects are useful for spam and phishing attacks as well). Anyway, so it doesn’t do much. It doesn’t even display the image, so I can’t even put a goatse or tubgirl (hmmm, I wonder how many times I can throw those two terms into this post?) picture on every page they visit or anything. Time to think outside of the box, as I would imagine goatse or tubgirl might do.

A day or so later I was surfing around on, no, not for goatse or tubgirl, but rather my own damned site and I came across the solution: a popup! Why not hijack their computer with a mailto: popup every time they visit my page? Oh, it’s so simple I could have kicked myself for not thinking of it a month earlier - I’m feeling like goatse or tubgirl probably do right about now - all used up. Here’s the script:

#!/usr/bin/perl
print “Location: mailto:Dude, remove redirect from Greasemonkey already, I shut that crap down a month ago, email h\@ckers.org if you have questions\n\n”;

Yes, and just like that, poof! Almost all the traffic died down immediately. I guess people don’t like it when you force outlook or thunderbird to open on nearly every page view, just like people don’t like goatse or tubgirl. Go figure. But then I started thinking about it and there are other applications beyond a goatse or tubgirl substitute. One thing I’ve noticed is that lots of sites pull my favicon.ico file when linking to me. Most of them restrain the size so I can’t scar their website with the images of goatse or tubgirl so I’m left with little options. But what if I just want to let the user know, “Hey, guess what, stop stealing my bandwidth from your feed reader and download the picture already!” Not that they could do much about it on most systems since the user who will see it will have had nothing to do with it, but it sure would wake them up in a hurry.

Total goatse and tubgirl count, including this sentance? 8 times. I rule.

Variable Width Encoding

Thursday, August 17th, 2006

Just when you thought it was safe to jump back in the web security development waters something like this comes along. One of the things I’ve mentioned several times in my posts is that even once you figure out all this XSS stuff, you still need to make sure you have the proper encoding methods. My particular encoding method of choice is UTF-8. Then I read Cheng Peng Su’s explination of variable-width encodings filter evasion and my world shook for a moment. Truely shook.

Previously there were certain things you could assume are safe. Like, let’s say, an ALT tag in an image perhaps. The user should be allowed to enter anything in an ALT tag that they like, except the dreaded double quote that would jump them out of encapsulation. Well the way multi-byte works, it uses several characters and combines them into one. So if you butt a certain charachter up against another it renders as a third in the browser. Guess what, a double quote is a valid second char to butt up against. So if you put a certain set of chars butted up against a double quote you can now change that double quote into a meaningless third char which now keeps you encapsulated. Why is that good? Because we DO allow double quotes outside of the tags, because we are nice people and we like when people can quote things. When they put their own quote in after what we think is the end of the tag, that is now jumping them out of the encapsulation but within the realm of a valid HTML tag.

It’s all very confusing so I should probably give you an example. Click here in Internet Explorer. Excuse all the alert boxes, but that will show you which characters will work for this (it should also be noted that you actually don’t need the end angle bracket if you start another quote). It will just mess up the HTML, but for the purpose of the fuzzer output I had to put it in to keep it readable. It appears ASCII 192-253 and 255 all act as suitable starting double byte characters to jump out of quotes in UTF-8. As Cheng points out this is not limited to just UTF-8, but also GB2312, GB18030, BIG5, EUC-KR, EUC-JP, and SHIFT_JIS, although I think UTF-8 is by far the worst offender, even if it only affects Internet Explorer because of it’s prevalence. There’s a lot more research to be done here, with other chars and other encoding methods, but this is a fantastic start.

This is a very scary and very real possible exploit for any site that allows things like images with additional ALT parameters or inline style tags of any kind. This could have impacts all over the place. I will be curious to see how this plays out with the search engines (what encodings they are vulnerable to if any) for the blackhat SEO world. I applaud Cheng for finding this. It’s very easy to exploit if you know what you’re doing and very difficult to prevent.

Token Authentication Gone Phishing

Thursday, August 17th, 2006

I actually laughed out loud when I saw this link explaining how Citibank’s second factor authentication got phished. I’ve been saying this for years. You cannot stop people from entering in anything they know into any site that asks for it. Strong authentication isn’t really that strong. It’s got tons of usability issues (what happens if I’m blind, or just lent my keys to my girlfriend to go shopping for that matter?) and it’s still vulnerable to man in the middle, just like plaintext passwords are.

What’s the difference? Only the amount of time you have to initiate the phishing attack. And that’s only true if it’s a time based token and not an event (keypress) type token. Frankly, I’m pretty tired of big companies touting this as the answer to security. Here’s a quote from an ex-AOL employee about when they used tokens internally. And for those of you who aren’t aware, they were heavily phished before and after deploying it to their employees:

RSnake: back to the drawing board
Ex-AOL-Employee: Nice. I told them the first 2FA meeting I went that AOL phishers sent phishing email with the token fields to AOL employees who had sign in to AOL with a RSA token
RSnake: No kidding
Ex-AOL-Employee: _____________ brushed it off saying it shouldn’t be a problem…
RSnake: It shouldn’t, but yet, it is.
Ex-AOL-Employee: of course it is. At AOL, many lowly CS reps to VP got their account hijacked this way, and then the phishers sent out more phishing email and IM messages from those VP asking for sensitive info. It worked very well

My point is, the barrier to phishing is not a very high one. The cost to users is high, the cost to businesses is also high and in the case of the companies who are unfortunate enough to be heavily targeted, this hasn’t stopped the phishers from attacking. How do you sell second factor authentication? You say, “It’ll keep you safe!” And then the user is thinking, “But I thought I already was safe, you’re a bank, right?” “Well, even MORE safe… this time, you’ll be SUPER safe.” And then guess what, all you have done is raised the bar slightly. Anecdotally I talked with a token user and I asked her, “What would you say, if I told you I could hack into any account you had regardless of wether you had a token or not?” She responded with, “I’d still use it.” And I clarified, “Let’s assume for a second it’s zero difference in security.” She responded with, “I’d still use it because it makes it harder for the bad guys.” She couldn’t get it through her head that there is a possibility it might not be any more secure even when I asked her to theorize that it might be possible - boy has the security industry got her hoodwinked!

Okay, so maybe there is some value from a user perception, but if the whole world adopts it, and the whole world keeps getting phished, I don’t think that perception will last. It feels like snake oil to me and now I’ll have to carry even more crap on my keychain, and hope that I don’t accidentally break it or have the batteries die or I won’t be able to use my account - great.

Blackhat Talks Download

Wednesday, August 16th, 2006

Why pay $1000 + travel to Blackhat when Blackhat can come to you? A few people have sent this to me, so I figure it’s out there enough it’s okay for me to mention now. Here’s a list of the talks at Blackhat this year, with the associated powerpoints and files. There were some good talks this year, and while it’s not quite the same as sitting there and listening to the whole thing, for you non-native english speakers out there, you might actually have an easier time with this anyway. I’m sure this is copywrite infringement or otherwise not okay by someone somewhere, so don’t click on it (and remind me to add webbugs to any future talks I do). Enjoy!

DoSing Search Engines

Wednesday, August 16th, 2006

When Dinis Cruz and I were talking about how viral propogation would work for an XSS Warhol worm, one of the things we discussed is a centralized command and control element. One of the main problems with an XSS worm is that it needs to propogate itself blindly or it needs a central point to control all of the infected machines. The single point of control is the tough part. Eventually I think we settled on stealth over virulance as a concept, but let’s talk about that some other time.

Let’s assume for a moment that we did want a centralized command and control point. Let’s say we wanted a single point on the Internet that would allow the attack to surface. There are only a few networks in the world that could handle that load and few of them would be super happy being used a command and control point for a super massive worm. Fair enough. I don’t blame them. But what if it wasn’t so much a matter of if the machines had your content on it, but indeed were there at all?

Due to the nature of the Warhol worm you end up flooding almost any network in the world, and if the network doesn’t go down, the machines that host the site in question will go down trying to serve up your command and control point. But what if that weren’t just a side effect, but rather the goal? Let’s say I run a competitive search engine and I want to take down victim.com. What does that mean for me?

One thing I researched early on in my security career was resource exhaustion. Back then it was pretty easy to do. Just fork some processes and the machine would pretty much come to a stand still. That was back when some moron flooded the whitehouse.gov domain with emails and brought the server to it’s knees before the secret service came and escorted him off to the interrogation room. Today things are more complex and you can’t as readily run things on other people’s servers. But what if it’s a search engine? By default you are running an application on their servers. In fact that application tends to take up resources and time. It has to hit a database of some sort (perhaps in memory, perhaps not). Maybe it can cache common requests, but we can avoid that too.

So it comes down to what is the most expensive query you can come up with. For all modern search engines that I’m aware of they have a concept of boolean operators (and/or/not). The most complex of the three is “and” which means do two queries in one and then do some complex operation on the resulting dataset to represent it (yes, some work differently but that’s the premise). So what would happen if a successful Warhol worm started querying a search engine for a phrase like “tall and car” (in some search engines the boolean operator “and” is implicit but let’s just leave it there for clarity). Well first we have to define what a successful Warhol worm would look like. The first MySpace worm infected 1 million machines in a day. When Dinis Cruz and I talked about it, I was saying up to 100 million or more machines are vulnerable to this depending on what exploits you use. He was skeptical that all 100 million would be availible at any given time given the quantity of computers and a follow the sun issue, so I think we settled on between 15-20 million active machines at any second over the period of a day as a realistic target number.

So what if I launched 15-20 million additional POST requests to a search engine a second? Well it totally depends on the size of the infrastructure and if they have caching. The weird part is that it’s possible it could actually survive that because of caching. So what if we made it so that it wasn’t cachable? What if we strung abitrary words together and used that as the string? If we had 15-20 million requests a second doing between 5-10 million random search strings with between two and ten unique search terms, you are now talking about a worm that could bring down any infrastructure that I’m aware of. You’re talking a complete denial of service of the infrastructure itself (not bandwidth exhaustion). In fact, if you are extra clever, you might be able to use the Flash worm to create a header so it only does a HEAD request or otherwise chunk the data to reduce the return information so that the client does not pull the data so you can launch even more attacks per second.

Now that the search engine is offline that triggers the XSS warhol worm to begin it’s attack on the real target - at least that’s the original idea. But if the target was the search engine itself you have already succeeded. I’m not sure how you could defend yourself against that attack without doing some sort of heuristics on the user itself to insure that they came in the correct way (CSRF detection) which again, takes CPU time and time to develop. I don’t think this is a super practical application unless you are a competitive search company in another country that doesn’t care about or abide by normal rules of business and you just want to turn your competitor off for a day and hurt global e-commerce a little.

Anyway, just something I was thinking about.