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.