While I was working for my last enterprise company I got this sneaking suspicion that something was going on with our corporate email. In particular, I thought that someone was embedding information into the emails to be tracked at a later date. This was in an attempt to stop employees from sending corporate confidential emails to third parties without concent - particularly fuckedcompany.com (the owner of which now runs Adbright, as an aside) and internalmemos.com (which is down now), among others.

I’m not typically a very paranoid person, I’m just really good at knowing when and where Big Brother is waiting around the corner. One day I finally had enough information to test my theory. Someone sent me a copy of one of the memos that was send out to one of the larger groups. It detailed the transition of a very important vice president to “special projects”. For those of you not accustom to the corporate world, that is double talk for the professional equivalant of the round file. So it was exactly the kind of dirt that these types of website and indeed investors would want to know.

Since I had two copies of the same memo, I got out my trusty cygwin install and ran a diff against the plaintext of both memos. Sure enough, differences! Subtle differences! Firstly, there were differences in the stars at the bottom of the memo, which looked something like this:

**************************************************

Confidential memo, do not distribute! Extremely proprietary!
**************************************************

On one there would be 50 stars and on another there would be 48 stars, or 47 stars or some other number. Then there were other subtle things like a sentance that would state something like, “Our two companies COMPANYA and COMPANYB are both doing well this year.” And on another one it would be switched, “COMPANYB and COMPANYA“. Other things like strip off the last word of a sentance, like “COMPANYA did well this year and COMPANYB was not far behind, likewize.” where “, likewize” may or may not be there since it is a word that does not change the meaning of the sentence.

There were about half a dozen iterations in that one email alone (easily enough to cover all the permutations necessary to cover all of the employees of the company). I got another email copy from another employee and sure enough, it too was different. Then I started doing research on emails since then and low and behold all the confidential emails were marked in this way. Sometimes the names of people that would be switched in order. But every version of every email was different. The stenographic information was simply a unique number associated to the version of the email. Once the email was copied and sent to the third party and published openly, it could easily be tracked back to either the person who had sent it, or at minimum the person who sent it to the person who published it.

What does that mean for people who believe in full disclosure at whatever cost? Either use someone else’s email with their unique identifying marks in it, or write some algorythm to try to deduce what is different in the email and change it enough so that it cannot be tracked back to you.

This morning Jaimie Sirovich released a tool for doing cross site scripting relfection security auditing. The way he describes it’s function is that it looks for parameters and injects a small snippet of HTML. If that HTML is seen once the server returns data you know it’s vulnerable to cross site scripting. Of course that’s not always the truth, and there are many other forms of XSS that are missed by this approach but it’s free, and you can’t beat free. He is talking about it in context of Blackhat SEO, where you can raise your own page rank by injecting XSS into pages that have a high page rank, although this is relevant to both search engine optimization as well as web application security.

But it begs a good question, actually. What is the single best string to use to test for XSS? The other day, I was talking to an auditor who was trying to inject an XSS vector but couldn’t use an equals sign “=” or a slash “/”. It sounds easy enough, but it ended up being really difficult, in that it had proper encoding. You’d be surprised how difficult it was to find a valid HTML attack that didn’t allow either of those. Finally I found that if you don’t close a <style tag, and it is immediately followed by another HTML tag, IE, Netscape 8.0+ in IE rendering engine mode and Opera will render an embedded JavaScript directive inside of a URL parameter. Whew! I thought I was loosing my touch.

So I would say, based on that experience, an equals sign and a slash seem like good things to want to test for if you want to have a higher liklihood of a successful attack (especially if you want 100% coverage with all browsers since the forementioned attack wouldn’t work in Firefox because of the JavaScript directive). The simple cross site scripting string <XSS/> doesn’t test for either. So maybe <XSS=XSS/> is a likely choice? Now that also doesn’t test if you can jump out of quotes. But maybe that doesn’t matter because it assumes you’ll have to try to jump out of the quotes yourself. But if it were me, I’d try alf’s trick of putting in a single and double quote: ‘”<XSS=XSS/>

Now that won’t test for DOM based attacks but maybe that’s not a problem. The XSS locator (the first vector on the XSS CheatSheet) attempts to locate these for you by attempting to break out of encapsulation by escaping escapes in JavaScript. It’s got a high probability of jumping out of any quotes or encapsulation, but the problem is that it is a pretty long string, so perhaps ‘”<XSS=XSS/> is a better alternative. Who knows?

So back to the original point of Jaime’s post. Does this help with SEO? Arguably it will help a little, but it seems to me that reflected XSS and automatic 301 redirects are the worst way to improve page rank. It seems to me that getting pages that are highly ranked to store the XSS vector and show it once the browser reaches the site (which has already been to that URL) it would have a much higher probability of increasing page rank.

As a side note, the two important things for SEO is either to redirect the valid traffic that hits the site (in which case the search engines don’t need to see it and it can be as obfuscated as it needs to be) or it needs to improve page rank, in which case it needs to be valid HTML syntax, or close to it, for the crawlers to see the link. If it’s the latter, it’s more about HTML injection to inject links, than it is about JavaScript injection, which is more about the former (redirecting or hijacking the valid traffic away from the vulnerable page). In this time of SEO flux, webmasters will do anything to get ahead. Anyway, thanks, Jamie for the tool!

This week Jaime Sirovich, QuadsZilla and I had an interesting thread where Jaime proposed the idea of putting CSS inside a robots.txt protected directory. The CSS, of course, would hide spam on a page from the eyes of anyone who just visited the page thus allowing you to SEO (Search Engine Optimization) spam the spiders visiting your site.

Any robots that respected this would then spider with the spam intact. I believe you would have a better chance with /includes than /images if you are just trying to social engineer people from not being curious. Also, by absolute linking, verses relative linking, it wouldn’t matter if one of the engines cached it or someone used a language translation services, as all of the ones I’ve tested preserve hard links and call them directly or pass them through a proxy unchanged (in the case of the anonymizer).

The major downfall is that I’ve never yet seen anyone do this (which you’d think would be good). If you ever get caught it would be fairly easy for Google to put up a rule, where if it saw CSS linked to from a page hidden by a robots file it was automatically suspicious. It would be easy for them to do because there would be no false positives that I’m aware of. That could easily be made automatic in their algoryithm. The question is how likely are they to do it - which would probably depend on how many people knew about this and were doing it.

I think this is a valid idea for at least the short term, but it will be interesting to see how Matt Cutts and the folks at Google evolves with this new problem. phaithful had a good point when I talked with him about it “If you’re a site that is worth it’s salt… you’ve got lots of people looking to take you down any which way they can. It doesn’t have to be scalable on the engine’s side. They have users policing the pages all the time.” Then the users can just go to Google’s spam report and submit it as an invalid website. Done and done.

Interesting idea, but only good for a short while, is my feeling.

alf sent me an email about how single and double quotes are a pretty easy way to cause XSS injection. I had to ask him for more details, because that just wasn’t clear to my satisfaction, so then he sent me this XSS exploit library. His concept is that if you put a single quote and then a double quote and then your XSS vector it will bypass a lot of filters, IE: http://www.example.com/param.php?123′”{XSS}

After verifying that most of them will still working, it appears there are two problems that are causing this to work. The first problem is that people assume if something is encapsulated in quotes it is not vulnerable to cross site scripting. That’s definitely not the case, especially if you insert a quote and break out of it.

Even escaping quotes doesn’t help you, because there is no such thing as an HTML escape charachter (and if there were that could cause all sorts of other problems). So if the tag looks like: <TAG parameter=”variable” … and you insert ‘”{XSS} into the tag, you can jump out of it because it looks like: <TAG parameter=”‘”{XSS}” … and even if they put backslashes before the quotes, it still ends up being <TAG parameter=”\’\”{XSS}” … which ends up still breaking out (change the single quotes to double quotes and vice versa and it works the same). Now that you have broken out of the quotes you can use event handlers inside the tag, or you can try to break out of the tag as well with an end angle bracket. Either will work.

The second problem is that people take the parameter and don’t sanitize it for use in applications. In one of the cases it is just an error condition saying that the file you attempted to open …path…/’”{XSS}.php is not valid. Of course, there are probably other vulnerabilities there since it is command execution that is failing based on an unsanitized variable (eesh!). Scary stuff.

So the moral of the story is that single quote double quote combination can often help you find your way out of encapsulation. I’m always a little fearful of using things like this in automation because they have a greater tendancy to find SQL injections which can end up breaking applications, so for black box pen testing make sure it’s not on a live system, because the likelyhood of bringing it down is much greater.

Yesterday The Register pointed to an article on WashingtonPost.com that talks about how federal laptops must use encryption. That’s one small step towards securing laptops, but as I was saying the other day, I think there are a lot of other precautions that are flat out missed when it comes to corporate security and laptops.

Sure you can encrypt the drive, you can install firewalls, web application firewalls, and anti-virus, but can you protect it from spyware? Lots of spyware is not detected by anti-virus for some reason (to this day, I really don’t get why). Instead they sell different products which are not standard, or worse, let the user fend for themselves. So they end up downloading stuff like Microsoft’s Defender or Ad-aware (if they know to be paranoid about it). I haven’t yet seen one corporate laptop with anti-spyware installed by default for users.

If I can run arbitrary code on a laptop (whether that be an executable or even something as simple as XSS), that could be disasterous for corporate security. The scary part is even without admin rights, XSS still poses a threat, as Jeremiah will discuss. Anyway, my point is, the goverment made a step in the right direction but it was a very small baby step that doesn’t address some of the largest issues with laptop security and mobile computing platforms in general.

Second factor authentication tokens are literally my least favorite topic, and unfortunately one of the mailing lists I’m on is just getting overrun by innane conversation about it, from people who have only rolled it out in IT settings (not for consumers).

But the point of this post wasn’t to rant, so much as quote someone from Slashdot about a year ago.  Forgive me because I can’t find the source, but the jist of it was, “Hello, we are your bank. Your token has expired. Please mail us your username, your password and your token so that we can insure that it gets replaced.”

It doesn’t matter how smart you are, I can come up with a better idiot who will fall for identity theft.  Case in point:

Can we stop talking about this now?  You can’t save your users from stupidity by asking them to adopt security.  They’ll find a better way to bypass your security with their ignorance.  Trust me!

The other day, I ran across a website called Fight Phishing that claims to want to stop phishing by disclosing the cross site scripting vulnerabilities in the biggest applications out there that he can find them in that can be used for this type of attack. Among the companies, is AOL, Citibank, WellsFargo and the Internal Revenue Service.

Ultimately this is really about full disclosure, but if you look at the comments on this post you can see not everyone agrees with the tactics. I had to stop and think about how my site differs (if at all) from his site. Honestly, the only differences I can come up with are semantic. I am not so interested in outing the companies themselves, but rather raising awareness of the topic in general.

For instance, when I disclose vulnerabilities in some application it is not so much that I have any interest in that application or any other application for that matter. However, I am always interested in the underlying methodology and the ultimate ramification (to phishing or otherwise) of the exploits.

Honestly, I think what this guy is doing is pretty cool, although not my particular style. But for those zero-day guys who read my blog, this might be a good place to haunt.

Whiteacid posted last month about a community cookie logger script that he had created.  This is really no different than any cookie logger, except that this one is designed to be as open as possible so that anyone can use it.  I’ve actually thought about doing this before but the liability seems more than I’d like to take on since all those annoyed admins would be coming to me with the feds to get my logs.  Noooo thanks.

So that begs the next question, which is now you have to go retrieve those cookies, and what if the site is down, or can’t handle the amount of cookies you are stealing, etc…  You need some sort of distributed cookie stealing system.  The idea that came to my mind is using open bulletin boards.  If the page is already cross site scriptable, you can steal the cookies and forward them to any open webboard anywhere.  Chances are it’s also a very spammable board, but maybe that’s okay.  Maybe spam isn’t that bad, intertwined with your cookie theft.  I don’t know, but it’s an interesting thought.

Obviously you could get around detection on Whiteacid’s site by using proxies, or Tor or something, but I’d still be careful as all of those appear to have holes.  Not that I think Whiteacid would exploit those holes, but if the feds ever seized his machines they could easily implement something like the UnAnomyizer that metasploit came out with.

Personally I stay away from bookmarking sites like the plague, but I do know that if you get a 10 people digging you that means you get about 5x the amount of traffic to your site. For the blackhat SEO crowd this could be interesting because getting 100 people to digg you will make a lot of other people follow your link, just out of curiosity (and assuming the topic sounds interesting enough).

Today I got an email from Digger - aka Clear Rivers who sent me a link to his blog. If you remember he is the one who found the CSRF vulnerability in digg. This, in my mind, is actually more dangerous, because it could be used for phishing, and easily falsifying diggs by doing some AJAXy stuff via the JavaScript itself. The only minor saving grace is that it’s not really HTML injection, but rather parameter injection inside of an input tag, which makes it slightly harder to exploit on a large scale being that it does require some onmouseover stuff.

Of course to get around requiring a user to mouse over the search box you could do something tricky like put it in an iframe and move the iframe to wherever the mouse is on the page it is being called from to execute it, but who’s counting (thanks to Jeremiah Grossman for that particular idea).

But this is a perfect example of why stripping out open and close angle brackets does NOT prevent Cross Site Scripting - a very common mis-nomer. It closes down HTML injection, but parameter injection, DOM based attacks and things like UTF-7. All of which are still wide open. Nice find, Clear River!

Meanwhile Dcrab found a few vulnerabilities in MSN and Amazon. He has not released the exploits, so it’s hard to comment on them, but it’s no surprise.

I was toying around with Google Cache a few days ago and I ran accross an interesting thing. Google cache had searched my environmental variables display script called log.cgi. Log.cgi really doesn’t do anything but output any variables that the client sends to me. In this case it was Googlebot’s environmental variables.

Then I did a little more research and found that Yahoo Slurp too had logged itself. Then taking it one step further, I found MSNBOT had found me as well. Fairly amusing to look at how the various robots gave up everything. This is the first 100% definitive proof of what the various robots signatures are that I’ve ever seen. Everything else has been subject to spoofing, but this is 100% correct, and now I have proof. Anyway, it may be interesting for the SEO IP delivery community like Kloakit. I’ll be talking more about this at a later date.
In case they get removed, here are the signatures:

Googlebot:

HTTP_ACCEPT = */*
HTTP_ACCEPT_ENCODING = gzip
HTTP_CONNECTION = Keep-alive
HTTP_FROM = googlebot(at)googlebot.com
HTTP_HOST = ha.ckers.org
HTTP_IF_MODIFIED_SINCE = Fri, 09 Jun 2006 02:43:40 GMT
HTTP_USER_AGENT = Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
REMOTE_ADDR = 66.249.65.107
REMOTE_PORT = 50637

Yahoo Slurp:

HTTP_ACCEPT = */*
HTTP_ACCEPT_ENCODING = gzip, x-gzip
HTTP_HOST = ha.ckers.org
HTTP_IF_MODIFIED_SINCE = Thu, 22 Jun 2006 03:33:16 GMT
HTTP_USER_AGENT = Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)
REMOTE_ADDR = 68.142.250.77
REMOTE_PORT = 60560

MSNBOT:

HTTP_ACCEPT = text/html, text/plain, text/xml, application/*
HTTP_ACCEPT_ENCODING = identity;q=1.0
HTTP_FROM = msnbot(at)microsoft.com
HTTP_HOST = ha.ckers.org
HTTP_USER_AGENT = msnbot/1.0 (+http://search.msn.com/msnbot.htm)
REMOTE_ADDR = 65.54.188.105
REMOTE_PORT = 3319