Rajesh Sethumadhavan just published a number of XSS and other vulnerabilities in Yahoo. Unfortunately, none of these are useful to launch other attacks against Yahoo’s Ajax infrastruture the way they are built. The ones that use yimg (click here for an example in IE and then click on the banner once it loads). The problem is that yimg is not on the same domain as yahoo.com.

For AJAX to work (at least these particular attacks that I have in mind) the domain has to be the same, so finding an XSS in yahoo.com proper is far more useful to launch these types of attacks.  The ones against Yahoo mail don’t seem to be remotely exploitable from what I can tell (like the yimg one above) but those would be ideal.  But regardless, Rajesh did a great job finding them!

Okay, the title might be a tad inaccurate, but that’s the basic premise of this article at Neosmart.net I came accross today called “What XSS isn’t“.  I have so many problems with the article it’s hard to keep all of them straight in my head at the same time.  Firstly, he describes this as only a problem in JavaScript (obviously this isn’t just JavaScript, it’s also Visual Basic, Flash, Java, etc… etc…).  Secondly, he basically says that applications that have XSS in them are well written and XSS does not an insecurity make.  Wow.

If I make a system with a buffer overflow in it, intentionally, and hand it to a thousand people, by his argument since it was designed that way it’s not insecure.  I just couldn’t disagree more.  I thought the definition of insecure was something that compromised your security.  I personally think password, credit card, pin numbers, social security numbers, etc… constitute something I wouldn’t feel “secure” in handing to a bad guy.  I wonder if Pete would feel the same and if not, he is welcome to post those on this site.

I feel bad for developers who have to deal with XSS, but that doesn’t mean that they have well written programs. Well, obviously I think his opinion is pretty mis-informed to say the least, but I’ll let you make up your own mind on this one.

There’s a free webcast that ISSA published today called No Phishing Allowed (just click submit, you don’t actually have to register), sponsored by Mirapoint. It’s a fairly interesting talk if you aren’t super familiar with the phishing world. I kinda feel bad, because most of what they said feels like bunk to me.

Peter Firstbrook from Gartner spent a lot of time talking about the transport mechanism (they are assuming email, which is a good assumption). SenderID, DomainKeys, SPF records, blah blah… yes, email security is good, no, it won’t help. What? The email is now secure! Well, yes, except then the bad guys will just start using admin@wellsfhargoo.com instead. They really don’t care. And users, bless their heart, will still fall for it.

Then he went to the bad place and mentioned two factor authentication (like SecurID). I have no problem with the concept of second factor authentication, but it’s NOT a good security mechanism for most people - people who are too close to the security world always seem to gravitate towards hardware devices, which just happen to be the least usable and often the least accessable. It’s okay when you are talking about an IT security policy, where you force your users to have one, but guess, what? There are choices. I’m not going to buy a token every time I want to do business online. And btw, at one point I had three tokens.

Now do I need to carry around a token keychain? Dumb. AOL tried it. Are they still getting phished? You betcha. In their defence they did make people pay for it - “Pay to be secure on our site.” “But I thought I was secure.” “Well, sorta, mostly, but you’re even MORE secure if you buy our dongle that still suffers from MITM attacks. Oh, yah, and btw, your identity can still be stolen, they just won’t be able to log into your account. Oh, and sorry, if you’re blind, you have to be insecure.” And don’t even get me started on federation of tokens. I could rant for a week on that one. There apparently are some sites who have tried it and succeeded - I’m aware of Credit Suisse, Etrade and a few European banks that have used pin and tan cards, but they are not ecommerce sites. If Amazon could do it successfully, I’d be amazed.

Lastly, he mentions educating users. Okay, I’ve said it before, but apparently they didn’t read my blog. Education doesn’t work! You cannot train someone how to be secure. The best you can hope for is to train them to not open their spam bucket, but even that is pressing it. Users are users, and as long as there is enough idiots out there, the phishers will continue to make their billion dollars a year. I’ve worked for a number of companies with millions of users. It doesn’t work. I’ve tried. Trust me on this. You cannot train your users to know the difference between real email and fake email. That is the job of security companies (like Mirapoint or Symantec, or anyone else in the business) to handle. When you make dumb users understand things, you get dumb users who think they understand things, but really don’t, but swear they do.

Beyond security companies it’s the duty of browser manufacturers to get on board with it and help solve the problem. If they don’t, consumers will lose confidence and abandon online shopping - it’s a real threat, I’m not kidding, and big companies like Microsoft are scared shitless, as they should be. But they’re also making good strides to detect the problem in future versions of the browser. Netscape is already doing it with a feed from the Symantec owned WholeSecurity which maintains the PRN (Phish Report Network). Firefox, to my knowledge, is obstaining.

Anyway, it is an interesting talk, even if I disagree with a big chunk of it. As a side note, I have a ton of respect for Gartner, I just think a lot of people misunderstand phishing - making it a source of annoyance for yours truely.

I’ve had mixed feelings about steganography over the years. Sometimes I think it completely sucks as a security model and sometimes I think it’s just as valid a security model as memorized pass codes. A number of years ago (coming up on ten now) I had a conversation with Matthew Kwan about his tool called SNOW (Steganographic Nature Of Whitespace). His theory was that you can embed information at the end of lines with spaces and tabs (instead of ones and zeros). Adding a little encryption just for good measure and compression to increase the payload size, it’s a fairly interesting tool for hiding text in text.

Then I went to DefCon last year and I hear a talk by Bennet Haselton on using a steganographic language translation service to transmit information through national boundries in such a way that it will defeat censorship filters. In that scenario, there are far easier ways to defeat censorship filters, if you ask me, and btw, why would you tell anyone if that was your plan, cuz then the government in question will know anyone using that service is hiding data. Seems retarded to me.

The main point of steganographic file systems is that people don’t know if anything is there when looking directly at it. If the system is designed for the sole purpose of hiding information that’s not particularly good at hiding it, now is it? Well, maybe it is…

I went to a Cypherpunks meeting in San Francisco a few years back where I heard a talk by a lawyer of all things who went by Black Unicorn. Black Unicorn explained that steganographic file systems actually have a valid use for legal issues. With steganographic file systems you can actually have multiple layers of hidden data, each wrapping another layer, like an onion, and only with the correct password can you unlock the next layer, but there’s no way to know if there is another layer beneath the one you are on.

So his idea was to use the first layer to hide things like your passwords, or credit card numbers. The second layer maybe emails from your mistress or something that it’s clear you wouldn’t want someone close to you to know about. Then you get caught for something (like hacking, etc…) and they haul you into the confession room. They know that you have more on that drive, because they know you are using a steganographic file system. They also know you are a hacker type because that’s why you are in the room in the first place.

So let them beat you up for a while or threaten whatever they want. The trick here is to really make them believe you don’t want to give them the next layer. When they finally give you enough hell, give them the next layer. But instead of having that layer be something good, like the secret files you stole, have it be something completely unrelated but ALSO good. His suggestion was dog porn. It’s something that you could reasonably assume the police would want to find, but it’s not at all why they brought you in. Chances are they will let you go at this point. Interesting theory. It’s less applicable to web applications and more applicable to home security, I suppose, but steganographic tools in general, I believe, do have a place. It is assumed that terrorists are using it, for instance.

Obscurity, or obfuscation is a valid security model, if 100% of users don’t know about it, or the only people who do know about it have vested interest in keeping it secure. It’s not a valid security model during an audit, or when outside people are exposed to the secret (hense my problem with Bennett’s talk) or when used in place of a real crypto system but I do believe they have a place in modern application security.

Jeremiah Grossman and I spent some time looking at the exploit that Kurt Huwig found using malformed ASCII chars to bypass filters. We were able to actually turn this into HTML that will run, without using open and close angle brackets. In IE click here to run the proof of concept XSS (notice that the script tags are not encapsulated by valid ASCII chars).

The trick here is the encoding, we found. Unfortunately the scariness of this exploit is actually not as dramatic as we originally thought it may be, because it requires the US-ASCII char encoding to be set. After just a few minutes we had a working pototype and we even got XSSs working through the script.

So then we ran a scan of ~500 domains and found that only about 1% of the domains had this in them. So as a viable attack vector, sure, it’s possible that some servers (Kurt runs Tomcat, so maybe that one?) may be vulnerable in the way they are set up for any IE users who happen to use their sites.

A more viable possible problem is that content filters, anti-virus and other tools that monitor inbound packets will not see this encoding method. Any virii payloads, or otherwise blocked content like spam could easily follow this encoding method and travel unstopped to the browser, whereby they would be rendered as you would expect. Pretty scary stuff, actually.

Thanks to Jeremiah for his help in this blog post!

Kurt Huwig just released a vulnerability in the way the IE correctly handles ASCII encoding. It’s a pretty tricky flaw, that really is more of a problem in Firefox and Operat that they don’t also have the flaw, but the end result is that many forms of content filters will not be able to see the text when encoded in this way.

This is the link to the proof of concept page that shows text saying “The Magic Words are Squeamish Ossifrage” (view it in Firefox and IE to see the difference). Pretty interesting implications for the AV and content filtering world. I’ll be interested to see what the patches end up looking like when this is fixed.

Last week Choi Min-sung found a file upload exploit in Zeroboard. This was a particularly interesting vulnerability to me because it shows how two completely unrelated non issues can together create an issue. First of all Zeroboard allows you to upload a .htaccess file, which controlls the state of the directory in which it resides. Depending on what level of access controll that the system allows this may or may not be an issue.

Normally uploading a .php script is not allowed, but you can upload a .txt file or a .abc file or whatever. The .htaccess can direct the webserver to treat those file extensions as a valid PHP application extension. When the user uploads the .txt file or whatever it is treated as a valid file, and when the user goes to that file it is executed as the webserver user. Pretty normal script injection at that point, but fairly unique circumstances that allowed it to happen.

This reminds me of how Apache.org was successfully hacked a few years ago. Basically the FTP root was the same as the webserver root directory. Although they couldn’t upload their script injection directly through the web interface, they could through the FTP interface because it was world writeable. They simply uploaded the compromising PHP file and then ran it through the web interface and poof! Instant webserver access as the web user.

These out of band attacks are hard to find but they really do show how two unrelated and very hard to test for circumstances can cause major vulnerabilities. I’d love to see an automated scanner that claims it can find vulnerabilities that would locate that one. Humans are just better at finding obscure exploits, like script and command injection.

Only the very largest companies in the world use a concept of a looking glass. A looking glass is a script that is designed to be a helpful tool to network administrators. Let’s say I’m super-massive-ISP A that wants to talk to super-massive-ISP B and we are peers. If the connection goes down, it’s often unclear as to whom is at fault for the network outage.

So each super-massive-ISP sets up a script called a “looking glass” that is designed to run commands on border routers. The commands are simple things that attempt to diagnose network connectivity issues. The problem is that these script are open source, and often poorly written. It’s not inconceivable that these looking glass scripts have a vulnerability that allows you to run arbitrary commands on the router.

In this way you can hack the 2-3 OSI layers via the web application which sits at 5-7. Performing network level commands via web applications really opens a whole other realm to things like XSS attacks or SQL injection or code injection, where they can affect the operations of entire networks via a few small pieces of JavaScript put on a web board on a completely unrelated website. Pretty scary stuff.

Jaime from SEOegghead just emailed me with a post where he wrote a simple PHP cloaking script. It uses the IP lists from Iplists.com (which is used by Kloakit and other pay per use tools). It’s a pretty good demonstration script. I’ve actually chatted with Dan from IPLists before about his stuff, and I have some really good data that I’ll probably be sharing with the world in the not too distant future regarding spider mapping.

Ultimately, I think cloaking really has barely scratched the surface. If you haven’t read the post on how to detect cloaking, it’s an interesting read. That post is lacking a lot of information on other interesting ways to do cloaking. Most ways involve some sort of JavaScript. Since browsers don’t read JavaScript it’s easy to make the JavaScript do redirection, or even more tricky dynamically create the JavaScript based on IP addresses, etc. Not that I think IP addresses are the right way to detect spiders, but I’ll go into that in a later post. Anyway, take a look at Jaimie’s page.

Well, according to this article that id forwarded me, talking about China can be detrimental to your company.  There is a significant risk of either being censored or simply de-indexed altogether by the major search engines for talking about China.  It’s an interesting read.

But more importantly, it seems like the search engines are taking this largely on faith.  They are assuming that the content in question actually IS illegal (or rather that the owners of the site are even aware of it’s presence at all).  What happens if I inject content that is deemed illegal into Microsoft’s website?  Does that mean that suddenly Google will censor them and MSN themselves will de-list themselves?  The ramifacations here are pretty dramatic depending on how far you take it.

The ultimate problem here is that injection, not of code, but illegal words or content in general - whether it be terrorist information, Chinese curse words, or child pornography is largely out of control of the website administrators for most dynamically generated websites.  There are mitigation factors, but I’ve only seen them put in place a handfull of times.