At DEFCON 15 this year, Paul Sebastian Ziegler presented a"multi-platform" worm that runs in the .NET framework and compatibleimplementations. He called it "Akikaze", which is Japanese for "autumnwind". We call it MSIL.Yakizake,which is Japanese for "grilled fish". We never use the virus author'schoice of name, and since Yakizake sounds similar, it worked out well.
It's unclear why Mr. Ziegler thinks that his worm is multi-platform,because the platform is the environment in which the application runs.It's not the CPU on which it is running, and it's not the operatingsystem, either, if the environment is a virtual machine of some kind.In this case, the environment is the .NET framework or equivalent(which I'll simply call ".NET" from now on, but it's meant to includethem all), which is a virtual machine. While .NET itself ismulti-platform, the virtual machine that it...
I just got back from Black Hat 2007 Las Vegas, where I wasco-presenting with Nate Lawson and Thomas Ptacek regarding detection ofhypervisors. Previously, we had asked Joanna Rutkowska to prove her"100% undetectable" claim, but she had declined. However, we did manageto prove that our methods work.
Joanna agreed that the TLB timing method that I first described in detailin 2006 works against BluePill. As she understood it, though, shethought that I presented it as a 'foolproof method for "BluePilldetection"'. While I did present it as a foolproof method, I didn'trefer to BluePill at all: I said that it would reliably detect ahypervisor, which it does. That it detects BluePill is a corollary.
At the forum last week, she said that it can be defeated, but hermethod to do so is to single-step the code following the RDTSCinstruction. That assumes, of course, that RDTSC is the instructionthat is used...
It's not often that we get a proof-of-concept (PoC) virus, but toreceive four in two weeks is completely unprecedented. The first one,which we call MEL.Odorousis a virus for the Maya 3D scripting language. It searches in thecurrent directory for uninfected files, and prepends itself to them.After infecting files, it runs the host as usual.
The second virus, which we call WHS.Vred isa virus for the WinHex scripting language. Like MEL.Odorous, Vredsearches in the current directory for uninfected files, and prependsitself to them. Unlike MEL.Odorous, however, Vred does not run the hostcode after infecting files.
It seems that for every scripting language that is powerful enoughto host a virus, a virus will be written for it eventually. It alsodoesn't seem to matter if the audience for that scripting language isvery restricted, or that the scripts might not be shared with anyoneelse.
This brings us to the first virus for the Autodesk Maya 3D scriptinglanguage - "Maya Embedded Language" or "MEL" - which we call MEL.Odorous.
This virus is simply a proof-of-concept. It begins by searching inthe current directory for the .MEL file that contains its code. Itreads this code into a buffer that will be used for replication. Thenit searches again in the current directory for other .MEL files. Forany .MEL file that is found to not be already infected, the virus willprepend itself to the file. There is no payload, and it does nothingbut replicate.
A new virus has appeared for a new platform. Nothing really newabout that, except that this time, the platform is a...calculator. Yes,the Texas Instruments TI89 is now the target of infection. The TIcalculators are very powerful, and allow modules to be installed in theRAM. There are thousands of applications already, lots of games, hacksto display grayscale instead of just black and white, and of courselots of mathematics routines.
We don't even have a name yet for this virus, because we're still inthe process of deciding on a proper platform name. TI89 is not accurateenough, since it's the underlying software layer that determines if thecode can run, rather than the hardware. It might be AMS, after the nameof the ROM software. Anyway, we'll see.
The virus itself is interesting, since it is not only a parasiticinfector of other modules, but it is entry point obscuring. That is,instead of simply changing the entry point of a module to pointdirectly to the virus code,...
Microsoft's JScript is a very powerful and flexible language.However, great flexibility leads to a great potential for obfuscation.We have seen many examples of JScript obfuscation in the past, such asstring concatenation and dynamic decoding, and will likely see more inthe future.
The most recent and a potentially problematic example uses one ofthe simplest obfuscation methods: Unicode escaping. Normally, Unicodeescaping is used to send Unicode characters that might not travel wellacross networks, such as characters that could be transformed accordingto the system locale. From a security perspective, Unicode escaping iswidely used to deliver executable code in Web exploits.
What was previously unknown to us is that Unicode escapes can beapplied to function names, variables, and all kinds of other code. Thiswas demonstrated by the recent virus that we detect as ...
On Wednesday morning, we received anonymously a copy of the first "iPod virus", which we call Linux.Podloso(renamed from Linux.Noslo), a play on the virus author's name of"Oslo". Although this virus is designed to run on iPod Linux, there isnothing iPod-specific in the virus code, so it is not an iPod virus. Itis just another proof-of-concept Linux virus.
"iPod Linux" is a software project that allows a user to run adifferent operating system, Linux, directly on an iPod. So, when theiPod is switched on, the user sees a Linux interface instead of theusual Apple interface. This virus runs within that particular Linuxframework and infects the files that are part of that operating system.
The virus arrives as a file called "oslo.mod.so" and it infectsspecific iPodLinux files on the compromised device. To infect an iPodwould require a user to...
Apparently, they are all written by the same person, a virus writerwho goes by the name of roy g biv. (Please note that the names aboveare the names given by the virus writer.) The question, though, is howlikely is it that...
SecuriTeam recently ran a Code Cruncher competition. The idea was to create the smallest possible Windows executable file that could download an arbitrary file from the Code Cruncher site.
While the final results are not in yet, one entry at 210 bytes (including the length of the URL) looks set to be the winner. Why? Because it executes entirely from within the PE header. That's right - there is no code outside of the file header, only strings, such as the URL. Even more amazing, those strings are encrypted. The decryptor fits into the PE header, along with the downloader code.
Here's a sanitized version of it (the relevant code and URL have been replaced):
We received a virus on Thursday morning that parasitically infects OSX Mach-O format files, without relying on resource forks. It's called OSX/Macarena. If you have read the OSX/Leap paper from this year's Virus Bulletin conference, you will have seen some suggestions about possible infection methods. Those suggestions were all ignored by the virus author in this case. Instead, the virus writer has found a rather unexpected region of memory in which to place the code, along with a way to gain immediate control when an infected file is executed. There is no payload in this virus—it simply replicates. However, it won't replicate very well, because it is restricted to the current directory. On Windows systems it is common to have directories like "Windows" and "Windows\system32" full of executable files; but, files aren't stored like that on OSX systems....
“Garry’s Mod” is a fairly popular modification add-on to the first-person shooter game Half-Life 2. Garry’s Mod doesn’t actually contribute any benefits to the game play, but it allows Half-Life 2 players or enthusiasts to modify objects and/or features in the Source engine, which is the 3-D gaming engine used to run Half-Life 2. Lua scripting has also been added to Garry’s Mod to allow players to create personalized game modes and weaponry. Of course, along with the introduction of Lua scripting support to Garry's Mod comes the predictable appearance of Garry's Mod-specific Lua viruses. So far, all of them simply copy themselves into a specific location and add a reference to themselves in the startup list.
Corresponding with the appearance of the virus scripts was the appearance of antivirus scripts. Unfortunately, some of those antivirus scripts are themselves viruses—the classic and misguided "spread to all...
I have posted this blog in order to outline a recent Q&A session that provides more information about my previous blog regarding a new virus affecting the AMD64 platform.
Q. How does the virus function occur (infection, propagation, etc.)?
When an infected file is executed it functions normally; however, when the application wants to terminate (e.g., the user closes it), the virus code is then called. At that time, the virus will seek other files in the directory that contain the currently infected file and all subdirectories below it. Any Windows executable file, regardless of the file extension (i.e., not just .exe files), will be infected if it passes a strict set of criteria that the virus carries.
Q. Is it easily detected and, for that matter, avoided?
We recently saw the first polymorphic virus for the AMD64. It was released by the same virus writer responsible for the development of the first virus for the Intel Itanium platform; I suppose it was only a matter of time before this author began to do some serious research on the AMD64 platform, too.
The AMD64 virus is both polymorphic and entrypoint obscuring. The entrypoint obscuring is achieved in two ways: one is by making an unusual use of the Bound Import Table, the other is by creating a polymorphic decryptor that contains no explicit register initialization (e.g. MOV instructions). The result is that it is not a simple matter to find the true start of the decryptor and to emulate from the wrong place can result in incorrect decryption.
Interestingly, the virus author also created a 32-bit version of the same virus, using exactly the same techniques....
On July 2nd, 2006 a virus author released the first virus that infects IDC files (W32.Gatt), claiming that it would be very hard for antivirus researchers to detect and that the source code would be made public at the end of the month. Media reports at the time speculated that the virus release was intended to embarrass virus researchers because it targeted some software tools that we use to analyze malicious code. However, on July 3rd we released antivirus detection for the virus. On July 4th, the virus author withdrew the claim that the source code would be released. Coincidence? I don't think so.
Symantec’s Security Response team is just that: a response team. We responded quickly when this virus appeared and we were able to provide antivirus detections in short order. It was more than likely that the virus author had originally intended to post the...
Things have been pretty interesting here lately. The first virus for Sun Microsystems’ StarOffice appeared, although it wasn't a real virus because it didn't actually work. We also received reports of the first parasitic virus for the .chm (compiled HTML help file) file format, and reports of the first virus that is an IDA plug-in. I say "reports" because we have been told these two viruses exist but we have not received any samples to prove it.
The StarOffice virus just goes to show that virus writers don't test their code. Despite four attempts (represented by the samples that we received; who knows how many others we didn't receive) the virus author still couldn’t seem to work out why his code wasn’t infecting anything. However, hot on the heels of these initial samples was the...
