'Stealth' Worm Hinders Sandbox Analysis
Tuxedo Jack writes "The Register reports that the new Atak worm cannot be analyzed or debugged by antivirus companies without quite a bit of work, due to the author being sloppy with his or her code. Windows machines, as per the norm, are the only vulnerable ones, and it still requires user intervention to infect. Perhaps future worms will start including this 'bug' in their releases. We can only hope not." It doesn't sound like a bug at all, from the virus writer's perpective.
One possible method I would probably use (off the top of my head) is to find out the time elapsed between executing two instructions - the time would be fairly high if the code were being singlestepped to.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Anti-debugging techniques have been in use for a long time. As an example, I remember attempting to reverse engineer some (ahem) commercial code about 15 years ago on x86 (MS-DOS). The first problem I hit was they'd replaced the keyboard interrupt (INT 9) with their own handler, so my debugger no longer responded to keypresses. After I worked around that I then discovered that they'd used the breakpoint interrupt (INT 3) to implement some critical functionality. Normal users would never even know, but as soon as you're in a debugging environment everything falls apart.
To be fair, them replacing the keyboard handler wasn't an anti-debugging feature but it still had the same effect since it still rendered my debugger impotent. It sounds like this virus has a similar effect.
Of course it wasn't long before the debuggers started to provide ways to overcome these types of problems, but it was always a constant game of leapfrog and I can't imagine much has changed.
Thats one way of looking at it... if you like looking at it the wrong way.
It was intentional, there is no question of this. It's funny that they're calling the code sloppy, and I wish I had a copy of the virus to see if I can figure out why they're saying this.... but its obviously intentional, but barely genious....
Too much is being made of it... It's not a new technique outside of viruses, it's been mentioned further up the page, and personally I've dealt with programs that do the same thing, and effort always wins. You find the test traps, and you patch around them. It's not even any harder for them to detect, or add signatures in their virus definitions for, it's only more difficult to analyze what it does, but we know its a virus... so this is a non-news waste of time, the attention brought to it assures that more viruses will come equipped with a debugger check, and likely some virus writer will take the extra effort to make the code SO complicated/long/difficult to trace through (this may be the case with them calling the code sloppy) and a lot of extra $$ will be wasted and probably find its way into the cost of anti-virus software subscriptions....
It's not as if virus writers are the anti-virus writers bread and butter.... oh wait... yeah they are.
This comment should be Score:10
It has been awhile since a virus actually *did* something real bad to screw a user.
First Gen virii: Wipe hard drives, boot sectors, etc. For the most part, I haven't scene these for awhile...
Second Gen virii: Zombie annoying spam/dos crap that is annoyingly hard to remove. Slows the computer down but most clueless users probably don't even notice until one of us comes to clean off the 200 or so spyware/spam virus crap they have on thier machine...)
Next-gen: Random sentence inclusion into all word docs, change #'s in excel sheets, alter contents of address books, random data into access/sql databases.
That sh*t would be brutal to deal with.
Its one thing to know you have to restore from backups after a harddrive is wiped, or you just can't seem to shake the virus.
Its a whole other ballgame when the virus goes undetected for a month and the excel sheets you've been conducting your business with have been screwed with. Yeah, you can restore and recreate a month's worth of work, but how do you account for the decisions you've made with bad data over the course of that month?
Or even more fun, long documents you produce for meetings or public distribution. Embeded within are names harvested from your address book appended with a few choices words?
"Our gross margins have increased by 12% this last quarter and Larry Teasdale is teh suck."
Let's imagine a *really* slowly reproducing virus: one that attempts to infect just a single computer a day. Now, you *could* go even slower, but 1 a day is pretty slow, wouldn't you agree?
Now, on day 1, there might be only a single packet sent by a single computer. I don't think anyone is going to notice that. But at some point, a large-enough collection of computers will send out these requests, and it will get noticed.
The question is, how many infected computers do you need before your attack is detected? If it's something like Code Red, a few thousand will get noticed: they spew out too many requests. One a day? It's harder to say. Will someone notice when there are 100,000 attacks a day? 1,000,000? But how long will it take to *get* to 100,000 infected computers? How many attacks will fail? Odds are, most of them will fail: not every IP has an attackable computer...
In other words, you could easily create a silent attack that doesn't kill anyone. Or a very noisy attack that also kills no one because it's stopped in time. Can you create a somewhat silent attack that infects a large number of people before they find out? Very tricky. It's an almost impossible balance: crash too soon and it doesn't really do anything, wait too long and it'll get caught.
To me, the better attack would be a *lightning* quick attack. Something like Slammer. According to this, Slammer was able to attack every vulnerable computer available in 20 minutes. I'm not sure how much I believe this, but I've heard that 15 Million computers were infected in that same 20 minutes. Is 15 Million dead computers enough for you?
Create a virus that spreads for an hour. Infect 15 million computers. Kill them. Good luck stopping that. The best part is, if you do your job correctly, either build a virus that only remains in memory or have it destroy the local copy of the virus in the process of killing the computer. Not only will the computers be dead, but it'll be *real* hard to figure out what hit you...
Now that I write that, that is a little scary...
Linux IT Consulting and Domino Development in Michigan