Introduction
This latest report on malware evolution from Kaspersky Lab contains details of IT security events which occurred in the first quarter of 2006, and which are likely to influence the future evolution of malicious code and cyber threats. The report is intended for IT security professionals and users with an interest in malicious code.
- A modern Cryptonomicon: new offensives, new defences
- MacOS X under attack
- Tomorrow’s malware (vmware rootkits, boot rootkits, bios backdoors)
- Malware still calling
A modern Cryptonomicon: new offensives, new defences
The antivirus industry is constantly on the watch for new creations. Virus writers and their creations, the heavy artillery of cyber combat, are deflected by the armour of the antivirus industry. The industry finds itself in a state of continual stand-off, with virus writers always, seemingly, one step ahead – antivirus companies can only react as quickly as possible to new creations. There are many modern technologies such as proactive protection, heuristic analysis and emulation used by the industry which make it far harder to create an undetectable virus. Nonetheless, we have already encountered some of tomorrow’s threats, and the antivirus industry will clearly have to create new technologies to counter them.
We’ve reported more than once on cases where remote malicious users have moved away from the stealth use of infected computers (stealing data from them, using them as part of zombie networks etc) to direct blackmail, demanding payment from victims. At the moment, this method is used in two main ways: encrypting user data and corrupting system information.
Users quickly understand that something has happened to their data. They are then told that they should send a specific sum to an e-payment account maintained by the remote malicious user, whether it be EGold, Webmoney or whatever. The ransom demanded varies significantly depending on the amount of money available to the victim. We know of cases where the malicious users have demanded $50, and of cases where they have demanded more than $2,000. The first such blackmail case was in 1989, and now this method is again gaining in popularity.
In 2005, the most striking examples of this type of cybercrime were carried out using the Trojans GpCode and Krotten. The first of these encrypts user data; the second restricts itself to making a number of modifications to the victim machine’s system registry, causing it to cease functioning.
It’s the author of GpCode who has been most active – during the past year, Kaspersky Lab virus analysts have detected more than two dozen different variants of this type of file encryptor. The author constantly changed the encryption algorithm – however, Kaspersky Lab analysts have always been able to crack the algorithm, and add detection and decryption routines directly to the antivirus databases, without having to resort to dedicated utilities.
Since the beginning of 2006, the authors of such programs have attempted to radically alter the encryption methods used, in order to hinder the abilities of the antivirus industry to decrypt encrypted data. In January, GpCode.ac, the latest variant, appeared.
This variant of GpCode differed radically from its predecessors in that it used one of the best known and most secure public encryption algorithms, RSA. Previously, the author had used his own encryption algorithms, but with GpCode.ac, clearly decided to bring in the heavy guns.
However, once again Kaspersky Lab analysts were successful. The Kaspersky Virus Lab was able to get a copy of the main Trojan file which performed the encryption. In the vast majority of cases this hadn’t been possible, as the Trojan, once it’s delivered its malicious payload, deletes itself from the system. After several hours analyzing the disassembled code we were able to determine the key which had been used to encrypt the data. However, in order to crack RSA, you need the decryption key, which naturally enough was not included in the Trojan. However, the Trojan author made an important mistake – he used a 56 bit key, far too short for real security. Cracking the key, using knowledge about how the RSA algorithm works and current methods of cracking such algorithms on a modern PC was the work of minutes for our analysts. A file decryption routine was again added to the antivirus bases, without creating a separate utility.
However, the virus writers weren’t ready to give in. Taking into account the sad experience of their predecessors, someone (who may have been the GpCode author), in March 2006 let loose a new program which falls into the RansomWare class. (This is the name given to similar Trojans in some articles issued by the antivirus industry and by some security researchers: see http://en.wikipedia.org/wiki/Ransomware and http://www.halfbakery.com/idea/Computer_20ransomware).
The malicious users stopped using encryption algorithms. Cryzip.a didn’t use RSA, AES, or PGP. This Trojan scans the victim machine for user documents with any extension from a long list – MS Office, PDFs, zip files, images and more. Every file found was placed in a separate ZIP file which was then password protected. In every directory, the Trojan created a note to the user, in a file called AUTO_ZIP_REPORT.TXT, which informed the user that the data could be restored once $300 dollars was paid to one of several dozen accounts in the E-Gold system.
The Trojan’s author was kind enough to inform his victims that the password for the ZIP file was more than ten symbols long, and it would therefore be senseless to try and brute force it. It’s true that the current programs available for brute forcing passwords to ZIP files are able to get a password 1 to 5 symbols long in 5 – 10 minutes. However, when the password is extended to 6 – 7 symbols in length, this task becomes much more difficult and takes far longer.
The result was that it became clear that the problem of finding the password was occupying several antivirus companies at once. Some of the companies were able to get a copy of the Trojan file itself and by analyzing this file, establish what password had been used to compress the files. However, as we didn’t have the Trojan file, we used a different method, attempting to brute force the password by using a variety of known crypto attacks on ZIP archives. The result was that we managed to reduce the amount of time spent on brute forcing the password. I won’t go into specific details of the process, but we were able to open the password protected archive in a single evening.
It turned out that the author had used the directory path as a password: «C:Program FilesMicrosoft Visual StudioVC98». It’s clear that he thought by doing this that even if the Trojan fell into the hands of antivirus companies, virus analysts might well take such a string as typical of those created by files written in Visual C++, rather than understanding that it was the password they were looking for.
Whatever the case, the problem of restoring user data was solved. Unfortunately, we were not able to restore data via the antivirus program; however, knowing the password meant that the user would be able to restore data independently.
A third malicious program with similar behaviour should also be mentioned. This program is Skowor.b, which, in contrast to the first variant, an email worm, was unable to spread via email. However, it attempts to spread via shared resources which it creates itself. It is related to GpCode and Cryzip in that, once launched, it displays a message to the user that in order to get the password to delete the worm, the user has to reboot the computer five times. If this is not done, the worm will attempt to encrypt a number of important files, and change both the administrator’s password and the user password on the victim machine. Thankfully, the worm’s code is very buggy, and it therefore does not function as its author intended.
All of these events, which took place in the first quarter of 2006 bring us to the conclusion that holding user data hostage is one of the most dangerous and rapidly evolving types of cyber crime. In connection with this, users should be particularly careful to back up data; although up until now, we have been able to restore encrypted data, there is a danger that at some stage in the future, a very secure encryption algorithm or zip technique will be used.
It should also not be forgotten that Trojans do not give appear on a victim machine of their own accord. They may be installed by malware which is already in the system, or they may penetrate through browser vulnerabilities. The one way of protecting against them is preventative – regularly scanning the system and all downloaded files with an antivirus solution, installing patches and updating the operating system promptly, and backing up all important data as a matter of course.
As for what should be done if the data has already been encrypted – the examples above show that antivirus companies are able to help here, and in a relatively short space of time. Users should not give in to blackmail, as any money paid to virus writers will simply encourage them to continue to write and release new variants.
Mac OS under attack
Apple has undoubtedly become an IT market leader over the past few years. The sensational announcement that new versions of MacOS would run on Intel processors made many look differently at the future of traditional personal computers. Until the announcement was made, personal computers had been a field of battled between Windows and Linux based platforms. The possibility of using MacOS was of interest to a great many people. The potential popularity and consistent growth of future versions of MacOS didn’t just attract the attention of IT professionals and users, but naturally also of virus writers and hackers around the world.
We don’t intend to cover how many critical vulnerabilities have been discovered in MacOS over the past few months, and how quickly it is possible to hack a MacOS machine connected to the Internet. We will stick to our topic, which is computer viruses. Until recently, MacOS X had not been seriously targeted by virus writers – there were a few simple Trojans, a handful of exploits, and that was all.
However, February 2006 brought a clear answer to the question of whether it was possible to write a worm for MacOS X. The story started when some MacOS X user forums and sites started displaying a zip file called “latestpics.tgz” which was advertised as containing the very latest screenshots from the as yet unreleased latest version of OSX, version 10.5, or Leopard.
The file actually contained a worm, which was eventually named Leap. Leap propagated via IChat; the worm penetrated the victim machine, and infected system applications (like a classic virus) while continuing to spread. Leap clearly demonstrated that OS X could be infected.
A mere two days after Leap was detected, antivirus companies received a new sample of OS X malware, another worm which was christened Inqtana. In contrast to Leap, this worm did not infect files; however, the infection vector used by Inqtana was one which had previously been used only by mobile malware. Inqtana propagated via Bluetooth, just like Cabir, probably the best know worm for mobile phones. This is a very interesting example of symbiosis, when technologies for data transmission, developed for mobile devices, are then used to infect standard computers.
Inqtana uses a vulnerability in the Bluetooth File and Object Exchange service (CAN-2005-1333) in OS X v10.4.1, Mac OS X Server v.10.4.1, Mac OS X v10.3.9 and Mac OS X Server v10.3.9. This vulnerability was patched by Apple in June 2005. If the computer under attack accepts a file, the worm attempts to access files and folders which are not in the Bluetooth File and Object Exchange directory. As a consequence, it installs itself to the system and automatically launches constant scanning for new Bluetooth devices.
After a few days, the author of Inqtana was identified – one Kevin Finisterre, an active member of the OSX community. In an interview given to some publications (for example, http://www.securityfocus.com/columnists/389) he explained that he had created Inqtana in order to attract attention to security issues (both the attention of the user community and also of developers) in order to motivate the creation of new, more secure solutions.
From our point of view, such methods cannot be justified. As a rule, they result not in problems being fixed, but in virus writers effectively being offered ready made malicious code. Such independent research also makes the life of hackers easier. The most worrying thing is that such ‘research’ is becoming more and more common; the first quarter of 2006 included several other cases in which potential virus technology was created and published, allegedly in the interests of research. Further information on this is included below.
Tomorrow’s malware: vmware rootkits, boot rootkits, bios backdoors
The most interesting event in the area of ‘theoretical computer virology’ were was the creation of three Proof of Concept programs, developed purely for research purposes. However, the technologies used potentially pose a severe threat; the computer underground is undoubtedly considering how to use them in the future.
The first of these was a prototype rootkit, located in the boot sector, which gains control prior to the operating system starting. Because it is loaded in this way, it is able to modify many of the OS system functions. This backdoor was first made public by eEye Digital Security in August 2005.
In spite of the fact that almost all contemporary antivirus solutions are able to scan the boot sector of disks (after all, the history of viruses and antivirus solutions began with boot sector viruses all those years ago), it is still extremely difficult to detect the interception or substitution of system functions. This problem has still not been solved even in such a case as a Trojan and an antivirus within one operating system, never mind in the case of a backdoor which starts before the operating system does.
There was a lot of interest in this creation, and it was soon followed by similar programs. In January 2006, John Hesman, an employee with Next-Generation Security Software, announced that Advanced Configuration and Power Interface functions made it possible to create programs with rootkit functionality which could be saved in BIOS memory.
Viruses which write themselves to BIOS are nothing new. In 1998, the notorious CIH (Chernobyl) virus wiped the BIOS if it wasn’t able to access it. Then Trojan programs which conducted similar attacks came into being. Hesman created PoC code which made it possible to escalate system privileges and read data from the victim machine’s memory.
When malicious code is saved to BIOS, this code is more difficult to detect than a boot backdoor.
In March, there was a certain amount of fuss made about the concept of an undetectable rootkit, which used virtual machine technology. The burning question: what was the discussion all about, and was there really any cause for concern?
The project, that of a rootkit working at a level lower than that of the operating system, was created by the University of Michigan and sponsored by Microsoft. The details became public after the publication of the IEE Symposium on Security and Privacy conference proceedings were published; they included proof of concept code.
All malicious code operates within the same environment as that of antivirus solutions; this means that the two are effectively equal. Whoever operates at a lower level within the system has the advantage. The idea of the Michigan research was to take malicious code beyond this matrix, making it invisible from within.
To do this, an additional layer, a Virtual Machine Monitor, was created between the operating system and the hardware. At the boot stage, control passes not from BIOS to the loading of the user’s operating system, but rather to the VMM, which then loads whatever operating system is installed. In other words, all interaction between the user applications and the hardware takes place via VMM.
In addition to the user operating system, the VMM loads another operating system, exactly the same as that loaded by which virtual machines in VMWare load. Malicious programs can be launched within this operating system. Both operating systems have the same foundation, the VMM, which has direct contact with the hardware.
A practical example of the use of such a rootkit: the VMM, when data is entered via the keyboard, passes this information both to the user operating system, and to the ‘malicious’ operating system, where it will be intercepted and sent to the remote malicious user, bypassing both the user operating system and whatever antivirus solution may be installed. Both the code of the rootkit, and all traces of its presence in the system, are located beyond the bounds of the user operating system, and can therefore not be detected from within the operating system, no matter how powerful or effective the antivirus or firewall software is.
To create their PoC rootkit for Windows XP, the researchers used the source code of Virtual PC, a guest malicious operating system, and modified some of the drivers of the user operating system.
In spite of the seeming threat caused by the PoC rootikit, we don’t see much cause for alarm. Firstly, writing such a rootkit is difficult, and beyond the skills of the vast majority of virus writers, in spite of the fact that it uses a ready made VMM engine.
Secondly, the presence of an additional layer between the hardware and the operating system cannot be hidden. This additional layer will inevitably have an effect on the victim machine:
- it will slow the boot sequence
- it changes the timing of the processor and slows system functioning
- it changes the size of available disk space (the virtual machine rootkit created by the researchers required 100 – 200MB)
- working with graphics files becomes more difficult, due to crude emulation of the video driver.
- system files needed by the operating system to function correctly with the emulated (not the real) hardware are modified
Thirdly, it’s relatively easy to detect a virtual rootkit. In addition to checking for the signs above, the simplest way to detect such malicious code is to boot the computer from an external device and scan the hard disk from the device. And if the virtual machine rootkit emulates a reboot, which researchers say happened in their tests, with the rootkit taking control and hiding itself – in order to get around this, the user only has to pull the plug from the socket.
However, SubVirt, when taken together with eEye’s BootRoot, signal the dawn of an era when users will need hardware protection.
Along with proof of concept developments, which could have a decisive influence on virus threats in the coming years, we are constantly encountering reincarnations of old technologies which have been improved and adapted for new circumstances. This is most noticeable in classic file infectors, the oldest behaviour of all; these malicious programs have now been modified to insert their code into other programs.
In 2004, Backdoor.Win32.PoeBot was detected. This malicious program works in the following way: the malicious user configures a well known backdoor, in this case Backdoor.Win32.SdBot, takes a common program such as WinRar, and using EPO technology injects a Trojan into it. This program will then be spread in the same way as Trojan programs. As a result, antivirus companies either react more slowly to the new threat, as they have to locate the malicious program, and exclude possible false positives for the bearer program (in this case WinRar), or users will encounter numerous false positives where the legal program is detected as being malicious – this has already happened to a great number of antivirus companies.
In 2005, Virus.Win32.Bube appeared. This family of virus Trojans infects EXPLORER.EXE, and then attempt to download other Trojan programs several times an hour. Bube effectively transforms EXPLORER.EXE into a Trojan-Downloader.
Following Bube, Virus.Win32.Nsag, appeared, an even stealthier Downloader. The virus infects the WININET.DLL system library, injecting its malicious code into the HttpSendRequestA function. In this way, the Trojan gains control over any network activity on the victim machine.
The start of 2006 brought several similar Trojan programs, which indicates that the computer underground believe that such programs can be highly profitable.
Firstly, we should take a look at Trojan-Spy.Win32.Banker.alr. This Trojan is designed to steal information from the victim machine; it also modifies sfc.dll and sfc_os.dll in such a way that it is impossible to restore system files. Such Trojans are detected on a regular basis, and Kaspersky Lab analysts therefore decided to classify new variants as a separate family.
Trojan.Win32.Patched.a
Trojan.Win32.Patched.a infects svchost.exe by adding code which will load a file named mshost.dll (Trojan-Spy.Win32.Agent.ki) and then launch it for execution.
Trojan.Win32.Patched.b
Trojan.Win32.Patched.b infects a system file which has been chosen at random by adding code, which then launches the Trojan from an NTFS stream text file. The name of the text file is usually the same as that of the infected program. For instance, if the Trojan has infected the sysformat.exe file, the main Trojan component will be launched from the sysformat.txt stream. (C:WINDOWSsystem32sysformat.txt:tamrofsys.exe)
Trojan.Win32.Patched.c
Trojan.Win32.Patched.c infects a system file chosen at random, for example notepad.exe. It adds a very small piece of code to this file, which means that when notepad.exe is launched, so is the .log file from the Windows system directory.
Why do these Trojans work in this way, and what will the future bring?
It’s no secret that antivirus and firewall programs monitor certain branches of the system registry and network activity. However, all security solutions have a list of exceptions in order not to interrupt the user when he changes the system’s configuration in some way. The events of 2005 and 2006 have clearly shown that virus writers are becoming ever more inventive in using non-standard methods to evade and trick security software. Such methods include launching the Trojan not by using the system registry Run key, but via the launch of the infected system file, and downloading the Trojan program from explorer.exe or wininet.dll.
Apart from the fact that it’s relatively difficult to detect such actions, antivirus companies also need additional time to create procedures for detecting and curing infected system libraries.
The near future may well bring a range of malicious programs created on the principle “If changes to the configuration of the operating system modules are monitored, then we will modify the modules themselves”. This is an approach which has long since been used by virus writers in creating rootkits for UNIX.
Malware still calling…
The problem of mobile malware is intensifying by the day. In 2005 there was a steady trickle of Trojans designed to infect mobile devices running Symbian; by the end of the year, the trickle had transformed into a stream. Currently, Kaspersky Lab virus analysts add up to 10 new Trojans for smartphones to the antivirus databases every week. A significant number of these are Trojans written in Asian, specifically South Korea. This country is effectively the leader in producing viruses for mobile phones.
Mobile technologies are continuing to evolve, and, naturally enough, malicious code is also evolving at a considerable rate.
February brought 2 totally new malicious programs. The first of these was discovered by Kaspersky Lab, when a user contacted the company with information that a large number of sites for mobile phone users were spreading a program named RedBrowser. According to the program’s authors, RedBrowser made it possible for a user to access wap sites without an Internet connection. This could be achieved by sending and receiving SMSs which would contain the site’s code.
All the user needed to do was to download the program to his/ her mobile phone. Once done, it was clear that the program did indeed send SMSs. However, this didn’t enable the user to connect to the Internet – the messages were sent to premium rate numbers at a cost of $5-6 per SMS.
Analysis showed the Trojan to be a JAR file created for J2ME, an operating system used by the majority (not just smartphones) of modern handsets. Until recently, it seemed impossible that a program could be created that would infect most handsets; however, RedBrowser changed this. It had clearly been in the wild for some time, and had claimed victims. The Trojan was named Trojan-SMS.J2ME.RedBrowser.a, and shortly after the first variant appeared, a second variant was detected.
The appearance of a malicious program for J2ME is on a level with the appearance of the first worm for smartphones in 2004. It’s still difficult to gauge the exact impact of the potential threat; however, the fact that standard handsets can be infected means that antivirus companies will have to start working on antivirus solutions for these devices. There is also the possibility that similar Trojans, which send SMSs to premium rate numbers, will appear for Symbian smartphones.
The number of smartphones and PDAs using Windows Mobile is continuing to grow. Until recently, we knew of only two malicious programs for Windows Mobile/ Pocket PC – Duts, a virus, and Brador, a backdoor. However, the ranks swelled in February 2006.
The whole story started when an organization called MARA (Mobile Antivirus Researchers Association) issued a press release announcing that a virus had been received from an anonymous author. This proof of concept code was allegedly able to infect both PCs running Windows and handsets running Windows Mobile. The press release received a great deal of attention both from the mass media and the antivirus industry due to the fact that viruses for Windows Mobile are rare, and that the malicious program was a fully functional cross platform virus.
Naturally enough, both the media and antivirus companies contacted MARA requesting a sample for analysis, so that detection for the virus could be added to antivirus databases. However, all requests were met with the same response: it would be necessary to join MARA, as the organization’s rule prohibited exchanging samples with non-members.
This was an unexpected moved. From the moment of its birth, the antivirus industry has had certain rules, which include the regular exchange of samples with other companies. This is done without a company having to be a member of another organization. And when the virus under discussion is a proof of concept virus, companies share samples as quickly as possible to ensure that the maximum number of users are protected, regardless of which antivirus solution they favour. This co-operation is standard; antivirus companies compete against each other only in terms of marketing and services.
Not surprisingly, antivirus companies refused to join this little known organization – why give such a group publicity and credibility for the sake of a single virus? There were also doubts about some of the members of the organization; it seemed to have approximately 10 members, most of who were unknown to the antivirus industry, and there was no way to contact them. The best known member of the organization was Dr. Cyrus Peikari, the author of books on security and the general director of AirScanner, a small company which develops antivirus solutions for mobile phones. Peikari became known when he published the source code of WinCE.Duts, accompanied by an analytical article, which essentially acted as a guide to writing viruses for Windows Mobile. The most disturbing fact was that the article had been co-authored by Ratter, a member of the 29A group of virus writers. It had been Ratter that coded Duts, and who gave the virus source code to Peikari.
The antivirus industry took a dim view of the fact that Peikari had been working with virus writers, and his reputation and the reputation of AirScanner itself was blotted.
Questions about the crossplatform virus, named Crossover by MARA continued to arise. It was unclear why antivirus companies should have to join MARA in order to receive a sample, and disturbing that Peikari was working in conjunction with a known virus writers. It was also unclear why the virus had been sent to a MARA member (who was not named) rather than to an antivirus company, which is what normally happens with proof of concept viruses.
The antivirus industry decided to stop communicating with MARA. On 8th March 2006, Cyrus Peikari published a detailed analysis of Crossover, including code. This essentially amounted to another tutorial in writing viruses for Windows Mobile. No co-author was cited, and at the same time, the member list was removed from the MARA site.
Eventually, antivirus companies managed to get their hands on a sample of the virus, and it was named Cxover.
When launched, the virus scans the operating system and if it is launched on a PC, it uses ActiveSync to search for mobile devices. The virus then copies itself to accessible devices via ActiveSync. Once the virus has penetrated the telephone or PDA, it attempts to copy itself back to the PC. It is also able to delete user files from the mobile device.
Cxover shows that it is possible to create a virus which will function both on personal computers and mobile devices. The source code has been published. What will happen now remains to be seen. But one thing is clear – such viruses are no longer a matter of theory. Welcome to the future.
From the same authors
In the same category
Malware Evolution: January – March 2006