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.
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.
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
Then it's not a worm.
"Ask not what your country can do for you." --John F. Kennedy
"The greatest trick the Devil ever pulled was convincing the world he didn't exist." --Verbal Kint
And the greatest trick this guy pulled is making himself look like an ID10T...
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
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.
Read about the mechanics of disease spread with respect to viruses and you'll see why this does not happen.
Highly damaging viruses don't spread far. Today's virus/work/trojan writers want to capture large numbers of zombie PCs and resell these networks. They aim for control, not damage. It's about money, not vandalism.
Sig for sale or rent. One previous user. Inquire within.
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..."
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!
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!
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.
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.
but creating an ebola computer virus would not be hard.
code red for example if it had a timed payload that X minutes after infection kill the machine and that number of minutes was 3 days in the future it would be able to widely spread and STILL cause the death of the host machines.
the scaries is the stealth virus that spreads slowly, is silent and act's mostly benign for 90 to 120 days then simply kicks in for a full boat infection/attack+death 4 hours after final activation.
by the time it was discovered most people would be helpless.
Do not look at laser with remaining good eye.
There is still a way to blame microsoft for this!!! I was getting a little worried there.
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
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.
The guy who framed that poor patsy for creating Melissa, that's who.
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
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/