Today Ilia Alshanetsky proved the theory to be correct you can portscan from an HTML page without JavaScript enabled. Really when I say port scanning I mean ping sweeping in this case, because as Jeremiah and others have noted the difference between a server that’s alive showing an open port verses a closed port in time difference is negligible. This finally puts to rest the notion that surfing without JavaScript enabled is a safe way to surf the Internet. Hallelujah! I always felt like that was incorrect - even if you get rid of CSRF as an issue.

Ilia’s example shows the basic premise and he even gives code snippets, but he solves one interesting problem. There are some timeout issues that Jeremiah encountered which can be bypassed by using multipart/x-mixed-replace in the Gecko rendering engine and Safari/Opera. Very interesting. That allows the page to be re-rendered without the use of JavaScript or Meta refreshing etc… Very clever solution, however it appears to be limited to the non-IE crowd, which makes it’s actual effectiveness around 20-30% of the user population. Of course you can do browser detection to not even start scanning until you get a user who is using a compatible browser since browser detection can be done on the server side.

I think we’ve proven a our point. JavaScript isn’t the root of the problem here. Sure it enables bad stuff, but HTML and the client technologies alone can obviate the necessity for JavaScript alone. Do I think anyone is going to use this technique in reality? Probably not when JavaScript is so prevalent and cross browser compatible. But it is nice to know you can call people out when they claim they are safe because they turn off JavaScript.

Jeremiah and I both began thinking of JavaScript port scanning nearly a year ago. For a while we were saying annoying things like “Well if you want to be safe you had better start surfing without JavaScript turned on.” Don’t you hate it when you’re wrong? Jeremiah began talking with me about a way that he could do port scanning without the use of JavaScript several months ago. It wasn’t even theoretical at the time, but it was quite a bit of work to construct.

Given that some of the buzz has died down about using HTML pages to build websites Jeremiah felt it was time to release his idea to the world. I think this is the answer to when people say things like they surf without JavaScript turned on. I guess we have pretty much completely broken the same domain policies of yesterday. If I can scan your Intranet application from an HTML page without JavaScript or Java or any DHTML content whatsoever I think it’s time to start revisiting the entire DOM security model. That might just be my opinion but come on. What else do we have to do to prove it’s not working?

I’m working on another project to XSS somewhere around 60% of all web based applications, not that I have to since the mhtml vulnerability is still on the loose. But I really think that the whole concept of browser same origin policy security is a theory at this point, and a theory that isn’t proving to be very successful as it turns out. Anyway, read Jeremiah’s post. He’s put enough thought into it to have a working prototype, but I’m sure someone else is going to want to take this to the next level. If anyone does please let me know. I’ll be interested to see the working example.

Today is the first day I’m playing with my new laptop. It’s a Lenovo (very cool). Anyway, here I was messing with some environmental variables, as I am known to do and I notice something odd. Symantec’s Client Firewall actually modified headers in a very strange way that makes it very capable of being detected.

For some reason that completely escapes me, they attempt to mask the HTTP_ACCEPT_ENCODING variable. Again, the reason completely escapes me as there are way way scarier variables passed. Here is what it normally looks like for Firefox:

HTTP_ACCEPT_ENCODING = gzip,deflate

And here is what it looks like when masked by Symantec’s Client Firewall:

HTTP________________ = ————

The ultra strange part is that instead of just making it some random amount of blanks it is the exact number of characters that the normal header is. I completely don’t get it. Now let’s look at Internet Explorer:

HTTP_ACCEPT_ENCODING = gzip, deflate

Now masked:

HTTP________________ = —– ——-

Notice the space? I guess spaces don’t count as characters that need to be obfuscated. You should see the expression on my face as I type this. So, let’s see, assuming there is a lot of underscores that fits exactly with a header that is usually there but currently missing I think we can safely assume that that variable is always going to be HTTP_ACCEPT_ENCODING and given the fact that there is a comma and there is a set number of characters for the most common encoding types, I think it’s a safe assumption to say I can guess what the encoding methods the browser accepts. Talk about some crazy obfuscation.

I’m not even sure what it’s good for other than detecting users with this particular software installed. Go to my JavaScript Environmental Variables API to see your own HTTP_ACCEPT_ENCODING or detect it remotely. Weird.

I ran across this article today on 99 ways to secure your email. Largely it’s email etiquette and efficiency fluff and there are really only a small handful of actual ways to secure your email in it (numbers 78-99). There are a few tips that I’d tell people that are definitely not mentioned on their list. Here are a few from my personal list:

1) Turn off preview panes. When you click an email and it shows up in the preview you are rendering the remote images and the click-tracking that spammers use to verify the email lists executes. That alerts them to the fact that you a) are a real user and b) are a user who reads spam. Having your email automatically open also increases the likelihood of email client automatic exploitation. None of those are good, so turn off the preview pane.

2) Don’t put email addresses or sensitive corporate information into out of office emails. If you are out of office, just tell them the name of who to get in contact with. If they know anything about your company they’ll know how to get in touch with the front desk and use the person’s name to get in touch with them. A number of times people have set out of office messages with stuff like, “If you need information on super secret project x please contact….” Firstly, that’s bad if it’s someone who doesn’t really know you (sales people, etc…) secondly, if it contains email addresses those too can be scraped by the spammers who watch the return addresses for bounces.

3) Use domain keys, SPF (sender policy framework) records or other tools to reduce spoofing. If you want to allow people to know if you are legitimately sending email from all users on your domain without causing them too much grief, install domain keys or use SPF records to reduce the likelihood of people successfully spoofing your email. PGP signing is great but it only works for the one person using it, unlike domain keys.

4) Unlike what the article says do NOT use Yahoo or Hotmail as methods to send anonymous emails. Both send headers showing the recipient where you are originating from. Use something like hushmail instead.

5) Create custom email accounts for specific applications. I’ve seen a number of people who have begun building out vanity email addresses based on the specific site they are visiting, EG: ha.ckers.org@mysite.com

6) Validate users who are allowed to send email to you. This is an ugly one but by only allowing people who you have authorized to email you you can significantly reduce unsolicited email. You had better not use one of these accounts for anything you want to get electronic receipts for, but for personal accounts it’s a pretty decent solution.

7) Use a fake or modified name on each site you visit. If my name is “John Smith” I could use something like John Petsmart Smith will allow me to know that Petsmart has sold my email information when I get spam or phishing emails in the future.

Anyway, there are dozens of ways to secure your email. I’m sure everyone can contribute to this list. It’s a huge topic, that they really only scratched the surface of.

I’ve got mixed feelings about writing this, so I’ll try to stay as objective as possible since I know this is a religious issue amongst some developers. I ran across an email to the www-html list by Shane McCarron talking about how HTML is well… maybe you should just read it for yourself:

Okay, okay… I give up. You are right, I am wrong. IE is broken and everyone uses it, so we are screwed. There’s a shock. Let’s all roll over and keep using 1997 technology and hacking around using weird-ass abstraction libraries to implement “Web 2.0″ (gag-me) on top of incompatible underlying implementations rather than attempting to help the Internet evolve toward something light-weight, fast, and extensible like XML/XHTML.

Tag soup is sooo much better.

Honestly, people. You all disappoint me. But you are right - the HTTP spec does permit this broken behavior and I did not know that. In my world I always personally ignore */* in the accept header. Groups like the OMA have declared that you cannot use it that way for this very reason. Its silly. Oh well.

I will continue to use XHTML ’cause it works well, really it does. Or rather, it works no worse than anything else and it is forward looking. You all do whatever you want. I can sleep at night.

Despite being a little mouthy, there are some good points in here. HTML is really one of the most complex languages out there. It’s nearly impossible for a human to read something and know what it says without the aid of a rendering engine (and often I find people are amazed at what HTML is capable of - in a bad way). I don’t care what anyone says, HTML is not an easy language. Click here and view source to see what I mean (and this isn’t even that complex of an example).

From a web application security perspective it’s just as complex. Knowing what HTML has JavaScript in it is tough but try finding text has a bad word in it. Forget it. Maybe XHTML is the answer. Maybe a new version of the entire protocol is worth thinking about. I know it would mess a lot of things up in the short term, but from an information security perspective it would make it a lot easier to know what the user is submitting and how the page renders if we start talking about a real standard instead of the makeshift proprietary rendering engines that we have come to know and love.

Sometimes I really have to thank my readers, because they are just as educational to me as I may be to them. Here’s a case in point. Regarding my last post on stopping password theft by key loggers I got a really well thought out email by Steve Smith that I’m just going to have to cut and paste. I should have guessed someone had already encountered this problem before I did and there is some pretty crazy math involved. Here’s his email:

About the hole: it’s a classic computer science problem commonly referred to as the “longest common subsequence problem.” It’s not hard to make a program that works it out, and there’s plenty of code out there already that solves the problem. Interestingly, your examples’ LCS is “snjoopy,” which makes me think that if you were consistent with the extra typed characters that hole would be effectively plugged.

Consider if an attacker, instead of receiving 3 different strings with the password embedded in them, received 3 strings that were exactly the same. The LCS would simply be the entire string, and if the attacker wanted to try to brute-force it there’d be 2^n possible passwords (n being the length of the string containing the password). Your examples had lengths of around 25, so that’d be a pretty large search space. If the actual password were trivial (a single word or name, for example), the attacker could first brute force against a dictionary to reduce the search space, but anything non-trivial would be effectively protected, as far as I can see.

Granted, that level of password protection is pretty close to tin-foil-hat level of paranoid, but it makes me wonder if it would be possible for web browsers to simulate key presses in order to automate this kind of security. It could generate a hash of the URL (or somehow generate extra characters in a consistent way) and simulate key presses in between actual key presses during password entry to obfuscate the password. It would protect against key loggers and prevent the kind of analysis you described from figuring out the password from the obfuscated string. The only hitch I can think of would be how to handle when a user backspaces over part of the password and re-enters it.

It seems like a good idea, but I don’t really have any experience in this area to know if such functionality would even be possible.

Wikipedia has a good article on the LCS problem (http://en.wikipedia.org/wiki/Longest_common_subsequence_problem) if you’re interested. Also, if you want I can send you the Java code I made to solve the problem. I whipped it up just to quickly figure out the solution for your set of strings, but even without any attention paid to optimization it found the solution in a second or two.

Very informative, thank you Steve. And I think this proves an interesting point that a) the LCS for the strings are confused by consistency and b) it’s trivial to find the results in just a few seconds. What more can I say?

I ran across this article by Cormac Herley and Dinei Florencio today on how to protect your password from keystroke loggers. This is actually a very brief PDF that explains a simple concept in a very concise way. That said, it’s still pretty creative and I only found one non-obvious flaw with it.

The basic premise is that if you take a password and you obfuscate the logging of that password by clicking on random other places on the same page in between typing characters of your password you have now successfully stopped the attacker from knowing your password. Okay, now for the hole. If you receive a password that looks an awful lot like a string of random characters and it’s much longer than a traditional password changes are this is either a mistake or you’ve found someone trying to keystroke log your password.

That might seem like no big deal to the casual observer and on a one-off basis that might actually deter any reasonable attack against the password. But what about the second time, and then the third time? Let’s pretend you are an attacker and have a keystroke logger reading passwords. Over time you saw these strings over time:

www.hotmail.comasdf@fdsa.comw~eslkanij1o2h4oz3hphaky

www.hotmail.comasdf@fdsa.comasjsnkjna@joalkosjdpasony

www.hotmail.comasdf@fdsa.compsps1uhnu2jozuzo2!$p#lzy

That might not look super crackable with the naked eye, but programmatically it’s trivial to see the pattern in that. Each contain the exact same characters in the exact same order. The string “snoopy” is embedded in the content of the three unique strings. Don’t believe me? Let’s walk through part of the logic.

The first password starts with a “w”. Let’s walk down the second password and see if it shows up there. Hmm… nope. Guess that’s not part of the password. In fact let’s just look for all the characters that don’t show up in all three passwords and re-look at the same passwords (letters that are not repeated all three times are replaced by _ in the example):

www.hotmail.comasdf@fdsa.com___sl__n_j_o___o_3_p___y

www.hotmail.comasdf@fdsa.com_sjsn_jn__jo_l_osj_p_sony

www.hotmail.comasdf@fdsa.compsps___n__jo___o___p_l_y

Now you need to look for which strings are in order and match up with one another. There is a “s” followed by an “l” in all three examples, but there is no sln in all three examples so that’s out. So now you have to decide if the s or the l or the n or the sl or the sn or the ln are in all three. Anyway, you can see where I’m going with this. In just a few iterations you can come up with just a few possible combinations of potential passwords. Then using the password policies of the websites you can find the most likely password. One more quick point, this example above is only using three passwords. The more you have the easier the analysis becomes. So without insuring that the obfuscated password is identical each time it would be trivial through statistical analysis of the obfuscated password to identify the real password.

But really, who’s going to go through all that work? Yes, this is a clever idea, and yes there is a hole in the idea, but I’m not too worried about anyone figuring it out without long term analysis of the passwords used. Pretty cool paper! I’ve always been interested in password security. Maybe some day I’ll release my version of this paper talking about another form of obfuscation that has proven to get past all keystroke loggers too. Unfortunately mine is even easier to break than theirs is, so maybe I’ll leave that one for another day.

SecuriTeam released a pretty interesting issue with how search engines can be used to perform attacks on your behalf. This is exactly the sort of problem I have with automated crawling. Just the other day I was talking with Kyran about one of the major reasons I never liked Opera as it was being released. Pre-fetching (which is an aweful lot like crawling) forces your browser to move ahead of where you are and click every link, essentially, to make your surfing faster. Faster? Yes. Safer? No.

In this case, Google is being used as a proxy for PHP include hacking. It is being used to inject PHP into unsuspecting websites by way of following links off the internet. Didn’t Google’s mom tell it not to index strange websites? This may be an easy one for Google to fix - just by having a list of all known exploits and not indexing those. Eesh.

Anyway, it was an interesting issue, that I’ve definitely thought about before, and we’ve already seen in the case of XSS and of auto delete functions, where Google will delete entire websites, because it clicks on every link (and those links perform whatever function they would normally perform under any user controll). Not the best website design, but in the case of PHP includes, I don’t see how webmasters can really do much to protect themselves other than not using canned scripts with issues in them. Not a great answer to be sure.

There are other variants of this attack as well, and I’m sure you can all think of one or you on your own, but ths is also similar to the XSS proxy stuff we’ve talked about. Getting third parties to hack on your behalf is starting to become more mainstream, I guess. Anyway, nice article from the SecuriTeam folks.

I happened upon an article last night talking about how to access blocked websites. First of all, this is sorta missing a major component that most people are actually concerned with, which isn’t just how to access it, but rather how to access it and not get caught. Generally you don’t want to be accessing a website through a content filter and still set off alarm bells. The content filters in place are set up by governments, your place of work, your school or otherwise people who can negatively influence your life for looking at questionable websites.

Let’s walk through the list on that website and punch a few holes in it:

First they say to use anonymizer. Anonymizer is almost always bocked by content filters, so forget that one. Yes there are anonymous CGI scripts out there, but if your content filter works on keywords this is pretty much out.

Secondly they say to type the IP address of the website in. Okay, but how did you find out the IP address of the website? Presumably you did an nslookup on it? So now you have to ask yourself is your content filter watching outbound traffic on port 53? Or are they looking for strings like “nude” “xxx” “bombs” or otherwise sniffing the unencrypted traffic? Are you querying their name server or your own? And lastly, is the website in question even listening on an IP without requring you to send host headers? If they wanted to stop you from doing this, it would be very easy to do if this is the only trick you used.

Third he says use tinyurl or other redirection services. I don’t see how that could possibly fool a content filter. He’s claiming that the URL bar doesn’t change. Either it’s embedded in an iframe or otherwise concealing the page that is being rendered. That doesn’t mean your browser isn’t sending HTTP headers that the content filter can read. This one is just flat wrong. Beware people saying that redirection services make you secure. They don’t. At best the hide the referring URL (META refresh), at worst they do nothing (301 redirection).

Fourth he says to use Google Mobile Search. This is probably one of the few that might actually work, assuming the content filter isn’t keyword based. I won’t talk negatively about this, except that it is a really hobbled experience, and will dramatically reduce your browsing experience.

Fifth he says to use the cached version on Google or Yahoo. Ouch. A) keyword filters will still pick this up, B) Guess what, Google doesn’t cache any embedded content, so you still send headers for the images, the CSS, the JavaScript and any other embedded content, all of which will be blocked, if the content filter is set to be indistriminant about the file types (which most are). You’ll definitely get caught doing this.

Sixth he suggests using Google’s translation service. This has all the same problems as the cached version. Don’t use it for actual privacy.

Lastly he suggests using a proxy server. If the content filter allows you to use a proxy server and it is not the proxy server itself, this might work, assuming there are no keyword content filters. I mean, really onion networks work on this premise, but we’ve proven that this is a pretty easy thing to detect in some recent conversations on sla.ckers.org due to the fact that the tor networks have been mapped. Still, this might be your best hope.

There’s some end comments on that page discussing issues with the Chinese firewall, which clearly he doesn’t understand as the Chinese firewall primarily works off of keyword filters and is trivial to evade, and it’s not particularly relevant to the discussion anyway. If you want to evade the chinese firewall use peekabooty, Tor or SSH forward your connection, or simply rot13 everything because it cannot detect even the most simple obfuscation.

Anyway, I’m not trying to pick on the guy, but there is a lot more to anonymous surfing than meets the eye. Don’t take advice on anonymous surfing from people who don’t understand how the Internet works. Especially if your job or your life depends on it.

“RU @ Gmail.ru”? I’d love to work in marketing for the newest domain squatters to hit the press. My bet is on that Gmail.ru is a target for aquisition either way, but now they’ll be a lot more expensive than the cost of a simple domain name registration. I’m not sure what the international copyright laws are for Gmail, but my guess is that Google will have a fight on their hands if they want to buy this one. Gmail.ru claims to be able to handle 10,000,000 users. Even if they can’t it sounds good.

Perhaps there is an interesting loophole there, where trademarks can be squatted on in countries that don’t adhear to trademark violations. It doesn’t sound like a great business to be in, but presumably Google would pay more than a few dollars for that trademark and to get the super dorky Gmail.ru logo off what they probably percieve as their domain (not that I’m in love with Google’s slighty fruity rainbow colors either, mind you). And rightfully so, this is pretty obviously a rip-off. You decide for yourself:

It’s the same story over and over again. If you have a big brand register your domain everywhere. Yes, it’s expensive to buy foreign domains, but if you are net-ing a billion a year I think you can shell out a $30k a year for all your domains to stop squatters.

Anyway, good job to the Gmail.ru crowd. Even if it might be a huge nightmare to deal with the legal battles ahead, I laughed out loud when I saw it.