Goal of the Survey:
Everything we know about defeating the insider threat seems not to be solving the problem. In fact, evidence from the Deep and Open Web points to a greatly worsening problem. Today’s employees work with a number of applications and with a series of clicks information can be both maliciously and accidentally leaked.
The purpose of this survey and research is to uncover:
The extent of employees leaking critical information and tradecraft on illicit sites
Data types and formats being exfiltrated along with exfiltration mechanisms
Why so many of these threats go undetected
What happens to the data after it has been exfiltrated
Tools to disrupt and prevent the data exfiltration cycle
Possibilities to expunge traces of data once exfiltrated
It may be argued that the genesis of the cloud actually evolved from the early concept of the outsourcing model, where organizations sought to place their operations in the hands of suppliers who did technology—eventually evolving into the dynamic/elastic offering we see today as the cloud, or as I see it, the “Inverted Operational Environment”—but why inverted? Well, consider the definition of the word:
To turn upside down
To reverse in position, order, direction or relationship
To turn or change to the opposite or contrary, as in nature, bearing or effect
To invert a process
To turn inward or back upon itself
To turn inside out
In the context of this article I am focusing on two elements from the above list: 1)to reverse in position, order, direction or relationship, and 2)to turn inside out, insofar as the placement of all, or some elements of the technological support are being reversed against, what has been the operational norm of internal hosting; and that what has been accepted as an operational model based behind the logical-perimeter walls of the company, now being supported by an external actor in the guise of a cloud provider.
The benefit of a well-selected cloud provider is that they focus on delivering technology, maintaining currency in skills, and do tend to run optimized and well protected infrastructures. Please note that I have used the term well-selected cloud provider. However, the obtuse to this position is, as I have observed in some companies who did not exercise the required level of due diligence at the time of contracting out their operations into the hands of, what may be referred to as cheap-and-cheerful providers, only to realize their mistake when things go wrong.
When establishing a relationship with any external provider, in particular cloud, it is important to identify the areas of criticality which support the company. For example, is the selected provider aware of the policies, standards and guides to which the contracting company wishes them to adhere to? Another area which tends to get missed is that of incident response, with plug in from internal-to-external, establishing joined-up-thinking and cross-enterprise protocols and communications, which may be invoked when encountering cyber-adversity.
It is also essential when engaging the selected provider that there is an agreement around what the actual technological internals look like when it comes to segregation, platforms and the type of storage. It is at this juncture that it is also well advised to agree that no logical lock-ins are in place that could impact any future migrations if the provider is to be swapped out.
We then look to the governance and compliance challenges which must be addressed to ensure that the data objects that are being migrated out are in complete accord with the mandated obligations. For example, consider the financial institution that did not apply the required depth of due diligence at time of establishing their new partnership, further compounded by the lack of clarification around the profile of storage, resulting in PCI DSS data being sent to a multi-shared insecure jump server located within the cloud provider’s premises, leaving the bank exposed to a serious PCI breach situation.
We then come to all of the other elements which should be at the forefront of the operational mind-set, ranging from monitoring, service reviews, and of course, where applicable, escrow agreements. It is here in an ISACA webinar on 20 April we will explore the topic of the cloud and will dig deep into some of the operational and management challenges that should be considered prior to going live with any such external migrations.
In my previous blog post in the Exploitation Demystified series, we learned how memory corruption exploits are implemented using stack-based overflow vulnerabilities. Let’s talk now about a main alternative path: heap-based vulnerabilities.
What Is the Heap?
An operating system (OS) allocates memory to a computer program, with respect to the size of the data this program consumes, which is either known before or determined at runtime. We have already introduced the stack, which is the OS allocation mechanism to the former. We will now get to know the heap, which serves the same allocation function to the latter.
The heap is the memory pool from which dynamic data requests are fulfilled. From a vulnerability/exploitation perspective, the two material differences between the stack and the heap are:
Heap memory must be requested explicitly. The program asks for a memory chunk in a certain size and gets a pointer to the first address of this chunk. The program should alsofree this chunk when it has completed its task. The request-free logic is the root cause to the common vulnerabilities class of use-after-free/double –free.
The heap is significantly larger in size than the stack. This makes an accurate prediction of the shellcode’s address much more complicated than in the stack. This complication is the development driver of the heap spray exploitation technique, which is practically common practice in most to all heap-based exploits.
Memory Corruption Recap
Let’s remember what we have learned so far about memory corruption exploits. This class of exploits involves placing a shellcode into a data input file, which is crafted to trigger a vulnerability in the processing application. The vulnerability renders a foothold in the process memory space, which the attacker leverages to redirect the execution flow towards the shellcode address. I’ll explain how both the Overwrite and Redirect parts are implemented on the heap.
Heap-Based Vulnerabilities Overview
In this post we will not deep dive into the subtleties of heap-based vulnerabilities. This is because the role of vulnerabilities in the exploitation lifecycle is to enable the initial address overwrite. From a security standpoint, this initial overwrite can hardly be prevented (except by a vendor patch). But proactive prevention can be applied to the Redirect and Execute parts of the exploits, so we will focus on these.
For our purposes, it suffices to know that there are two main groups of heap-based vulnerabilities: heap overflows and use-after-free. Let’s see what address is overwritten in each of these groups.
Heap overflows take advantage of the heap internal structure. Consecutive heap requests generate consecutive memory chunks. Each chunk consists of a header, which contains the chunk’s metadata, and the actual memory space in the requested size. Heap overflow vulnerabilities will overflow the memory space and overwrite the next chunk’s header.
Use-after-free vulnerabilities take advantage of the explicit call/free feature we have previously described. As we have explained before, dynamic memory requests render a pointer to the first address of a newly allocated chunk. If this pointer maintains validity despite the pointed object being freed, attackers can overwrite it to point to their own code (i.e., the placed shellcode). Use-after-free were the most exploited vulnerabilities on Windows 7 and later versions of Windows during 2015.
Heap-Based Exploitation Redirection – Heap Spray
Once the attacker is able to overwrite and control a heap address, the main objective is to resolve the shellcode’s address. Due to the heap’s size and allocation architecture, it is a much harder task relative to the equivalent stack scenario.
The Prediction Challenge
When placing a shellcode into a data input that is loaded to the heap, the attacker can know theaddresses range in which this shellcode resides but not the exact address of the shellcode itself. I’ll explain the technique that has evolved in response to this challenge.
No Operation (NOP) Instruction
Attackers have overcome the prediction problem by loading multiple byte sequences and shellcode into the heap. The basic implementation of these sequences is to use NOPs. NOP stands for “No Operation”, and it instructs the CPU to move to and execute the instructions in an adjacent address.
NOPs can solve the heap address prediction problem. Consider a block that contains a NOP sequence, followed by a shellcode. Let’s assume that we fetch the CPU a NOP address. The CPU will simply move to the next address and so on and so forth until reaching the shellcode and executing it. The NOPs have exponentially raised the probability of a successful shellcode execution because, instead of just one “good address” (the shellcode’s), we have multiple.
Heap Spray
What I’ve just described is the basis for the Heap Spray technique, which, as the name implies, sprays a vast area in the heap chunk with many NOPs and shellcode sequences. The spray ensures that, no matter which address the execution flow will jump, it will end up with executing the shellcode.
Constant Evolution
Exploit writers continuously advance their heap prediction capabilities. The more accurate prediction capabilities are, the smaller a heap spray can get. The heap sprays that were featured in exploits from 2014–2015 are considerably smaller and more targeted than the ones from before this period.
Conclusion
In this post we have concluded our description of memory corruption exploitation essential building blocks. The three blogs together render basic understanding of what a memory corruption exploit is, and how it is implemented. Of course there is a lot more to learn and know on this vast subject, and we hope that this is the first step to encourage you to proceed onwards.
