There’s an interesting link over at Network Blog talking about a survey done of a number of office workers who were completely unaware of the risks involved with email security. Namely most of the users interviewed were happy to open any email they got and even worse click on links regardless of who sent it.

They then link to an article at Application Security Blog that discusses how webbugs work in the context of emails. Email clients are becoming more and more resistant to this trick now a days because they now ask if users would like to download images. Of course there are ways to circumvent those security measures (consumers preffer convenience and will turn almost any security measure off if they can if they don’t understand how it’s protecting them).

As we’ve seen malware is pretty prevolant these days - (at least 1/10th the spam I get has .zip or .src or other horrible attachments). Of course this goes beyond the realm of Outlook, Lotus and Thunderbird to the realm of Yahoo Mail, Hotmail and Gmail. Scanning attachments for viruses is one free service that a lot of these webmail clients offer, but it certainly doesn’t offer security from zero-day exploits - so one off targeted attacks will always be possible. And of course there are phishing aspects, or simply links that lead to malicious websites with all sorts of consequences (like the unsubscribe link and the JavaScript port scanner).

Email is a pretty scary medium these days. Part of the problem is that email clients and web browsers are becoming more full featured as user demands on functionality rise. These issues are only partially under control at the moment, but the interaction between software is becoming more and more complex and it is only allowing more and more vectors as a result. The fact that email can call the web is an issue, but there are tons of other applications that are starting to do the same (even things as obscure as online games). It will be interesting to watch these vectors morph as user interest in the mediums shift. Instant messaging is a great example as it gradually overtakes email in popularity and as it becomes more and more feature rich.

On the drive to work today, I started wondering what it would take to stop cross site scripting. Not from a website perspective - because god knows that’s such a huge task it would take forever to accomplish. But rather, what would happen if all the browsers, on the same day at the same time decided to shut off remote script includes? That would be great from a web application security perspective, but what exactly would break if that happened? A lot is the short answer, but here are a few things that make Fortune 500 type companies rely on it:

Analytics Yup, you can thank the likes of Google, Omniture and Hitbox for making JavaScript counters that do more than count, but also gather statistics that are only availible in JavaScript space. If remote JavaScript was turned off the only alternative would be to include some local proxy, to call the local dynamic page and proxy that information back to the analytics programs. Even huge companies would rather use their data warehouse only for auditing or spider analytics (which fly under the radar of JavaScript reporting systems) and use these JavaScript includes as the primary source for information about their site.

Contextual Banner ads Here you can thank the banner companies (Google and Overture primarily) for increasing the placement of dynamic banner ads all over the web. In doing so they have made a huge dependence on remote JavaScript for revenue generation (this site is no different).

AJAX Information super-highway 2.0, here we come! Tons of applications are starting to request off host XML files to include in their website. It’s the new way to deliver content without refreshing the page. If we got rid of it, what would happen? Well, we’d probably go back to refreshing the web-page, or using some other cross domain software, like Flash. I doubt anyone is giving up on this one any time in the near future.

Akamai I love Akamai in concept. Caching is a huge part of performance on big website design. If you can throw your static content, like images and, oh, JavaScript on remote hosts that cache that content for you, you can dramatically decrease load time and processor power. It’s sexy, and it’s here to stay. Too bad it forces me to allow JavaScript from everywhere if I want to see “Hello, RSnake” on the top of the websites I visit.

Page load and SEO Going hand in hand with Akamai is that big companies don’t want to include all the JavaScript on their page because it dramatically slows down the time it takes to render the page. The reason is because it is not cacheable if it’s a dynamic page (which large companies typically have a lot of). Also, if you are very bandwidth conscious and you have a ton of cookies you don’t want their browser sending those cookies over and over again (typically upstream is always slower than downstream too), so you are better off keeping the JavaScript off host so cookies aren’t sent in transit on every request. Additionally, spiders discount JavaScript in terms of SEO (search engine optimization). So keeping JavaScript on the page reduces the relevance of the content on your page.

All of those things together (and probably a lot of other things I haven’t thought of as well) make it pretty clear that there’s no way big companies are going to lobby the browser companies to shut off remote script sources. They want them. It’s good for business. It’s terrible from a security perspective, but there you have it. There are mitigating factors, sure, but the concept isn’t going away. And speaking from experience, you can’t surf without JavaScript turned on all the time. Tons of websites force it (thanks, Adsense and Orkut!) forcing their users into a lower state of security, regardless of their intentions. So we continue to fight the issues on the server instead.

There was an interesting post today on modernlifeisrubbish.co.uk discussing how to crash Internet Explorer in one line of JavaScript. It’s a pretty interesting one line of JavaScript, but it more or less just sends Internet Explorer into an infinite loop. I’ve seen similar issues in Firefox, Opera, Netscape, etc… so I wouldn’t call this a major make or break deal, but it is nice to know you can safely crash the browser every time reliably.

I’m particularly interested in how DoS can affect user input though. There has to be interesting ways to use this towards breaking applications although I haven’t found any practical applications beyond after a MITM attack has succeeded and you want to avoid conflicts by killing off the user’s connection, or surfacing so many alerts that they inadvertantly click on something that executes malware. I’m sure there are other applications, but I just haven’t spent enough time thinking about it.

Last month Sarah and I had a discussion regarding weak password policies. Sarah mentioned that there are ways to improve password security by using policies, and I argued that that is true only in terms of time to crack, and not in terms of actual keyspace in many of the cases I have seen. I really feel like I should give more information on this because it’s a complicated issue and I’ve recently run into a few great examples of this. But before I get started there was an email I recieved that’s probably worth a read:

Hello, I’ve been visiting your site for a few months now, and love your ability to constantly come up with new security issues. A few weeks (maybe a month), you posted a message about Facebook being harvested for data by 2 individuals. I followed the link, and copied the master file they created. At first I had the semi-malicious intent to enter users information (mostly if they had Myspace accounts) so I could advertise a bit, or get a laugh.
I ended up deciding to pursue checking passwords for statistical purposes on password issues. I wrote a program to run through the 1,280 email addresses listed on the file, request a search on Myspace to detect if they were users, found 840 Myspace users out of the list, and then attempted to login “by hand”. A large portion of the time the password for their Myspace was the same as their email, or if it wasn’t, and I could access the email, I could simply request the password. I had the intent to go through all of them, and then generate a page for my site (without
their passwords) listing wiether or not access was easily obtained to their Myspace, their email, and if their email passsword was the same as their Myspace password. I’m not a Myspace user, but I figured it’s a very large network with millions of “noobs”.
Perhaps you should address these password concerns on your site. A good portion of passwords were birthdays, “password”, years, or parts of their email address. If I weren’t afraid to get caught doing this (because proxies were taking too long so I did it without one), I’d most likely go through all of them, and write out the statistics.

It’s true. Users tend to use the same passwords everywhere as a statistic. Either that or subtle variances. I can’t spout statistics, but in anecdotal experience I’ve seen upwards of 20% of users use the same password everywhere, and closer to 50-80% use the same 5-10 passwords everywhere. The remainder either use part of the same password everywhere with a subtle difference in the front or the end of the password, or completely random passwords. That’s still such a high statistic that it’s statistically probable that if you have someone’s password from a webboard you also have their password for their email and their work account, etc…

But let’s take a quick second to look at password policies. I was reading through the new Web Application Security Exposed book and it mentioned the last four digits of your social security number as a common password policy. That’s an impossibly small keyspace. You went from 8 chars of 64 possible combinations per digit = 64^8 = 2.8 x 10^14 down to 10,000 That’s not even a fraction of a percent as large a keyspace. Meaning the time it would take to crack that password is down to a few seconds max. But let’s take it one step further. What’s the worst password policy I’ve ever seen? The month and year of your birthday.

Let’s look at what that would consist of. Let’s say I was born in January, 1978. That means my password would be “0178″. You’d think that would be the same keyspace as the last four digits of your SSN above, but no, it’s far worse. First of all there are only 12 months in the year. So okay, that would be 12*100 = 1200, right? Wrong. If you are looking at the average user population of an internet application it represents people less than 65 on average. So 12*65 = 780, right? Well, no, because I haven’t seen many 2 year olds on the net either. So let’s say 12 to 65 year olds represent the target = 53 years times 12 months = 636 combinations. Yes, 636 combinations! That’s an insanely small amount of possible guesses. Now, if you are running a targeted attack, you could actually check dating sites or horiscope sites to get the user’s birth month (or two if you are talking about astrological signs) and now you probably know the approximate age of the victim, you could be talking about a keyspace of 106 combinations or less!

Now let’s take another example of where password security actually acts as a detriment to overall security. Not too long ago I saw Grid Data Security - which attempts to secure websites from phishing by asking them to click buttons on a webpage to denote which corresponding number is associated to which letter (and it changes). It’s too complicated for me to explain here, just look at the site to get the full explination. The point is it changes the password from any letter or number combination to only a number combination. So instead of 64^8 = 2.8 x 10^14 you have 10^8 = 10 Million! That’s an insane reduction in security. Add onto that that to phish the password all you need to do is to ask the user a few times and do statistical analysis on the answers by rotating the numbers and focusing your attack on only the possible letters that the user could have typed in. Add onto that the fact that the passwords must be availble for comparison so they are no longer hashed, making database security a much larger concern. The point is, for all it saves the user in reduction in possible fraud it totally hurts user experience and greatly reduces overall security.

This is a typical case of shifting security issues or at minimum making it unusable (like physical devices - “Oops, where did I leave my token?”). This is a super common issue with password security, and one I have not seen solved by anything effectively to date.

While trying to answer a question on the web application security forums, I was going back to find a possibly archived link on the Internet Archiver. While playing around with Internet Archiver I noticed they had a pretty boring XSS exploit in them:

Here is the XSS exploit. As I said, pretty boring. But then it occured to me there is an old SEO (search engine optimization) trick that uses this engine. First, let me start by saying, I know there are ways around this - like turning off JavaScript. It was just something that sprung to mind.

One of the ways SEOs make money is to buy recently expired domains. Then they go to the internet archiver and input that domain. They crawl the entire internet archiver for all the content on the site, and then restore it back to it’s original glory. The external links are still valid, and the pagerank slowly goes back to the way it was before the site changed ownership. Once the pagerank is good and high they can switch it to whatever they want and monetize it as they wish. The original owner is powerless at this point.

But it occured to me, if I have control over the output of the page, I could theoretically change what the scrapers see. I could add external links, or change them around. If I thought they were going to do it by hand, I could include JavaScript to make their day bad, or something as simple as spawning an alert to me elsewhere using a remote JavaScript include. It only relies on the original URL string containing that malicious code - and who’s going to include XSS on every single URL?

But then it got me thinking, there are other (probably easier and more effective) ways to do this, including IP delivery to the Internet Archiver bot. You could put up heavy drug spam stuff, so that if someone ever steals your domain they’ll be hosting spam instead of your original content, or running malicious JavaScript or copywrited materials. All of which preclude them from having a legitimate looking domain based on your content.

Phaithful sent me an interesting bit of what looks at first glance to be spam. Normally I don’t care much about this stuff, but this was actually fairly interesting as it uses social engineering to ask users to click an unsubscribe link (something I typically don’t do as that is a way for spammers to verifiy that your address is valid). Upon clicking the unsubscribe link you are taken to a page with four embedded iframes. Those iframes run a series of JavaScripts that attempt various exploits (one of the files was named metasploit.exe… so that should give you an idea).

Proceed to this URL with extreme caution, it is definitely not benign.

It always is interesting to see a shift in tactics though. Using obfuscated JavaScript is not new. embedding malware into pages isn’t new either. But what is new is using an unsubscribe link to sucker people into visiting the page in the first place. Yet another reason to not click on Unsubscribe links. I guess the CAN SPAM act is the newest tool in virus writer’s toolkit. Educating users that unsubscribe links must be present and function is just anther tool in the arsenal now.

As I’m nearing completion of my XSS fuzzer for people, I’m finding more and more interesting issues. Just so you know I’m not keeping everything from you all, here’s another interesting problem I uncovered. Sure you remember the original problem with US-ASCII encoding, where a character could be modified and in US-ASCII it would render as a open angle bracket, or any other character, if you encoded it correctly. Wellllll, it just happens that that is only one very small problem it turns out. Sure you can look for everything higher than 7F (or 127 in decimal) and less than FF (255 in decimal) and kill it but that won’t solve your problem. One of the tests I ran was:

[CHAR]IMG SRC="" onerror="XSS_ME([DECIMAL-CHAR])">

Where [CHAR] was an enumerating list of characters and [DECIMAL-CHAR] was the decimal representation of that character. I expected to only find 60 (the decimal representation of the open angle bracket, and the additional character 188 (the US-ASCII issue that Kurt Huwig found). Alas, there was far far more vulnerable characters. Here’s the list:

188, 316, 380, 444, 508, 572, 636, 700, 764, 828, 892, 956, 1020, 1084, 1148, 1212, 1276, 1340, 1404, 1468, 1532, 1596, 1660, 1724, 1788, 1852, 1916, 1980, 2044, 2108, 2172, 2236, 2300, 2364, 2428, 2492, 2556, 2620, 2684, 2748, 2812, 2876, 2940, 3004, 3068, 3132, 3196, 3260, 3324, 3388, 3452, 3516, 3580, 3644, 3708, 3772, 3836, 3840, 6588, 6652, 6716, 6780, 6844, 6908, 6972, 7036, 7100, 7164, 7228, 7292, 7356, 7420, 7484, 7548, 7612, 7676, 7740, 7804, 7868, 7932, 7936, 10684, 10748, 10812, 10876, 10940, 11004, 11068, 11132, 11196, 11260, 11324, 11388, 11452, 11516, 11580, 11644, 11708, 11772, 11836, 11900, 11964, 12028, 12032, 14780, 14844, 14908, 14972, 15036, 15100, 15164, 15228, 15292, 15356, 15420, 15484, 15548, 15612, 15676, 15740, 15804, 15868, 15932, 15996, 16060, 16124, 16128, 18876, 18940, 19004, 19068, 19132, 19196, 19260, 19324, 19388, 19452, 19516, 19580, 19644, 19708, 19772, 19836, 19900, 19964, 20028, 20092, 20156, 20220, 20224, 22972, 23036, 23100, 23164, 23228, 23292, 23356, 23420, 23484, 23548, 23612, 23676, 23740, 23804, 23868, 23932, 23996, 24060, 24124, 24188, 24252, 24316, 24320, 27068, 27132, 27196, 27260, 27324, 27388, 27452, 27516, 27580, 27644, 27708, 27772, 27836, 27900, 27964, 28028, 28092, 28156, 28220, 28284, 28348, 28412, 28416, 31164, 31228, 31292, 31356, 31420, 31484, 31548, 31612, 31676, 31740, 31804, 31868, 31932, 31996, 32060, 32124, 32188, 32252, 32316, 32380, 32444, 32508, 32512, 35260, 35324, 35388, 35452, 35516, 35580, 35644, 35708, 35772, 35836, 35900, 35964, 36028, 36092, 36156, 36220, 36284, 36348, 36412, 36476, 36540, 36604, 36608, 39356, 39420, 39484, 39548, 39612, 39676, 39740, 39804, 39868, 39932, 39996, 40060, 40124, 40188, 40252, 40316, 40380, 40444, 40508, 40572, 40636, 40700, 40704, 43452, 43516, 43580, 43644, 43708, 43772, 43836, 43900, 43964, 44028, 44092, 44156, 44220, 44284, 44348, 44412, 44476, 44540, 44604, 44668, 44732, 44796, 44800, 47548, 47612, 47676, 47740, 47804, 47868, 47932, 47996, 48060, 48124, 48188, 48252, 48316, 48380, 48444, 48508, 48572, 48636, 48700, 48764, 48828, 48892, 48896, 51644, 51708, 51772, 51836, 51900, 51964, 52028, 52092, 52156, 52220, 52284, 52348, 52412, 52476, 52540, 52604, 52668, 52732, 52796, 52860, 52924, 52988, 52992, 55740, 55804, 55868, 55932, 55996, 56060, 56124, 56188, 56252, 56316, 56380, 56444, 56508, 56572, 56636, 56700, 56764, 56828, 56892, 56956, 57020, 57084, 57088, 59836, 59900, 59964, 60028, 60092, 60156, 60220, 60284, 60348, 60412, 60476, 60540, 60604, 60668, 60732, 60796, 60860, 60924, 60988, 61052, 61116, 61180, 61184, 63932, 63996, 64060, 64124, 64188, 64252, 64316, 64380, 64444, 64508, 64572, 64636, 64700, 64764, 64828, 64892, 64956, 65020, 65084, 65148, 65212, 65276, 65280, 65340, 65404, 65468, 65532

Forgive the mess, but yes, all those characters can substitute for an open angle bracket, and run HTML and your cross site scripting vectors. Looks like theres tons of other problems to look for. Thankfully US-ASCII encoding is not that prevelant (about 1% of Fortune 500 by our estimates), however I’ve only just begun my testing. Almost everything I’m trying works, which is pretty scary. Lots more to come…

Here’s another one of the failed attacks on ha.ckers.org. I copied the file in case anyone wants to do forensics on it. It’s located here. The odd part is that it is a .gif file. I’m not sure what filter they were attempting to evade by renaming the file, but it didn’t do much.

Is anyone cataloguing this stuff? Should I continue to post it? If not I’ll save myself the trouble, but I wanted to keep it here for any of the AV guys who visit the site. They may get more out of this stuff than other people.

Jeremiah Grossman sent me a link to his blog where he went into more detail about the FireFox extention revealer. He built upon mine quite a bit and got a much better version of it working. His has gone beyond the basic proof of concept and is much more useful and quicker from what I can tell. Here’s a link to his post.

It still feels like there are a lot of vulnerable plugins to research. IEView was not the only one, I promise you that. I’d be curious to hear if anyone is actually doing research on the extentions themselves, now that we can detect them.

According to Matthew Wollenweber there is another MySpace worm variant on the loose. Was that really a surprise? It uses a phishing attack to request users enter their username and passwords. I haven’t seen the actual vector yet, so I cannot properly analyze it, but the payload is in the URL and if it gets taken down I’ve made a copy here.

There’s no word as to the number of compromises due to the phishing yet as far as I’ve seen. Worms are becoming pretty prevolant on social networking sites lately, huh? Interesting. We’ll see how this plays out but to me this feels like kitten play, and the beginning of much worse things to come.