Sunday, 28 November 2010 15:12

Whitepaper: Attack of the Clones - Is Homogeneity in a network environment safe?

Homogenous -

1.composed of similar or identical parts or elements
2.of uniform nature


Management love homogeneous networks; they reduce the amount of training needed, the number of IT Technicians to offer support and, of course, offer an opportunity to obtain bulk discount through volume licensing.

But in pursuing lower capital and maintenance costs, are these same managers opening their networks to attack?


There are three types of network;

  • Homogeneous – All systems run the same Operating System and Software stack

  • Heterogeneous – A mix of systems and software are used.

  • Hybrid – All systems of a given type (e.g. desktops) run the same OS. Servers may differ.

In reality, most networks are Hybrids. Desktops all run the same OS and very similar software stacks in order to minimise the amount of user training required. Servers often run whichever OS and software is best suited to their required task.

Unfortunately, from a business perspective, the risks of a hybrid system are almost as high as those of a fully Homogeneous system. For the purposes of this paper, we will assume that the two are one and the same.


The Risks of Homogeneity

Whilst homogeneity is great from a support point of view, if (and when) malware attacks the network, the situation can quickly escalate. You see, in a homogeneous network, all systems run the same software. They, therefore, are all susceptible to the same attacks.

This means that if a worm successfully infects just one machine on your network, it is capable of attacking every system on your network. As your IT support cell will confirm, removing malware from a single device can be a painstaking task, imagine the effort required to cleanse a whole network.

Whether the malware is targeted specifically at your network, or generic (like Conficker) a homogeneous system ensures that the malware can spread across your entire network.



Case Studies

Case Study 1 - Conficker

Also known as Downadup, Downup and Kido the Conficker worm was first detected in November 2008. Conficker targeted systems running Microsoft Windows and spread through a weakness in the Windows File Sharing protocol (Server Message Block or SMB).

The worm also used Dictionary based attacks on the Windows Administrator password in order to help 'enlist' the machine into a botnet.

It's believed that Conficker successfully infected over 15 million machines, owned and operated by Governments, Businesses and Home Users around the world. Panda Security reported that six percent of computers scanned by their software were infected with Conficker[1].

Both the Royal Navy and their French counterparts experienced disruption as a result of the malware, indeed the French were forced to quarantine their network. This lead to aircraft being grounded until the network could be restored.

Other victims of the malware included;

  • Hospitals in Sheffield

  • German Armed Forces

  • Manchester City Council

  • Houses of Parliament

  • Greater Manchester Police

Although malware is an in-avoidable in today's world, the impact of Conficker was undoubtedly worsened by the software monoculture utilised today. Because of the widespread use of Microsoft Windows, the worm had countless potential targets and was therefore able to propagate easily.

Microsoft did, in October 2008, release an emergency security patch to counter Conficker. However, in January 2009 and estimated 30% of systems remained unpatched. Sheffield Hospital was one of those remaining unpatched and as a result experienced system problems in their operating theatres[2].

Many of those affected could be considered 'high profile' targets. It is often assumed that Military networks are (almost) impenetrable, however in pursuing lower costs and easier administration, Governments around the world have widened the potential attack surface.

Whilst Microsoft Windows has its uses, there are tasks which can be completed far more efficiently on other Operating Systems. Had a mix of operating systems been used, the malware would have found it far more difficult to propagate.



Case Study 2 - Melissa

Although often referred to as a worm, Melissa is in fact a Macro Virus. This malware was also known as Malissa and Simpsons.

Melissa began to spread in 1999 after being posted to the UseNet group The payload was embedded in a Word Document containing a list of username/passwords for over 80 pornographic sites.

The code was able to run on Microsoft Word 97 & 2000, Excel 97 & 2000 & 2003. Once called it used either Outlook 97 or Outlook 98 in order to email itself to the first 50 entries in the users address book.

The initial variant of Melissa wasn't actually intended to cause any harm, however it spread so effectively that the traffic it generated began to overload internet servers. Shortly after Melissa was released into the wild, new variants began to emerge;

  • Melissa.U

  • Melissa.V

  • Melissa.V/E

  • Melissa.AO

With the exception of Melissa.AO, all of the above were designed to cause harm to the host system. Melissa.U deleted and corrupted important Operating System files, whilst variants V and V/E targetted the users data.

Because the malware required a specific environment in which to operate, only those systems using the correct version of Microsoft Office were affected. However, even in 1999, Microsoft Office dominated the productivity market and so many systems were vulnerable. Because Microsoft Office was available on multiple platforms, the underlying Operating System was irrelevant. Apple Macintosh users were, therefore, as prone to infection by Melissa as users of Windows.

Some systems were susceptible to infection, but unable to automatically propagate the malware further due to an incompatible mail client. Unfortunately, once the system was infected, any Word Documents manually emailed were also infected by Melissa. Similarly, users not susceptible to Melissa at all still encountered difficulties due to the volume of e-mail received from infected friends and colleagues.

Exact statistics on the extent of Melissa's attack are not available, but the Software Engineering Institutes Computer Emergency Response Team (SEI CERT) noted that from the first report of infection it took just three days to record over 100,000 infections.


A Holistic View

As Case Study 2 highlights, there is more to heterogeneity than the underlying Operating System. A business could have been running 100 different operating systems on a 1000 different machines, but if they shared the same software stack (in this case Microsoft Office 8) they would all have been vulnerable to infection by Melissa.

Although the underlying Operating System does remain very important, malware authors (also known as Vxers) are increasingly targeting the software stack instead. Microsoft have learned, to their cost, that no effort should be spared on securing their systems. Although Windows is still quite vulnerable, many of the practices of the past are being rectified. As the much needed focus on security develops within Redmond, Vxers will increasingly set their sights on higher level applications.

The most common target, at time of writing, is Adobe's Flash Player[3]. So heavily has Flash been targeted that the CEO of Apple Corp – Steve Jobs – gave security concerns as part of the reasoning for controversially banning flash from the iPhone, iPad and iPod[4].

Although Flash undoubtedly has it's weaknesses, it is not, and will not be the only application to be targeted. Although applications running in userspace have far less control than those in kernelspace, the continuing practice of running with Administrators rights increases the ability of malware to exploit userspace applications. Windows Vista and Windows 7 attempted to rectify this issue with the new 'User Account Control' (UAC), but user education is still required.


Evolution of Malware

When attempting to combat the spread of malware, it is important to understand the continuing evolution of this black market. Originally, much malware was written as a Proof of Concept. The malware, much like the original strain of Melissa, was not intended to do any real harm, but instead to highlight that something could be done.

The original Vxers wrote malware for 'kudos', with some even going so far as to include an uninstaller[5].

Later strains of malware began to actively cause harm to the infected system and/or the user's data. This was probably a continuation of the Proof of Concept motivation, albeit mixed with some malevolence.

In today's marketplace, very little malware is written purely for amusement. Criminal Gangs have become involved, having realised the huge financial potential in malware. As the world becomes increasingly dependant on computing, the potential of malware to steal money and identities increases accordingly.

The techniques used by malware are becoming increasingly novel, with some written solely to create 'botnets'. Such malware connects to a central control server (the Command and Control Centre) to check for instructions, and forces the infected system to complete whatever task is instructed of it. When the number of infected systems is in the hundreds of thousands, those controlling the malware are able to demand ransom money from website operators in order to avoid being hit by a Distributed Denial of Service Attack.


Overt Techniques

Many strains of malware attempt to hide their very existence from the host system, however we are seeing an increasing trend towards making the user very aware that they are infected. A new sector of malware known as scareware has emerged.

Scareware functions by infecting a system and then claiming to be an Anti-Virus scanner. The scareware will report that the system is badly infected and will offer to 'clean' the infections. In order to do so, the user must pay for the 'software' despite the only infection being the software they are paying for.

There is much concern about scareware, not only are users being tricked into paying for software that they do not need, they are unknowingly handing their payment details to criminal gangs.



Although heterogeneity could pose an effective defence against the spread of malware, it is becoming increasingly difficult to implement. As our reliance on electronic systems develops, so does our reliance on specific technologies.

As time goes by, it may become increasingly difficult to implement heterogeneity. As we have seen, homogeneity encompasses more than just the underlying operating system, potential attack surfaces now include the software that we run in user space. A unified push to embrace heterogeneity would probably lead to disruption in our ability to share information between different systems.

The foundations of the communications era have already been exploited -The Morris Worm[6] spread by exploiting the TCP/IP stack. This stack forms the very foundation of most communication between computer systems. There's certainly no reason to believe that underlying standards such as TCP/IP will not continue to be exploited.

There's a common explanation of a 100% 'secure' system used by those within the IT sector. In order to achieve it, a user would need to complete the following steps;

  1. Disconnect the system from all networks

  2. Disconnect the system from it's power supply

  3. Submerge the system in concrete

  4. Place it under armed guard in an underground bunker.

The point in this explanation is that it is simply not possible to create a 100% system unless you are willing to accept that nobody will be able to utilise it. This is exactly the issue experienced when attempting to implement a 'secure' heterogeneous environment – there will always be a component common to all systems. Removal of these components might improve security, but will remove an important ability (i.e. to communicate with other systems).



A Possible Compromise

So we've established that the ideal of a truly heterogeneous environment is unattainable. Are there steps that we can take to achieve a reasonable compromise between heterogeneity and functionality?

The biggest threat posed by homogeneity is the sharing of common vulnerabilities between systems. This can be countered, slightly, by abandoning the practice of using a shared image for the installation of new systems. Rather than ensuring each system runs the same software stack, we should be more discerning about which software runs on which system.

For example, does every user in your business require Adobe's Flash? If not, then why install it on every machine? Does every user require Microsoft Outlook? Could some of your employee's complete their duties with Outlook Express? Do they need Microsoft Office, or could they function with OpenOffice?

Do all your employee's require Microsoft Windows? Would GNU/Linux or Mac OS X be better suited to the needs of some of these users? Ironically, the common functions which make heterogeneity so difficult do allow you to easily utilise different Operating Systems within a single network environment.

The difficulty with such a tactic is that it can lead to increased costs, your IT Cell would need to configure each system individually when deploying new hardware. It may even be that the business attracts a lower discount on Volume Licensing because of the reduced need for a specific piece of software.

However, consider the cost to the business of a wide ranging security breach. If your homogeneous network were to be compromised by Conficker, what would the cost be compared to that of a (partially) heterogeneous environment?

If there's one thing that you must do, it's to break the pattern of homogeneity on systems holding sensitive data. If your network uses Microsoft Windows on all workstations, is it wise to run Microsoft Windows on the server holding your (very sensitive) customer data? Is there any good reason why this server could not be running UNIX, GNU/Linux or a BSD variant?



Homogeneity poses a major security risk to all networks, corporate or otherwise, and can lead to infections spreading rapidly. Malware such as Conficker and Melissa spread so effectively because of the software monoculture that exists in today's market.

Whilst Heterogeneity may seem like the perfect solution to this issue, in today's world it has become almost unattainable.

Whilst it is not possible to achieve 100% heterogeneity, steps can be taken in order to minimise the potential attack surface. In order to do so, businesses need to begin to embrace the 'best tool for the job' ethos. Why do we continue to install software on machines that do not require it? It presents no benefit to the user, and simply provides an additional machine to be infected by any malware targeting that software.

Whilst IT is a very cost sensitive sector, current practices are untenable. The huge impact of malware such as Conficker highlights just how grave the situation has become. Because a homogeneous system was used, the French Navy was forced to ground aircraft as a result of a malware infection. Businesses need to consider the potential risks of a widespread malware infection and take steps to minimise the impact.

Contrary to common practice, consideration of malware should not be consigned solely to Disaster Recovery and Business Continuity procedures, but should be considered at the very conception of a new networking system.

Deploying hardware with the bare minimum of required software comprises a large step towards achieving the perfect balance between homogeneity and heterogeneity. Installing software after the hardware has been deployed poses very little inconvenience, and so long as it is controlled on a 'reasonable need' only basis can be very effective. This would, of course, mean that the practice of management demanding all available software would also need to be approached.

Each users job varies from that of his/her colleagues, and there's no good reason why the computer he/she uses needs to be 100% identical to those around him. Only once we begin realising that not every user needs the same software can we begin to approach the issues raised by homogeneity.










You can download this Whitepaper in PDF format here.



Last modified on Monday, 25 June 2012 22:45
Ben Tasker

Ben is a Network Security and Linux specialist with experience on a wide range of Unix based Operating Systems, as well as a serious amount of experience with the Microsoft Windows Operating Systems.  Ben is also an amateur photographer and enjoys writing articles on technical subjects.


Leave your comments

0 Character restriction
Your text should be more than 10 characters
terms and condition.
  • No comments found

Training Courses

There are no courses in the selected category

Looking for our open source software?


We release and support our open source software at Virya Software

Forthcoming events

No events found

Latest tweets

Virya Technologies If you work in Marketing, SEO, SEM, or any related fields and you're based in/around Suffolk, make sure this is on y…
Friday, 06 February 2015 08:43
Virya Technologies We will be conducting essential hardware maintenance from 11pm GMT tonight on our Prajna server, which will result in a period of downtime
Sunday, 01 February 2015 14:48
Virya Technologies We are aware of an outage on our shared hosting server Prajna and are working to resolve this urgently
Monday, 13 October 2014 12:43

Follow ViryaTech on Twitter