Moving Target Defense: Beating the Hackers at Their Own Game

The Threat

Risk is a function of likelihood times impact.  When it comes to zero-day exploits, particularly those that use return-oriented programming (ROP) or one of its many cousins the likelihood is high, and the impact is higher.  How do these attacks work, and what is the industry doing to stop them?  More importantly, what can you do to stop them?  Is it possible to stop a zero-day without patching or updating systems?  Let’s explore these questions.

How ROP Works

Return-oriented programming, or “ROP” is a more sophisticated version of its time-worn ancestor, the buffer overflow attack.  The inner sanctum of a computer, the CPU, executes very small operations in sequence, very, very quickly.  These operations are useful only if executed in proper sequence, so the processor must keep track of the sequence very precisely.  Let’s look at how this works, using a simple example from the (almost) real world.

Suppose you need to send a letter (the old-fashioned kind, in a physical envelope).  Since you are incredibly detailed and obedient, you write down the steps for sending a letter on a to do” list, and you follow it blindly no matter what (rather like a computer).  You might end up with something like this:

1. Print & fold the letter
2. Put letter in envelope & seal the envelope
3. If you do have a stamp, put the stamp on the letter
   1. If you don’t have a stamp:
   2. On a Post-It, write “step 5”
4. Follow instructions for buying stamps below
5. Put stamp on envelope
6. Address the envelope & mail the letter

Buying stamps:

1. Leave the house
2. Lock doors
3. Drive to post office
4. Buy stamps
5. Drive home
6. Unlock doors
7. Resume at the step written on the Post-It note

If a criminal could change step 6 to read “unlock the doors and leave the house”, you might find yourself vulnerable to a robbery (they know you follow instructions blindly, like a computer). 

You are smart, though, and you write your instructions with a Sharpie, so criminals can’t change it.  Not to be outdone, the criminal changes the Post-It to read “step 7”, and adds a step 7 to say “unlock doors and leave the house”.

Now, let’s suppose there’s no way to add any new steps; there is no “blank space for new instructions”.  Can your nemesis still outfox you?  They can’t change the instructions, and they can’t add new instructions, but they can change the order of instructions that are already there. 

Did you notice that the “buy stamps” procedure includes the instructions “unlock doors” and “leave the house”?  These instructions make sense in context, and are not dangerous if executed in the proper sequence.  However, if executed in the wrong sequence, they could leave your home vulnerable, if you did them out of sequence and out of context.  This example shows how ROP works.  ROP uses instructions that are already present in an operating system – innocent and useful instructions – but perverts their intent by executing them in the wrong sequence and in the wrong context.  A set of “good” instructions for bad purposes is called a “ROP gadget”. 

If the hacker has enough instructions at their disposal (and computers always do), and enough determination (and hackers always do), they can make enough gadgets to create what geeks call a “Turing complete” system.  In non-geek language, that means they can make your computers do anything they want.

Stop ROP:  The Goal

One potential solution to ROP attacks is to randomize the memory layout of systems, otherwise known as Address Space Layout Randomization (ASLR).  In our example, this approach would be like adding a random number or offset to each step number.  If we choose an offset of 10, step 1 would become step 11, step 2 would become step 12, and so on.  This can slow an attacker, who might expect instructions to be numbered a certain way.  However, if the attacker figures out the offset – which is not difficult with ASLR –they are back in business. 

Suppose, however, that the numbering system was truly random.  You might figure out where the first step is, but the second step (and the third, and the fourth) are not where the attacker expects to find them  Such a systems would greatly complicate the adversary’s task even on a single machine.  Now let’s imagine a numbering system that is not merely random, but completely different on each system.  In this scenario, even if the enemy figures out the randomization on one machine, they can’t use their knowledge to compromise another machine.  On top of that, let’s suppose you realize one of your systems has been compromised by an ROP, or similar, exploit.  If you could simply re-compile the operating system using a different randomization scheme, the attacker has to start all over again. 

This randomization approach is in use now, and it’s one of many flavors of “moving target defense” (MTD), also known as polymorphic defense.  In the real world, as I write this, MTD prevents ROP attacks as well as many other zero-day exploits that leverage a knowledge of memory layouts in operating systems, including the notorious Spectre and Meltdown vulnerabilities, without swapping out CPUS, and without the overhead of an artificial intelligence system.

It is difficult to overstate the significance of MTD.  The best systems defend against zero-days, it entails little or no performance hit, and mitigate the need to patch constantly.  Some, such as Polyverse, guard against exploits such as Spectre and Meltdown without the need to replace CPUs. 

Current Research and Products

There are many threats to computing systems in addition to ROP, and there are many types of moving target defense.  MTD research efforts range from theoretical research in academia to commercially available products.  These efforts attack the problem at various levels, in four broad categories:  data; software; dynamic networking and platforms; and dynamic runtime environments.  I’ll start with the most esoteric, and end with the most currently practicable.

Data-Level Defenses

At the data level, most MTD technologies are confined to research labs and many are not available to the public.  They typically address only specific types of data and often carry a high penalty in performance.

Software

Efforts at the software level are more promising, and many are available through open source repos such as GitHub.  However, I know of no commercial products currently available.  Here are some examples to illustrate the state of the art in this area.

Moving Attack Surfaces (MAS) for Web Services, created by Yih Huang and Anup Ghosh, is a rotational scheme that uses functionally equivalent virtual servers.  Each server is configured differently and can be brought on- or off-line according to a schedule, or in response to an attack, and attack indicator, or other unforeseen circumstance. 

M. Azab and M. Eltoweissy, are developing a system called ChameleonSoft.  Based on biological and genetic diversity, the system has a grand aim:  encryption of software behavior.  This is a fascinating concept, though it is likely to be a long time before it is practical and commercially available

Several researchers (Simon Allier, Olivier Barais, Benoit Baudry, Johann Bourcier, Erwan Daubert and others) are working on end-to-end software diversification, whose goal is to randomize software at multiple levels:  scripting, API calls, keywords and syntax in HTML and HTTP and more. Again, this method looks promising, but practical applications are far in the future.

Dynamic Networking and Platforms

Some very interesting activity is in progress here.  Benjamin Cox and his colleagues, for instance, are developing N-variant systems.  N-variant systems have two main components. One component automatically creates and executes diversified, bt functionally equivalent program variants.  The other component is a monitor that compares inputs, to ensure that it generates equivalent outputs on all variants.  The authors have published some impressive performance statistics, showing that this approach may not be as cumbersome as it sounds.

H. Okhravi and associates have created TALENT, for “Trusted Dynamic Logical Heterogeneity”.  Its name is awkward, but its operation looks to be quite the opposite.  TALENT uses containers and a portable checkpoint compiler to migrate applications across platforms rapidly and automatically -- in about one second, according to the authors, keep attackers on guessing.

Reconnaissance Deception System, developed by S. Achleitner and colleagues, takes aim at an early phase of the kill chain:  reconnaissance.  It automates aspects of Software-Defined Networking (SDN) to implement five defense techniques:  Dynamic address translation; route mutation; vulnerable host placement; honeypot placement; and dynamic detection of malicious flows.

Chongkyung Kil, et al. have proposed Address Space Layout Permutation (ASLP), an enhanced address-space randomization technique that randomly relocates code and data segments.  Their results -- an approximately 20% increase in executable size and memory footprint – have been confirmed independently.

V. Pappas and colleagues have taken on a major challenge:  fighting return-oriented programming (ROP) attacks – the threat that began this article.  Their technique, in-place code randomization, has worked well against well-known ROP attacks, and against systems specifically designed to elude in-place code.  This technology is extremely promising, given its minimal system impact, and apparent effectiveness.

Morphisec is a commercially available product that randomizes memory and retains a copy of non-randomized memory for troubleshooting and exploits identification.  Interested readers can visit www.morphisec.com

K. Lu, et al, have developed ASLR-GUARD, which prevents leaks that let attackers identify the memory locations of code gadgets.  It comes with a performance penalty at load time but is a potentially strong technique. Further research may yield improvements in the load time issue.   

Polyverse^* is a young company with multiple MTD products.  Among these is compiler that scrambles program binaries but retains internal logic and performance. They have a similar product for closed-source applications, and a “polyscripting” system that replaces keywords and tokens in high-level language interpreters, defeating code injection attacks.

^*Full disclosure:  Polyverse is a client of my company, DLT Solutions, a Tech Data Company. 

Summary

ROP attacks, and other memory-based attacks are significant threats to our computing systems. Moving target defense (MTD) promises to defeat this attack, but MTD development encompasses a much wider range of defenses, detailed above.  These defenses are at various stages of development, but all seek to reverse the asymmetry in cybersecurity:  the attacker can change and morph at will, while the defender is a static “sitting duck”.