|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| Malware | 2019 | 2018 | 2017 | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 | 2010 |
| 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 |
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
It looks like the author of Klez was involved in spam distribution, may be porno spam distribution, the worm demostrated a couple of well-known spammers tricks, including fake sender and usage of rejected messages -- both tricks were never used by prev worms.The fake mail generation had shown the problem with SMTP mail quit vividly, and here there is nothing AV companies can do -- this is a weakness of the protocol, that makes finding infected computer more difficult. It's interesting that AV software became part of the problem, not part of the solutions, as warnings were send to wrong people contributing to the confusion.
Signature-wise AV companies reaction was to Klex.h was not that bad (24-48h) and more quick and coherent than usual because it was a new version of already known virus. The other to notable tricks that this Klex.h played is that infected attachment sometimes makes as a disinfection tool for Klez.E and as a rejected message.
IMHO this virus had shown that executable attachments stripping is not an option, this is a necessity in a corporate environment. Corporations that don't do this are simply irresponsible. This was true two yeas ago and this is true now: enough is enough.
Among typical subject lines:
Hi,
Hello,
Re:
Fw:
how are you
let's be friends
darling
your password
honey
some questions
please try again
welcome to my hometown
the Garden of Eden
introduction on ADSL
meeting notice
questionnaire
congratulations
sos!
japanese girl VS playboy
look,my beautiful girl friend
eager to see you
spice girls' vocal concert
Japanese lass' sexy pictures
File::Scan 0.33 (Development) by Henrique Dias - Tuesday, July 16th 2002 06:08 EDT
Index of -authors-id-H-HD-HDIAS
About: File::Scan allows users to make multiplataform virus scanners which can detect Windows/DOS/Mac viruses. It include a virus scanner and signatures database.
Changes: Two new virus signatures have been added (W32/Duni.worm.b, W32/Plex@MM), and the W32/Frethem.fl@MM signature has been updated.
|
|
|
About: MIMEDefang is a flexible MIME email scanner designed to protect Windows clients from viruses. However, it can do many other kinds of mail processing, such as replacing parts of messages with URLs, adding boilerplate disclaimers, and so on. It can alter or delete various parts of a MIME message according to a very flexible configuration file. It can also bounce messages with unacceptable attachments. MIMEDefang works with Sendmail 8.11/8.12's new "Milter" API, which makes it more flexible and efficient than procmail-based approaches.
Changes: Support for RAV Anti-Virus and Trend Micro "vscan" was added. The -U option was added, allowing filters to be run as a non-root user. Warnings can now be placed inline instead of in their own MIME part. The sample filter was tightened up and the code was reorganized. Parts of type "multipart/alternative" are now longer inappropriately converted to "multipart/mixed".
|
|
|
GPLed program. Uses two instances of Sendmail and serves as a bridge between them. This solutions can be used for filtering spam too.
About: MailScanner is an Email virus scanner and spam tagger. It supports sendmail and Exim MTAs, and the Sophos, McAfee, F-Prot, F-Secure, CommandAV, InoculateIT, Inoculan 4.x, and Kaspersky anti-virus scanners. It supports SpamAssassin for highly successful spam identification. It is specifically designed to handle Denial Of Service attacks. It is very easy to install, and requires no changes at all to your sendmail.cf file. It is designed to be lightweight, and so won't grind your mail system to a halt with its load.
Changes: This release fixes the problems caused by viruses embedding newline characters in the middle of the subject line, which broke the MIME parsing code. The Sophos "autoupdate" script was fixed to properly handle the new Sophos "NSV" version of their virus scanner.
|
|
|
Perl module
About: File::Scan allows users to make multiplataform virus scanners which can detect Windows/DOS/Mac viruses. It include a virus scanner and signatures database.
Changes: New virus signatures were added. A "suspicious" method was added to test if the file contains suspicious words. The speed was increased and the documentation was updated.
... ... ....
|
|
|
|
|
|
COMPUTER VIRUS MAKING TO BE PROSECUTED AS HATE CRIME FOR TARGETING STUPID PEOPLE
Systems Administrators Now On Front Lines of Bias Crime
Washington, D.C. (SatireWire.com) - With yet another email virus spreading across the globe, 41 U.S. states and six European countries today announced that the act of creating an attachment-based computer virus will now
be considered a hate crime because it intentionally targets stupid people."In a hate crime, the offender is motivated by the victim's personal characteristics, and in the case of email viruses, the maker is clearly singling out those who open email attachments when they've been told a
thousand times not to," said California Attorney General Bill Lockyer. "Like any other segment of the population, people of stupidity need protection from bias."The decision, however, is already causing a firestorm of controversy. In the United States, the American Civil Liberties Union vehemently opposed the action, arguing it runs counter to the spirit of hate crime laws.
"Hate crime statutes are specifically designed to protect minority groups," said ACLU President Nadine Strossen. "I'm not sure the number of stupid computer users meets that criterion."
France, meanwhile, said it would not prosecute anyone willing to write a virus in French.
But in London, the British Civil Idiots Union applauded the move, arguing that virus-based hate crimes cause victims to suffer psychological harm. "Every time we pass on one of these emails, our self-esteem is shattered when we are forced to publicize our condition," said CIU President Michael Overly. "It's always a shock to my system every time I have to write, "Hey everybody, if you get an email attachment from me, don't open it! I just found out my computer got infected by a virus! Sorry!"
|
|
|
Reverse Engineering Hostile Code
by Jon Stewart
last updated October 23, 2002Computer criminals are always ready and waiting to compromise a weakness in a system. When they do, they usually leave programs on the system to maintain their control. We refer to these programs as "Trojans" after the story of the ancient Greek Trojan horse. Often these programs are custom compiled and not widely distributed. Because of this, anti-virus software will not often detect their presence. It also means information about what any particular custom Trojan does is also not generally available, so a custom analysis of the code is necessary to determine the extent of the threat and to pinpoint the origin of the attack if possible.
This article outlines the process of reverse engineering hostile code. By "hostile code", we mean any process running on a system that is not authorized by the system administrator, such as Trojans, viruses, or spyware. This article is not intended to be an in-depth tutorial, but rather a description of the tools and steps involved. Armed with this knowledge, even someone who is not an expert at assembly language programming should be able to look at the internals of a hostile program and determine what it is doing, at least on a surface level.
Tools Required
As with most types of engineering, you'll need some tools. We'll cover tools native to both Unix and Windows. While Unix is the ideal platform to perform the initial reverse engineering process, you can still make do on Windows, especially if you install tools such as Cygwin, a Unix environment that runs on Win32 platforms. Most of these commands are also available for Windows when running Cygwin. However, when you get to the decompile/disassemble/debug steps ahead, going the Windows route will cost a lot of money, whereas the Unix solutions are all free. Be sure to weigh the costs of working on Windows versus the benefits before making it your reverse-engineering platform of choice.
Some useful commands are:
dd - byte-for-byte copying of raw devices. Useful to perform analysis on a compromised system's hard drive without affecting the integrity of evidence of the intrusion.
file - tries to identify the type of a file based on content
strings - outputs the readable strings from an executable program.
hexedit - allows you to read and edit binary files
md5sum - creates a unique checksum for a file for comparison
diff - outputs differences between files
lsof - shows all open files and sockets by process
tcpdump - network packet sniffer
grep - search for strings within a file
Compressed ExecutablesTrojans are often compressed with an executable packer. This not only makes the code more compact, it also prevents much of the internal string data from being viewed by the strings or hexedit commands. The most commonly used executable packer is UPX, which can compress Linux or Windows binaries. There are several other packers available, but they are typically Windows-only. Fortunately, UPX is one of the few that also provide a manual decompression to restore the original file. This prevents us from having to use advanced techniques to decompress the file into its original format.
In an ordinary executable, running the "strings" command or examining the Trojan with hexedit should show many readable and complete strings in the file. If you only see random binary characters or mostly truncated and scattered pieces of text, the executable has likely been packed. Using grep or hexedit, you should be able to find the string "UPX" somewhere in the file if it was packed by UPX. Otherwise you may be dealing with one of the many other executable packers. Dealing with these other formats is beyond the scope of this article, but you can find resources to help work with these files.
Decompiling
Occasionally you will get lucky and find that the Trojan was written in an interpreted or semi-interpreted language such as Visual Basic, Java or even compiled Perl. There are tools available to decompile these languages to varying degrees.
- Visual Basic - There is a decompiler floating around the Net for VB version 3. For newer versions, there are no decompilers known, but you can use a tool such as Compuware's SmartCheck to trace calls in the program. While its output is not a source code listing, you can see just about everything the program is doing internally.
- Java - There is the excellent decompiler jad, which decompiles to a complete source code listing which can be recompiled again. Several other java decompilers are also known to exist.
- Perl - Perl programs compiled into Windows executables can be reduced to their bare script using exe2perl.
Disassembly p
If the Trojan was written in a true compiled language, you'll have to bite the bullet and disassemble the code into assembly language. For Unix executables, objdump is the way to go. For Windows executables, you'll want IDA Pro or W32dasm. There is a free version of IDA that is just as powerful as IDA Pro but has a console-based interface. These programs will disassemble your code, then match up strings in the data segment to where they are used in the program, as well as show you separation between subroutines. They will attempt to show you Windows API calls by name instead of by offset. This kind of output is known as a deadlisting, and can give you a good idea of what the program is doing internally. The GNU objdump program does not provide such useful features, but there is a perl-based wrapper for objdump called dasm, which will give you much of the same functionality as the Windows disassemblers.
Debuggers
While a deadlisting can be quite valuable, you will still want to use a debugger to step through the program code, especially if the Trojan is communicating via network sockets. This gives you access to the memory and temporary variables stored in the program, as well as all data it is sending and receiving from socket communications. On Unix, gdb is the debugger of choice. It has a long history on Unix, is well documented, and best of all, is available free of charge. Under Windows, the choices are far more varied, but most tutorials on reverse engineering under Win32 assume you are using SoftICE. It does cost a fair amount of money, but is worth getting if you can afford it.
Preparing to Debug
You must take precautions when running hostile code, even under a debugger. You should never debug a Trojan on a production network. Ideally, you should set up a lab network, as shown in figure 1.
Figure 1: A typical debugging network
The debug system should have a clean install of whatever OS the Trojan is intended for, with a second box acting as a firewall. A third system on the network allows you to emulate services and capture the network traffic generated by the Trojan. Capturing this traffic can be invaluable in tracing the source of the infection. Ensure that you firewall all outbound connections, allowing only the Trojan's control connection through. If you don't want the master controller to know your lab network is running the Trojan, you can set up services to mimic the resources the Trojan needs, such as an IRC or FTP/TFTP server.
Stepping Through the Code
Now that we have constructed a proper quarantined lab environment, we can begin debugging the code. Using the deadlisting, we look for key functions in the program, such as Winsock and file I/O calls. The debugger allows us to set breakpoints in the program based on offset values, so we can interrupt the flow of the program and examine the program memory and CPU registers at that point. The remainder of this article will look at an example of how such a debugging session might look on an x86 Linux platform.
Running the DebuggerWe want to know how the Trojan communicates with its controller. Often, sniffing the network traffic will be sufficient. However, many newer Trojans are incorporating encryption into their network traffic, making network sniffing a lost cause. However, with some cleverness we can grab the messages from memory before they are encrypted. By setting a breakpoint on the "send" socket library call, we can interrupt the code just prior to the packet being sent. Then, by getting a stack trace, we can see where we are in the program. For example, the Trojan source code might look something like:
/* encrypt output to master */
elen = encrypt(crypted,buf,len);/* write crypted output to socket */
send(s, crypted, elen, 0);Examining the compiled Trojan in gdb might give us the following output [note that the bolded statement represent the author's comments on the output]:
[test@debugger test]$ gdb
./Trojan
GNU gdb 5.2.1-2mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of
it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "i586-mandrake-linux-gnu"...
(no debugging symbols found)...
(gdb) set disassembly-flavor intel [Switch syntax output from AT&T]
(gdb) b send [Set a breakpoint on the "send" library call]
Breakpoint 1 at 0x400f5c10
(gdb) run
Starting program:/home/test/Trojan Breakpoint 1, 0x400f5c10 in send () [We hit a breakpoint]
(gdb) where [Do a stack trace to see where we are at in the program]
#0 0x400f5c10 in send () from/lib/i686/libc.so.6
#1 0x080487fa in socket ()
#2 0x40040082 in __libc_start_main () from/lib/i686/libc.so.6 The above output from the "where" command in gdb shows us the offset each subroutine will return to after execution. Since we know that the "send" call was right after our encrypt call, we need only to examine the previous subroutine, which encompasses the return offset 0x080487fa. We are interested in the assembly language code just prior to this offset. Using gdb, we can disassemble the code at this point.
(gdb) disas 0x080487d2 0x080487fa
Dump of assembler code from 0x80487d2 to 0x80487fa:
0x80487d2 : call 0x8048804
0x80487d7 : add esp,0x10
0x80487da : mov DWORD PTR [ebp-836],eax
0x80487e0 : push 0x0
0x80487e2 : push DWORD PTR [ebp-836]
0x80487e8 : lea eax,[ebp-824]
0x80487ee : push eax
0x80487ef : push DWORD PTR [ebp-828]
0x80487f5 : call 0x8048534
End of assembler dump.We see that just prior to the call to "send", there was a call to 0x8048804 . In reality, this is our "encrypt" subroutine. When programs are stripped of their symbols, gdb is often confused about where subroutines begin and end, so it continues the name of the last one it recognizes for all following subroutines, often the previous dynamic library call. In this case, it is mislabeled as being part of the "socket" function.
To examine the contents of the unencrypted packet, we need only know how the "call" instruction works. The arguments to our subroutine were pushed onto the "stack", a place where temporary data and return offsets are stored. We can access the contents of the variables by setting a breakpoint on the call and then using an offset from an internal CPU register known as the stack pointer, ESP. ESP+4 will be a pointer to the first argument, ESP+8 will be a pointer to the second argument, ESP+12 will be a pointer to the third argument, and so forth. Just keep poking at the stack until something useful comes up. In this case, the useful information (the plaintext data) is in the second argument to "encrypt". Let's set a breakpoint at the encrypt call, and examine the stack [Again, the bolded statement represent the author's comments on the output.]
(gdb) b * 0x80487d2 [Set a breakpoint on the "encrypt" call]
Breakpoint 2 at 0x80487d2
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) yStarting program:
/home/test/Trojan
(no debugging symbols found)...
Breakpoint 2, 0x080487d2 in socket ()
(gdb) x/x $esp+8 [Get the offset of the second argument ESP+8]
0xbffff5e4: 0x0806fe20
(gdb) x/fs 0x0806fe20 [Examine the contents of the memory at 0x0806fe20]
0x806fe20: "root pts/0 Oct 11 14:22\n"From this output we can see that the Trojan is reporting back on who is currently logged on to the system. Of course, it could send any kind of data; network packet captures, keystroke logs, etc. Fortunately, we have our network set up so this traffic will be redirected to the sniffer host instead.
Conclusion
The Trojan above is not real. Had it been an actual Trojan, we might have followed additional courses of action. Often times a Trojan will use established channels such as IRC to reach its master. We can take advantage of this fact, and use it to track down the source of the attack, even gaining control of the entire network of Trojaned hosts if the Trojan writer has been careless. If the Trojan uses FTP to update itself, you might find additional code on the FTP server and possibly clues to the identity of the Trojan writer.
Although we've only scratched the surface of reverse engineering, you should be able to take the basic information above and put it to work. Read the documentation for your debugger; you'll be surprised at how powerful it can be, and how much it can tell you; even if you're not the best at reading assembly code. If it seems overwhelming at first, don't give up hope. The payoff can be quite gratifying. During one reverse-engineering session the author of this article found the real name of the Trojan author unintentionally embedded in the program's source code (hint: don't write Trojans in VB when logged in to your NT workstation at work). With a quick trip to Google the author's email address and picture was available, posted to a VB discussion site. One "whois" later and his home address and phone number was found.
|
|
|
As the saying goes, an ounce of prevention is worth a pound of cure, particularly when it comes to computer security incidents. By taking steps to prepare for incidents of all types, administrators can prevent or severely hamper the installation and activation of all sorts of malware.
The first step to preventing malware from being installed on a Win2K system is to understand how the malware gets onto the system in the first place, and what it does once it is activated. The point at which malware infiltrates a system is referred to as the "infection vector". Unfortunately, there seems to be an almost unending supply of infection vectors, ranging from age-old misconfiguration issues (i.e., open network shares) to more recent issues such as Malware combining multiple IE vulnerabilities). Then, of course, there are e-mail attachments and users downloading infected files. Due to the sheer enormity of possibilities, the infection vectors will not be addressed specifically in this article. (However, Paul Schmehl's SecurityFocus article Infection Vectors: Past, Present, and Future offers a good discussion.)
Once a backdoor Trojan is on the system, for the most part, it usually instigates some sort of action, usually one that allows the attacker to manipulate or control the target system. At a bare minimum, the Trojan or bot needs to be activated, therefore activating will be a process the system. For a process to be running, in most cases, a file (or several files) will need to be copied to the victim system. For the attacker to control the Trojan (and hence, the victim system) a network port will need to be opened. In the case of Trojans, a port will be opened and netstat.exe will report a state of "LISTENING". Most IRC bots will open a client port and connect to a remote IRC server, most generally on port 6667.
Finally, most Trojans and bots will include a mechanism for establishing persistence, so that they will be active across reboots, and logins by different users. Reviews of anti-virus Web sites clearly demonstrate how this is done. For the most part, Trojans and bots create an entry in a Registry key so that they are restarted whenever the system restarts or the user logs in. For example, Backdoor.Latinus.B creates an entry in the ubiquitous "Run" key, as does the "russiantopz" IRC bot:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
Backdoor.OptixPro.10 modifies the Registry key that defines the standard Windows execution of ".exe" files:
HKEY_CLASSES_ROOT\exefile\shell\open\command
Another persistence mechanism includes creating a shortcut in a Startup directory.
The prevention mechanisms available to administrators are quite simple [2]. While setting up systems from a minimalist perspective, administrators can set access control lists (ACLs) on directories such as c:\winnt\system32to prevent users from writing to (i.e., creating or modifying files) them. The same applies to certain Registry keys, particularly those mentioned above. If the infrastructure and corporate environment allows administrators to restrict a user's ability to install software, then setting the appropriate ACLs will prevent or severely hamper the installation of Trojans and bots.
Tracking Down the Trojan
Many times, the administrator will suspect the presence of a Trojan or bot due to some unusual behavior on the infected system. This may be seen as a slight change in how the system responds, as unusual traffic captured via an intrusion detection system (IDS), or via filtering at a firewall. Other times, the initial discovery may come from an outside source, as the infected system may be used to scan or attack other systems, and the victim of that attack puts forth the effort to contact the administrator.
However the malware is discovered, the follow-up steps taken by the administrator are critical. Public lists abound with posts by administrators who port scan systems to determine open ports, or discover "something unusual" in the Registry of the victim system and simply delete the entry. Both of these actions are, at best, ineffective incident response measures, as they really don't provide the administrator with usable forensic information. Open ports obtained from a port scan usually lead to the administrator searching for executables or services that "officially" use those ports. However, new Trojans are being developed all the time, and while they generally have default ports that they bind to in order to listen for connections, this port assignment is usually configurable by the user.
A more effective means of determining if a Trojan or bot is installed on a system is to gather very granular process information from the system. There is a small set of five tools that can be run to collect this information. Specifically, these tools are:
- handle.exe
- listdlls.exe
- pslist.exe
- fport.exe
- netstat.exe
The first three tools are available from SysInternals, fport.exe is available from FoundStone, and netstat.exe is a tool native to Win2K systems.
(Author's Note: There has been a good deal of discussion about rootkits and Trojaned binaries on Win2K systems. While this is something that happens on Linux systems quite a bit, similar activity has not been reported to a similar extent on Win2K systems. This is not to say that such things don't exist. Greg Hoglund's NTRootKit is an example of such a thing for NT and 2K systems. However, as of the publication date of this article, there have been no reports of extensive use of the rootkit. If there is a concern about Trojaned binaries, specifically netstat.exe, then copy the executable from a "clean" system when creating an incident response CD.)
The listed tools, along with a batch file that launches them, can be copied to a diskette in the following manner:
@echo off @echo Running listdlls... listdlls > a:\listdlls.log @echo Running handle... handle > a:\handle.log @echo Running pslist... pslist > a:\pslist.log @echo Running fport... fport > a:\fport.log @echo Running netstat... netstat -a > a:\netstat.log @echo Done.The batch file runs each of the tools in turn, redirecting the output of the files to log files on the diskette. The administrator can run the batch file, or have a first responder run it. Other methods of obtaining the information include using psexec.exe from SysInternals to run the tools remotely via an Administrator connection to the victim system.
Running the preceding batch file (or executing the commands by hand) will result in five log files being created. Next, the investigator will need to parse through these files, correlating data on a per-process basis, and then analyze that data. The available information will include such things as the process name and identifier (PID), the path to the executable image for the process, the security context that the process is running in, the command line used to launch the process, modules and handles used by the process, and so on. This is a lot of information to sort through, the analysis of which is prone to errors. A much faster way of correlating the data into a single, easy to read view is to use a tool like procdmp.pl (which the author created). This script parses through the five files and correlates information about each process. An example HTML output file is available here.
Notice in the example HTML output file how the information for each process is listed in a tabular format. Each process is listed with the PID, command line, context, open filehandles, and open ports, if any exist. The third process should be of particular interest, with a PID of 1148. At first glance, a process called "inetinfo" might seem to be relatively harmless. In fact, this process is most often associated with the IIS Web server. However, a look at the command line will show that this particular process is probably a copy of Netcat, running on port 8080. The "open ports" section of the output not only shows that port 8080 is open in "LISTENING" mode, but also that there is a remote system connected to the system.
As a point of interest, another interesting process listed is PID 776. This process has the command line shown with a background color of red, indicating that the process was launched from an NTFS alternate data stream. This may be another indicator of malicious code, because alternate data streams are not normally used.
There is also a standalone executable version of procdmp.pl that provides a GUI for selecting the files to be parsed. This utility is available from the same Web site as procdmp.pl.
These five utilities will provide a comprehensive snapshot of the running processes on the system. Correlating the data using tools such as procdmp.pl makes the data easier to read, and is less prone to misinterpretation. By using these tools, investigators can quickly retrieve and analyze data, and make accurate decisions regarding follow-up steps in their investigations.
|
|
|
THE PROGRAM HAS CODE that not only works hard to hide the virus' presence, it also randomizes the program's size so as to make it harder to identify. On top of that, the fourth and latest variant of the bug-which emerged this week-can spread to both Windows and Linux computers."This is really pushing the boundaries on how to create cross-platform viruses," said Vincent Weafer, senior director of security response for antivirus-software maker Symantec.
The virus is hard-coded proof that a small segment of rogue programmers can create complex code that is still difficult for antivirus software to detect. If more viruses like Simile.D appear, it could leave antivirus companies with a tough trade-off.
With complex viruses such as Simile.D, antivirus software has to try multiple ways of identifying the code to get high recognition rates. And while that might leave PC users protected from such viruses, it would also bog down most computers. On the other hand, efforts to maintain performance may instead let stealthy bugs through.
"It is getting us to think about different ways of handling the problems," said Jimmy Kuo, antivirus researcher and McAfee Fellow at security-software maker Network Associates. "What we are worried about is detection taking too long to be useful. If the viruses get so complicated that detection takes forever to detect the virus, than that will cause a problem."
That's more of a threat than Simile.D itself.
If loosed on the Internet, the virus could cause some problems for administrators because of its ability to jump from Windows to Linux and back again. But the virus doesn't do much harm. On Windows systems, it opens a dialog box with the author's name and the name of the virus, and it's programmed to do this only twice, on March 17 and Sept. 17. On infected Linux computers, the virus posts a message with similar content to the console, on March 17 and May 17.
Other attempts have been made to create a virus that infects both Windows and Linux, most notably the year-old Winux or Lindose virus. However, that virus failed to spread. While Simile.D spreads successfully to Linux machines, the risk is lessened by the fact that only systems running in so-called superuser mode can be fully infected. "Superuser" and "user" modes refer to the level of access a user has to a system and the programs on it.
"It is less effective in Linux, especially if the user is running in user mode," said Symantec's Weafer. "It's more likely to infect from a Linux system to a Windows system than the other way around."
Roger Thompson, technical director of malicious code research for security-information provider TruSecure, didn't think the Simile.D virus would be much to worry about, even with it's cross-platform attack.
"It's going to be a Code Red and a Nimda-worms that use some new exploit-that are really going to spread," Thompson said.
Nimda, which struck last September, blended several different types of attacks-spreading by e-mail, JavaScript, shared network drives, and vulnerable Web servers-and poked holes in the defenses of many companies, even those with antivirus software.
Nimda, like Simile.D, showed antivirus vendors that the arms race between the virus writers and antivirus researchers is going full tilt.
Simile.D, also known as Etap.D, is an example of a "concept virus," a lab sample created by the virus underground and published for others to see. The major antivirus companies have already incorporated detection into their software, so Simile.D poses little threat to most users on the Internet who regularly download the latest definitions.
Yet, finding ways to detect it weren't easy.
Many antivirus programs detect viruses based on a "digital fingerprint" of the code. For example, the latest variant of the Klez worm, Klez.h, can be easily detected by current antivirus software based on its digital fingerprints.
However, with Simile.D's ability to change its characteristics like a chameleon, that's not possible.
For just such an eventuality, most antivirus programs also look for virus-like behavior and try various types of pattern-matching that are keyed to encryption routines designed to hide a virus, and to the way a virus piggybacks on other programs.
"What you end up doing is a combination of the above, and you look at the code itself," said Symantec's Weafer.
Such techniques are time consuming, however, leaving software makers looking for other ways to maintain system security: "signing" code with a digital signature from a trusted source; keeping a database of acceptable code on the system; and limiting user power on the computer to certain tasks that aren't subject to virus attacks.
But while Simile.D has renewed discussions between antivirus researchers over how best to keep viruses out of systems in the future, standard measures still work, said Network Associates' Kuo.
"We aren't there yet," Kuo said.
Google matched content |
...
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March, 12, 2019
