One of the most interesting software releases in programming terms is (or was) The Last One (TLO), a Pascal-driven application that was released to critical acclaim in 1991 and coded by David James, a programmer famous for his expert coding exploits in the late 1980s and early 1990s.
TLO was notable in that it allowed its users to enter a programme design by selecting from a number of flowcharting options. As each flowchart is selected, the programme asks a series of simple questions, in order to better understand what the user wants from that particular element of programme code.
Once the entire flowchart has been entered by the user, TLO's programme 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 programme that does what the flowchart specifies. The resultant programme - 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 programme 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 programmes 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 programme code would be highly complex and cover tens, if not hundreds of millions of lines of source code.
A specialised version of a modern-day TLO – one designed, for example, for the creation of specialised 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. And, 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 Conficker 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 to the malware as and when required.
|"Under certain circumstances, 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."|
According to Alan Bentley, vice president of EMEA for vulnerability analysis security specialist Lumension, the Conficker malware 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.
“It's 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 the Conficker worm allows itself to update by – quite literally – phoning home across the internet, and downloading fresh instructions, then modifying its malware programme 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.
According to Wood, because http sessions have far less data and IT resource overheads 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 but Wood tells Infosecurity that it is perfectly 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, meanwhile, is also a believer in the automated approach to hackers and their malware.
Citing his firm's April 2009 Intelligence Report, he explains to Infosecurity that, if you look closely at the incidence of various pieces of high-profile malware on a month-by-month basis as they start to infect, continue their infection of large numbers of internet users, and then start to fade away, you get some interesting results.
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 programme code of the malware that exhibits this type of behaviour, he says, you start to realise 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.
|"Some malware types are emerging - like Conficker - that are capable of modifying themselves in teh face of changing situations on the internet."|
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 programmer(s) and/or third party hackers.
What is certain, however, he says, is that self-modifying malware is a reality in 2009 and is why some pieces of malware resurface in the Messagelabs charts on a regular basis.
According to Lumension's Bentley, one of the ways in which organisations can better protect themselves against self-modifying malware, such as Conficker and its descendants, is to reduce the IT resource's attack surface.
This is achieved, he says, by a five-stage process of discovery, assessment, prioritisation, 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 prioritise 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 organisation'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 analysing and stepping through the analysis process at high speed.
The Messagelabs' modus operandi in this regard, he says, is to adopt a five-stage real-time analysis process that steps through a number of stages as various IT threats are encountered when monitoring an organisation's emails as they stream in – and out.
The first stage is to bandwidth throttle any suspicious IP traffic to give the organisation's IT security software a chance to analyse 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 analysed 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 programme 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.
One 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 – says Paul Wood, is to perform a DNA analysis on the message and its attachment(s).
This process, he tells Infosecurity, is arguably the most interesting of all, since it allows an evolutionary approach to be taken to the analysis process, with the security software modifying its approach as it encounters new potential infection or hacker attack vectors.
Currently, he says, this process normally requires the interventions of programmers to check for false positives, but - in time - the process could well become automatic.
Almost as automatic, Infosecurity notes, as the self-modifying malware that the software is designed to detect and deal with.