-=( ---------------------------------------------------------------------- )=- -=( Natural Selection Issue #1 ---------------------- Covering Your Tracks )=- -=( ---------------------------------------------------------------------- )=- -=( 0 : Contents --------------------------------------------------------- )=- 0 : Contents 1 : Introduction 2 : The Obvious 3 : Keeping Too Much Info 4 : More Recently 5 : Conclusion -=( 1 : Introduction ----------------------------------------------------- )=- In the past little while we saw a number of large scale virus scares like Melissa and many others. These viruses created a response like none past from the AV, the public, and, consequently, various law enforcement agencies. It seems that nowadays, when a virus that gets very far is created, the FBI and/or the police go after the author more than the parties they believe to be responsible for the distribution. The point of this article is to make you a little more aware - or at least get you thinking about - writing a virus in such a way that, if the virus is spread, you can hopefully avoid getting a call from the FBI and spending a few unpleasant hours in questioning where you're asked you all sorts of nasty questions whose answers are really none of their business. I have noticed that people seem to be writing their viruses in such a way that they leave tracks back to themselves to various degrees. From there, it's just a matter of effort to found out who wrote it. Usually the errors in coding that lead to these tracks can - and thus should - be avoided. Granted - the police, is generally too stupid/lazy to disassemble your code and find the things that they could use to trace you back, but if the virus ever gets wide-spread enough, someone self-righteous idiot will take it upon himself. Yes, the police usually catch virus writers through other means (like the guy responsible for Melissa was caught from phone records) thus this article wouldn't have been much use to him, but if the guy had covered his tracks better in the real world, then the police might have no other choice but to have a more careful look at the virus itself. -=( 2 : The Obvious ------------------------------------------------------ )=- I don't really think I have to mention something this obvious, but: IF YOU DON'T WANT TO BE TRACED THEN DON'T PUT YOUR NAME INTO IT!!!!!!! How hard is it to find the author of a virus when the string "Virus XXX by YYYY/group (c) date" is in the virus and printed to the screen every once in a while? If the cops have a handle to work with, it's only a matter of time before they find one of your posts on newsnet, find you on IRC, or get some vXers or AV guys (The AV guys seem to actually collect a surprisingly large amount of information about xXers) help in tracking you down? Anonymous remailers and such help, but one slip and you may as well not have ever used one. And always remember, the amount of hype a virus gets is directly proportional to the amount of energy and man-power the police are willing to use to track you down. Another thing I found from talking to a person that shall remain nameless for now. He made an IRC worm that, when certain people who he hates join a channel, (and an infected user has ops) then it kicks them. What's wrong with that you ask? All anyone has to do is to go onto IRC, find who is using the nick that gets kicked, and most likely that person will have a very good idea as to who wrote the virus - and may be more than willing to talk about it. Another author, who will also remain nameless, gets his worms to message him when an infected user logs on (not to mention piss off entire channels full of vXers). Ugh... The same principle is true about including names of friends. Although a friend will most likely be much more reluctant to give you away, there is no point in taking the chance that the police can twist their arm enough. After all, it's rare to have friends that value their friendship more than avoiding criminal charges for themselves (which they probably would, in the name of Justice, be blackmailed with). In short, if you're including your Handle (or that of your friends and enemies) in a virus, you may as well put into it your real name and telephone number (and reading the rest of this article is completely pointless since you obviously don't care). -=( 3 : Keeping Too Much Info -------------------------------------------- )=- Keeping too much information in your virus can result in the virus being tracked back at least 1 generation. Thus the original infected file on a system can usually be tracked down, and either human memory or file logs can in theory determine where the file came from. Typically this does not happen as the infected systems are too numerous and the sys admins "too busy" to be bothered. To understand why this is the case, one has to understand the difference between the data segment (.data) and the uninitialized data segment (.data?). For simplicity lets look at a DOS EXE virus, though the principle is the same in any executable format. Suppose you have a DOS direct action EXE virus that looked something like this psuedocode: VirusSize equ VirusEnd - VirusStart VirusStart: - Save OldIP .. OldSS into HostIP .. HostSS - Set the DTA to NewDTA - If time for payload, write VirusName and Message - Save Current Directory into CurrentDir - Find EXE file - if not found switch to PrevDir and try again - Read in EXE header - store values into OldIP .. OldSS - Do polymorphic stuff on virus - store 'poly'ed virus into PolyVirus - Modify header and write out VirusSize to the end of file. - Return to original directory with GoOldDir - Restore DTA to PSP:80h - Restore and jump to host with HostIP .. HostSS ; .Data Section VirusName db '[XXXX]',0 Message db 'Some message for payload',0 GoOldDir db '\' ; (The '\' needed to restore dir) CurrentDir db 65 dup (?) HostIP dw ? ; IP of currently running file HostCS dw ? HostSP dw ? HostSS dw ? OldIP dw ? ; IP of infected file OldCS dw ? OldSP dw ? OldSS dw ? NewDTA db 128 dup (?) FileMask db '*.EXE',0 PrevDir db '..',0 VirusEnd: ; .Data? Section PolyVirus db VirusSize dup (?) So, let's look at this in detail. Viruses usually don't copy all of their data into the new host. For example, the space needed to store the polymorphed virus would be a waste of space to store on disk (not to mention you'd create an infinite loop in the definition of the virus's size). However, many more things should be kept out of the data section too. The .Data section, is basically the section between the VirusStart and VirusEnd. This section contains data (like code, filemasks, etc) that needs to be set for every generation. The .Data? section, is the place where one keeps uninitialized data that is set at runtime, and can be anything at load time. This is the stuff outside (usually after) the VirusEnd, as only the section between VirusStart and VirusEnd is copied in every generation. Variables that are set at runtime should be kept here. It is this lack of differentiating between .data and .data? which is causing the possibility to be tracked back. So let's look at the example: -=( 3.1 : Old Host Info -------------------------------------------------- )=- During the infection of a file, the files original CS:IP and SS:SP are saved in OldCS, OldIP, OldSS and OldSP. When an infected file is run, it must re -save these somewhere else, otherwise during it's infection process, this information would be overwritten by the CS:IP SS:SP of the file being infected, and thus could not return to the host (I don't think I'm telling you anything new here). The Problem is that the HostCS, HostIP, HostSS and HostSP contain the CS:IP and SS:SP of the program that is infecting. This information is written out into the next generation of the virus. That means, that the information about the previous generations CS:IP & SS:SP is in the virus (on disk). That being the case, a scan through all the infected files on the system (a scan that would match OldCS in one file to the HostCS of another, etc) could usually find the order in which the files were infected. After finding the first infected file, figuring out where it came from is usually easier. This is all, of course, if someone has enough patience to do this - but for the purpose of this article, one assumes the virus really annoyed someone, and they're pulling out all the stops. So, what can be done about this? Simple. Move the variables HostCS, HostIP, HostSS and HostSP into the .data? section (after VirusEnd). This will not only reduce the size of the virus by 8 bytes, but also make this method of tracking impossible. -=( 3.2 : Directory ------------------------------------------------------ )=- When the virus starts up, it gets the current directory and stores it into the variable 'CurrentDir'. When the file infects, it copies all the data between VirusStart and VirusEnd INCLUDING 'CurrentDir' into the host. Thus EVERY infected file will have a text string pointing to the directory from where the file that infected it was run from. Thus, a simple search through the files will tell you all the directories that files were infected from. When the person finds a file with a directory that does not exist on his computer, one can say, with reasonable assurance, that that is the file which started the infection and thus its source. Not only this, but having the directory in the virus can help locate all infected exes. Again the solution is the same as before but with a twist. Since the coder was clever and used the '\' as a means of being able to switch the directory later (by calling ChangeDir with GoOldDir as an argument), you just can't move the buffer for the path alone. Two simple solutions exist. Either move the '\' as the last thing in .data and the path as the first thin in .data?, or simply copy the '\' into the path buffer manually. Similarly, the DTA should also be in .data? as it a) serves no purpose in being in .data at all in the first place, b) the virus shrinks by 128 bytes with no loss of functionality, and c) the DTA - being the Disk Transfer Area and all - will have fragments of the files you are infecting (hence once again it could be possible to track down the oldest infection on a system). -=( 3.2 : Time Change----------------------------------------------------- )=- If the virus does not reset the file time after infection, then it is possible to look for the oldest infected file on the system and figure out where it came from. The solution is obvious, and there really is no excuse for changing file times as resetting them back to normal is trivial. -=( 4 : More Recently ---------------------------------------------------- )=- More recently, things like worms are becoming more popular and things like mass mailers are still going strong. In a mass mailing virus, assuming someone was stupid enough to send the first file out from his hotmail account (or worse - their ISP account), then obviously the "From: " field should not give away the last infected user. Unless the virus sends itself through an anonymous remailer however, the worm is still traceable fairly easily. The implication of this is of course that viruses and worms which spread by sending email with "Click on virus.exe for a good time" messages, are not all that great at being untraceable. Other worms - like exploit worms (like Code Red, et al.) - can store other info which could be used to trace back - like IP addresses. That of course is another nice thing to avoid. The host hog files should also always be modified or deleted. -=( 5 : Conclusion ------------------------------------------------------- )=- Be very careful as to what kind of info you have stored in your data segment at the time of infection. If there's something that gives away even one generation of the file, then either move it to .data? or if that's impossible, then zero it before propagation. Granted, I don't expect law enforcement or others to use these methods of discovering where a file came from (for they know very well that infected any break in the infection trail means a dead end, and even with luck on their side, all they'd probably find is a hacked account somewhere or anonymous post), but there really is no reason to risk it, is there? Then again, maybe I'm being paranoid, but it's not that hard to be careful. -=( ---------------------------------------------------------------------- )=- -=( Natural Selection Issue #1 --------------- (c) 2002 Feathered Serpents )=- -=( ---------------------------------------------------------------------- )=-