Slashdot Mirror
'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.
I've always heard that it takes a very good programmer to write effective and powerful virus.
Now just imagine if someone wanted to actually be malicious with this stuff..
I wonder if a virus with some code to re-partition your drive on a reboot would cause this issue to be taken more seriously.
I think we're just lucky these writers don't do more with the holes Microsoft gives them.
Der Tod ist der einzige Weg hier raus!
From the article: "I haven't seen such ruses used in a mass mailer in a long time. This piece of code is so sloppy, it's devious," said Mircea Ciubotariu, a researcher at Romanian AV firm BitDefender.
I'm sure it's lost something in the translation. The rest of the article suggests it's by design rather than accident.
So all you have to do to be safe is make sure you've got a debugger running, and the virus kills itself. I guess that adds new meaning to the term "de-bugger" :-)
"You're right, it's pure genius - they couldn't guess we'd do that, because only a frickin' idiot would do that!" - paraphrased from (approximately) 3.14 million movies.
Maybe this will teach them how to teach outside the (sand)box! Maybe they can harness their synergy with this new paridigm shift into sandbox free thinking.
:)
Ahh, its 1999 all over again
StickMan
www.rageagainst.net
One or the other... devious or sloppy... but surely not both.
/tinfoil on
/tinfoil off
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.
Sig for sale or rent. One previous user. Inquire within.
Then it's not a worm.
"Ask not what your country can do for you." --John F. Kennedy
Strippers writing viruses? Sounds like a Fox special. And, being your typical Slashdotter without a girlfriend, I have to ask, do you have pictures?
If my answers frighten you, stop asking scary questions.
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
"I haven't seen such ruses used in a mass mailer in a long time. This piece of code is so sloppy, it's devious," said Mircea Ciubotariu, a researcher at Romanian AV firm BitDefender.
Considering virus writers are more motivated by being devious than impressing analysts, doesn't it seem inappropriate to assume the coding was "sloppy?"
C'mon, *her* code? Isn't that a bit gratuitous? I mean, we're talking about code here, not a delicious turkey dinner.
1) Contains a "bug", well let's just call it a "feature". 2) Sloppy code, but Hey! it works. Sort of. 3) Run on Windows only. Sounds like every piece of comercial software sold by Microsoft to me.
If the virus randomly changed a few numbers in a few of the Excel spreadsheets it could access.
Damaging the computer itself is too easy to catch and causes people to take it seriously.
Changing data has more implications for CORPORATIONS and would take longer to detect.
This piece of code is so sloppy, it's devious
It shouldn't be hard to find the author, he obviously works at Microsoft.
I'm not normally an irrational zealous dickhead, but I figure "When in Rome..."
My guess is that they are so confounded, that by releasing that statement labelling the coding as sloppy they hope to draw the writer out in some way. Seems they are going for his/her ego.
Because hey no coder legit or illicit wants to be thought of as a sloppy coder.
I am Bennett Haselton! I am Bennett Haselton!
The code is so bad that they can't read it, so it's insecurity through obscurity?
Can't they break it down with a hex editor and see what's under the hood?
Not really. It's kinda like looking at that blueprints to a race car. Even if you know every little bit of the thing, you don't really understand what it does or how it does it until you can take it out on the test track.
Besides, looking at compiled code in a hex editor is kinda like looking at a jpeg in a hex editor. Maybe you see some interesting patterns, but it's tough to get the big picture.
BTW, yes, it is bad analogy week here on Slashdot. Didn't you get the memo?
"In a 32-bit world, you're a 2-bit user. You've got your own newsgroup, alt.total.loser." -Weird Al
Apparently they want to run it in one of the "modern" debuggers. If the program manages to run through a few very simple tests, it'll detect it's in a debugger environment and can easily self-destruct.
.. but they're right: I don't think things like that have been done in a while. Some vandal's been playing with the Way-Back Machine :-)
I did things like this years ago when fiddling around with a copy protection scheme. (Remember those days?) Trivial, really
If you really step through the code with a debugger, you can see the tests and traps (if you know what to look for) and avoid them. But that's tedious, to say the least.
Obviously somebody at the virus scanner companies couldn't be bothered, and was impressed with or surprised by a lousy "debugger bit test".
This content author has villified every artist who has ever had their work reverse engineered.
This is a great day for copyright, authors, and those downtrodden by IP terrorists!
Hopefully this clears up the "Is it sloppy or is it devious?" posts. It is both.
Number 1 (from the article):
Atak uses a variety of tactics in its attempts to escape antivirus analysis. Its main trick is to check to see if it's being run in a debugging environment. If so, it exits to avoid detection. The ploy prevents casual perusal of the code by researchers and (potentially) rival virus writers.
So that part is intentional.
A possible bug, related to the way Atak checks its activation date, prevents it from being run in a "sandbox". A sandbox is a virtual environment commonly used by AV researchers to look at the behaviour of malware in a safe environment.
So what I think they are saying is that even with it's ability to detect if it's being run in debug mode they would still normally be able to run it in a sandbox. Unfortunately (for the AV companies) there's the second thing. The seemingly unintentional bug that prevents it from working in a virtual environment.
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.
IsDebuggerPresent
The IsDebuggerPresent function indicates whether the calling process is running under the context of a debugger.
This function is exported from KERNEL32.DLL.
BOOL IsDebuggerPresent(VOID)
Parameters This function has no parameters. Return Value If the current process is running in the context of a debugger, the return value is nonzero. If the current process is not running in the context of a debugger, the return value is zero. Remarks This function allows an application to determine whether or not it is being debugged, so that it can modify its behavior. For example, an application could provide additional information using the OutputDebugString function if it is being debugged.
No sharp objects, I'm a programmer!
Isn't a "stealth worm" that requires "user intervention" a paradox?
Gentoo Linux - another day, another USE flag.
I'm kind of surprised that AV companies don't use custom VMware-type environments that can be debugged at a level above what the virus or any other processor could detect, or use special hardware/simulators that also can't be detected.
I'd think this would give them greater granularity and more control over the entire environment than trying to just run in it in a standard debugger.
Unless the writer has gone to great lengths to obfuscate, a disassembler combined with a skilled x86 assembly programmer should be able to tell you all about what it does. Maybe the AV companies don't have those skills . . . methinks they should.
Hey... If they reverse engineer this thing, won't they be violating the DCMA? I say the virus writer should sue all the anti-virus companies.
;-)
By copying parts of the virus into their virus scanning signatures, perhaps everyone running the anti virus software is also violating the DCMA, I say fire off a few hundred law suits and see what happens.
(Maybe with thinking like this RIAA will hire me.)
I don't understand... Why are they saying the code is sloppy? It seems to me that what they are doing is intentional. So it's not sloppy in the sense that it is full of mistakes.
I also don't understand how stopping execution if your product is being debugged equates to "sloppy". It seems to me that a large number of software companies would WANT their software to behave in this way to make reverse engineering and hacking harder?
In fact, if it is so difficult for antivirus companeis to debug this, when why isn't more software using this technique to make piracy more difficult, and/or hacking network games harder?
A viruswriter should add an EULA to his/her virus.
- You may execute this virus 'as is'.
- We accept no claims of any kind of any or all damage done by this piece of software.
- You are responsible for the consequences of executing this software.
- You are NOT allowed to disassemble the code (DCMA).
- etc, etc..
Privacy is terrorism.
We call those heisenbugs and they are the bane of a programmer's existence. The whole damn point of a debugger is to replicate the same behavior as normal, not allow the program to choose to exhibit a different behavior.
"I'm going to look at you more closely now. Please act normal. (But it's your call if you don't.)"
Yeah, that "surprise inspection" works great everywhere else, why not in programming? Fucking morons...
I was happier not knowing about this function. soundman32, I shake my fist at thee. :-)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.
You are in a maze of twisted little posts, all alike.
This used to be a pretty heinous hack but seems well documented now; googling for the keywords: will get you some interesting results and tutorials.
* http://codeproject.com/system/api_spying_hack.asp
* http://tochna.technion.ac.il/project/Win32APIInte
Pretty cool shit.. anyway, the point is after you put a dummy IsDebuggerPresent that always returns false, you can step through it normally.
Or, heh, a method that would probably be a million times easier would to simply step through the code until it calls IsDebuggerPresent and change the value of EAX to 0 after it returns (since the return value of functions is placed in EAX after return).
Anyway, just musing and putting up those links because I learned a lot about how Windows internals work through playing with things like that and figured others might want to learn.
-fren
"Where are we going, and why am I in this handbasket?"
There is still a way to blame microsoft for this!!! I was getting a little worried there.
Viruses which could detect that they are being run in a debugger were common 10 years ago when I used to work for an anti-virus company. For example, One-Half is such a virus.
A possible bug, related to the way Atak checks its activation date, prevents it from being run in a "sandbox"
Sounds more like a bug in the sandbox to me. A sandbox should be indistinguishable from running on a real non-virtualised computer.
The parent is horribly bipolar.
I have heard the "BMP thing" being spouted by a Microsoft / closed-source apologist
Actually an apologist wouldn't be spouting about the BMP exploit. Rather an apologist would be trying to dismiss it as you do in here:
Is there any documented evidence that this has been used in *any* virus/worm/hacks?
There. Now you're being the closed source apologist by saying,"We're sorry about the BMP thing but does it really make a difference?" Since it's been pointed out that the BMP thing was only present in older editions of MSIE (5.5?) it's pretty plausible that the forensic trail of tracking any exploits is long covered, formatted, and reinstalled.
And has there actually been more than one bug found
The security industry has its hands full simply processing data on exploits which are submitted. The people who have time to go over that released source code routine by routine, structure by structure, loop by loop, aren't going to tell you about it first. If they're nefarious they're not telling anyone.
Additionally, did you read this yesterday? Did you try contacting the authors who published those vulnerabilities? It's quite possible that they came onto those vulns by looking at the source code.
So sit down and...
If the exploit was evident by looking at the code, the code writer would probably fix it
That's a bit shallow minded. Not every programmer who works for MS was a 4.0 overachiever who visualized code loops and logic flow in real time. Very few middle managers were 4.0 overachievers--many got to their position because they were better at social networking than coding networks. By the time the code gets to the upper management it's not being audited line by line. Even 4.0 students aren't always guaranteed overachievers with amazing perceptual abilities. Many 4.0 students know how to stand in line and keep their mouths shut. That's the most assured way to a 4.0.
Every single exploit is discovered by accident
I would agree that the majority of exploits are discovered by someone noticing erratic behavior in a program and taking the initiative to dig in deeper. However I know a number of people who take great delight in poring over changelogs and then going back to audit source code when "Bug in <sourcefile.c> fixed." The changelog may have been a roadsign but when sourcefile.c is 1000+ lines it's still a testament to skill to find the bug which was fixed.
+++ATHZ 99:5:80
Hmm, scan word docs looking for legalese adding and removing the word "not" at appropriate points.
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.
Government of the people, by corporate executives, for corporate profits.
most people don't fix their computers until they no longer work at all. A virus like this would have little impact on the computer. If it was well hidden enough, it wouldn't get fixed when the person call tech support for other problems either. The key is being quite and unintrusive right up till the end, then you lay waste to the computer.
Frankly, I'm with the first poster. I good 'ole fashion hard disk reformatter would light some fires out there. I'm tired of seeing people with 5 or 6 viruses, uncountable spyware programs and everthing on their computer broken wanting the damn things fixed without a clean install because they don't know what a file is and have no idea how to back things up.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Remember the old days of self modifying assembly code?
(ie:
instruction purpose
1-20 alter instruction 21-40
21-40 alter instruction 1-20, jump to 1
1-20 do something
21-40 alter 50-70 and 1-20
50-70 do something, jump to 1-20)
All alteration naturally is done in the most tricky of ways.
Ah, those were the days.
GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
See, this is what I've been trying to tell my boss: I'm not writing sloppy code, I'm trying to prevent people from reverse engineering our product!
We visionaries are always persecuted.
- First they ignore you, then they laugh at you, then ???, then profit.