674 lines
28 KiB
Plaintext
674 lines
28 KiB
Plaintext
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.
|