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.

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.

I ran into an interesting article on SANS that I think proves an interesting point in the next generation of JavaScript Malware, which is browser dependant and self-dependant decoding. This article explains two techniques used by the malware author to return different values depending on how you attempt to dump the code in a visible way, as well as dependant on the browser you use. This is a very interesting read, because it seems like this is the first time the SANS guys have done this which makes it for a more interesting read than it would have been if I had said the same thing, as well as the fact that it describes in pretty good detail about the deobfuscation issues they ran into themselves.

I too use nearly the exact same methodology as the author does. Unfortunately there is no good tool that I have come across like a JavaScript decompiler that would have completely obviated this issue. The closest I’ve come across is a decompiler that is based on having no dom whatsoever (not particularly useful when we are talking about a web-page). It would be interesting to have such a tool, though, because it would make it possible to traverse a JavaScript function without worrying about it actually executing without warning. Sure, you can do other things like watch the HTTP traffic in transit (easy enough to do) but that may not be enough information (perhaps it calls different sites at different times of day, or based on your browser type, or your screen width or any of hundreds of other variables).

Of course a decompiler would have similar issues, because it would still only follow a specific path based on the variables you had off hand, so perhaps that’s not the best way to do it. Another possibility is measuring relative entropy. If a JavaScript function has high entropy, it could be considered untrustworthy. Of course then the Malware author could submit a lot of nulls or whitespace or other characters to be stripped which would bring the entropy down to much lower levels. All of these ideas probably need a lot more thought, but JavaScript really is beginning to show off how obfuscation really does make straight detection much harder.

Well, it was just a matter of time, but there are finally some reports of a fake google toolbar executable that hides a trojan horse.  Great!  Well, I always knew it would happen, and I’ve been warning people for ages,  “If you put executables on your webpage, it’s just a matter of time before the phishers do the same thing.”  Thankfully the barrier to entry in building executables is still fairly high, making this a fairly small attack vector, but used in combination with hacking a big DNS could be huge.  Think about what a fake Microsoft Windows Update could do in terms of numbers!

This probably falls into the Pharming category rather than Phishing, as it doesn’t actually intend to directly compromise you by asking you for information, but it does try to get you to download something based on a brand that you are supposed to trust.  To my knowledge this is the first time this has ever happened.  But getting someone to install this toolbar could lead to information loss, but also to more phishing, because the anti-phishing built into the Google Toolbar will obviously be turned off.  Pretty nasty.  Executables are pretty nasty.

I’m still waiting for a day when there will be a single signing authority for executables so you can know what is real and what isn’t.  Google Toolbars should be signed by a central authority, and your machine shouldn’t even let you download it unless you know where it comes from and can verify that.  That might be a pipe dream, and that would kill a lot of the little guys, but if it at least warned you that it wasn’t signed that might give people a clue that it wasn’t Google.  Either that or they’d just click through.  This is frustrating, because there isn’t really a good answer, other than better detection of fraudulent websites claiming to be big brands.

Several years ago I read a paper called Owning the Internet in your spare time. Besides being the single best security paper I’ve ever read coming out of a college, it opens the door to a new classification of viral propogation in the security community. The basic premise is this. Traditional viruses travel in a very innefficient manner. They scan a series of hosts either nearby their netblock or just start at a single point in the entire IP space and start scanning in one direction. Then when they find a vulnerable host they infect it and start scanning in the same place all over again. As I said, super innefficient. The concept of a Warhol worm is what Andy Warhol was famous for - “15 minutes of fame“. A virus that could propogate in 15 minutes globally.

Now in spite of the great premise of the paper above, it still lacks some reality (in talking with some viral genetic researchers). There are two things that make this paper infeasable. The first is that it requires users to have their computers on. Typically that is a follow the sun model. The fastest you can get a worm to travel is slightly less than the time it takes for every computer on the planet to turn on and be infected (approximately 24 hours). The other problem is network traffic. If you have every machine in the world probing for computers, it can take down huge sections of the network, so you have to have some mitigating factors to make sure only high bandwidth hosts are capable of scanning large chunks of the network and stay relatively geographically close to their origin until the next time zone is awake. The first example of a Warhol worm (or Flash worm) was the SQL Slammer worm which used a psuedo-random number generator for propagation.

So assuming you could figure these issues out (they aren’t that difficult - but I’ll leave it as an academic excersize) how does this affect cross site scripting (XSS)? Let’s take a look at the MySpace Samy worm for a second. That affected 1MM users, in a fairly non diverse location (mostly users in the United States). 1MM users is a LOT of infected machines, but still not enough. Let’s take it one step further. Let’s pretend for a second that there are users who have access to multiple websites that are similar to MySpace (it stands to reason that if a user is accessing MySpace they probably have other accounts elsewhere as well). Finding vulnerabilities in multiple platforms should be relatively easy (it has been historically anyway).

Now let’s say instead of simply just attacking MySpace, the worm also attacks MyYearBook.com or another similar social networking site with another significant amount of users. Suddenly you have an XSS worm that can jump from platform to platform. Now let’s take it one step further, and say you find multiple vulnerabilities in social networking platforms located in every time zone around the world. If you tie them together you now have a social networking XSS worm that can leap from platform to platform and infect huge chunks of the global population. Now, let’s take it still one step further and say that we can embed certain exploits in known open source applications like PHP nuke, etc… Scanning the local IP space, using a search engine with the keywords that match a likely candidate for exploit then connecting the browser to it and attempting to exploit the vulnerabilities could make a worm that could theoretically attack nearly every computer on the internet that was used by an internet facing user.

Instead of affecting 1MM users it could be 1 billion users, and it wouldn’t have to have much genetic diversity to do that, because it would only have to survive for one day. The ramifications of a worm like that propagating across the internet could be disasterous. The payload could be something as easy as a DDoS, or the largest phishing platform mankind has ever seen, or even as stupid as just flooding the global network for a day (anyone need a vacation day?). Critical infrastructures could not handle and additional billions of requests a day (and I doubt the search engines themselves could handle the billions of additional searches being performed), which could easily flood off tons of networks, particuarly the smaller ones, even with no payload. The cost to businesses could be in the billions.

It might not be 15 minutes of fame, but 24 hours of infamy is probably just as scary. I’m really trying to hold back on my fear-mongering, but this isn’t fiction - it just hasn’t been built (yet).

One of the main problems with detecting cross site scripting (XSS) is that it is not an easy feat to traverse the document object model (DOM). Rendering engines are slow, and they are processor intensive. But let’s just suspend disbelief for a second and say that we could do exactly that. On every new submission to every form, let’s pretend we had enough processor time to execute each submission once and see the results before it was sent to the browser, looking for anything that might denote something malicious from a web application security perspective.

That would be great, in theory! I could suddenly remove obfuscation (the entire reason for the XSS Cheat Sheet) as an attack vector, because I could detect any possible variant, just by watching the DOM execute. Pretty slick, right? Well, no. Even setting aside for a second the problem mentioned above with processing power, there are other troubling issues with this.

The first is timed functions, or remote execution. The problem with JavaScript from a detection and parsing standpoint is that it is a full fledged language, that supports all sorts of interesting things. One of those interesting things is the ability to pull in remote information and do analysis on it. Let’s say I set up a JavaScript function specifically to pull in a remote image (from a server I have at least partial control over). If the image is over a certain height or width or the combination is just right, the JavaScript will execute malware. If you get really tricky you can use a combination of sized images as a decoding key for some enciphered peice of code. Here’s an example:

<SCRIPT>
image_1 = new Image();
image_1.src= "http://ha.ckers.org/images/kcpimp.jpg";
if (image_1.width > 1 ) {
// Execute malware
}
</SCRIPT>

Now, that pretty much puts to rest the notion that you could traverse the DOM and get the same results as the user will (once I switch the images out). So if I know you are going to scan my block of code prior to letting it get posted, I can simply allow it to stay put until that grace period is over. When I’m convinced that you won’t be scanning it any further, I’ll change the images out, and the code will execute for all future users, until I either change it back, or the code is removed.

There is still one other problem, which is that you have to pick a rendering engine to do this with. You’re now saying, “Well, of course you do! That’s a stupid thing to say!” Well which one would you pick? IE seems to have the most vectors that effect it and the highest penetration, so that would seem to be the obvious choice, but are you going to allow the Gecko (Firefox) only vectors to go through - thereby allowing double digit percentages to be infected by the malware? Tough choice, and certainly not bullet proof.

The remote execution issue is the biggest in my mind, though. Because the attack is now controlled by a remote device (an image or series of images) it is now out of the hands of the user to even decrypt if you so choose. Typically JavaScript is a very easy function to de-obfuscate, if you have the human eyes and time to do it, but in this case, if the images aren’t there or are different sizes, the decryption is meaningless. And even if you could scan every single input, you’d still be at the mercy of a timed function where the image changed after a certain point.

This could give a ceneral command and control aspect to XSS worms, where the central image controlled the timing function, as to keep the attack under wraps until the timing was right. This would be particularly effective in DoS attacks. The downside is that the single command and control is easy to remove - unlike self sufficient viral code which depends on nothing but itself and the machine for propogation and originating page for roots to continue growth.

In the spirit of my post on why companies shouldn’t use laptops like firewalls I did a little research on ways to mitigate giving users no access while still maintaining some level of control over Windows operating systems for when users need to install certain programs as administrator.  Then I came accross an interesting blog article that had a funny quote in it, speculating that it is in fact better to be a local user without admin privileges and without anti-virus than it is to be an admin with AV installed. In the same article he posted a link to SudoWN which is essentially sudo for Windows.

It’s a pretty clever idea, to allow users access only when it is known and intentional.  Of course there are unknown security holes in the system itself, and given keystroke loggers it sorta makes the point moot (yes you can build a keystroke logger in JavaScript even, no admin rights needed).  But it’s a concept worth exploring nontheless.