The codebreaker menace

By on

It’s an axiom of software development that every program will contain between five and 50 bugs per 1,000 lines of code. And five is reckoned to be only the most optimistic result; the reality is much closer to 50.

Consider then the potential for bugs in a program the size of Windows XP, with a core installation involving 40,000,000 lines of code (loc). Taking the most conservative figure of five bugs per 1,000 loc, the sum reveals that Windows XP, the world's most widely-deployed PC operating system, may statistically include as many as 200,000 bugs.

Of those, around ten percent will be bugs in security components of the OS, of which around one percent (at absolute base level of expectation) will represent exploitable security weaknesses. A further quick calculation then reveals that, at even the most optimistic assessment, an operating system as large as Windows XP may contain at least 200 remotely exploitable security bugs.

Why should we worry?

The most serious current concern in the email security landscape is the rise of the 'robot-net', or 'botnet' for short. This is a technique whereby trojans are secretly planted on the PCs of unsuspecting users and remain dormant until required for action by the remote controller.

These compromised computers are then assembled into global botnets that can number many thousands of infected PCs. The pay-off for the botnet controller is that such networks can be hired out for illicit use by spammers who wish to conceal their identities or criminal gangs for the purpose of identity theft, fraud, money laundering, extortion and other nefarious activities.

In terms of defence, on one hand antivirus technology is systematically adding detection measures to counter the malicious software that tries to exploit the loopholes by which PC systems can be infiltrated remotely; on the other, the software manufacturers regularly release patches to cover the loopholes in their software. As a result, the virus writers have had to seek ever-more resourceful ways of gaining access to innocent computer users' machines.

That is why exploitable vulnerabilities in standard operating systems have become such a threatening focus of attention for the criminals who perpetrate this menace.

Preparing the way in for trojans

Once the virus author has identified an exploitable route into his target system, it is a relatively simple task to install the malicious software on the end-user machine. By using existing spamming techniques, usually, but not necessarily involving social engineering, the email message will encourage the recipient to open an attachment which may look innocent enough -- but with dire consequences. And in many cases, if the exploitable route into the target system has already been identified, there may be no need for the end user to open the attachment at all.

For example, by opening or letting your email client display something as simple as a jpeg attachment, you could be inviting a secret payload on to your system into the bargain. While you view the image, the trojan is automatically downloaded by exploiting a buffer overflow weakness in the Windows operating system, giving the perpetrator a range of possible ways to control your machine for illegal purposes in the future. And you won't suspect a thing.

So why not just fix the bugs?

The short answer is that it's an expensive and lengthy business. Commercial software systems are written in order to generate profit, so successful development always faces a conflict of interest between getting the job done quickly and the quality of the end result. Moreover, there is a second level of incompatibility: flexibility versus security. Simply, the more flexible the software, the more security will be compromised.

The virus writer, on the other hand, has no such commercial constraints. He has the luxury of time to probe systems and seek out the exploitable bugs. And if he doesn't get it right first time, he can just keep trying, knowing that the rewards are potentially substantial enough to warrant the effort.

The power of the small

With time on his side, the virus author can also refine his work to create trojans that are exceptionally small and efficient. For example, the calculator facility in Windows is about as simple as commercial software gets, running to around 112kb or 11,000 lines of code. The arithmetic set out above implies that calc.exe has around 50 bugs (not all of which will be exploitable).

Compare that with the Sober.K virus that proliferated recently. At 50kb, it was only half the size of calc.exe, yet it had the functionality to open ports and destroy conventional antivirus defences. But Sober.K was huge in comparison with another prevalent trojan -- which appeared in so many variants that it never even acquired a recognisable name (some companies call it Trojan.Small) -- which was just 2kb in size and can be highly destructive.

The virus writer can also download conventional antivirus software from the Internet in order to probe its weaknesses by reverse engineering. For this reason, there is a clear advantage to adopting a security solution or service whereby the software is never available publicly.

'Bad unless proven to be good'

Owing to the dynamics of new vulnerabilities emerging in the market, it's difficult for conventional AV vendors to keep track of them all and to develop effective detection. However, it is possible to adopt a 'bad unless proven to be good' approach to malware detection.

Take, as an example, the vulnerability of jpegs. It is possible to parse every jpeg file, not only scanning for a particular vulnerability, but also ensuring that the file is valid in its structure i.e. conforming to 'standards'.

I've deliberately put 'standards' in quotes because, although there's a published standard for the structure of a jpeg file, it's amazing how many jpegs do not conform to the standard, but remain valid. So 'standards' in this context means the statistical representation of what constructs may be part of a valid, good jpeg file.

If there are anomalies in the structure of a file, it could potentially indicate a new vulnerability that no one in the AV community is yet aware of. Of course, this approach is very resource-hungry, so it's only possible for larger, more powerful processing units. For that reason, conventional AV solutions are forced to adopt a 'good unless proven to be bad' approach, owing to resource limitations.

Bigger phish to fry

A recent phishing attack, purporting to be a communication from a major UK bank to its customers, provides a significant pointer to likely future developments in the email banditry arena.

It works like this: customers receive an email that makes the usual phishing bid to gain personal banking details -- but it also has a more purposeful payload. Before attempting the phish, it first uses an IFRAME exploit to download a trojan installer without the user's knowledge.

The installer checks a number of parameters on the system -- for example, the versions of Windows and Internet Explorer being used, whether Norton AV updater or McAfee AV updater are running and what version of Java Virtual Machine is in use. Based on the information it collects, the installer chooses one of the four different exploits to perform the trojan executable drop.

The innovation here is that, not only are different exploits and vulnerabilities used to penetrate the user's computer, but also that a trojan installer is an integral component of the phishing attempt.

If this new technique proves as successful as its criminal perpetrators surely hope, we can expect to see even greater uses of such convergence in the future. With the prospect of spam messages arriving in your inbox trying to sell you a product while attempting also to obtain your personal banking information -- and planting a trojan on your computer at the same time -- the case for adopting comprehensive email security has surely never been more pressing.

The author is antivirus technical architect at MessageLabs

Copyright © SC Magazine, US edition

Most Read Articles

Log In

|  Forgot your password?