'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.
Not a worm (Score:5, Informative)
Then it's not a worm.
Re:Okay...? (Score:3, Informative)
Re:Not a worm (Score:2, Informative)
Source: Wikipedia [wikipedia.org]
Clarification, there are 2 issues (Score:5, Informative)
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.
Re:How does it do that? (Score:5, Informative)
Have a look at this [jhu.edu] paper and be enlightened
It's part of the API - From MSDN (Score:5, Informative)
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.
Re:Hex it? (Score:5, Informative)
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.
Re:Sloppy or devious? (Score:3, Informative)
Re:How does it do that? (Score:2, Informative)
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.
Re:How does it do that? (Score:5, Informative)
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.
Re:How does it do that? (Score:2, Informative)
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.
Re:Hex it? (Score:5, Informative)
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 [codeproject.com]
* 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
Explain for non-programmers? (Score:3, Informative)
Someone, anyone, clue me in to what's going on.
Nothing new (Score:4, Informative)
Re:How does it do that? (Score:3, Informative)
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.
Re:Custom VMWare environment or hardware? (Score:4, Informative)
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.
Re:Mailers? (Score:5, Informative)
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.
Re:Finally! (Score:4, Informative)
Hope that makes sense.
Re:I'm waiting... (Score:2, Informative)
Remember the old days (Score:5, Informative)
(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.
Re:Finally! (Score:4, Informative)
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.
-
Re:Strange (Score:3, Informative)
"...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!"