github/metasploit-framework
1
Fork 0
mirror of https://github.com/rapid7/metasploit-framework synced 2024-11-12 11:52:01 +01:00
Code Releases Activity
a0adc4bde5
metasploit-framework/dev/bh/submission_form.txt
Matt Miller 993573dcce minor typos 
git-svn-id: file:///home/svn/incoming/trunk@2473 4d416f70-5f16-0410-b530-b9f4589650da
2005-04-23 05:16:42 +00:00

674 lines
28 KiB
Plaintext
Raw Blame History

Date of Submission:
04/2005
I would like to present this at:
USA 2005
Personal Information
Primary Speaker Name:
spoonm
Primary Speaker Title (if applicable):
Additional Speaker Name(s), Title(s) and Company(s) (if applicable):
skape
Speaking on Behalf of:
Primary Contact's Email:
spoonm@gmail.com
Primary Contact's Telephone:
Speaker's Email (if different from the primary speaker's email):
Speaker's Telephone (if different from the primary speaker's telephone):
Has the speaker spoken at a previous Black Hat event? Yes or No
Yes
Does the speaker have any professional speaking experience? Yes or No
Yes
If yes, please list the three most recent engagements.
- cansecwest 2005
- defcon 2004
- blackhat 2004
Has or will this presentation be seen in any form? If so, explain how this
presentation is different from previous versions, and where/when this material
has been seen before.
No
Will or has the speaker(s) be presenting at ANY event 30 days prior to this
conference? If yes, please specify which event and on what topic(s).
No
Presentation Information
Name of Presentation:
- Beyond EIP
Select the track(s) that your talk would be most appropriate for your topic (you
must select at least one of the nine):
- Deep Knowledge
- 0 Day Attack
How much time does your presentation require? 75 minutes, 90 minutes or 20
minutes (turbo track) (please specify)
90 minutes (could do 75 if necessary)
What are the three most important reasons why this is a quality Black Hat talk?
Reason 1:
Although we continue to publicly release much of our work, there is much
more involved under the hood than just what's released. Blackhat is the
perfect venue to discuss our ideas, research, design, and development in
detail. It's really important to be able to discuss the sort of things we've
thought very hard about and to present the conclusions that would otherwise
be taken for granted.
Reason 2:
The technology discussed in this presentation impacts a wide number of
security related fields including NIDS, HIPS, Anti-Virus, penetration
testing, and the exploit development cycle in general.
Reason 3:
Many of the audience members can't be fully engaged in the deep world of
security research. This is a chance for them to get a "view from the
trenches", and see what's actually happening on the attacker security front.
Audience members will get an idea of where technologies currently stand, how
they work, and what might be in store for the future.
Is there a demonstration? Yes or No
Yes
Are the speaker(s) releasing a new tool? Yes or No
Possibly, or will talk about many recent (within a year) releases.
Are the speaker(s) releasing a new exploit? Yes or No
No
Is there audience participation? Yes or No
No
What are your equipment needs?
1 projector.
Will you require more than 2 lcd projectors? Yes or No - if yes, please specify
how many
No
Will you require internet access? Yes or No
No
Will you require a white board? Yes or No
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:
When we built Metasploit, our focus was on the exploit development process. We
tried to design a system that helped create reliable and robust exploits. While
this is obviously very important, it's only the first step in the process. What
do you do once you own EIP? Our presentation will concentrate on the recent
advancements in shellcode, IDS/firewall evasion, and post-exploitation systems.
We will discuss the design and implementation of the technologies that enable
complex payloads, such as VNC injection, and the suite of tools we've built upon
them. We will then present a glimpse of the next generation of Metasploit, and
how these new advances will serve as its backbone.
Blog Entry:
Blog entry, Stardate April, 2005
We have recently been on a new shellcode kick, but this time it's not about
making them smaller. We're currently working on building very powerful new
post-exploitation shellcode and toolkits, and a very powerful unified API to
expose their functionality. This will allow us to diverge from precanned
payloads, which will in turn allow users to quickly build powerful and portable
post-exploitation tools. We have built strongly upon our Windows DLL
injection, and are working on extending similar functionality to the land of
Unix. We're also working hard on the next version of Metasploit, which follows
this same philosophy of embedability and extensablity, allowing users to build
their own tools on top of our framework. Our previous work was all about exploit
frameworks. In our new approach we are really building more of a hacker tool
framework, allowing very strong automation and customization.
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 interests 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, spoonm, 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, spoonm, 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.
View Git Blame Copy Permalink