Nine Lives - Self-modifying Malware

One of the most interesting historical software releases in programming terms is The Last One (TLO), a Pascal-driven application that was released to critical acclaim in 1991. TLO was coded by David James, who was famous for his expert coding exploits in the late 1980s and early 1990s.

The program was notable in that it allowed its users to enter a program design by selecting from a number of flowcharting options. As each flowchart is selected, the program asks a series of simple questions, in order to better understand what the user wants from that particular element of program code.

Once the entire flowchart has been entered by the user, TLO’s program code checks it for logic and errors, requesting further information from the user as and when required.

Once this process is completed, TLO goes off and writes a program that does what the flowchart specifies. The resultant program – coded in BASIC, a simple programming language – could then be compiled into machine code.

Although simplistic by today’s 32 and 64-bit programming standards, TLO was – and still is – largely unique in being an application that generates relatively unique program code as a direct function of its operation.

As its creator David James said in the early 1990s, TLO does what it claims; it writes programs automatically.

Now here’s the big question – could the self-programming capabilities of TLO be applied to modern-day coding?

The answer, of course, is that within certain parameters, a modern-day TLO could be created, but the program code would be highly complex and cover tens, if not hundreds of millions of lines of source code.

A specialized version of a modern-day TLO – one designed, for example, for the creation of specialized spreadsheet applications – would be a realistic option, but most observers would ask ‘why bother’?

The Re-inventing Worm

Let’s advance this question further – could the self-programming capabilities of TLO be applied to a piece of malware that infects users’ PCs and propagates using a number of self-modifying techniques?

The answer is a resounding yes. To a certain extent, the Conficker worm that has been hitting the headlines in the last nine months or so applies these principles, since each iteration of the worm seems to perform different attack functions.

Detailed analysis of the Conficker worm reveals that the secret to its success is its modular nature, allowing third-party hackers – as well as the original programmer/programming team – to `develop’ extra features as and when required.

According to Alan Bentley, vice president of EMEA for vulnerability analysis security specialist Lumension, the Conficker worm is one of a new generation of worms that can automatically update itself and even adapt to the way it infects users based on different system conditions it encounters.

“Its success, if that is the right word”, says Bentley, “is based on its intelligence in this regard”.

In its first iteration in October 2008, Bentley tells Infosecurity, the Conficker worm was a piece of shellware that exploited a number of issues with the Windows Server environment.

Its uniqueness, he says, is that it allows itself to update by phoning home across the internet, and downloading fresh instructions, then modifying its program code and capabilities accordingly.

“It’s a very powerful worm in this context. Much more powerful than, say, the Blaster worm seen in 2003/2004, which was written by Jeffrey Lee Parson, and was considered quite revolutionary in its day”, he says.

The Conficker worm, he explains, will update itself and then look for network share and other resources through which it can propagate and further infect a given set of IT resources.

Automating the Manual Hacker Process

Over at penetration and networking specialist First Base Technologies, Peter Wood, the firm’s chief of operations and ISACA conference committee member, says that the automation of malware and attacking processes – especially those involving man-in-the-middle types of attack – is something which is now being carried out by hackers.

At the Infosecurity Europe show in April, for example, Wood and his team revealed a serious structural error in the security of secure cookies in regular use on the internet.

Many sites, says Wood, “do not set the secure text flag on their site’s session cookie”. He explains: when web sessions flip between the https and http protocols – as many major e-commerce sites frequently do – this flaw can be exploited by a hacker.

According to Wood, because http sessions have far less of a data and IT resource overhead than https sessions, major sites often only use the latter secure protocol when requiring users to enter personal data such as payment card details on specific pages.

Furthermore, if the hacker uses the cookie to take over an internet session, they can then intercept this personal data.

“Under certain circumstances”, says Wood, “it is even possible for a hacker to seize control of a supposedly secure and authenticated IP session just as the user has entered their payment card data and other personal information”.

The sequence of assuming control of a user’s IP session is highly manual. Nevertheless, Wood tells Infosecurity that it is possible to automate the process to the point where a piece of malware could be coded to conduct the hacking whilst the hacker watches.

“I’m pretty sure this exploit has been used by hackers in the past. It explains a lot about how some sites have been hacked”, he says.

Paul Wood, chief information security analyst with Messagelabs, is also a believer in the automated approach to hackers and their malware.

Citing his firm’s April 2009 Intelligence Report, he explains some of the trends in high-profile malware infections. As it starts to infect, continues its infection of large numbers of internet users, and fades away, you get some interesting results on a month-by-month basis.

Some pieces of malware start to fade away and then, he says, seemingly come back from the dead and start to infect a second wave of users.

If you look at the program code of the malware that exhibits this type of behavior, he says, you start to realize that there is more at work than hackers simply modifying existing malware.

“Some malware types are emerging – like Conficker – that are capable of modifying themselves in the face of changing situations on the internet,” he says.

It’s not yet clear, Paul Wood adds, whether this process is entirely automated, or whether it is being assisted by the actions of the original malware programmers and/or third party hackers.

What is certain, however, he says, is that self-modifying malware is a reality in 2009. It is why some pieces of malware resurface in the Messagelabs charts on a regular basis.

Protection

According to Lumension’s Bentley, one of the ways in which organizations can better protect themselves against self-modifying malware, such as the Conficker worm and its descendants, is to reduce the IT resource’s attack surface. We can do this using a five-stage process of discovery, assessment, prioritization, remediation and reporting.

In the discovery stage, IT managers should attempt to discover all the network resources on the company systems. Once this process is carried out, he says, managers can then identify the vulnerabilities that exist on the network.

The third step is to prioritize the remedial steps needed, namely understand the details of the IT resource’s vulnerabilities, their potential severity and their impact of the business.

“The fourth stage,” says Bentley, “is to remediate, or eliminate the network vulnerabilities, using a process of installing security patches at all points, and mitigate any other risks by creating custom remediation.”

The fifth and final stage is to report on the risks and the solutions applied to the problem of reducing an organization’s attack surface.

This is normally achieved, says Bentley, “by in-depth reporting at all stages in the process, and then consolidating the reports into a master analysis, which can be updated as new risks arrive and new resources are added to the IT system(s) concerned.”

Messagelabs’ Paul Wood, meanwhile, says the process of blocking malware – especially self-modifying hacker code – can also be highly automated, with IT security technology analyzing and stepping through the analysis process at high speed.

Five Stages of Analysis

The Messagelabs’ modus operandi involves a five-stage real-time analysis process. It kicks in as various IT threats are encountered when monitoring an organization’s incoming and outgoing emails.

The first stage is to bandwidth throttle any suspicious IP traffic to give the organization’s IT security software a chance to analyze the suspect messages and/or attachments in real time.

If the email is found to be suspect, but does not conform to known infection signatures, then the message’s header can be analyzed and, if an infection etc., is found, the email can be quarantined.

The third stage in the analysis process is to perform user management and address validation, with Messagelabs’ security applying a number of automated checks to verify whether the message comes from a source previously known to be dangerous.

“The fourth stage”, Paul Wood says, “is to apply the Skeptic anti-malware and anti-hacking analysis program for anything suspicious that has passed the first three analysis stages but does not pass muster”.

The fifth and final stage, he explains, is to apply Skeptic’s anti-spam technology to the messages, allowing the security software to weed out anything that still looks suspicious for later, manual, analysis by the IT staff concerned.

There is an additional security step that can be carried out to detect hybrid and self-modifying malware and email infections that cannot be spotted using conventional signature pattern analysis, or heuristic analysis. This is to perform a DNA analysis on the message and its attachment(s).

Wood says that this process is arguably the most interesting of all, since it allows an evolutionary approach to be taken to the analysis process. The security software modifies its approach as it encounters new potential infection or hacker attack vectors.

Currently, he says, this process requires the interventions of programmers to check for false positives. In time, though, the process could well become automatic – almost as automatic, perhaps, as the self-modifying malware that the software is designed to detect and deal with.