379 lines
17 KiB
Plaintext
379 lines
17 KiB
Plaintext
04/19/2005
|
|
|
|
Note:
|
|
|
|
We've tried to include most of the topics that will be covered in our
|
|
presentation. However, many of these things will be discussed, but will not be
|
|
our main concentration. The majority of our presentation will be around topic
|
|
V. C, our new post-exploitation advances, and how they will be designed and
|
|
integrated into Metasploit 3. Metasploit 3 won't be finished in time for
|
|
Blackhat, but more important than the software itself is the work we've done
|
|
on developing the individual components that it will be built from.
|
|
|
|
This outline is pretty indepth, so it's hard to pick out all the nuggets of
|
|
coolness. We've developed many really useful technologies in the area of
|
|
payload development. These are things we've created since last year's
|
|
Blackhat, including many advances in polymorphic shellcode, and
|
|
high-permutation attacks.
|
|
|
|
I. Introduction
|
|
A. Who are we?
|
|
1. spoonm
|
|
2. skape
|
|
B. Exploit Technology
|
|
1. Three Phases of Exploitation
|
|
a. Pre-exploitation
|
|
b. Exploitation
|
|
c. Post-exploitation
|
|
2. Pre-exploitation - Preparing the payload
|
|
a. NOP generation
|
|
b. Payload encoders
|
|
c. Connection handler initialization
|
|
3. Exploitation - Leveraging the vulnerability
|
|
a. Stack overflows
|
|
c. Heap overflows
|
|
b. SEH overwrites
|
|
d. Arbitrary pointer overwrites
|
|
4. Post-Exploitation - Manipulating the target
|
|
a. Command shell redirection
|
|
b. Arbitrary command execution
|
|
c. Pivoting payloads
|
|
d. Advanced payload interaction
|
|
B. Where do we stand?
|
|
1. Pre-exploitation
|
|
a. Robust and elegant encoders do exist
|
|
i. SkyLined's alpha-numeric encoder
|
|
ii. Spoonm's Shikata Ga Nai
|
|
b. Payload encoders generally taken for granted
|
|
i. Most encoders are static with a variable key
|
|
ii. IDS able to signature static decoder stubs
|
|
c. NOP generation hasn't publically changed much
|
|
i. PoC exploits generally use predictable nops, if any
|
|
ii. ADMmutate easily signatured by most NIDS (Snort, Fnord)
|
|
iii. Not considered very important to many researchers
|
|
d. NIDS deployments are playing chase the tail
|
|
i. The mouse always has the advantage; NIDS is reactive
|
|
ii. Advanced nops and encoders push NIDS to its limits
|
|
2. Exploitation
|
|
a. Techniques have become very mature
|
|
i. Linux/BSD exploitation techniques largely unchanged
|
|
ii. Win32 heap overflows now more reliable (oded/shok)
|
|
iii. Win32 SEH overwrites make exploitation easy, even on XPSP2
|
|
b. Exploitation topics have been beaten to death
|
|
3. Post-exploitation
|
|
a. Common payloads are limited
|
|
i. Command shell interaction has poor automation support
|
|
ii. Limited to the command set that the interpreter provides
|
|
iii. Bounded by the utilities installed on the target machine
|
|
iv. Restrictive environments (chroot) can hinder command execution
|
|
v. HIPS vendors becoming more adept at detecting basic payloads
|
|
- LoadLibraryA from the stack, etc (mcafee 8.0i)
|
|
b. Communication vectors largely unchanged
|
|
i. Reverse and port-bind payloads still the most common
|
|
ii. Findsock style payloads still unused by PoC exploits
|
|
iii. Alternative communication vectors rarely discussed
|
|
c. Pivoting technology exists
|
|
i. Core ST described system call proxying in 2002
|
|
ii. Metasploit's (2.3) meterpreter provides basic network pivoting
|
|
C. What will we discuss?
|
|
1. Pre-exploitation Research
|
|
a. NOP generation
|
|
i. Opty2
|
|
b. Encoders
|
|
i. Additive feedback encoders
|
|
ii. Shikata Ga Nai
|
|
2. Post-Exploitation Research
|
|
a. Library Injection
|
|
i. Facilitates things like Meterpreter and VNC injection
|
|
b. VNC Injection
|
|
i. Introduced at blackhat04 with the Metasploit 2.2 release
|
|
c. Meterpreter & dN
|
|
i. The cross-platform post-exploitation suite
|
|
3. Payload Research
|
|
a. PassiveX
|
|
i. Taking advantage of ActiveX controls
|
|
b. Ordinal Stagers
|
|
i. Tiny network capable stagers
|
|
c. Egghunt (maybe?)
|
|
i. Small payload capable of locating a larger payload
|
|
ii. Useful for exploits with limited space
|
|
II. Pre-exploitation
|
|
A. OptyNop2
|
|
1. Creation and benefits of multi-byte nopsleds
|
|
B. Additive feedback encoders
|
|
C. Shikata Ga Nai
|
|
1. High permutation shellcode through simple dependency mappings
|
|
III. Post-exploitation
|
|
A. Library Injection
|
|
1. Overview
|
|
a. Paper published in 04/2004
|
|
b. Provides advanced code execution
|
|
c. Code can be written in any language that can compile down
|
|
to a shared object.
|
|
d. Allows developer to use all of the APIs exposed to a normal
|
|
application.
|
|
e. Detailed explanation can be found in included resources
|
|
(include lib inject paper)
|
|
2. Two types of library injection
|
|
a. On-Disk
|
|
i. Library is loaded from the target's harddrive or via a
|
|
file share.
|
|
ii. Can be detected by AV products due to fs access
|
|
b. In-Memory
|
|
i. Library is uploaded to the target and loaded from memory
|
|
without touching the disk
|
|
ii. Evades file system filter drivers, such as those
|
|
provided by AV companies
|
|
iii. Not touching the disk means no forensic trace
|
|
iv. VirtualLock prevents swapping to disk, but requires admin
|
|
3. In-memory library injection on Windows
|
|
a. System calls used by the library loader are hooked
|
|
i. NtCreateFile
|
|
ii. NtMapViewOfSection
|
|
iii. etc
|
|
b. Unique image name is used to identify the image to image that
|
|
is in memory
|
|
c. System call hooks are removed so that future injectino can
|
|
occur
|
|
d. Alternative approaches
|
|
i. Could do client-side relocations, but would need to handle
|
|
import processing
|
|
4. In-memory library injection on Linux/BSD
|
|
a. No known public implementations
|
|
b. Requires alternate approach
|
|
i. Hooking API routines not always possible -- symtab not
|
|
mapped into memory
|
|
ii. libc symbol version mismatches lead to linking nightmares
|
|
c. Client-side relocations seem most feasible
|
|
i. Remote side maps a region of memory and sends the client
|
|
the base address
|
|
ii. Client processes relocations and transmits the relocated
|
|
image as its mapped segment would appear
|
|
iii. Requires locating rtld base so that PLT lookups will
|
|
work
|
|
B. VNC Injection
|
|
1. Implements VNC as an injectable DLL
|
|
a. Uses RealVNC as the code-base
|
|
b. VNC communication uses the exploit connection
|
|
c. No physical trace is left of the VNC server
|
|
d. Can operate regardless of existing VNC installations
|
|
2. Easy way to illustrate insecurities
|
|
a. Suits understand mouse movement better than black box command
|
|
prompts
|
|
C. Meterpreter
|
|
1. Generic post-exploitation suite
|
|
a. Based on library injection
|
|
b. Uses the established exploit connection
|
|
i. Especially powerful with findsock payloads; no new connection
|
|
c. Executes entirely from memory
|
|
d. No new processes or file access required for the payload to
|
|
succeed
|
|
e. Detailed explanation can be found in included resources
|
|
(include meterpreter paper)
|
|
2. Extension system provides advanced automation support
|
|
a. No need to hand write tedious assembly
|
|
b. Existing native code can be ported to a meterpreter extension
|
|
3. Architecture
|
|
a. Design goals
|
|
i. Very flexible protocol; should adapt to extension requirements
|
|
ii. Exposure of a channelized communication system to extensions
|
|
iii. Stealth operation
|
|
iv. Should be portable to various operating systems
|
|
v. Client from one platform should work with server on another
|
|
platform
|
|
b. Protocol
|
|
i. Uses TLVs (Type-Length-Value) to support arbitrary data
|
|
passing.
|
|
ii. TLVs allow the packet parser to be oblivious to the structure
|
|
of the value field
|
|
iii. Type field is broken down into meta types
|
|
4. Core interface
|
|
a. Overview
|
|
i. Minimal interface to support the loading of extensions
|
|
ii. Implements the basic packet transmission and dispatching
|
|
facilities
|
|
iii. Exposes channel allocation and management to extensions
|
|
b. Advanced features
|
|
i. Migrating the server instance between processes
|
|
5. The ``stdapi'' extension
|
|
a. Overview
|
|
i. Included in Metasploit 3.0
|
|
ii. Provides access to some of the common subsystems of the
|
|
target operating system
|
|
iii. Allows for easy automation and implementation of robust
|
|
post-exploitation scripts
|
|
b. File System
|
|
i. File and directory interaction
|
|
ii. Files can be uploaded and downloaded between the
|
|
attacker and the target
|
|
c. Network
|
|
i. Transparent network pivoting
|
|
ii. Route table enumeration and manipulation
|
|
iii. Local interface enumeration
|
|
d. Process
|
|
i. Process execution, optionally with channelized IO
|
|
ii. Enumeration of running processes
|
|
iii. Modification of arbitrary memory
|
|
iv. Creation and modification of running threads
|
|
v. Loading and interacting with shared object files
|
|
e. Registry
|
|
i. General registry API access
|
|
ii. Opening, creating, and removing registry keys
|
|
iii. Setting, querying, and deleting registry values
|
|
iv. Enumeration of both keys and values
|
|
f. User interface
|
|
i. Disabling local user interaction via the keyboard
|
|
and/or mouse (similar to VNC)
|
|
ii. Idle timeout checking to see how long it's been
|
|
since the user did something interactive
|
|
6. The ``priv'' extension
|
|
a. Still in development
|
|
b. Exposes an interface to escalating local privileges
|
|
through local vulnerabilities
|
|
c. SAM dumping support similar to pwdump3
|
|
D. dN
|
|
1. Simple low-footprint post-exploitation tool
|
|
2. Useful to scope out execution enviroment, then bootstrap other tools
|
|
IV. Payload Research
|
|
A. PassiveX
|
|
1. Overview
|
|
a. Post-exploitation payload
|
|
b. A derivative of On-Disk library injection that uses
|
|
ActiveX controls
|
|
c. Supports arbitrary DLL injection in any language that can
|
|
be compiled as an ActiveX control (C++, VB, etc)
|
|
d. Detailed analysis can be found in included resources
|
|
(include passivex paper)
|
|
2. Payload Implementation
|
|
a. Disables iexplore Internet zone restrictions on
|
|
ActiveX controls
|
|
i. Modifies four registry values that are stored per-user
|
|
b. Launches a hidden iexplore at a URL with an embedded
|
|
OCX
|
|
i. The OCX does not have to be signed
|
|
ii. No user interaction is required
|
|
iii. OCX is automatically downloaded, registered, and loaded
|
|
into the browser's context
|
|
3. Sample HTTP tunneling ActiveX control
|
|
a. HTTP GET/POST used to build tunnel to attacker
|
|
i. Uses the WININET API
|
|
ii. Outbound traffic from target machine encapsulated in POST
|
|
request
|
|
iii. Inbound traffic from attacker encapsulated in GET response
|
|
iv. Proxy configuration automatically inherited
|
|
v. Requires HTTP server capable of performing encap/decap on the
|
|
HTTP packets
|
|
b. Streaming connection through HTTP tunnel can be created
|
|
i. socketpair doesn't exist natively on win32 but can be simulated
|
|
with a local listener
|
|
ii. Streaming abstraction allows advanced payloads to transparently
|
|
use the HTTP transport (Meterpreter, VNC)
|
|
iii. Local listener less covert, but highly beneficial
|
|
4. Pros
|
|
a. Bypasses restrictive outbound filters
|
|
b. Re-uses proxy configuration
|
|
c. Looks like normal user traffic
|
|
d. Allows full access to the win32 API like all forms of
|
|
library injection
|
|
5. Cons
|
|
a. Touches the disk
|
|
b. Requires administrative access
|
|
i. Internet Explorer prohibits the downloading of
|
|
ActiveX controls as non-admin
|
|
B. Windows Ordinal Stagers
|
|
1. Overview
|
|
a. Technique from Oded's lightning talk from core04
|
|
b. Uses static ordinals to locate winsock symbol addresses
|
|
c. Compatible with all versions of Windows
|
|
d. 92 byte reverse stager, 93 byte findsock stager
|
|
e. Detailed explanation can be found in included resources
|
|
(include spoonm ordinal paper)
|
|
2. Reverse Ordinal Stager
|
|
a. Walks InitOrderModuleList searching for ws2_32
|
|
b. Uses static ordinals to index the export table
|
|
c. Creates fd with socket
|
|
d. Chains connect and recv frames
|
|
e. Returns into buffer read in from file descriptor
|
|
C. Egghunting
|
|
1. Overview
|
|
a. Small stub payload that can search for a larger payload
|
|
b. Useful for exploits that have limited payload space but can
|
|
stash more payload elsewhere in memory
|
|
c. Example exploits include the IE object type vulnerability.
|
|
d. Goal is to safely search target address space for the larger
|
|
payload.
|
|
e. Larger payload is located by searching for an egg that is prepended
|
|
to it.
|
|
f. Detailed analysis can be found in included resources
|
|
(include egghunt paper)
|
|
2. Two primary methods of egghunting on Windows
|
|
a. SEH
|
|
1. 60 bytes in size, searches for an 8 byte egg, compatible with all
|
|
versions of Windows (including 9x)
|
|
2. Installs a custom exception handler
|
|
3. Begins walking the address space
|
|
i. When a bad address is encounter, the current pointer is
|
|
incremented by PAGE_SIZE
|
|
ii. When a mismatch of the egg is encountered, the current pointer
|
|
is incremented by one
|
|
4. Each address is compared against the 8-byte egg
|
|
i. Bad addresses will throw exceptions which will be handled
|
|
by the custom exception handler
|
|
5. When the egg is found, jump past the egg into the larger payload
|
|
b. System call
|
|
1. Very small stub (32 bytes), searches for an 8 byte egg, only
|
|
compatible with NT+
|
|
2. Uses a non-intrusive system call (NtDisplayString) to search validate
|
|
addresses
|
|
i. Same page walking logic as SEH is used
|
|
3. When the egg is found, jump past the egg into the larger payload
|
|
3. One primary method of egghunting on Linux
|
|
a. System call
|
|
1. 30 bytes in size, searches for an 8 byte egg
|
|
2. System call technique applies to other UNIX variants as well
|
|
3. Uses the sigaction system call to validate 16 bytes at once
|
|
4. Pros
|
|
i. Very small
|
|
5. Cons
|
|
i. Corner cases may cause it to be unstable
|
|
V. The Complete Picture - Metasploit 3.0
|
|
A. The power of pre-exploitation prepartion
|
|
1. Abstract NOP generation
|
|
2. Abstract payload encoding
|
|
3. Abstract exploit connection handlers
|
|
i. Bind handler
|
|
ii. Reverse handler
|
|
iii. Findsock handler
|
|
B. The power of exploit generalization
|
|
1. Standardized exploit creation interface
|
|
i. Robust target definitions
|
|
ii. Detailed exploit implementation information
|
|
iii. Entirely payload independent, no hardcoding paylaods
|
|
C. The power of post-exploitation automation
|
|
1. Complicated tasks made simple with scripting
|
|
i. Want to download a targets entire harddrive?
|
|
ii. Want to disable local user interaction?
|
|
iii. Want to upload and play an mp3 on the target?
|
|
iv. Want to 'be' on the target's network?
|
|
2. Standard interface means cross platform support
|
|
VI. Conclusion - where do we go from here?
|
|
A. Future Post-exploitation research
|
|
1. Mesh network support
|
|
2. Expansion of the stdapi described in this document
|
|
|
|
included resources:
|
|
http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf
|
|
http://www.hick.org/code/skape/papers/meterpreter.pdf
|
|
http://www.hick.org/code/skape/papers/remote-library-injection.pdf
|
|
http://www.hick.org/code/skape/papers/passivex.pdf [not released yet]
|
|
http://www.metasploit.com/users/spoonm/ordinals.txt
|
|
|
|
cited material:
|
|
STRIDE:
|
|
http://www.ics.forth.gr/carv/acs/ACS/Activities/papers/stride-IFIP-SEC05.pdf
|
|
|
|
syscall proxy:
|
|
http://www.coresecurity.com/files/files/11/SyscallProxying.pdf
|
|
|
|
|