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.
Then it's not a worm.
"Ask not what your country can do for you." --John F. Kennedy
The formal definition changes depending on who you ask, but in this case, the key attribute that defines this as a worm instead of a virus is that viruses embed themselves in other programs. This program doesn't infect other programs, it just runs as a separate program placed in your Windows\system directory.
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.
You hook the int 2 (?) and int 3 during the run, so your code gets called before the debugger's breakpoint handler, amongst other techniques.
:)
Have a look at this paper and be enlightened
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!
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.
No, from what I read the virus has a crappy date detection routine and for some reason the "safe" environment they run tests in causes it to break. Of course when writing a virus you go for lean and mean rather than using the standard bloated OS interface so it's not a bug in the virus so long as it works correctly under a normal environment.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
From MSDN:
IsDebuggerPresent
The IsDebuggerPresent function determines whether the calling process is being debugged.
BOOL IsDebuggerPresent(void);
Parameters
This function has no parameters.
Return Values
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.
To determine whether a remote process is being debugged, use the CheckRemoteDebuggerPresent function.
To compile an application that uses this function, define the _WIN32_WINNT macro as 0x0400 or later. For more information, see Using the SDK Headers.
Requirements
Client: Included in Windows XP, Windows 2000 Professional, Windows NT Workstation 4.0, Windows Me, and Windows 98.
Server: Included in Windows Server 2003, Windows 2000 Server, and Windows NT Server 4.0.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.
1 Clear interrupt bit, so that code is sure to stay in the cache the entire time
2 Causes CPU I cache to reload
3 Store addr of lbl2
4 Store a RET over the nop at lbl2 (0C3h = RET)
5 nop to be clobbered only if under debugger
6 Remove interrupt bit
Of course you need to be a bit stealthier than this, but this is the basic idea.
Ryan T. Sammartino
"Ancora imparo"
This is a very stupid method (not for a virus of course...).
If a processor uses a different cache updating scheme which updates the instruction cache upon writes into memory then your program won't run.
You might argue that "this would be stupid processor design" or "not necessary for any decent processor to do this" - well, such methods were the reason why several copy (crack) protected old DOS programs won't run on Pentium computers. The method used there was exploiting the same effect with the instruction pipeline instead of the instruction cache. Some nops were overwritten with a ret or an interrupt call causing a program within a debugger to exit. However, the pipeline on the Pentium was either too small or a write triggered a refresh - I don't recall the actual details. So the program always exited.
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?"
Someone, anyone, clue me in to what's going on.
[Fuck Beta]
o0t!
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.
1. STI/CLI are priveleged instructions, so cannot be run by a windows process (other than a driver)
2. This will only stop a debugger in single step. If the user spots what you're doing, they just put a breakpoint after this code and run through the whole section and it works fine.
I'm kind of surprised that AV companies don't use custom VMware-type environments
They do, but you can still tell whether your code is running in one of these environments if you're tricky enough. This is exactly the "sandbox" they're referring to.
NO CARRIER
The hit list technique speeds up the initial phase of infection, which is normally slow and vulnerable to isolated failures. The list is compiled ahead of time by normal vulnerability scanning; the machines on the list are simultaneously infected to start the attack. Each copy of the worm then scans for and infects further vulnerable machines as quickly as possible, dividing the address space at each hop to avoid unnecessary overlaps (some redundancy might be desirable, but completely random scanning would be inefficient). The list can be divided in a topology-aware way to reduce congestion that might otherwise limit the rate of infection.
Viruses are not copyright; if they were the author would be admitting to a felony, where 1. s/he cannot benefit, and 2. they cannot claim possession of something illegal, ala. controlled substances. Copyright is, in essence, a form of constructive possession. A virus is like child porn, in that sense. It's worse to claim you own it than to argue for your possessory rights.
:)
Hope that makes sense.
those already exist. they have for quite some time.
They're using their grammar skills there.
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!
Viruses are not copyright; if they were the author would be admitting to a felony
The first half is absolutely false, and the second half could be false as well. Everything you create is automatically covered by copyright. And it is not a felony to create a virus, only to intend to release it. If you accidentally release it you might get nailed by civil suits (but not criminal ones), and if someone else released your virus without your permission you would not be subject to anything.
There's a DMCA exemption to decrypt software, but only for interoperability purposes. There is also a DMCA exemption for law enforcement agents. However any non-law-enforcement agent decrypting a virus in an effort to combat it *would* be commiting a felony. The DMCA is seriously fuxored.
Oh, and I just thought of something else. Commiting a felony by decrypting the virus is still commiting a felony even if the (criminal) author of the virus is unknown.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
Actually, that was first said by Baudelaire in "Le Joueur généreux", published 1864.
"...la plus belle des ruses du diable est de vous persuader qu'il n'existe pas!"
"...the devil's best trick is to persuade you that he doesn't exist!"
$ echo "ceci n'est pas une pipe" | sed -Ee 's/(eci n|pas )//g'