Malware evolution: January – March 2008

Our annual report on malware evolution in 2007, published a few months ago, contained forecasts on how the threat landscape would evolve in 2008. Now that the first three months of the year have passed, we can start to draw some preliminary conclusions.

Unfortunately, as often happens in the antivirus industry, the conclusions are fairly discouraging. The speed at which the number of malicious programs is rising continues to increase, with thousands of new variants being detected every day. This is starting to be accompanied by increased technical sophistication, and we are also seeing a shift in attack vectors, with malicious users starting to direct their attention to less well protected fields, such as Web 2.0 technologies and mobile devices.

We continue to see the reincarnation of old ideas and techniques, and the implementation of these at new levels enhances the level of threat. Examples are infecting boot sectors on victim machines; spreading malicious programs via storage media, and infecting files.

It looks as though the first quarter of 2008 brought the symbolic, but irrevocable death of the old school of virus writing. At the end of February, the site of the legendary 29A group officially announced that the group would cease to exist.

The people who had created “Cap” (the first macro virus to cause a global epidemic), “Stream” (the first virus for additional NTFS streams), “Donut” (the first virus for the .NET platform), “Rugrat” (the first virus for the Win64 platform), the mobile viruses Cabir and Duts and many others, have now retreated, under pressure from the increased criminalization of the world of virus writers. No one creates malicious programs to express themselves, assert their personality or for research purposes anymore – it’s far more profitable to generate hundreds of primitive Trojan programs and then sell them.

The death of 29A was commented on by nearly all the major antivirus companies: each company threw a virtual clod of earth on the grave of the group which in its time created many difficulties for virus analysts. So it’s fitting that we should also mention the event.

As for what came to replace the ‘romantic’ ideal of virus writing in 2008, this is discussed in the following chapters:

1. Bootkit
2. The storm continues
3. TrojanGet
4. Some sociable worms
5. Mobile news

Bootkit

Bootkit rootkits – rootkits with the ability to boot from the boot sector of any device – became, de facto, the main problem for the antivirus industry at the start of 2008. Although the efforts made to combat this problem, and the seriousness of the issue may not have been obvious to the public at large, it may be that the subject will come to cause problems for everyone in the near future.

The story begins

It all started in November 2007, or perhaps, more correctly, in 2005. However, this isn’t totally correct either. Let’s take a quick trip into the past and recall what took place 22 years ago, in 1986.

This is how the events of that year are described in the Virus Encyclopaedia on viruslist.com (http://www.viruslist.com/en/viruses/encyclopedia?chapter=153311030):

So this was the start of the story. For more than 10 years, boot viruses were one of the most widespread type of malicious programs.

The principle on which these viruses work is relatively simple: they use algorithms which launch the operating system when the computer is switched on or rebooted. The system boot program reads the first physical sector of the boot disk (A:, C:, or the CD-ROM drive, depending on BIOS Setup parameters) and pass control to it. If there is a virus on the boot sector, the virus will gain control.

There’s only one method known which is used to infect floppies: the virus replaces the original boot sector code on the disk with its own code. The hard drive can be infected in three different ways – the virus either replaces the MBR code with its own code; replaces the boot sector code on the boot disk (usually C:) with its own code, or modifies the address of the active boot sector in the Disk Partition Table located on the hard drive MBR.

In the majority of cases, when infecting the disk the virus moves the original boot sector (or the MBR) to another disk sector (for instance, to the first free sector).

Developers started adding protection to prevent the MBR from being written to. Windows 95/98 appeared, floppies started to disappear from use, and after almost a decade, boot sector viruses faded from the landscape, becoming part of the history of virology.

However, at Black Hat USA in 2005, Derek Soeder and Ryan Permeh, two researchers from eEye Digital Security, presented BootRoot. This technology made it possible to place code on the boot sector of the disk – code that would intercept the booting of the Windows kernel and launch a backdoor, making it possible to remotely administer the machine via the local network.

This work attracted a certain amount of attention, and it was soon emulated. In January 2006, John Hesman from Next-Generation Security Software announced that functions for managing the electricity supply of the computer (the so-called ACPI – Advanced Configuration and Power Interface) make it possible to create programs which implement rootkit functions that can be saved to the BIOS flash memory. Malicious code saved in this location (BIOS) is more difficult to detect than in the case of the boot backdoor. Hesman also created prototype code which makes it possible to increase system privileges and read data from the computer memory.

A year later, at the end of 2007, two Indian programmers called Nitin and Vipin Kumar presented Vbootkit – a rootkit with a function making it capable of launching from the boot sector of any device. The program can also run on Windows Vista. The source code was not made public, but was passed to some antivirus companies.

The main principle behind Vbootkit is shown below:

The authors promised to implement BIOS infection in the next version of the bootkit.

In other words, what came to pass was no surprise – old technology for infecting the boot sector was combined with the fashion for rootkits. In spite of the fact that nearly all antivirus companies today are able to scan the boot sector of disks, it’s still difficult to detect if system functions have been intercepted or substituted. And this is true even in the case of a Trojan and an antivirus running on one operating system, without even addressing a backdoor which starts before the operating system has launched.

All of the above seems like a potentially explosive mixture that could go up at any moment. And the explosion came in November 2007, although news of this came slightly later, at the end of December, when several thousand users (there is no exact data on the number of infections) came under attack from the first malicious implementation of a bootkit.

The bootkit

Between the 19th and the 28th December several websites appeared which used drive-by downloads (infecting a victim machine by placing exploits on a web site which then download a malicious program). A detailed analysis of the malicious program revealed code able to infect the MBR and hard disk sectors.

Once on the victim machine, the malicious code modifies the MBR, writes the rootkit part to a disk sector, extracts a Windows backdoor from itself, installs the backdoor, and then deletes itself.

When infecting the MBR, instructions pass control to the main part of the rootkit which is placed on several hard disk sectors and which is not represented as files in the system. This part monitors the already loaded Windows operating system and when reading, it hides the infected MBR and the “dirty” sectors by presenting clean ones instead. It does this by intercepting and substituting system functions.

In addition to hiding its presence in the system, the malicious code installs a backdoor in Windows; the backdoor will steal user data, including user data to a range of online banking systems.

A reconstruction of events based on the variants of the rootkits detected, analysis of the infected sites and the code of the malicious program downloaded from these sites showed that from November 2007, the unknown authors had been preparing to launch their code on the world. Several of the first variants of this malicious program stem from mid-November to mid-December; these are effectively alpha versions which contain serious errors in the code, and indicate that the authors were searching for optimal variants.

The code released at the end of December was already relatively effective. We classified the malicious program, which combined the functions of a bootkit and a backdoor, as Backdoor.Win32.Sinowal. This was because many of the functions in the backdoor, and also the method used to ‘litter’ code were identical to those which we are familiar with in Trojan-PSW.Win32.Sinowal.

In spite of increased sophistication and the many innovations implemented in the bootkit, it’s only able to protect itself – this leaves the backdoor file open to being detected and deleted. This indicates that different people were involved in developing the bootkit and the backdoor, and there are a number of reasons to suggest that the bootkit was created by virus writers from Russia. There are well known cases in which virus writers have worked together. However, the result in this case suggests a warrior who has been hastily dressed in another’s reforged armour which is, effectively, useless.

Nevertheless, the bootkit appears to be a self-sufficient platform – something that could be added to any existing malicious program in order to protect that program and mask its presence in the system. It may be that bootkits for sale will appear in the near future, making the technology available to thousands of script kiddies. Taking into account the rate at which the number of malicious programs is increasing, this could become one of the most widespread threats.

Protecting against bootkits: the problems

Why is it so difficult to protect against bootkits? The main problems are as follows:

1. The malicious code gains control before the operating system starts, and, consequently, before the antivirus program starts
2. It’s difficult to detect the interception of functions from within an infected operating system
3. Restoring intercepted functions can lead to the entire operating system crashing
4. Curing the MBR is only possible if the original MBR can be detected

Of course, the best protection is to prevent the system from getting infected in the first place – after all, a bootkit doesn’t materialize out of thin air. It has to get onto the computer somehow. Some antivirus programs are able to prevent infection even by unknown variants of malicious programs. However, there is always the possibility that such protection can be penetrated, and this raises the question of how to disinfect an already infected machine.

Here there are two options – either an antivirus is already installed on the system (in such cases, the four points mentioned above relate to the antivirus solution) or there is no antivirus, and one needs to be installed. In the second case, we encounter an additional problem related to that in point 1; the malicious code can block attempts to install an antivirus solution on the infected system.

Virus writers have analysed how antivirus companies solve the problems listed above, and in February 2008, a new improved version of the bootkit was released. All the methods previously implemented to combat bootkits turned out to be useless.

At the same time, the bootkit started spreading in new ways. Links to sites containing exploits which would install the bootkit were discovered on a number of European sites which had been hacked.

So far, apart from Sinowal, we haven’t detected any other malicious programs which come equipped with a bootkit. At the moment, the standoff between antivirus companies and virus writers is following the classic path of attack and counter-attack. Even the latest variants of the bootkit can be combated without significant innovations in antivirus solutions.

However, looking a couple of steps down the line it’s clear that sooner or later that only one method will guarantee that such malicious programs can be detected and deleted. This will entail a shift from software protection to hardware protection.

The key question is what gains control first – if it’s the virus, then an antivirus will, a priori, be useless.

So, viruses have (again) reached the MBR. 10 years ago we solved this problem by using a boot disk equipped with an antivirus. It may be that the time is coming when we’ll see the return of not just old virus technologies, but old antivirus technologies as well.

The storm continues

Mid January 2008 marked the first anniversary of the appearance of the first samples of what would become known, variously, as Zhelatin, Nuwar or the Storm Worm. Until then, computer virology had not encountered such a vigorously and variedly evolving malicious program.

Zhelatin continued to use and develope the concepts which had been implemented in the Bagle and Warezov worms. Zhelatin took its modular structure from Bagle, and copied Warezov in the frequent release of new variants. It also resembled Warezov in moving away from mass-mailing the main component via email, instead using hundreds of infected sites as well as Skype and IM to spread the malicious code. Added to all of this were social engineering tricks, rootkit technologies, methods for launching counter attacks on antivirus companies, and a decentralized botnet. In less than a year, the Storm Worm became the information security industry’s main problem, due to its almost mythical botnet.

The exact dimensions of the Storm botnet remain a mystery. In 2007 we heard a widely varying range of estimates of the number of infected machines, and these estimates were all voiced around the same time. For instance, in September some experts estimated that the botnet had 2 million machines; others put the figure at between 250,000 and a million, while a third group believed the size to be 150,000 machines. There were even those who talked of 50 million infected computers! The reason for such a wide variety of figures is clear – because of the decentralized nature of the botnet, it’s impossible to establish the exact number of zombie machines. Estimates can only be made based on indirect indicators, which are of course debateable.

Whichever way you look at it, the Storm botnet did exist. However, it was inactive. There was no ‘classic’ botnet activity detected; it wasn’t used for mass mailings, or to conduct DDoS attacks (which, incidentally, doesn’t rule out the botnet having been created by cybercriminal for criminal use). This left the impression that the botnet didn’t perform any function apart from spreading the Storm worm itself (it did this by sending new messages containing links to infected sites and then placing modules on the infected machines which would then be downloaded onto new victim machines). It really wasn’t clear why the botnet had been created: simply for the sake of it? But that doesn’t happen – botnets take far too many resources to create and maintain.

Around October 2007, the frequency of mass mailings conducted by Zhelatin started to decline somewhat. Experts who had previously talked about millions of infected machines started to drop their estimates of the size of the botnet to between 150,000 and 200,000 computers. The suspicious emerged that the botnet was being prepared to be sold on in sections. Around the same time, the first mass mailings of spam from computers infected with the Storm Worm were detected. However, it couldn’t be stated conclusively that spam was being sent via the botnet, rather than via other malicious programs which might also be located on the victim machines.

The end of 2007 and the early months of 2008 provided an answer to the question of what was happening with the Storm Worm.

At Christmas, the worm reappeared. The botnet started sending out millions of messages with titles such as “Find Some Christmas Tail”, “Warm up this Christmas” and “Mrs. Clause Is Out Tonight!”. The messages were designed to entice the user to a site called merrychristmasdude.com, which contained exploits that would conduct a drive-by download to get the Storm Worm onto victim machines. In actual fact, merrychristmasdude.com wasn’t a single site which could have been closed down in order to prevent infection. Zhelatin used fast-flux, a technique for changing DNS addresses which constantly modifies the location of the site between more than a thousand deliberately prepared computers.

Similar attacks, with only slight variations, carried on over the next few days, up until 15th January, when something strange happened. Either it was a joke on the part of the authors, or they simply made a mistake; whatever the case, the botnet started sending out messages containing Valentine’s cards, even though Valentine’s Day was still a month off.

The messages had titles such as “Sent with Love”, “Our Love is Strong”, “Your Love Has Opened” and so on. Naturally, the messages led the user to the fast-flux site currently being used.

The mass mailings in January turned out to be on a larger scale and also more intrusive than those which were conducted in the second half of 2007. They were also the largest mass mailings carried out in the first quarter of 2008. The authors of Zhelatin had struck a series of blows to either return the botnet to its original size or perhaps even to enlarge it. Computers infected by Zhelatin started to participate in DoS attacks, and MessageLabs started estimating that the Storm botnet was behind almost 20% of spam currently being sent out.

At approximately the same time Fortinet announced it believed the botnet was part of phishing attacks launched against the Barclays and Halifax banks. If this is the case, then it is the first time the Storm botnet has been directly used for classic cybercrime aims.

At the same time as the Storm Worm increased its activity, talk turned to the need to catch and sentence its authors. However, experts couldn’t agree on even the nationality of those behind the worm, never mind naming names.

At the moment, there are two prevailing points of view. Dmitry Alperovitch from Secure Computing believes that a Russian is responsible, even going so far as to point to a location in St. Petersburg. He draws parallels with the notorious Russian Business Network (RBN) and the authors of the exploit bundle Mpack. Many experts support the view of the worm’s Russian origins.

Others believe that the Storm Worm has been created by Americans. This argument is supported by the fact that the authors, in their use of social engineering tactics, demonstrate a suspiciously good knowledge of American life and psychology. The mass mailings play on specific incidents and events which will be of particular interest to the American public. And these events could well be unknown to virus writers from other countries, and particularly those from Russia.

We do not have any information which supports one point of view or the other. It seems to us that one of the most likely scenarios is that an international group which has clearly defined responsibilities lies behind this activity. Someone creates the worm; someone else is responsible for mass mailings; someone else places the worm on the infected sites; someone else hacks the sites; someone else is responsible for spreading the malicious program via instant messaging, and finally, yet another person is responsible for creating the exploits.

The widespread nature of the Storm Worm and the attack vectors which are being used are far too extensive to be within the capabilities of one, two or three people. If our suppositions are correct, then the Storm Worm is a text book example of modern cybercrime and its international distribution of labour. It is of course true that it is still unclear how the cybercriminals are making money using the Storm Worm.

While we were still looking for the answers to the questions raised by the Storm Worm, at the end of March its authors sent out the latest flood of messages. The occasion – April 1st, known throughout the US, Europe and Russia as April Fool’s Day.

The question remains: who will have the last laugh?

TrojanGet

Although incidents in which legitimate programs and software companies spread infection are relatively rare, they do exist in the information security world. Past cases have ranged from infected distributions to infected document files being sent to clients and partners.

Every incident of this nature has a significant effect on the reputation either of the software or of the company concerned. They affect users who do observe the basic rules of computer security and cause problems for antivirus companies who view legitimate software and the sources it stems from as trustworthy.

The first quarter of 2008 brought the latest case of this type.

At the beginning of March, Kaspersky Lab analysts received messages from users saying that a Trojan was present in the directory of the popular download client FlashGet. Analysis showed that the problem affected users throughout the world. The symptoms of infection were the appearance of files called inapp4.exe, inapp5.exe and inapp6.exe in the system. Kaspersky Anti-Virus detected these files as Trojan-Dropper.Win32.Agent.exo, Trojan-Dropper.Win32.Agent.ezo and Trojan-Downloader.Win32.Agent.kht.

It was a strange situation: no other Trojan program which could have got this Trojan onto the system was detected. Some of the victims had fully patched operating systems and browsers. So how could these malicious programs have penetrated the infected machines?

What attracted our attention straight away was the location of the Trojans – in the FlashGet directory itself. A quick check showed that apart from the presence of the Trojan files, the FGUpdate3.ini file had recently been created and modified (the blue text shows the differences from the original file):

The link to inapp4.exe (the Trojan file) led to the genuine FlashGet site: the Trojan would download from the site in the form of a file called appA.cab.

There wasn’t any information about the incident on the FlashGet site, and a look at the user’s forum returned a lot of messages about both about infections, and the fact that the developers were remaining silent on this matter.

Information found on the Internet showed that the first cases of infection had been detected back on 29th February. The most recent infection that we knew of at that time had been on 9th March. For ten days, a legitimate program had been acting as a Trojan downloader program, installing and launching Trojan programs placed on the developers’ site on victim machines.

It might have seemed that the incident was over – when we published information about this case, the Trojans had already been deleted from the site, and the FGUpdate3.ini file (which is also downloaded from the Internet) had been reverted to its original condition. However, in less than two weeks, on 22nd March, Steve Bass, the editor of the popular publication PC World, detected Trojan-Downloader.Win32.Agent.kht in his FlashGet directory. It looked as though history was repeating itself – both the FlashGet site and the program itself were once again spreading malicious code.

We can see two ways in which FlashGet could be transformed into a Trojan downloader program.

The first is the most obvious explanation – the site itself was hacked. As a result, a malicious user would be able to replace the standard configuration file with a file that would lead to the Trojan placed on the site. We don’t know why the hackers didn’t use a different site – it might be that they worked on the principle that hiding in plain view (e.g. a link to the FlashGet file in the configuration file would not raise suspicions) would be the best disguise.

We decided to check if it would be possible to use this trick to download any other files from any other sites. The answer: yes. All you need to do is add a link to the FGUpdate3.ini file. And that link can lead to anything, which will then be automatically downloaded and launched on your computer each time FlashGet is launched. Even if you don’t press “Refresh”, FlashGet will independently use the information from the .ini file.

The ‘vulnerability’ is present in all versions of FlashGet 1.9.xx. This means that even though the hack of the FlashGet site has been fixed, the vulnerability in the user’s system remains. Any Trojan program can modify the local FlashGet .ini file, making it act as a Trojan downloader. And it’s this method which is the second of the two mentioned above.

Is there any need to stress the fact that FlashGet is usually treated as a trusted application, and that any network activity generated by the program is seen as legitimate, as well as contacting any sites?

There has, to date, been no official reaction from the Chinese company which develops FlashGet. The true cause of the incident remains unknown, and there is no guarantee that it will not happen again. You can draw your own conclusions…

Antivirus companies retain the right to decide whether or not FlashGet is potentially malicious, and have started to classify it as Riskware. There are more than enough grounds for doing so.

Some sociable worms

We wrote about the danger caused by social networking sites in our annual report. We forecast that in 2008 users of social networking sites will become the main targets for phishing attacks. There will start to be increased demand among malicious users for account data to services such as Facebook, MySpace, LiveJournal, Blogger and others. This will become a dangerous alternative to placing malicious programs on hacked sites. In 2008, many Trojan programs will spread via user accounts on social networking sites, on their blogs and on their profiles.

February 2008 met these expectations in full. Once again Orkut, the popular social networking site owned by Google, came under attack.

Orkut is extremely popular in a number of countries through the world, and particularly in Brazil and India. According to data provided by Alexa.com, a web information company, 67% of the requests made to Orkut come from Brazil, and more than 15% from India.

For the last few years, Brazil has been seen as one of the most virus-ridden countries in the world. Brazilian virus writers are notorious for the thousands of different Trojans they’ve created to steal user data to bank accounts. Families such as Bancon, Banpaes and Banload are made up almost 100% of Trojans created in South America.

Online banking is very popular in Brazil. Orkut is very popular in Brazil. There are lots of virus writers in Brazil. These three factors combine to result in one thing: the appearance of a worm which spreads via Orkut and steals account data to online banking systems.

Out of all the social networking sites, Orkut has the longest list of malicious programs which target it. In 2006 and 2007 the site suffered from virus epidemics, and between 2005 and 2007, Orkut was the target of hacker attacks, and many vulnerabilities were detected. The most recent publicized incident was the appearance of a script worm in December 2007, when over 700,000 users ended up infected.

A mere two months later, in February 2008, a new epidemic broke out. This time the hackers hadn’t bothered to search for or exploit XSS vulnerabilities on Orkut. The new worm functioned in accordance with relatively simple principles:

1. The user gets a message from one of his/ her contacts. The message contains a pornographic picture in flash movie format.
2. If the user clicks on the image, s/he is redirected to a malicious site.
3. The user is asked if s/he wants to install a flash player application, which is in fact a Trojan program.
4. Once the Trojan has been downloaded and launched, it will download other Trojan components to the victim machine via the Internet.
5. The user account is then used to create new messages as described in point 1.
6. The malicious module tracks the user’s use of Orkut.
7. Other modules harvest data entered via the keyboard when the user contacts Brazilian online banking systems.

It’s impossible to establish the exact number of victims, but our colleagues from Symantec estimate a minimum of 13,000 affected users.

This incident shows once again how vulnerable users of social networking sites can be. The main factors which make Web 2.0 services popular with users and hackers alike are listed below:

1. The migration of user data from the PC to the Internet
2. The ability to use one account to access a number of different services
3. Detailed information about the user
4. Information about the user’s contacts and friends
5. Space to publish whatever you like
6. Trust between contacts

The problem has already become fairly serious, and stands every chance of becoming a major information security issue. We’ll be releasing a paper dedicated to this topic in the near future.

Mobile News

The world of mobile virology was an eventful place in the first quarter of 2008. It was clear that technologies were continuing to evolve and more and more participants – both virus writers and antivirus companies – got involved.
Innovations in terms of malicious code were split more or less evenly between the four targets of Symbian, Windows Mobile, J2ME and the iPhone
.

Symbian

As far as Symbian goes, this operating system came under attack by the latest worm from a completely new family. Up until this point, we’d see two types of threat: Cabir, which spreads via Bluetooth, and ComWar, which spreads via MMS. Of course, there were several variants of both these worms.

At the end of December, a program was added to our antivirus databases which at first glance seemed to simply be a new ComWar clone: ComWar.y. However, in January the appearance of this program in the traffic of one of the largest mobile operators forced us to take a more detailed look at the new sample.

An analysis conducted by one of our partners, the Finnish company F-Secure, showed that in actual fact this malicious program was representative of a completely new family, which had nothing in common with ComWar, created three years ago in Russia.

The worm, which was classified as Worm.SymbOS.Beselo.a (Beselo.b was detected shortly afterwards) functions in a way very similar to ComWar, and takes an approach typical for worms of this type. It spreads by sending infected SIS files via MMS and Bluetooth. Once the worm is launched on the device under attack, the worm starts to send itself to the contacts on the phone, and also to all accessible Bluetooth devices within range.

What’s the news value in this? It’s the fact that there is a new, active family of worms for mobile devices (which implies the existence of active virus writers) and the presence of this worm in the wild. New variants of Beselo could cause serious local epidemics – this after all is what happened in spring last year, when 115,000 smartphone users fell victim to a Spanish modification of the ComWar worm.

Windows Mobile

The appearance of a new malicious program for Windows Mobile, which hasn’t been a focus of attention for virus writers up until now, is certainly noteworthy. However, InfoJack, a Trojan which was detected at the end of February, is particularly interesting for the following reasons:

InfoJack.a

1. attacks Windows Mobile
2. was detected in the wild
3. is spreading in China
4. steals data

This is the first malicious code targeting Windows Mobile which has been found in the wild and which has caused a significant number of infections. The code spread from a Chinese site which contained a range of types of legitimate software. The Trojan was added to mobile product distributives such as Google Maps and game clients. The owner of the site which the Trojan spread from stated that he did not have any illegal intentions, but was collecting information about the users of the site in order to improve the service and to analyze the market for mobile applications.

Once it is on the system, the Trojan attempts to disable the protection mechanism which prevents the installation of applications which do not include a developer’s digital signature. When the infected smartphone is connected to the Internet, InfoJack starts to send confidential information from the device to the Trojan’s site. This information includes the device serial number, information about the operating system and installed applications. At the same time, the Trojan may download additional files to the phone without the knowledge of the user, and launch these files – it’s able to do this because protection against launching unsigned applications has been disabled.

After a few days the activity of the site was halted, probably in connection with the investigation conducted by the Chinese police.

This report has already covered what happens when virus writers turn their attention to popular services (e.g. the attacks on Orkut in Brazil). China is undoubtedly the world leader in terms of production of malicious code; at the moment, more than 50% of all new malicious programs in our antivirus databases originate in China. Until now, Chinese hackers have targeted online gamers who use personal computers. However, the case of InfoJack shows that there is the capability to organize mass epidemics and create mobile viruses.

China has become the first country to suffer from a Windows Mobile Trojan. It’s possible that the author of InfoJack really didn’t have anything illegal in mind. However, now the foundation has been laid, the thousands of Chinese hackers currently creating viruses for personal computers may choose to build on it.

J2ME

During the first quarter of 2008, Trojans for J2ME (which will run on almost any modern mobile, and not just on smartphones) started appearing with frightening regularity. In January we detected Smarm.b, followed by Smarm.c and Swapi.a, and March brought SMSFree.d

All these Trojans were detected in Russia, and they all use the same method for making money out of users: sending SMS messages to premium numbers. (An investigation into a similar SMS sending Trojan, Viver, which we conducted last year, showed that in three days the author of the Trojan could earn approximately $500). In spite of all these incidents, Russian mobile content providers continue to maintain the anonymity of those who register premium numbers. This effectively makes virus writers immune to prosecution: the appearance of new variants of malicious programs and a lack of information about any arrests clearly demonstrates this.

Apart from the J2ME Trojans mentioned above, there are another two malicious programs which send SMS message for which a charge is made. Flocker.d and Flocker.e, both written in Python and designed to attack smartphones, were detected in January 2008.

These malicious programs use the same propagation method as InfoJack: they spread via popular sites which offer software for mobile phones. The Trojans are either disguised as legitimate utilities, or are integrated into such products.

iPhone

We’ll conclude this section on mobile threats with information about a long awaited event: the release in March of the iPhone SDK.

We had believed that the release of the SDK would lead to the appearance of a multitude of malicious programs for iPhone. However, what the open Apple SDK provides is actually very limited.

Apple has followed Symbian’s lead: the model for creating and distributing programs for the iPhone is based on the idea of ‘signed’ applications. The main restrictions are laid out in the agreement for use for the iPhone SDK:” No interpreted code may be downloaded and used in an application except for code that is interpreted and run by Apple’s published APIs and built in interpreter(s). An application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.”

This restrictions do not only make life more difficult for virus writers, but they also effectively rule out such applications as Firefox, Opera, many games, IM clients and much other useful software: applications which could be extremely popular among iPhone users and which could extend the device’s capability.

In the four days after the SDK was released, it was downloaded more than 100,000 times. It seemed that such a huge number of potential developers should lead to an increase in new applications created using the SDK. However, this is not happening.

Apple has, in a formal sense, fulfilled its promise by making the SDK available. However, it’s not yet clear how this step will influence the development even of legitimate software for the phone. The restrictions are too stringent, and too many functions in the SDK remain closed.

The second major restriction is that applications which have been created using the SDK can only be distributed via Apple’s estore. This creates a large number of additional barriers, ranging from the number of ‘vendors’ (developers) allowed, to geographical restrictions (only those in the USA are allowed to participate).

It’s clear that under these conditions it will be impossible to launch an antivirus product for the iPhone – not for technical reasons, but due to the issues described below.

The continued hacking of the iPhone acts as the backdrop here. It’s estimated that between 45% – 50% of all devices sold have been ‘unlocked’. All of these devices are potentially vulnerable to infection by any malicious program for iPhone, as the user will be downloading files from many different unofficial sources to his/ her device. This can’t be controlled in any way: users of modified phones are not entitled to official technical support, and we’ll be unable to provide them with any antivirus protection.

It’s likely that in the foreseeable future the number of people using such devices will equal the number of Symbian smartphone users in 2004 – the year that Cabir appeared.

Conclusion

The events of the first three months of 2008 show that the period of technical stagnation in the threat landscape is drawing to a close.

Last year, we described conveyor belt code: a process generating multiple primitive copy-cat programs, which do not make implement new virus technologies. The phenomenon can be explained: virus writers chose to use tried and tested methods because at the time, even old well known approaches, were capable of bringing in profits if applied on an industrial scale.

However, now there is a noticeable change in direction, which is shown above all by the appearance of the first malicious implementation of a bootkit. In addition to this, file infection methods are being used more and more frequently, often in conjunction with complex polymorphic techniques. It should also be noted that virus writers are borrowing certain technologies from the antivirus world. For instance, we’ve already detected malicious programs which, in order to combat antivirus solutions by deleting them or blocking their installation contain signature detection for the antivirus file. Previously virus writers confined themselves to having their creations search for such files by name.

Today, old technologies are being re-examined, rethought, and implemented at new levels. The struggle of virus versus antivirus is moving from software towards the hardware level.

Although the events of the first quarter of 2008 cannot yet be seen as creating a definite trend, the issues raised may have a strong influence on the entire information security business in the near future.