Core Impact Underlying Technology

Agent Technology

Agents are a critical component of Core Impact's architecture because they provide the functionality to execute code in the form of modules, either locally or on other agents. The following sections describe the key underlying technology employed by Core Impact agents.

The ProxyCall Interface

Every module execution in Core Impact is associated with a source agent, the default agent that the module uses to interact with the operating system (OS). The interaction between the agent and the OS is achieved using the ProxyCall Interface, a common interface for all platforms. The ProxyCall Interface abstracts the operating system's user-mode services using syscalls for UNIX and Win32 API functions for Windows. This common interface makes Core Impact's modules available in all platforms where a ProxyCall implementation exists. A ProxyCall implementation provides the module with one function call for each available syscall in the underlying OS and a mechanism to call arbitrary syscalls if needed.

For example, the gethostname()syscall is part of this common interface. In a UNIX ProxyCall implementation the gethostname() call is translated in its corresponding syscall into the OS's kernel. In a Windows implementation it is translated into a call to the gethostname()function within the wsock32.dll dynamic library.

There are two main branches in the ProxyCall hierarchy:

• UnixProxyCall and ProxyCallv2 for Unix, provide services for marshalling calls to any system call supported by the underlying UNIX-like OS. These calls are sent directly into the system kernel.
• WindowsProxyCall and ProxyCallv2 for Windows, provide services for marshalling calls to any DLL entry-point function by first dynamically loading the library into the process space of the agent using the LoadLibrary call, then obtaining the offset of the desired function in the loaded library using the GetProcAddress call, and lastly jumping into it.

Python

Core Impact 's Console uses a Python Virtual Machine (see http://www.python.org/) to run modules. The only significant difference between the typical Python VM distribution and the one distributed with Core Impact is that Core Impact 's VM uses the ProxyCall Interface to implement all of Python's system services.

This means that:

• Python's file object uses the ProxyCall Interface for all its functions.
• Python's socket object uses the ProxyCall Interface for all its services.
• Basic OS services implemented in the sys and os modules use the ProxyCall Interface.

A Python script that is typically used to open a socket will open a ProxyCall socket when run inside Core Impact. (This is why Core Impact modules do not look significantly different from typical Python code.)

SysCall Proxying

If a ProxyCall implementation forwards the call to a remote server instead of directly calling the underlying OS syscall, remote execution will be simulated. Whenever a module is run by a remote source agent, all the module's calls into the ProxyCall interface are forwarded to a remote ProxyCall server. This is known as SysCall Proxying.

The following example describes how SysCall Proxying works:

1. A module is executed using a remote agent deployed in host victim.
2. The module calls the gethostname() from the agent's ProxyCall interface.
3. The function marshals its arguments into a structure that is specific to the remote system's OS and generates a remote call into the ProxyCall server running in the victim host.
4. The server in victim calls the real gethostname() function in victim's operating system, marshals the result, and sends it back to the client.
5. The client ProxyCall implementation returns the results to the module.
6. The module prints the gethostname() results to the console as if it was running in victim.

Inside Core Impact's architecture ProxyCall servers are implemented as target-dependent assembly code. Optimized for size, these tiny SysCall servers are the basic component of agents.

Using a SysCall server as payload for an exploit also makes the task of customizing a shellcode unnecessary. Once the remote agent is up and running, further syscalls can be executed in the remote system.

The following example describes how this works:

1. An attack module that exploits a vulnerability in a ftp daemon succeeds and installs an agent.
2. You connect to the newly deployed agent and realize that you are inside a chroot jail.
3. You select the new agent as source and run a setuid module and a chroot breaker module.
4. The agent is freed from the chroot jail.

The successful completion of the process described above would typically require the exploit developer to change the exploit's shellcode to accommodate the change made in step 3. It would also depend on the user successfully exploiting the vulnerability again, which might not be possible.

For a comprehensive explanation of Syscall Proxying, refer to "Syscall Proxying - Simulating Remote Execution" by Maximiliano Caceres.

About Agents

Core Impact agents can multi-task (run multiple modules) and have a Secure Communication Channel. Once deployed, they can provide all system calls and arbitrary code execution on platforms with built-in stack protection. Local agents use Python Virtual Machine and local Syscall implementation embedded in the console connected to the database.

The following table lists the platforms that agents support.

Agent-supported Platforms

Platform

Ubuntu Linux 5-14 (x86 / x86-64) RedHat Linux 6, 7, 8, 9 (x86) Red Hat Enterprise Linux AS 3, ES 3, WS 3, AS 4, ES 4, WS 4, AS 5, ES 5, WS 5, AS 5.1, ES 5.1, WS 5.1 (x86) Mandrake Linux 7.1, 7.2, 8, 8.1, 8.2, 9, 9.2, 10 (x86) Mandriva Linux 2006, 2007, 2008.1 (x86) Linux Fedora Core 2 - 10 (x86) Linux Fedora 7 - 8 (x86) SuSE Linux 7-9.3 (x86) OpenSUSE 10.1-2 (x86) SUSE Linux Enterprise 10 - 11 (x86) OpenBSD 3.5 - 3.9, 4.0 - 4.9 (x86) Windows 10 (x86 / x86-64) Windows 8.1 (x86 / x86-64) Windows 8 (x86 / x86-64) Windows 7 (x86 / x86-64) Windows 2012 R2 (x86-64) Windows 2012 (x86 / x86-64) Windows 2008 (x86 / x86-64) Windows 2000 (x86) Windows XP (x86 / x86-64) Windows 2003 (x86) Windows Vista (x86 / x86-64) Mac OS X 10.9.x (Mavericks) (x86-64) Mac OS X 10.10.x (Yosemite) (x86-64) Mac OS X 10.11.x (El Capitan) (x86-64) Mac OS X 10.6.x – 10.8.x (x86-64) Mac OS X 10.4.6 - 10.4.11 (x86) Mac OS X 10.5.0 - 10.5.2 (x86) FreeBSD 5.5 - 7(i386) Cisco 2611XM Cisco 2811 Cisco 2911 Cisco 3640 Cisco 3725

The following table compares the functionality and attributes of the different deployment types of Core Impact agents. Because the communication channels available to agents are dependent on privilege level, the table includes both agents and agents running "as root". Note that some agent functionality listed below (such as sniffing and IP spoofing) is dependent on the presence of optional product plug-ins.

Agent Functionality and Attribute Comparison

Category	Multi-task?	Crypto?	Send ICMP?	Sniff?	Spoof IP?	Persistent	Real Shell
Agent	yes	yes	no	no	no	no	yes
Agent as root / Administrator	yes	yes	yes	no	no	yes	yes
Agent + PCAP as root / Administrator	yes	yes	yes	yes	yes	yes	yes
Local Agent	yes	N/A	yes	yes	yes	N/A (yes)	no