Can viruses actually inject their code in other processes?

Question

Can a virus really inject its own code into a process so it stays on your computer permantly? The only way to actually remove it is to reinstall your OS. My question is how can it do that without damaging the file or process?

Answer 1

You can use DLL Injection to inject code into other processes without affecting any other data
(depending on the method, of course).

Other ways include renaming and moving legitimate files and replacing them with infected versions, startup entries, etc., but those are easily removable manually.

The only way that I can think of to permanently infect without personally using OS patches or other data modifications is to use a startup entry to load a rootkit driver such as Migbot or FU that also includes function hooks to hide files and registry entries, making it impossible to remove manually.

However, this type of rootkit usually uses kernel patches, which modify the binary OS data on disk (making a reinstall necessary to completely disinfect) and defeats the whole purpose of not modifying data.

The only alternative is to stay out of the kernel and use a normal process to run the malware and use Windows Message hooks or something similar to apply hooks without modifying data.

There is a downside to this approach though... Userland hooks are very easy to detect, compared to kernel OS patches.

So, therefore, it is possible to have malware that does not modify data, but it is easily detected and removed by any half-aware antivirus/rookit software, which means that not many (if any!) in the wild malware will use non-modifying approaches because patches and such are much better from a stealth standpoint (and sometimes even easier than non-modifying hooks!).

Answer 2

You are asking about two different issues.

Can viruses actually inject their code in other processes?

The answer is: Yes, they can. You can inject your code into other processes with DLL Injection. This does not ensure that the virus will load each time the computer starts up or that the virus will be undetectable / nondetachable. It just means that the virus will be running from the address space of another process (possible PE).

Does the fact that viruses inject their code into other processes ensure that they will be "attached to the os" until a re-installation?

No, unless they have some rootkit capabilities. There are a few methods by which rootkits attach themselves to your system. You can read about one of the methods in an article about TDL4 who's writing itself to the MBR in order to launch itself, thus ensuring that malicious code will run prior to operating system start.

If the virus is a known one, most AV's should recognize its behavior and clean your machine. For new variants of viruses / rootkits, it can be very complex to remove the malicious code with regular tools. Rootkits run from ring-0 (kernel mode) as a driver which you will have to find and disable(do this from an uninfected OS!).

Answer 3

I think it's worth understanding what running a process on an OS means, first up.

Most operating systems use something called demand paging. In Linux, this is the effect of PROT_READ | PROT_WRITE | MMAP_PRIVATE on the mmap() system call. Specifically, processes aren't wholly copied into memory - the code segments are, whilst the rest is mapped to the file system. If any of those pages are modified in memory, they're copied into memory first. This is also known as "copy on write". The implication here is that any modifications to a running process are not written back to disk automatically through mmap() (or the Windows equivalent).

The end result is that you should imagine there are effectively two things: a copy of the program on disk (hereafter disk image) and a copy of the process in memory, resident in its virtual memory sandbox (hereafter "address space").

A process' address space doesn't just compromise the program itself - it also includes shared libraries (DLLs) and in many cases, half the virtual address space includes OS stuff you can't get to (see 2GB split vs 4GB/4GB mode. Ever wonder why processes on Windows are limited to 2GB? This is why). Program data such as the stack and "heap" are also present in the virtual address space - both of these contain program data.

So now we have some background, here's the two ways you can alter a process:

Run time modifications

This is actually less modification than you might think - typically, your objective is to exploit poor coding and use an input method to get a specially crafted piece of input into the process address space, usually called "shell code" whose objective is to give a remote attacker a terminal prompt (hence "shell"). This isn't the only action you can take though - you can do anything, from downloading remote files to modifying registry settings. If you're not handing out administrator prompts to remote boxes, then your goal is most likely to deliver a bigger payload than can fit into the input buffer and execute that (drive by downloads operate this way by exploiting browser plugins).

There are various variants on this techique, but all of them involve altering the flow of execution to get something unintended, and usually beneficial to the attacker, to happen. As a result of the copy-on-write setup, the original, on disk image of the executable remains untouched, but chances are you'll crash the process you've just exploited, or else produce some glitch. It's hard, but not impossible, to produce a silent exploit.

Why does everyone keep mentioning DLL Injection?

Well, it turns out some programs are written with security as part of their development process and we can't feed them any garbage input and get them to execute it. So other techniques are needed. DLL Injection, or LD_PRELOAD in Linux-speak, is the process of getting a shared object to be loaded before all others into every, or just one processes' address space. This gives you code inside the virtual memory of a target process which can then "hook" (redirect) certain parts of the program. Tutorials for this are quite easy to find. You're then able to exploit the process to your own ends. However, you'll need the DLL on disk most of the time.

It turns out that wasn't enough for those nice people at metasploit who have developed meterpreter, a shellcode capable of downloading a DLL into memory and then injecting it into the system.

Modifying disk images

You are probably going to use the above technique or its variants to get into a system and you are probably going to deliver a payload somewhere and ensure it gets executed. However, something else you can do is to actually write a new disk image, modified with your chosen payload, over a known program installed on the system. To do this successfully you need to carefully reverse engineer the original code and insert your exploit. There are three potential issues:

1. If you make a mistake, the program will likely crash.
2. You've got moving target issues if you target a highly variable component. Will your modification work in all instances and all scenarios?
3. Some programs are specifically engineered to resist attempts to reverse engineer or patch them. This is fairly common practice in the gaming industry to prevent copying of disks. You might not think you're using anything written this way, in which case I invite you to have a read of the vanilla skype part 1 and part 2 efforts. It turns out the authors of skype don't want it reverse engineered. That level of protection makes it much harder to successfully modify the executable.

Kernel patching - what is it?

Patching is a bit of an odd word to use. Applied to the kernel, it usually means modifying data structures inside a kernel thread's address space in order to hide something, or achieve some other end, such as monitoring.

However, kernels themselves also have disk images, so it is possible to patch components of the kernel, including drivers, this way. Again, modifying disk images is hard, but not impossible.

On persistence and the reinstall requirement

Persistence requires writing to disk at some point. If the computer reboots, you're going to need your malware stored somewhere. Exploit code that is in a processes (or the kernels) address space will be lost like all RAM is between reboots, so you need some way, if you wish to persist reboot, to reload your code. This includes rootkits, which will need to ensure they are reloaded, too.

You don't technically need to reinstall your operating system even if critical parts are modified - all you need to do is replace those critical parts with clean versions (i.e. from your Windows install disc). Nothing about malware requires that you must do a re-install. It's all about how much you have to unpick and how likely it is you've removed all the bad code. As such, it is safer to do a reinstall. That is what I would do and what I would advise anyone else does.

Tell me there's some defences?!

Yes. Authenticode is designed to prevent modifications to any old program from going undetected. Kernel Patch Protection (wikipedia)(faq) protects kernel data structures from modification by drivers. W^X, ASLR, Stack Canaries, Non Executable Stack etc protect running programs from obvious modifications. None of these are perfect, but used properly they make exploitation harder.

Answer 4

Yes, it really is true. Yes, a virus can infect your machine so it stays infected until you re-install the OS.

For instance, the virus can install itself in the startup folder so it is automatically restarted each time you boot the computer. It can also modify the executable files stored on disk to replace them with an infected version, so that each time you launch the program, it gets launched with a virus already infecting it.

You didn't say why you think that viruses won't modify anything on the filesystem and won't modify the process. Some viruses certainly do one or both of these.

Answer 5

Your core assumption is incorrect - you have asked how a virus can "do that without damaging the file or process?"

Many times it doesn't - damage often occurs. This often isn't a concern of the virus writer - it all depends on their aims. Maybe they want the virus to be very stealthy - in which case they will try and write it more carefully, so there is no obvious impact. Other times they may just want the virus to spread rapidly and so you may get a very noisy virus which damages a lot of the OS/Application on its way.

Answer 6

In addition to the excellent answers here also consider that it is possible to have malware even persist beyond reinstalling the OS. If the system is infected at the firmware level (for example http://www.theregister.co.uk/2011/09/14/bios_rootkit_discovered) no amount of reinstalling of the OS will fix you. This type of attack works outside of the OS and succeeds by modifying components that the OS typically trusts implicitly.