'Stealth' Worm Hinders Sandbox Analysis 461
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.
Strange (Score:4, Interesting)
"So sloppy it's devious"? (Score:5, Interesting)
Maybe it's just a sign that malware is evolving along the same rules as organic life: accidental errors get selected for survival value and passed along to following generations.
Malware that detects and disables attempts to reverse engineer it... ?
Or perhaps we can read the anti-virus researcher's comments in a totally different light:
"Most viruses [which we develop ourselves to stimulate sale of our products and services] have a function to let us easily identify and sandbox them. In this example, the function is broken. So sloppy it's devious [and perhaps intended as a warning that we're not paying our freelance coders enough]."
Nah.
How does it do that? (Score:5, Interesting)
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.
Re:Sloppy or devious? (Score:3, Interesting)
Or maybe I'm to cynical.
Re:Hex it? (Score:1, Interesting)
because x86 is a CISC type of processor, its hard to find instrictions after the first dynamic jump (is that data or code for the next x bytes?)
think of it as if we didn't have spaces when we wrote. you could still read it, but it would take longer. youcouldstillreadit,butitwouldtakelonger.
RISC code is usually easier to disassemple because it always starts on a word aligned byte.
either way though, any code that self-rewrites or has dynamic jumps are a pain to take apart.
Re:Hex it? (Score:5, Interesting)
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.
Re:How does it do that? (Score:5, Interesting)
There are tons of CRACKME's (small program written solely for people to crack or bypass) I have seen which look for debuggers and will exit if encountered.
Re:Finally! (Score:5, Interesting)
Yeah, 'sloppy'. (Score:3, Interesting)
Re:so is this what MSFT does? (Score:3, Interesting)
Re:"So sloppy it's devious"? (Score:5, Interesting)
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.
Re:It's part of the API - From MSDN (Score:2, Interesting)
--
Re:How does it do that? (Score:5, Interesting)
Int68:
MOV AH, 43h
INT 68h
CMP AX, 0F386h
JZ FoundDebugger
Check for SoftIce(most common/powerful debugger) by using the CreateFileA API to check for the SICE VXDs.
And an interesting one found in the SafeDisc protection where(if I recall) they use a checksum of the GDT to decrypt a section of code. The debugger modifies this table and will cause the code to crash.
You're missing the point (Score:1, Interesting)
The Symantec's and McAfee's fo the world have got a nice symbiotic relationship with virus writers. Why would you interrupt cash flow to try to essentially "escalate the tech war"?
Think about it. I think its the dirty secret of all the anti-virus companies. I think they all suck, as do their products.
--Tom
Re:Strange (Score:3, Interesting)
Arsonists and firebugs like to watch firemen put out their fires. Is it really a stretch to apply that behavior to digital firestarters?
Re:How does it do that? (Score:2, Interesting)
Re:More damaging. (Score:5, Interesting)
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."
Re:Okay...? (Score:5, Interesting)
You're right.
This program doesn't infect other programs, it just runs as a separate program placed in your Windows\system directory.
Wouldn't that qualify it as a "Trojan Horse" then? Generally a Trojan Horse is a program that tricks the user into running by appearing as something it is not (hence the double extension trick). Of course the classic Trojan Horse appears to be one thing (like a weather program, or an clock syncronizer) but while it does that thing it secretly does something else, like install keyloggers, adware, etc.
Admittedly, the AV makers have been trying to pollute the definitions, calling these e-mail Trojans "worms" in a PC attempt to avoid assigning blame to the users, but I've always felt these three definitions to be pretty clear and well defined.
Re:Custom VMWare environment or hardware? (Score:3, Interesting)
That was probably their first step.
I'd think the ultimate setup would be a high end machine with 8-16 CPUs capable of x86 virtualization that could be run a half-dozen or so images that would be virtually networked with each other.
That way you could simulate a real network on real machines, including a server, clients, etc and see what happened. Even setting up and imaging a lab of 8 machines and a server would be time consuming.
Doesn't anyone sell x86 virtualization on Sparc or IBM mainframe hardware?
Re:DCMA Violation! (Score:3, Interesting)
And, yes, someone should write a short bit of copyrighted work (I suggest a hiaku or limerick...those are definately protected under copyright law, and fairly small.), and encrypt it into a virus. If they ever get caught, possibly they can sue antivirus companies, because the antivirus company would probably admit to decoding their virus before they realized it was a trick.
An even funnier gag would be to store the poem, unencrypted, on the hard drive, and have the virus prevent you from accessing it. Ergo, removing the virus is circumventing a access control device, and all antivirus software that does so is illegal.
Yes, yes, the software could delete the poem, also, but we all know that deleting a file doesn't make it go away. (If deleting a file does count, someone should write a program that decodes DVDs, rips the MPEGs, and then just deletes them, so you have to go and immediately undelete them.) You could always recover it from the hard drive using undelete tools. So basically, they'd have to secure erase the poem...and I'm willing to bet no antivirus software has that built in, so if they realized what was going, at the very least you'd have forced an upgrade.
And it's entirely likely that no one will realize what's going on. So if the virus writer ever gets caught, he can take the antivirus companies down with him by suing their pants off for distributing an access control circumvention device for his stuff.
God, I love the DMCA. It's so monumentally stupid.
Re:Mailers? (Score:5, Interesting)
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 [pcmag.com], 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...
Re:How does it do that? (Score:4, Interesting)
SafeDisc also loads a driver into the kernel which reads the debug register in the CPU. SafeDisc does a whole ton of clever things though, those guys really know their stuff, so I can well believe it hashes the GDT too.
The most common techniques are checking for SoftIce (a very, very popular kernel level debugger) using a variety of techniques, google for "MeltIce" to see one I patched Wine to work with a few weeks ago, checking the x86 debug register, playing with interrupts, examining a Windows internal structure called the PEB, and so on... lots of devious tricks you can use.
Counterexample (Score:4, Interesting)
Unless the damage is delayed and/or random.
Big counterexample is AIDS:
- Attacks the immune (i.e. antivirus) system directly.
- Goes dormant until the infected cell is activated for other purposes.
- Mutates "rapidly" for a virus (though slowly on reproductive cycle time scales), resulting in mutiple strains from a single infection after a few years.
- Infects slowly enough that it doesn't create a tight cluster of infected individuals.
This enables it to spread widely before the occasional activation of the immune system cells carrying it expand its infection in an exponential cascade taking out the doomed host.
Birthday viruses / easter eggs are a simple mechanism to allow wide spread of computer viruses before they take out their hosts - and the hosts that are down at that time provide a reinfection reservoir. But it's primitive compared to AIDS.
A highly damaging virus could be made which makes random choices on when to utterly trash its host.
They aim for control, not damage. It's about money, not vandalism.
Unfortunately, while there are several criminal enterpises spreading worms/trojans/viruses whose intent is to create DDoS zombies, spam remailers, or keylogger/filters looking for bank account access or other sensitive information, there are still plenty of virus authors chasing other things - including those who will vandalize machines for the fun of it.
And there are power groups with significant membership whose agendas would be advanced by taking out as much as possible of the IT infrastructure of the world - the more widespread and more lasting the damage, the better for their purposes. A family of worms with AIDS-like properites would serve their interests nicely.
Finally - while diseases evolve to be relatively benign, they do so randomly (and designed programs often don't do quite what was intended, especially on first release). Sometimes you get one that strikes a balance between spread and damage that results in a massive, widespread dieoff among the host populatin before the combined evolution of the disease and hosts contain its remanents. Classic example: Bubonic Plague.
So let's not be lulled by analogies to the common cold and childhood diseases. They're the result of a lot of death and misery before the diseases found a stable niche. And while computer viruses share much of the math of disease spread they are designed, not evolved, and can easily have properties rarely seen in nature.
Any debugger exploits? (Score:2, Interesting)
Re:EULA (Score:4, Interesting)
Re:Undetectable debuggers (Score:4, Interesting)
It is not easy to make a software emulation of hardware that is exact without taking a huge performance hit. The processor, yes, but all that peripheral hardware is where the real emulation work is. Early versions of the UAE Amiga emulator emulated the video scan in the Amiga custom chips pixel-by-pixel, and it was so slow that UAE stood for "Useless Amiga Emulator." They later settled on refeshing the video on the (emulated) horizontal scanline flyback, which broke some exotic plasma-screen demos (which manipulated the palette in the middle of a scanline...try doing that on a PC!) but at least made UAE useful.
Of course some partisan wankers had to write sofware that detected the emulation evironment & refused to run, apparently in the belief that emulation would kill the Amiga hardware market (not admitting that it was already cold & dead).
What you describe can be done in hardware though, consisting of an FPGA + CPU board that plugs into the CPU socket and a communication cable to a separate debuggging PC. They are called In-Circuit Emulators (ICE) and are expensive, but very powerful, tools popular for embedded development.
not (Score:5, Interesting)
should/will/must should/will/must not
Fairly simple but that alone could cause some interesting effects on contracts etc. I'm sure there are other simple and more effective ways of changing the meaning of sentences which would require the re-reading of them by the authors to guarantee that the meaning is correct.
Re:Mailers? (Score:3, Interesting)
do a slammer attack, fast as hell infection rate delay only a 3 minutes or so and then roll the dice to speak.
give computers a 50% chance of dying or simply an immune carrier/spreader.
that would be even more evil... there is a 50 50 chance that your Pc unce infected will be killed, or it becomes a spreader until it is cured.
now make the virus morphing. try attack1, infect. if attack1 fails, use attack2 and morph to hide from scanners.
so you got atacked, cleand it, there is still a chance of you getting reinfected and killed.
Re:Mailers? (Score:3, Interesting)
Re:Mailers? (Score:3, Interesting)
The solution to that sort of problem is not to just pound wildly on everything out there. Set up your virus to create a P2P style communication network of nodes and actually have instances of the virus COORDINATE their attack.
Such a system could be quite nasty indeed.
Jedidiah.
Re:It's New Coke! (Score:3, Interesting)
Just because corn sweeteners are cheaper today, doesn't mean that Coca Cola won't be able to buy a vast quantity of sugar at an even lower price due to commodities futures market fluctuations. They leave the door open by printing their labels with the "and/or" bit.
BTW, did you know that Hershey uses so much sugar and cocoa that they have their own commodities futures trading room in house that specializes in these contracts?
Re:Strange (Score:3, Interesting)
The virii that come out of those are mostly yet-to-be detected, I'm sure...
For example, on this specimin [galttech.com], they have:
ATTENTION WIN XP USERS: Windows XP will not allow you to access 16-bit screen savers (which make up about 2/3 of all the screen savers out there, including many of your classic favorites.) To get around this, you need to use a screen saver utility like Screen Control, which allows you to access ALL your 16-bit and 32-bit savers with simple one-click access from your system tray. Try a FREE DOWNLOAD today.
Uh huh - highly suspect.
Re:Remember the old days (Score:2, Interesting)
analyze CPU speed timings.
install Xor crpyting interrupt routines 1, 2, 3 and 4
routines 1 & 2 decrypt current instruction+2
routines 3 & 4 encrypt current instruction-2
the program has to run at exactly the right speed to be in sync with timers.
Oh and the main program of course runs in trace mode, doing some fancy things at each instruction, so a debugger can't run.
oh yeah... good old days
Re:Mailers? (Too much flash) (Score:4, Interesting)
That's the problem with viruses these days, too much flash. Either it saturates a network spreading itself, or it quickly kills the host. Either way it brings way too much attention to itself to be truly scary.
How's this for a thought experiment;
Write a small, stealthy piece of code that would randomly change a single digit in a single number found in a random Word or Excel etc. file by some small random amount once a day. It propagates by attaching portions of itself to no more than 1 email message/irc chat/telnet/ftp/video conference or other communication application a day. Until all of the pieces are present in memory, all the code does is attach itself to some systems process and look for the rest of itself. When all of it has been received it adds itself to some innocuous systems level process and begins changing values and slowly sending itself out around the world.
So what good would that do? Well it doesn't draw attention to itself, neither in its mode of operation nor the way it spreads itself. Therefore while it would propagate slowly, no one would ever be looking for it. It's payload could cause great amounts of harm without ever giving the user any reason to think that his computer might be infected. What happens if it's on a pharmacy/hospital computer and it changes the dose of a prescription? Most pharmacies these days use numbers as a prescription ID. 20034978 might be a beneficial prescription while 20034879 could be deadly. We lost a Mars probe because someone didn't convert between feet and meters correctly. What if they did and a virus like this deftly changed it behind their back? A million widgets at $1.24 each is a lot different that a million widgets at $1.98. Building a bridge with a support beam that's 84.539 meters long isn't the same as one of 84.639 meters. You see where this is going don't you. Taken by themselves they look like simple user errors.
The computer, or user, is diagnosed with Alzheimer's when it's actually infected with Creutzfeldt-Jakob. Machine's get rebuilt, people loose money, or get killed, and no one ever suspects that a very stealthy virus is the root cause of it all.
That my friends is what I would call truly scary.
someone247356
Re:Finally! (Score:3, Interesting)
For purposes of this subsection, the term ''security testing'' means accessing a computer, computer system, or computer network
You're not accessing a computer, computer system, or computer network. You are accessing the virus.
The only way I can see it fit is if you are working on an already infected system and you attempt to argue that the virus is now part of your computer system. Chuckle. There's sort of a logic to it, but I'm not sure that would be accepted as the intent of that exemption.
-