updated submission form
git-svn-id: file:///home/svn/incoming/trunk@2456 4d416f70-5f16-0410-b530-b9f4589650da
This commit is contained in:
parent
0067faeecf
commit
24c5c130e7
|
@ -146,3 +146,516 @@ Will you require a white board? Yes or No
|
|||
Will you require any special equipment? Yes or No - if yes, please specify.
|
||||
|
||||
No
|
||||
|
||||
Detailed Outline:
|
||||
|
||||
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
|
||||
|
||||
Abstract:
|
||||
|
||||
Blog Entry:
|
||||
|
||||
Supporting File(s):
|
||||
|
||||
Additional files/materials? No
|
||||
|
||||
Speaker's Bio(s):
|
||||
|
||||
Spoonm:
|
||||
|
||||
Since late 2003, spoonm has been one of the core developers behind the
|
||||
Metasploit Project. He is responsible for much of the architecture in version
|
||||
2.0, as well as other components including encoders, nop generators, and a
|
||||
polymorphic shellcode engine. A full-time student at a northern university,
|
||||
spoonm spends too much of his free time on security research projects.
|
||||
|
||||
Skape:
|
||||
|
||||
Skape is a lead software developer by day and an independent security researcher
|
||||
by night. He joined forces with the Metasploit project in 2004 where his many
|
||||
contributions have included the Meterpreter, VNC injection, and many other
|
||||
payload advances. Skape has worked on a number of open-source projects and has
|
||||
authored several papers on security related technologies. His current security
|
||||
related intrerests include post-exploitation technologies, payload development
|
||||
and optimization, and exploitation prevention technology.
|
||||
|
||||
Transfer of Copyright
|
||||
|
||||
I warrant that the above work has not been previously published elsewhere, or if
|
||||
it has, that I have obtained permission for its publication by Black Hat, Inc.
|
||||
and that I will promptly supply Black Hat, Inc. with wording for crediting the
|
||||
original publication and copyright owner.
|
||||
|
||||
If I am selected for presentation, I hereby give Black Hat, Inc. permission to
|
||||
duplicate, record and redistribute this presentation; including, but not limited
|
||||
to, the conference proceedings, conference CD, video, audio, hand outs(s) to the
|
||||
conference attendees for educational, on-line and all other purposes.
|
||||
|
||||
Yes, I, (insert primary speaker name), have read the above and agree to the
|
||||
Transfer of Copyright.
|
||||
|
||||
Agreement to Terms of Speaking Requirements
|
||||
|
||||
If I am selected to speak, I understand that I must complete and fulfill the
|
||||
following requirements or I will forfeit my honorarium:
|
||||
|
||||
1) I will submit a completed presentation in Powerpoint format for publication
|
||||
in the printed conference proceedings by the date specified in the CFP Letter of
|
||||
Acceptance.
|
||||
|
||||
2) I understand if I fail to submit a completed presentation by the date
|
||||
specified in the CFP Letter of Acceptance, I may be replaced by an alternate
|
||||
presentation or, if allowed to present, will forfeit $250 of my honorarium.
|
||||
|
||||
3) I will submit a completed (and possibly updated) presentation, a copy of the
|
||||
tool(s) and/or code(s), and a reference to all of the tool(s), law(s), Web sites
|
||||
and/or publications referenced to at the end of my talk and as described in this
|
||||
CFP submission for publication on the conference CD by the date specified in the
|
||||
CFP Letter of Acceptance.
|
||||
|
||||
4) I will include a detailed bibliography as either a separate document or
|
||||
included within the presentation of all resources cited and/or used in my
|
||||
presentation.
|
||||
|
||||
5) I will be on hand and accessible to delegates during Black Hat social events
|
||||
including, but not limited to, luncheons and receptions.
|
||||
|
||||
6) I will complete my presentation in the time allocated to me - not ending 15
|
||||
minutes before or running 5 minutes over the time allocation.
|
||||
|
||||
7) I understand that Black Hat will provide 2 lcd projectors, 2 screens,
|
||||
microphone, and video switch box. I understand that I am responsible for
|
||||
providing all other necessary equipment, including laptops and machines, to
|
||||
complete my presentation.
|
||||
|
||||
8) I will submit, within 5 days of the completion of the conference, any
|
||||
updated, revised or additional presentation(s) or materials that were used in my
|
||||
presentation but not included on the conference CD or conference proceedings.
|
||||
|
||||
I, (insert primary speaker name), have read the above and understand and agree
|
||||
to the terms as detailed in the Agreement to Terms of Speaking Requirements.
|
||||
|
||||
Agreement to Terms of Speaking Remuneration
|
||||
|
||||
1) I understand that Black Hat will only pay for one roundtrip coach class
|
||||
airfare per presentation.
|
||||
|
||||
2) I understand that if I choose to arrange the airfare myself, I must first
|
||||
receive approval from the Conference Administrator or I will not be reimbursed
|
||||
for the airfare. I understand that if I wish to be reimbursed for airfare, I
|
||||
must supply a valid receipt in the form of a travel agency issued air itinerary
|
||||
and/or ticket receipt with the airfare printed on it. I understand that there is
|
||||
a $750 cap for airfare and I will be reimbursed for up to that amount.
|
||||
|
||||
3) I understand that if I choose to travel by automobile I will receive $0.32
|
||||
per mile, roundtrip, as reimbursement. If I travel by rail or bus I will be
|
||||
reimbursed for the cost of the ticket price.
|
||||
|
||||
4) I understand that Black Hat will pay for one hotel room for three nights at
|
||||
the official venue hotel.
|
||||
|
||||
5) I understand that I will be required to provide the hotel with a valid credit
|
||||
card on check in to secure the room and any and all additional costs incurred by
|
||||
me (including but not limited to room service, phone line usage, room internet
|
||||
access, movies, etc) WILL NOT be reimbursed by Black Hat.
|
||||
|
||||
6) I understand that the person listed as the primary speaker will be required
|
||||
to complete a W9 form (only if a US citizen) in order to be paid. Non-US
|
||||
citizens will be paid via wire transfer (or you may choose to be paid with a
|
||||
company check).
|
||||
|
||||
7) I understand that Black Hat will issue one payment per presentation and the
|
||||
check will be issued to the person listed as the primary speaker. Payment will
|
||||
be made net 30 from the end of the conference.
|
||||
|
||||
8) I understand that the name and address on the W9 or wire transfer is where
|
||||
the payment will be sent.
|
||||
|
||||
9) I understand that if I am employed by an official Black Hat sponsor, that I
|
||||
will not receive any compensation for travel, hotel accommodations or an
|
||||
honorarium from Black Hat, Inc.
|
||||
|
||||
10) I understand that should my talk be determined to be a vendor or sales pitch
|
||||
that I will not receive any reimbursement for travel, hotel accommodations or an
|
||||
honorarium.
|
||||
|
||||
11) I understand that should my talk be selected for the "Turbo Talks" I will
|
||||
ONLY receive entrance to the Briefings. As a "Turbo Talks" presenter, I WILL NOT
|
||||
receive a speaking honorarium or compensation for hotel or travel.
|
||||
|
||||
Yes, I, (insert primary speaker name), have read the above and understand and
|
||||
agree to the terms as detailed in the Agreement to Terms of Speaking
|
||||
Remuneration or I will forfeit my honorarium.
|
||||
|
|
Loading…
Reference in New Issue