Although much work has gone into detecting, mitigating, and preventing their exploitation, remote code execution vulnerabilities remain one of the most prevalent and serious vulnerability classes in software today. While reported remote code execution vulnerabilities in common server software have gotten more rare, they are still highly prevalent in web browsers, office suites, media players, anti-virus suites, and other local application software.
Remote code execution vulnerabilities are exploited by injecting a small amount of executable machine code into the remote process and then triggering the vulnerability (the injection vector) in order to cause the remote process to execute the injected code ( the payload). Traditionally, these payloads have been written in processor-specific assembly language, assembled, and extracted by hand into reusable machine code components. These payloads were typically small and executed an operating system shell, causing them to be commonly referred to as shellcode. Common shellcode variants included functionality such as restoring dropped privileges, breaking out of chroot environments, and attaching the shell to an inbound or outbound network connection. This style of payload construction was both labor and skill intensive.
With the growth of commercial penetration testing services and especially commercial penetration testing products, exploit payloads have gotten considerably more capable and complex. These payloads have facilitated the construction of products that help less experienced penetration testers better demonstrate the risk presented by exploitable security vulnerabilities. In addition, the increased prevalence of layered host security defenses require that payloads be more robust and capable of more complex logic. The Unix chroot system call is typically used to run a network service in a restricted file system environment. Extensions including FreeBSD's jail [1] extend this model to assign a dedicated IP address to a jail. More recent developments include the Windows Integrity Mechanism in Windows Vista. The Windows Integrity Mechanism is a Biba Integrity Model[2] Mandatory Access Control security system used to implement Internet Explorer's ``Protected Mode'' and User Account Control (UAC). Protected Mode Internet Explorer runs as a low-integrity process that prevents it from writing to anywhere except designed places on the file system or in the registry, regardless of the discretionary access control list on the objects. Escalating privileges in these restricted permission environments, pivoting through networked hosts, or achieving mission objectives from these restricted execution environments requires complex payload logic.
This work addresses two shortcomings of the existing exploit payloads found in commercial and open-source penetration testing tools. The first is a lack of secure payload delivery and communication mechanisms. Most available systems offer partial solutions to this at the present time by either only supporting encryption in later-stage executable agents or by only supporting simple XOR-based traffic encoding. The second area that this work addresses is the applicability of existing payloads against mobile clients. Most of the existing frameworks require a constant network connection to the compromised target in order to carry out mission objectives. This paper introduces a target-side scripting environment in order to push mission-objective logic onto the target. The secure channel established by the earlier stage payload ensures that mission objective logic is not compromised in transit to the target.
This paper is organized as follows. First, a summary of existing advanced payload techniques and frameworks is presented in the next section. Afterwards, Encrypted Payload Protocol describes a system for cryptographically securing exploit payload delivery and communication. The final stage of this payload system, a lightweight and powerful remotely scripted agent is introduced in the section titled Target-Side Scripting. Finally, the paper concludes with some discussion of the security and utility of the described payload system.