A year or so ago I had an interesting conversation with a network security guy at a big company about terrorism and global information warfare.  He said that one day they were doing a war game to assess what happens in a global operations when they are under significant attack.  Now mind you that this was happening around the time when operation shock and awe was just beginning.  They were sitting in their SOC (security operations center) watching the corporate LAN when suddenly big chunks of the global network started going down.

It took them a few hours to figure out that the US bombs had knocked out the power to essentially the entire city of Baghdad.   Later when we were talking about it, it became clear that this could be used to assess large scale bomb accuracy assessments.  If an application is being housed out of a certain building, it is trivial to access the application before and after detonation to see if it was successful it destroying the target.  Additionally measuring applications in surrounding buildings would tell you the state of collateral damage (at least as a measurement of power and telecommunications).

But bringing it one step further, geolocation tied to specific applications can tell you a lot about the state of affairs of huge chunks of the globe.  As more and more networks are being built, you can detect many forms of natural disasters, like earthquakes, floods, fires, tornadoes, tsunamis, etc… anything that can cause power or telecommunication outages.  This seems like an interesting application, but it would need to be so decentralized that it makes it very cumbersome.

Some companies already have this sort of thing set up because of the nature of their business, but it is not tied into global response.  Maybe something like Echelon has enough nodes and sensors to be able to detect something of this magnitude, although it is doubtful if the three letter agencies of the world would share this information to the public in any reasonable timeframe.

Luny has been on a roll lately, finding dozens of XSS vulnerabilities. I could probably devote my entire blog to his efforts if I just wanted to document various working exploits. I, however, am more interested in the obfuscation techniques required to perform a number of his sucessful attacks, because that is what the XSS Cheat Sheet is all about - filter evasion.

The first was in apnaspace.com. I think this is relevant because of the obfuscation that bbcode provides. I cannot stress more what a bad idea I think bbcode is. All it does is make it harder to understand what is going on, and it makes people learn a new way to write the exact same thing they are already used to writing. If you are going to allow HTML, fine, just parse it. BBcode makes you parse it anyway, so you gain nothing. It’s crap, I tell you. Crap!

The hi5.com exploit is the second XSS attack worth looking at. The technique that was interesting there was that embedded tabs were required. The interesting point here is that for some reason they blocked the word “alert”. I’m not sure if this was an IPS/webapp firewall block or if it was just some inline code block, but either way, why? Blocking alert just obfuscates the problem. If you aren’t going to fix the problem, why put a bandaid on one method of detecting it? It’s ridiculous if you ask me. Shoddy programming, and it gains you nothing. And the worst part is they actually knew the problem to have blocked it in this way. If you know the problem, why would you try to stop something benign like “alert”? Maybe I’m just not getting it, I thought the point was to stop code injection, not to stop warning boxes.

Luny also did me a huge favor by finding an XSS hole in about.com. I really dislike about.com. Okay, maybe there wasn’t anything interesting in the fact that about.com wasn’t even attempting to stop the problem, but I think they are a waste of bandwidth since I can never find what I am looking for on there. Nuff said.

Lastly, B3ta.com tried their best against XSS, but alas, they were overcome by hex encoding in images. That works in IE and the IE rendering engine in Netscape 8.0+.

Luny deserves some praise. He’s raising the awareness, if nothing else. Good job!

If you haven’t visited my my vulnerability lab page it’s probably worth your time if you are into spam at all.  Text obfuscation in HTML is really simple.  It gets infinitely more complex if you add in JavaScript but even without it, it can be extremely complex.  If someone claims they know HTML show them the source of this HTML obfuscation page and then ask them to tell you what it says. Just because you can build a webpage doesn’t mean you know HTML.

That said, often times I am unsure about text obfuscation, or more exactly, I am unsure of the usage of a certain parameter of a tag.  For this there is only one page worth looking at on the entire web that I’ve found.  The HTML Cheat Sheet (aka the HTML Element Index). Brian Wilson put together the most exact and useful set of information for HTML on the web.  It’s seriously the only bookmark I use for HTML, period.  Granted, encoding and JavaScript obfuscation is not it’s primary function but many of the vectors I have come up with have been derived from Brian’s work (his was for webmasters, mine was for security experts, but you get the idea).  I highly recommend this to anyone who wants to get familiarity on the subject.

The reason this is relevant to XSS is because most people think XSS is about script injection.  That’s completely untrue unless you are talking about DOM based XSS.  In most cases you are talking about HTML injection which includes JavaScript.  The hard part is getting the HTML on the page, to run the JavaScript.  In this way, I think people have spent way too much time on JavaScript and not nearly enough on HTML, which is why the XSS Cheat Sheet talks mostly in terms of what HTML is allowed on the page, not what JavaScript is allowed.

Additionally, DOM based is usually easier to audit by hand in a black box environment because the source is easily downloadable, where in reflected and stored XSS it is not.  That’s why I’ve spent most of my time researching the different vectors rather than new ways to make JavaScript pull in additional data, although I think there are definitely doors to be opened there (Jeremiah’s Google exploit is a prime example).  Anyway, check out Brian’s page.  It’s definitely worth the time.

Alexa is spyware. Alexa also provides an interesting service to do website ranking. Quadzilla even ran an article about how Alexa can be used to help Google index your website. I haven’t confirmed this claim, but it’s an interesting premise. Using other conduits to spider your site for you, is pretty fascinating. Now, in the spirit of full disclosure, Quadzilla’s links to Alexa are including a referal link (presumably to get some cash out of the deal) so I’ll probably end up verifying this claim at a later date to ensure it’s on the up and up (not that I don’t love Quadzilla, just that blackhat is as blackhat does).

Anyway, it got my brain spinning. As blackhat as Quadzilla is, I’ve got trickier things up my sleeve. First, let’s just make the assumption that he’s right and that it does help pagerank, which ends up driving more traffic. Alexa is still spyware and you probably don’t want it installed as his article suggests. Sure, you could throw it in a VMWare session but then you have to have a VMWare session set up just for that so it won’t take over the rest of your computer. So what are some alternatives?

Well unfortunately Quadzilla’s link is about a year old, so the link to the software that he suggested downloading as an alternative is long since gone. So I decided to do a little spying on Alexa to see what it does. Here’s what a normal Alexa packet looks like (click to enlarge):

Now let’s take a close look at this. It contains a link that I happened to be going to (the SEO section of my blog) and a bunch of variables. It also contains a User Agent that has the word Alexa in it. It contains a variable called twym65 that looks an aweful lot like a unique identifier, as well as a cookie. Well, let’s take a look at a couple of those GET requests side by side (I cleaned this up to remove the URL encoding):

• /data/sfqA41hH4oY0zp?cli=10&dat=snba&ver=7.0&cdt=alx_vw=20&wid=30040&act=00000000000 &ss=1024×768&bw=1000&t=0&ttl=6407&vis=1&rq=8&url=http://www.google.com/
• /data/sfqA41hH4oY0zp?cli=10&dat=snba&ver=7.0&cdt=alx_vw=20&wid=30040&act=00000000000 &ss=1024×768&bw=1000&t=0&ttl=3703&vis=1&rq=9&url=http://www.yahoo.com/

Well, I have a sneaking suspicion that Alexa gets spammed a lot. Here are some of their countermeasures. Firstly this includes the screen resolution in the variable “ss”, Secondly my bet is that rq is the request count since it increments. The TTL (time to live?) appears to be changing, so that could either be the time since the last request, or the time that the user visited the page, or something else (that would require more testing). The URL itself appears to be pretty unique, so that is probably unique per visitor. So it’s probably not worth attempting to spoof an Alexa toolbar without having already downloaded it. So what are our other options?

Well, the main goal here is to get Alexa to see more of your pages. Again, we are going on the assumption that Alexa helps page rank (something I am still unsure of). If that’s true, all we need to do is to get Alexa to see those pages. How about if we use Alexa against itself. Since it’s spyware it leaks a lot of information. One thing that doesn’t change depending on where it connects to is the User Agent. The User Agent prominantly declares that the user has Alexa installed. Okay, so what are the requirements that Alexa uses to determine if one of it’s spyware packets is to be sent?

Here’s what I was able to find. Alexa does not follow iframes or 301 redirects. By all appearances it appears that Alexa only looks at the parent frame once it has finished loading. That’s slightly harder to mess with, but not by much. I could easily build a script that would identify an Alexa user (by the User Agent) and send that user via a 301 or JavaScript refresh or whatever to another one of my sites. Okay, so they hit another one of our sites. How is that useful we lost pagerank on the site they hit first, right? Well, that’s only assuming we don’t redirect them back after a certain amount of time. Alexa doesn’t care what is actually on the page. If they page is 100% dynamic it has no way of knowing that. If you bounce them from one page to another after the page has completed it’s loading Alexa will register BOTH as hits.

Okay, but then the user is on another site, and isn’t seeing the content they wanted to see. Again, that can be dealt with by watching the referring URL. If both are your sites you should know what the content was on the referring page. You can either display it on the other site, or you can redirect them back again to the primary site after the page has completed loading (delay in the JavaScript refresh, or a meta refresh after a few seconds, etc…).

The point being you can easily use Alexa against itself and increase your Alexa pagerank across many many sites without actually ever installing it once.

After a weekend away I got an interesting email from one of my subscribers.  It was regarding some auditing that he was performing against a website, and that website had asked him to remove the offending information from his website.  Here’s a snippet from the email (I’m not going to post who it is unless he wants to talk about it more himself):

Does he have the legal right to ask such a thing, and If I didn’t remove
it, would anything happen because of it?

I’m no lawyer, honestly, but I really don’t think he has a legal right to get you top stop publishing your information unless it falls under one of three categories.  One of which is libel.  Libel is where you write something that is not the truth.  In this case, if it is true, it’s not libelous.  Slander is where you say something that is not true, and defamatory.  Clearly neither are true.
The second is more along the lines of a governmental issue, where you cannot insight riots, terrorism, etc…  I don’t think this falls under that one either.

The last one that comes to mind is DMCA.  The DMCA might hold true if you are reverse engineering the software to perform a security audit of it.  I’m not sure if there is actually and valid legal precedence for that claim, although Snosoft was nearly sued under it by HP for finding a vulnerability in their product a few years back.   After a huge uproar by the security community HP issued a press release and retracted the suit against Snosoft.

Now all that said, the legality in performing unsolicited penetration tests against live websites is pretty much getting to be risky business.  Regardless of your intentions any sort of unsolicited security penetration testing is tantamount to hacking.  Dmitry was pretty much screwed after finding an issue with Adobe’s products.  Then there was the kid who did a F5 “attack” by trying to get his classmates to DoS their school server by hitting refresh.  The amusing part of that attack is that it caused the attack to happen inadvertantly because it was Slashdotted later (my favorite comment on that one was, “I went to the website, but it was down, so I hit refresh, and it’s still down.”) It was later taken down by slashdot because of legal ramifications, I’m assuming.

It’s basically war on penetration testing and vulnerability assesments right now.  So good intentioned or not, watch your back.

Digger just sent me a link to a story that diggs itself (Warning: turn off JavaScript or log out of Digg.com before you click on this or you will digg the article.)  This is actually a pretty good tutorial on how cross site request forgeries (CSRF) work, if you aren’t familiar with it.  What Digger showed is that his site can redirect back to a form that performs a site function.  Since you are logged in it performs the function as you since your browser goes to that function.

This is actually a pretty little known attack for some reason.  I’m still not quite sure why it hasn’t taken off with more virulance.  Generally the attack does fairly benign stuff like automatically logs you out of a website or something else equally lame.  But it really can perform nasty functions (like getting an admin to turn you into an admin, etc…).

Digger also showed something that surprisingly is a very common misunderstood way of fixing a CSRF attack, which is they require the form to be a POST method rather than a GET method.  That’s super easy to defeat.  The only time you can’t defeat it is when you can’t actually enter HTML, but rather all you can do is get a user to click on a link.  Another way this is easily defeated is if the user is using ISAPI or other tools that don’t care if the method is GET or POST (it’s actually abstracted from the web developer).  Alas…

Anyway, I’m out for a few days so this’ll be my last post until the weekend is over.  No parties while I’m gone - not unless you save some for me.  Have a good weekend!

I got an interesting email from id immediately after I posed about how to DoS Chinese people using XSS:

So…right after you posted that article about the Chinese firewall,
guess what happens to all our return packets into China…

19:02:18.279696 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
19:02:19.706738 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
19:02:21.827586 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
19:02:23.702761 211.151.239.41 > 69.12.144.65: icmp: host 211.151.239.41
unreachable - admin prohibited
19:02:25.997517 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
19:02:26.456323 211.151.239.41 > 69.12.144.65: icmp: host 211.151.239.41
unreachable - admin prohibited
19:02:34.596689 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
19:02:43.715250 211.151.239.41 > 69.12.144.65: icmp: host 211.151.239.41
unreachable - admin prohibited
19:02:51.814670 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
19:03:06.728772 211.151.239.41 > 69.12.144.65: icmp: host 211.151.239.41
unreachable - admin prohibited
19:03:26.452484 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
19:03:52.658481 211.151.239.41 > 69.12.144.65: icmp: host 211.151.239.41
unreachable - admin prohibited
19:04:35.223478 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
19:05:25.269166 211.151.239.41 > 69.12.144.65: icmp: host 211.151.239.41
unreachable - admin prohibited
19:09:51.021360 211.151.239.39 > 69.12.144.65: icmp: host 211.151.239.39
unreachable - admin prohibited
19:09:51.577978 211.151.239.39 > 69.12.144.65: icmp: host 211.151.239.39
unreachable - admin prohibited
19:09:52.705064 211.151.239.39 > 69.12.144.65: icmp: host 211.151.239.39
unreachable - admin prohibited
19:09:54.955989 211.151.239.39 > 69.12.144.65: icmp: host 211.151.239.39
unreachable - admin prohibited
19:09:59.445295 211.151.239.39 > 69.12.144.65: icmp: host 211.151.239.39
unreachable - admin prohibited
19:10:08.404253 211.151.239.39 > 69.12.144.65: icmp: host 211.151.239.39
unreachable - admin prohibited
19:10:26.358232 211.151.239.39 > 69.12.144.65: icmp: host 211.151.239.39
unreachable - admin prohibited
19:11:02.667654 211.151.239.39 > 69.12.144.65: icmp: host 211.151.239.39
unreachable - admin prohibited
19:12:14.659422 211.151.239.39 > 69.12.144.65: icmp: host 211.151.239.39
unreachable - admin prohibited
19:49:21.225050 211.151.239.41 > 69.12.144.65: icmp: host 211.151.239.41
unreachable - admin prohibited
19:49:24.700345 211.151.239.41 > 69.12.144.65: icmp: host 211.151.239.41
unreachable - admin prohibited
19:49:31.698610 211.151.239.41 > 69.12.144.65: icmp: host 211.151.239.41
unreachable - admin prohibited
19:49:45.677806 211.151.239.41 > 69.12.144.65: icmp: host 211.151.239.41
unreachable - admin prohibited
19:50:13.648465 211.151.239.41 > 69.12.144.65: icmp: host 211.151.239.41
unreachable - admin prohibited
20:41:13.932165 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:41:14.449852 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:41:15.487234 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:41:17.560017 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:41:21.711272 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:41:29.995980 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:41:46.568665 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibitedc
20:42:19.811039 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:43:26.055585 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:51:41.142530 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:51:41.660478 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:51:42.704785 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:51:44.789354 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:51:48.956126 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:51:57.292101 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:52:13.970979 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:52:47.319824 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited
20:53:54.009886 211.151.239.37 > 69.12.144.65: icmp: host 211.151.239.37
unreachable - admin prohibited

The irony here is that I’m actually warning the Chinese of the possibility of using their own firewall against them. Why wouldn’t they want to know that? Oh well. Ignorance is bliss, I guess.

Online Casinos aren’t as vulnerable as they look. Having this site and being a pretty active member of the community, I’ve pretty much heard and seen it all.  I’ve been asked to hack into banks, into governments, and just about every other thing you can imagine. I was having a beer with a good friend of mine a year or so ago, and he mentioned that a friend of his was juiced in with the Thai mob. Basically this guy had been recruited into it to help them cheat casinos (essentially he got caught by the Thai guys and in exchange for his kneecaps he got to help them out - and a healthy paycheck to keep a smile on his face). They had chosen a really low-tech route by getting a whole bunch of really talented players, stuffing them in a room and paying them to play poker and win all day. Wow, that sucks.

So my buddy, being the computer guru that he is, and also a professional gambler, gave his buddy a few helpful tips on how to succeed, by using proxies, clearing cache and cookies, blah blah. Then he went on to tell me how he would write an AI bot to do detection of the cards on the screen and automatically play for you. My friend is smart. My friend is also unaware of Online Casino security. So here’s how it works, for anyone who wants to avoid getting caught.

First, online casinos are not automated completely. There are indeed humans behind the wheel. If they see something that looks “robotish” they will intercept the user with a dialogue box to get human interaction. With this information they can tell if you are a robot or not. Okay, so what if you had a human nearby who could monitor the screens and respond if something like that happened? Well, eventually if you win too much, just like any Casino in real life, they reserve the right to kick your ass out as a suspected cheater. No problem, just log in as a different user, right?

Wrong…. My friend had the right idea about clearing cookies, and cache, blah blah. The part that he got wrong was that he didn’t know about the OTHER things these systems to do your computer. The Casinos put a piece of software in the Java clients that they ask you to download that map your computer’s hardware. If you come from the same machine twice, even as different users on the machine, despite using proxies, or what have you, they’ll still see you as the same user. Okay, so let’s just bounce around to another Casino, right?

Wrong…. That same software is logging to a centralized database that more and more Casinos are buying into. That software stores all of your hardware specs remotely. When Casino “A” kicks you out for being a cheater, Casino “B” will see you are coming in as a suspected cheater and that Casino “A” that they know and trust has blacklisted your computer. In this way, they are able to keep tabs on you as you move from Casino to Casino. Eventually this could end up being much more virulant softare that does a lot more than just mapping your drive and having a blacklist flag. But that’s a ways out, and giving customer information to competitors has never been a good business model for Casinos.

Are there ways around it? Sure, VMware sounds like a fantastic idea… the problem with virtual machines is that they almost always end up looking the same. Changing your hardware specs doesn’t really help too much, unless you change more than a certain percentage. They store as much information as possible and if they see one datapoint that doesn’t match they are fuzzy enough with their logic to detect that the user is probably the same. Are they logging in other ways? Well, almost definitely (although I have no definitive evidence of this), but those logging mechanisms are probably worth another post.

Is this all spyware? No, it’s DRM. They reserve the right to know that you have a licensed copy of their Java client.

Sorry, cheating online casinos just isn’t that easy anymore.  That’s probably why the low-tech route that the Thai mob is using is probably the most lucrative oddly enough.

This is probably going to be one of the weirder posts I’m going to do, but it’s been on my brain for the last year or so, so I should probably write about it. China has a countrywide firewall that attempts to protect it’s citizens from the infidels. I’ve done a number of tests on this and found that there are many possibilities. Unfortunately, the result of testing is that I get banned for about five minutes from whatever site within China that I am attempting to contact. The firewall is so strict that I can’t even type the words here, or anyone viewing this from China will be unable to view the site.

Of course there are ways around it (rot13 comes to mind). To see the Chinese banned words click here (WARNING, if you are in China I cannot take responsibility for what happens to you upon clicking this). It took me a few weeks to peice together these possible bad words. I gave up on testing since it take so damned long to run through the varients and I don’t promise that these will work but you can do your own tests if this is actually important to you (let me know if what I have on there is wrong or innacurate). Read the instructions on the link to further understand how I tested if you just want to see it for yourself in action.

Now, how does this relate to XSS? Well, let’s say you know that you have some competitor within China that you don’t want visiting sites. If you can get them to visit your site, and view a peice of JavaScript that then queries the site that you don’t want them to visit, for 5 minutes they will be in the penalty box and will be unable to view the site in question. This could be a huge problem if you inject the bad words via the page they are viewing itself, as they will be perma-banned from looking at the page unless they can find some other creative way around it or until the word is removed. Pretty nasty, huh?

Don’t bother forwarding Chinese people to my page, all it will do is block them from my site, not from any other site. I did a little bit of work on TCP/IP spoofing to see if I could spoof a few packets to the Chinese firewall and get other domains blocked but it didn’t work (I’m assuming their stateful packet inspection is smart enough to understand what is a real connection) but my tests were in no way exhaustive.

Sec-Consult just released that Outlook web access has an XSS vulnerability in it.  They  say that they are going to hold onto the exploit code for 2 weeks before releasing it. $10 goes to whoever finds it first.  And yes, if you Sec-consult guys just want $10, let me know. 

The implications may or may not be profound, depending on what the JavaScript has access to, and how the page is constructed.  I’ll refrain from commenting more before seeing the actual working exploit code, but it sounds bad, however it ends up working.  Nothing like reading people’s corporate mail remotely.  Sounds like an industrial espionage dream come true.