Shadow Honeypots

We present Shadow Honeypots, a novel hybrid architecture that combines the best features of honeypots and anomaly detection. At a high level, we use a variety of anomaly detectors to monitor all traffic to a protected network or service. Traffic that is considered anomalous is processed by a "shadow honeypot" to determine the accuracy of the anomaly prediction. The shadow is an instance of the protected software that shares all internal state with a regular ("production") instance of the application, and is instrumented to detect potential attacks. Attacks against the shadow are caught, and any incurred state changes are discarded. Legitimate traffic that was misclassified will be validated by the shadow and will be handled correctly by the system transparently to the end user. The outcome of processing a request by the shadow is used to filter future attack instances and could be used to update the anomaly detector. Our architecture allows system designers to fine-tune systems for performance, since false positives will be filtered by the shadow. We demonstrate the feasibility of our approach in a proof-of-concept implementation of the Shadow Honeypot architecture for the Apache web server and the Mozilla Firefox browser. We show that despite a considerable overhead in the instrumentation of the shadow honeypot (up to 20% for Apache), the overall impact on the system is diminished by the ability to minimize the rate of false-positives

Detecting Network-Based Obfuscated Code Injection Attacks Using Sandboxing

Intrusion detection systems (IDSs) are widely recognised as the last line of defence often used to enable incident response when intrusion prevention mechanisms are ineffective, or have been compromised. A signature based network IDS (NIDS) which operates by comparing network traffic to a database of suspicious activity patterns (known as signatures) is a popular solution due to its ease of deployment and relatively low false positive (incorrect alert) rate. Lately, attack developers have focused on developing stealthy attacks designed to evade NIDS. One technique used to accomplish this is to obfuscate the shellcode (the executable component of an attack) so that it does not resemble the signatures the IDS uses to identify the attacks but is still logically equivalent to the clear-text attacks when executed. We present an approach to detect obfuscated code injection attacks, an approach which compensates for efforts to evade IDSs. This is achieved by executing those network traffic segments that are judged potentially to contain executable code and monitoring the execution to detect operating system calls which are a necessary component of any such code. This detection method is based not on how the injected code is represented but rather on the actions it performs. Correct configuration of the IDS at deployment time is crucial for correct operation when this approach is taken, in particular, the examined executable code must be executed in an environment identical to the execution environment of the host the IDS is monitoring with regards to both operating system and architecture. We have implemented a prototype detector that is capable of detecting obfuscated shellcodes in a Linux environment, and demonstrate how it can be used to detect new or previously unseen code injection attacks and obfuscated attacks as well as well known attacks

Protecting Against Address Space Layout Randomization (ASLR) Compromises and Return-to-Libc Attacks Using Network Intrusion Detection Systems

Writable XOR eXecutable (W XOR X) and Address Space Layout Randomisation (ASLR), have elevated the understanding necessary to perpetrate buffer overflow exploits [1]. However, they have not proved to be a panacea [1] [2] [3] and so other mechanisms such as stack guards and prelinking have been introduced. In this paper we show that host based protection still does not offer a complete solution. To demonstrate, we perform an over the network brute force return-to-libc attack against a pre-forking concurrent server to gain remote access to W XOR X and ASLR. We then demonstrate that deploying a NIDS with appropriate signatures can detect this attack efficiently

On Ladder Logic Bombs in Industrial Control Systems

In industrial control systems, devices such as Programmable Logic Controllers (PLCs) are commonly used to directly interact with sensors and actuators, and perform local automatic control. PLCs run software on two different layers: a) firmware (i.e. the OS) and b) control logic (processing sensor readings to determine control actions). In this work, we discuss ladder logic bombs, i.e. malware written in ladder logic (or one of the other IEC 61131-3-compatible languages). Such malware would be inserted by an attacker into existing control logic on a PLC, and either persistently change the behavior, or wait for specific trigger signals to activate malicious behaviour. For example, the LLB could replace legitimate sensor readings with manipulated values. We see the concept of LLBs as a generalization of attacks such as the Stuxnet attack. We introduce LLBs on an abstract level, and then demonstrate several designs based on real PLC devices in our lab. In particular, we also focus on stealthy LLBs, i.e. LLBs that are hard to detect by human operators manually validating the program running in PLCs. In addition to introducing vulnerabilities on the logic layer, we also discuss countermeasures and we propose two detection techniques.Comment: 11 pages, 14 figures, 2 tables, 1 algorith