Chapter 4. ELF Virus Technology – Linux/Unix Viruses

The art of virus writing has been around for several decades now. In fact, it goes all the way back to the Elk Cloner Apple virus that was successfully launched in the wild in 1981 through a floppy disk video game. Since the mid '80s and through the '90s, there have been various secret groups and hackers who have used their arcane knowledge to design, release, and publish viruses in virus and hacker e-zines (see http://vxheaven.org/lib/static/vdat/ezines1.htm).

The art of virus writing is usually of great inspiration to hackers and underground technical enthusiasts, not because of the destruction that they are capable of, but rather the challenge in designing them and the unconventional coding techniques that are required to succeed in programming a parasite that keeps its residency by hiding in other executables and processes. Also, the techniques and solutions that come with keeping a parasite stealthy, such as polymorphic and metamorphic...

ELF virus technology

The world of ELF virus technology shall open up many doors to you as a hacker and engineer. To begin, let's discuss what an ELF virus is. Every executable program has a control flow, also called the path of execution. The first aim of an ELF virus is to hijack the control flow so that the path of execution is temporarily altered in order to execute the parasite code. The parasite code is usually responsible for setting up hooks to hijack functions and also for copying itself (the body of the parasite code) into another program that hasn't yet been infected by the virus. Once the parasite code is done running, it usually jumps to the original entry point or the regular path of execution. This way, the virus goes unnoticed, since the host program appears to be executing normally.

Figure 4.1: Generic infection to an executable

ELF virus engineering challenges

The design phase of an ELF virus may be considered an artistic endeavor, requiring creative thinking and clever constructs; many passionate coders will agree with this. Meanwhile, it is a great engineering challenge that exceeds the regular conventions of programming, requiring the developer to think outside conventional paradigms and to manipulate the code, data, and environment into behaving a certain way. At one point in time, I did a security assessment at a large antivirus (AV) company for one of their products. While talking with the developers of the AV software, I was amazed that next to none of them had any real idea of how to engineer a virus, let alone design any real heuristics for identifying them (other than signatures). The truth is that virus writing is difficult, and requires serious skill. There are a number of challenges that come into play when engineering them, and before we discuss the engineering components, let's look at what some...

ELF virus parasite infection methods

There are only so many places to fit code in a binary, and for any sophisticated virus, the parasite is going to be at least a few thousand bytes and will require enlarging the size of the host executable. In ELF executables, there aren't a whole lot of code caves (such as in the PE format), so you are not likely to be able to shove more than just a meager amount of shellcode into existing code slots (such as areas that have 0s or NOPS for function padding).

The Silvio padding infection method

This infection method was conceived by Silvio Cesare in the late '90s and has since shown up in various Linux viruses, such as Brundle Fly and the POCs produced by Silvio himself. This method is inventive, but it limits the infection payload to one page size. On 32-bit Linux systems, this is 4096 bytes, but on 64-bit systems, the executables use large pages that measure 0x200000 bytes, which allows for about a 2-MB infection. The way that this infection works is by...

The PT_NOTE to PT_LOAD conversion infection method

This method is extremely powerful and, although easily detectable, is also relatively easy to implement and provides reliable code insertion. The idea is to convert the PT_NOTE segment to the PT_LOAD type and move its position to go after all of the other segments. Of course, you could also just create an entirely new segment by creating a PT_LOAD phdr entry, but since a program will still execute without a PT_NOTE segment, you might as well convert it to PT_LOAD. I have not personally implemented this technique for a virus, but I have designed a feature in Quenya v0.1 that allows you to add a new segment. I also did an analysis of the Retaliation Linux virus authored by Jpanic, which uses this method for infection:

http://www.bitlackeys.org/#retaliation.

Figure 4.5: PT_LOAD infection

There are no strict rules about the PT_LOAD infection. As mentioned here, you may convert PT_NOTE into PT_LOAD or create an entirely new PT_LOAD phdr and segment...

Infecting control flow

In the previous section, we examined the methods in which parasite code can be introduced into a binary and then executed by modifying the entry point of the infected program. As far as introducing new code into a binary goes, these methods work excellently; in fact, they are great for binary patching, whether it be for legitimate engineering reasons or for a virus. Modifying the entry point is also quite suitable in many cases, but it is far from stealthy, and in some cases, you may not want your parasite code to execute at entry time. Perhaps your parasite code is a single function that you infected a binary with and you only want this function to be called as a replacement for another function within the binary that it infected; this is called function hijacking. When intending to pursue more intricate infection strategies, we must be aware of all of the possible infection points in an ELF program. This is where things begin to get real interesting. Let's take a...

Process memory viruses and rootkits – remote code injection techniques

Up until now, we've covered the fundamentals of infecting ELF binaries with parasite code, which is enough to keep you busy for at least several months of coding and experimentation. This chapter would not be complete, though, without a thorough discussion of infecting process memory. As we've learned, a program in memory is not much different than it is on disk, and we can access and manipulate a running program with the ptrace system call, as shown in Chapter 3, Linux Process Tracing. Process infections are a lot more stealthy than binary infections, since they don't modify anything on disk. Therefore, process memory infections are usually an attempt at defeating forensic analysis. All of the ELF infection points that we just discussed are relevant to process infection, although injecting actual parasite code is done differently than it is with an ELF binary. Since it is in memory, we must get the parasite code into...

ELF anti-debugging and packing techniques

In the next chapter, Breaking ELF Software Protection, we will discuss the ins and outs of software encryption and packing with ELF executables. Viruses and malware are very commonly encrypted or packed with some type of protection mechanism, which can also include anti-debugging techniques to make analyzing the binary very difficult. Without giving a complete exegesis on the subject, here are some common anti-debugging measures taken by ELF binary protectors that are commonly used to wrap around malware.

The PTRACE_TRACEME technique

This technique takes advantage of the fact that a program can only be traced by one process at a time. Almost all debuggers use ptrace, including GDB. The idea is that a program can trace itself so that no other debugger can attach.

Illustration 4.9 – an anti-debug with PTRACE_TRACEME example

void anti_debug_check(void)
{
  if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) {
    printf("A debugger is attached, but not for long...

ELF virus detection and disinfection

Detecting viruses can be very complicated, let alone disinfecting them. Our modern day AV software is actually quite a joke and is very ineffective. Standard AV software uses scan strings, which are signatures, to detect a virus. In other words, if a known virus always had the string h4h4.infect.1+ at a given offset within the binary, then the AV software would see that it is present in its database and flag it as infected. This is very ineffective in the long run, especially since viruses are constantly mutating into new strains.

Some AV products are known to use emulation for dynamic analysis that can feed the heuristics analyzer with information about an executable's conduct during runtime. Dynamic analysis can be powerful, but it is known to be slow. Some breakthroughs in dynamic malware unpacking and classification have been made by Silvio Cesare, but I am not certain whether this technology is being used in the mainstream.

Currently, there exists...

Summary

In this chapter, we covered the "need-to-know" information about virus engineering for ELF binaries. This knowledge is not common, and therefore this chapter hopefully serves as a unique introduction to this arcane art of viruses in the underground world of computer science. At this point, you should understand the most common techniques for virus infection, anti-debugging, and the challenges that are associated with both creating and analysing viruses for ELF. This knowledge comes to great use in the event of reverse engineering a virus or performing malware analysis. It is worth noting that many great papers can be found on http://vxheaven.org to help further your insights into Unix virus technology.