I was pointed to an interview with Ed Foy of eFashion. It’s a pretty interesting interview about how companies are reeling in a post TJX world. The good news is obviously people like Mr. Foy are paying attention to the problem and trying to do their best to fix it. The issue is everything mentioned into the article has nothing to do with the problems TJX faced. He mentions network access control and Hacker Safe. Hrmm… my personal feelings about the validity of Hacker Safe being anything other than a marketing gimmick aside, security this does not make.

TJX was compromised through WEP, poor network access controls and poor infrastructure, not web compromises. Not that you should ignore the web, definitely not, but throwing a Hacker Safe logo on your site doesn’t do anything for your security other than make you a bit of a joke. Sure, explaining to your customers that you care is important, network security is important, and sure, even a logo on your site explaining that is okay. But it’s no substitute for real security, as TJX found out. I have absolutely nothing against eFashion but just as TJX themselves found out just because you embrace security doesn’t mean you’re good at it.

A few weeks ago at RSACon I sat down with Amit Klein and asked him one question that I’ve wanted to ask for a long time. I wanted to know if there was one defining moment in his past that suddenly opened his eyes. More specifically, some event that made him realize that he had stumbled upon knowledge that would lead him down a path that only a very select few would ever travel. I wanted to know that one cathartic event that made him realize the web was extremely vulnerable. I wanted to know this because I wanted to know if there was a common thread between him and some of the other experts in the field.

Amit took his sweet time thinking of a good answer, of course telling me all the while that there was no single defining moment and that the question was harder than it sounds. Yes, yes, Amit, but out with it! He finally began to tell me the first time he messed with a binary. He went in with an editor and changed one word. Expecting it not to work, he ran it, and sure enough it did. To him that was totally amazing that it would work, and suddenly, he realized that there were probably a lot of exploitable things out there similar to that. He also told another story about how he had read the HTTP spec and realized you could put a newline in front of the first line of the HTTP request, which in the future would eventually lead to exploitation.

So then I asked the same question of Dinis Cruz:

I can probably point to three key moments:

- the first was when I was a CTO of an university and one of campus’ IT guys showed me how he was able to access (over the internet) another campus internal network (via a remote shell delivered via one of the earlier IIS exploits)
- the 2nd was when I read back to back the first Hacking Exposed book and really got an understanding of network and application exploitation
- the 3rd was when I realized that my programming background (ZX Spectrum generation, Assembly programming on Amiga/x86, etc..) really allowed me to ‘understand’ Application security (vs network security) AND to write exploits

Jeremiah Grossman also gave his story:

For myself it started almost immediately when I began developing web applications many years ago. I read all the books, walk through the examples, and built websites. Being the natural prankster that I am I immediately saw how others could potentially screw around with the way my application worked, post offense stuff, and just generally cause a poor user experience. At the time I didn’t know to even to call it "security", it was just something that could be done to a webapp. The AHA moment came when I got the feeling that my code was no better or worse than anyone elses.

As I just passed my 800 blog post mark, I realized I had never talked about my moment either, and what better way to talk about it than to talk about other people’s moments as well. Mine was a very vivid point in time in my memory. I had read the HTTP spec and knew the basic principles of how it worked, but one day I followed some guide and telnetted to port 80 for the first time and started typing in commands. The first time I saw a flood of headers fly by my screen was like getting hit in the face with a brick. I just couldn’t deny how powerful that knowledge was and how broken everything must be if it was that simple. I know most people look at HTTP and kinda shrug their shoulders, but for me it was an awakening that made me realize that there is almost no end to the potential and danger that it allows.

I don’t know that I can point to any one particular thread between these experts, but I do know that the net effect was the same. The realization that everything is vulnerable is a pretty profound concept. So? What’s your story?

My friend Michael Eddington did a very good write-up on the differences between ASP.NET 1.1 vs 2.0 in terms of XSS protection. Surprisingly, it’s actually gotten quite a bit worse between the two versions. So much so that all the event handlers are now wide open, directives are wide open, and style sheets are wide open. I haven’t tested this myself yet, but if Michael’s diagnosis is correct that’s spelling bad news for anyone who adopted the 2.0 filters to prevent against XSS.

The funny part is that I actually thought the old ASP.NET filters were pretty good, not perfect, maybe, but good. Not only did they prevent against most of the major classes of XSS vulns, but because of the heavy reliance on viewstates, it also made tampering credentials a far more difficult task, and in some cases entirely impossible (via CSRF). My question is why would you intentionally make your filters worse? For the time being I’d stick to 1.1 if you use ASP.NET and are really concerned about XSS.

I ran across a really good example of some of the Intranet hacking through web-pages that I was talking about a while back. Doing some poking around in BlogEngine.Net I found a great example of this where a file not only allows you to read files from the disk (including things like the web.config the sql.config and other sensitive files with the syntax /js.axd?path=/web.config etc… but also the syntax /js.axd?path=http://localhost/ would disclose local websites. Ouch.

To make matters worse, if I know someone is running this software internally and I don’t have direct access to it, I can use it to proxy my requests all through their intranet on my behalf because there is a cross site scripting attack in BlogEngine.NET with the syntax: search.aspx?q=%22%3E%3Cscript%3Ealert(%22XSS%22)%3C/script%3E.

So I would simply need to get a user that I knew belonged to a company running this software to click on an link. It would then force their browser back to the Intranet website running BlogEngine.NET, where the XSS would use XMLHTTPRequest to pull in the js.axd file’s results, which de-facto would allow me to read every site on their Intranet that wasn’t password protected, as well as enumerate RFC1918 looking for private IP space. Ouch again.

A few people asked me when I first talked about this if I had ever seen it in the wild, so it took me a while to find something that was this widespread (probably 100,000 public installs) this is probably the best working example I have seen. Google dork: BlogEngine.NET 1.3.0.0.

David Ross had a good blog post a few weeks back about how IE8.0 is no longer vulnerable to the US-ASCII encoding attack. For those of you who don’t know what I’m talking about you can find an example of it on the charsets page. Looks like both of the browser manufacturers are stepping up their game a little for the next version of the browsers to hit the market.

On a side note, and something I’ve been meaning to post for a while now, I’ve found a discrepancy between IE and Firefox that I think is worth noting. Most of the time this isn’t an issue but most web-pages decode Unicode inputs, so the fact that Firefox automatically encodes every GET parameter with Unicode is not a big deal. However, if the page doesn’t do any conversions, but rather echos the data back exactly as it was seen Firefox isn’t vulnerable. However, Internet Explorer is - because it doesn’t convert " into %22 for instance.

It’s a subtle difference, and only effects certain websites, but it was big enough of an issue that I had to switch testing methods because Firefox wasn’t giving me the results I was expecting - even though I could see the vulnerability using a proxy. I don’t know what percentage of pages do this, but it will lead to a lot of false negatives in scanners that are looking for XSS injection, if they follow the RFC. Net result for me? Firefox = less good for testing and IE = less secure.

Meanwhile, not that anyone cares, but it turns out that blogging is going to make me die an unfortunate and unglamorous early death. And I always thought it was because it was going to be due to an explosion. You people totally owe me. I expect payment in the afterlife.

Okay, I waited long enough to tell this story, but it’s funny enough that it’s worth it. At SOURCE Boston, Jeremiah, Mark Kranack and I were sitting around talking and apparently at one point long ago he had started a religion. The religion was simple, all you had to do was accept Mark as your god and that’s that. No fees, no prayers, no nothing, just accept him as your god. You don’t even have to do it on purpose, one guy joined by accident as a matter of fact by inadvertantly saying that Mark was his god as he described it. There’s no way to get kicked out of his religion and nothing really special about it in any way beyond the religious leader, of course. You can still find a reference to it on the internet archive.

Then we got to talking and laughing and ultimately came up with a CSRF joke of all time. We could get tens of thousands, maybe hundreds of thousands, or even millions of people to join through CSRF via images to forms on MySpace, or what have you. You see, there is a bit of a bug in the acceptance program of Kraynackism. You don’t have to necessarily “say” that Mark is your God it turns out, you just have to somehow indicate it to him, either intentionally or inadvertantly as we saw with his friend. We could turn Kraynackism into the fastest growing religion the world has ever seen! You could be a member right now and you wouldn’t even know it!

It’s funny but it’s less funny when you talk about getting people arrested in China as we talked about a long time ago or of course going to jail for child porn, etc… Funny and scary all at the same time.

I was having our weekly cigar meeting with the local security guys when we stumbled across a pretty funny thought. There’s a pretty good paper put out by Cybersource about trends for 2008 in which it had a graph showing that as a percentage of online transactions fraud was dropping. Whoah! That’s not what I expected to hear. But then in closer examination that’s a red herring, because total fraud is still increasing at the same rate it always has. Not so good after-all, it just means consumer spending is out pacing the bad guys. That makes it worth being in the business of online retailing, but spending will eventually taper off with population growth.

The funny part of the story is what if all the consumers finally hit a tipping point where they just decided to go home and stop using the Internet completely? What if we just had bad guys trying to phish bad guys, and spammers just trying to spam other spammers? What would the Internet be when every page was a scam and every person on it was desperate for money because all the people who they wanted to scam went outside to go play in the grass? A funny thought! Hey, we were having cigars, sue us for getting a little off topic!

Good for Mozilla - they recently fixed a very odd referrer spoofing issue that I was talking about back in January. It wasn’t exactly ten days, but who’s counting. But referring URLs are a tricky beast. I see them being relied on an awful lot. I also see a lot of misbehaving robots in my logs that seem to think they understand what a referring URL is, but yet… they don’t.

One good example are robots that forget how Google works: http://google.com instead of http://www.google.com/ (notice the “www.” and the trailing slash are missing.) Also spammers, please note that as of today and every other day I have checked I have never once been a link on the front page of Google’s website and if it did happen, there will be a great earthquake; and the sun will become black as sackcloth of hair, and the moon will become as blood, so we best not even talk about such things. There’s tons of this garbage in my logs all day long. It’s almost surprising to me that the bad guys would bother. If anything it makes it stand out like a sore thumb. Yet, I do see companies making security decisions based on referring URLs. Kinda scary given how many reasons referring URLs might be wrong or non existent.

As a side note, when I attempted to use the :username@ trick for phishing it did not silently drop the username, it actually redirected me to the search engine, which is actually pretty appropriate behavior given that it’s malformed. I’m glad someone was able to reproduce it because I had a hard time proving to myself that it was even something widespread enough to talk about. Anyway, Kudos to Mozilla for the patch!

Whelp, we’ve talked about it, but now it’s finally possible. CSRF can now cause jail time. The FBI has begun arresting people who click on links to supposed child pornography. Now, I understand the noble pursuit, but there’s a fairly huge flaw in the old logic. I can force users to click on links anytime I want. Now here comes some interesting CSRF technology grey area. The authorities might reasonably say, “The referrer doesn’t match.” Okay, well that’s what our good friend META refresh is for. I can force you to click on things without leaving a referring URL at all.

So now the real question is would a user with no referring URL be worthy of investigation? Is this the newest wave in reasons to turn off referring URLs? I mean, seriously, what if the browser pre-fetches, or if an attacker puts a hovering iframe beneath the mouse, or they are using an older browser/plugin that allows spoofed referring URLs. Eesh. Again, I’m all for the noble pursuit, but seriously - this seems a little dangerous to me. Is clicking a link evidence enough of guilt? If so, can I now take search engines to court for trying SQL injection against me or for spidering and caching illicit content? And now have we given people plausible deniability, “I knew it was fake before I clicked on it” or “I was just seeing if it was an FBI site or not” etc….

<sarcasm> Be the first kid on the block to surprise your friend with an illegal version of a Rick-roll. </sarcasm> The act of clicking a link as evidence of guilt is almost certainly asking for trouble and abuse.

Sample code on how easy it is to not send a referring URL: <META HTTP-EQUIV="refresh" CONTENT="0;url=http://child-porn-site">

I got this picture from a reader of the site. Apparently the reader was simply viewing Yahoo mail and poof, RogueIframe trojan. We are starting to see a lot more of this kind of stuff, but it’s really disappointing that third party ads are being displayed on otherwise sensitive apps (or at least I think most people feel they are sensitive). Here’s the picture:

Click to enlarge

We’ve seen this exact hack hit before, against Facebook. But I think this kind of thing may be the beginning of a epidemic. As long as you can end up with your advertisements on any site that is even vaguely sensitive, you can start either taking over the site, or delivering malware. Whatever best suits the attacker’s needs. I think this all goes back Tom Stripling’s speech at OWASP where he in painstaking detail explained why you cannot trust third party JavaScript on your site, and yes, that definitely includes advertisements. Anyway, I hope this gets cleaned up quickly.