metasploit-framework/dev/csw05/csw05.tex

870 lines
24 KiB
TeX

% $Header$
\documentclass{beamer}
\usepackage{graphicx}
\usepackage{color}
\usepackage{comment}
\mode<presentation>
{
% \usetheme{}
% or ...
% \usecolortheme{seahorse}
% \usecolortheme{crane}
% \useinnertheme{inmargin}
% \setbeamercovered{transparent}
% or whatever (possibly just delete it)
}
\usepackage[english]{babel}
\usepackage[latin1]{inputenc}
\usepackage{times}
\usepackage[T1]{fontenc}
% \usepackage{beamerthemeshadow}
% Love from spoon
\newcommand{\pdfpart}[1]{\label{pdfpart-#1}\pdfbookmark[0]{#1}{pdfpart-#1}\part{#1}}
\newenvironment{sitemize}{\vspace{1mm}\begin{itemize}\itemsep 4pt\small}{\end{itemize}}
% Presentation meta-information
\title{Advances in Exploit Technology}
\author[hdm \& spoonm] {hdm \& spoonm}
\date[CSW 2005] {CanSecWest, 2005}
\subject{Advances in Exploit Technology}
% Add a spacer between each part
\AtBeginPart{\frame{\partpage}}
% Turn off the navigation on the bottom yo
\setbeamertemplate{navigation symbols}{}
% Kick this sucker open
\begin{document}
% Throw down the title
\begin{frame}
\titlepage
\end{frame}
%--------------------------------------%
\pdfpart{Introduction}
%--------------------------------------%
\section{Who are we?}
\begin{frame}
\frametitle{Who are we?}
\begin{sitemize}
\item spoonm
\begin{sitemize}
\item Full-time student at a Canadian university
\item Metasploit developer since late 2003
\end{sitemize}
\end{itemize}
\begin{itemize}
\item H D Moore
\begin{sitemize}
\item Full-time employee at a network security firm
\item Metasploit project founder and developer
\end{sitemize}
\end{sitemize}
\end{frame}
\section{What is Metasploit?}
\begin{frame}
\frametitle{What is Metasploit?}
\begin{sitemize}
\item Research project with 8 members
\begin{sitemize}
\item Focused on improving the state of security
\item Provide information and tools for researchers
\item Resource for IDS and security tool vendors
\end{sitemize}
\end{sitemize}
\begin{sitemize}
\item Created the Metasploit Framework
\begin{sitemize}
\item Open-source exploit dev platform
\item Includes 60 exploits and 70 payloads
\item Implements ideas from everywhere
\item Currently four primary developers
\item Handful of external contributors
\end{sitemize}
\end{sitemize}
\end{frame}
\section{What is this about?}
\begin{frame}
\frametitle{What is this about?}
\begin{sitemize}
\item Recent advances in exploit technology
\item Exploit development trends and XP SP2
\item New and upcoming post-exploitation techniques
\item Improving the randomness of attack data
\item Metasploit Framework 3.0 architecture
\end{sitemize}
\end{frame}
%--------------------------------------%
\pdfpart{Windows Exploitation}
%--------------------------------------%
\section{Exploit Trends}
\begin{frame}
\frametitle{Exploit Trends}
\begin{sitemize}
\item Public Windows exploits are still terrible...
\begin{sitemize}
\item Tons of ugly, inflexible, hardcoded crap
\item Demonstrate no knowledge of underlying flaw
\item Rarely use information leakage for system targetting
\end{sitemize}
\end{sitemize}
\pause
\begin{sitemize}
\item ...but they have improved over the last year!
\begin{sitemize}
\item More exploits are supporting multiple payloads
\item Return addresses are more reliable
\item Payloads are getting slightly less ghetto
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}
\frametitle{PoC Community}
\begin{sitemize}
\item The number of people capable of writing exploits is going up...
\begin{sitemize}
\item Nearly 250 PoC authors in 2004 (packetstorm, etc)
\item Win32 exploit dev information has hit critical mass
\item Exploit development training is in high demand
\end{sitemize}
\end{sitemize}
\pause
\begin{sitemize}
\item ...but the number of "hard" exploits made public is the same
\begin{sitemize}
\item People are lazy, skilled people tend to horde their code
\item Example: Microsoft ASN.1 Bit String Heap Corruption
\item Most "difficult" exploits are disclosed due to leaks
\item Win32 kernel exploits are still the domain of a few :-)
\end{sitemize}
\end{sitemize}
\end{frame}
\section{Windows XP SP2}
\begin{frame}
\frametitle{Windows XP SP2}
\begin{sitemize}
\item Microsoft's "patch of the year" for 2004
\begin{sitemize}
\item SP2 included a handful of anti-exploit changes
\item The important ones were already in 2003
\begin{sitemize}
\item Use of registered system exception handlers
\item Core services compiled with stack protection
\end{sitemize}
\item Page protection is still dependent on hardware
\end{sitemize}
\end{sitemize}
\pause
\begin{sitemize}
\item Most of the SP2 changes can be avoided
\begin{sitemize}
\item David Litchfield demonstrated SEH exploitation
\item Matt Conover continues to dismantle the heap
\item Third-party applications basically unaffected
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}
\frametitle{Metasploit and SP2}
\begin{sitemize}
\item Exploit development barely affected by SP2
\item A handful of XP SP2 and 2003 SEH return addresses
\item Third-parties are not using Visual Studio 7
\begin{sitemize}
\item Most commercial applications do not use /GS
\item Have yet to see one that uses Registered SEH
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{comment}
%--------------------------------------%
\pdfpart{Mac OS X Exploitation}
%--------------------------------------%
\section{PowerPC Processor}
\begin{frame}
\frametitle{PowerPC Contraints}
\begin{sitemize}
\item Mac OS X runs on the PowerPC processor
\begin{sitemize}
\item PowerPC uses fixed-width 32-bit instructions
\item Data and instruction caches are independent
\item The instruction cache runs in "incoherent" mode
\end{sitemize}
\pause
\item Stack overflows need to return twice to be exploitable
\item (Similar to exploits on SPARCs, etc)
\end{sitemize}
\end{frame}
\section{Exploits are annoying}
\begin{frame}
\frametitle{Exploits are annoying }
\begin{sitemize}
\item Double-return means having to patch other pointers
\item Code which calls \_exit before sometimes unexploitable
\item Shellcode must be placed into location not in i-cache
\item Exploits can have different results between diff CPUs
\end{sitemize}
\end{frame}
\section{Shellcode issues}
\begin{frame}
\frametitle{Shellcode issues }
\begin{sitemize}
\item Double-return means having to patch other pointers
\item Shellcode must be placed into location not in i-cache
\item Exploits can have different results between diff CPUs
\end{sitemize}
\end{frame}
\end{comment}
%--------------------------------------%
\pdfpart{Return Addresses}
%--------------------------------------%
\section{Reliability}
\begin{frame}
\frametitle{Return Address Reliability}
\begin{sitemize}
\item An exploit is only as good as the return address it uses
\item Many vulnerabilities only allow one exploit attempt
\item Returning directly to shellcode is not always possible
\begin{sitemize}
\item Most Windows exploits use a "bounce" address
\item Indirect returns are useful on other platforms as well
\end{sitemize}
\end{sitemize}
\end{frame}
\section{Windows Addresses}
\begin{frame}
\frametitle{Windows Return Addresses}
\begin{sitemize}
\item Windows stack addresses are usually not predictable
\item Executable and library addresses {\em are} predictable
\begin{sitemize}
\item System libraries are often static between patch levels
\item Application libraries change even less frequently
\item Executable addresses only change between app versions
\end{sitemize}
\end{sitemize}
\begin{sitemize}
\item Static system libraries can go a long way...
\pause
\item A great example is the "ws2help.dll" library:
\begin{sitemize}
\item Static across all versions of Windows 2000
\item Static across Windows XP SP0 and SP1
\item Used in dozens of exploits in the Framework
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}[fragile]
\frametitle{The Magic SEH}
\begin{sitemize}
\item Stack overflows rarely exploit return address overwrites
\item Overwriting the structured exception handler (SEH) is easier
\item The first exception causes smashed SEH to be called
\item SEH frame can exist before or after the return address
\end{sitemize}
{\footnotesize
\begin{verbatim}
/* Struction Exception Handler */
typedef struct _EXCEPTION_REGISTRATION
{
struct _EXCEPTION_REGISTRATION* prev;
PEXCEPTION_HANDLER handler;
} EXCEPTION_REGISTRATION, *PEXCEPTION_REGISTRATION;
\end{verbatim}
}
\end{frame}
\begin{frame}[fragile]
\frametitle{The Magic SEH}
\begin{sitemize}
\item Overwrite the frame, trigger exception, got EIP :-)
\item The prototype for the SEH function is:
\end{sitemize}
{\footnotesize
\begin{verbatim}
EXCEPTION_DISPOSITION
__cdecl _except_handler(
struct _EXCEPTION_RECORD *ExceptionRecord,
void * EstablisherFrame,
struct _CONTEXT *ContextRecord,
void * DispatcherContext );
\end{verbatim}
}
\pause
\begin{sitemize}
\item \texttt{EstablisherFrame} points 4 bytes before handler address
\pause
\item Passed to exeception handler function \texttt{[esp+8]}
\pause
\item Return back to code via \texttt{pop reg, pop reg, ret}
\pause
\item The pop + pop + ret combination is easy to find in memory
\pause
\item Registered SEH and Windows XP/2003 limit this type of abuse
\end{sitemize}
\end{frame}
\section{Unix Addresses}
\begin{frame}
\frametitle{Unix Return Addresses}
\begin{sitemize}
\item Linux and BSD
\begin{sitemize}
\item Library addresses are usually not predictable
\item Every executable has a static load address
\begin{sitemize}
\item Every distribution has compiled its own executable
\item Exploits must target specific versions and operating systems
\item Commercial (binary-only) applications are mostly static
\end{sitemize}
\end{sitemize}
\end{sitemize}
\pause
\begin{sitemize}
\item Commercial Unix
\begin{sitemize}
\item Library addresses are sometimes predictable
\item Every executable has a static load address
\begin{sitemize}
\item These addresses are static per package version
\item Windows-style return addresses work well
\item This includes Mac OS X, Solaris, HP-UX, AIX, etc
\end{sitemize}
\end{sitemize}
\end{sitemize}
\end{frame}
\section{Analysis Tools}
\begin{frame}
\frametitle{Analysis Methods}
\begin{sitemize}
\item Finding solid return addresses involves a few steps
\begin{sitemize}
\item Load the executable or library into memory
\item Determine all permutations of the desired opcode
\item Search memory contents to find these bytes
\item Determine the virtual address for each offset
\end{sitemize}
\end{sitemize}
\pause
\begin{sitemize}
\item Many people use a debugger to accomplish this task
\begin{sitemize}
\item This is a tedious process to do manually
\item Limited to one version at a time, even with a plugin
\item Requires the installation of each tested version
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}
\frametitle{msfpescan}
\begin{sitemize}
\item msfpescan - a utility included in the Metasploit Framework
\begin{sitemize}
\item Can analyze any PE executable or DLL in offline mode
\item Simple to automate and cross-reference results
\item Does not require a Windows system to run
\item Easily analyze multiple versions on the command line
\item Capable of dumping other information as well
\begin{sitemize}
\item Imports, Exports, and IAT addresses
\item Resource information, internal versions
\item Standard PE header information
\end{sitemize}
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}[fragile]
\frametitle{Using msfpescan to find addresses}
\begin{sitemize}
\item Install the Metasploit Framework (2.3 or newer)
\item Place your target executable or DLL into some directory
\item Use msfpescan to quickly find return addresses:
\end{sitemize}
{\footnotesize
\begin{verbatim}
# Locate any form of pop/pop/ret opcodes
$ msfpescan -f mod_oiplus.dll -s
0x1001413c esi edi ret
0x10009ea2 esi ecx ret
0x100113bd esi ebx ret
# Locate any opcodes that take us to [eax]
$ msfpescan -f mod_oiplus.dll -j eax
0x1000969d push eax
0x100141a3 jmp eax
0x10010e69 call eax
\end{verbatim}
}
\end{frame}
\begin{frame}
\frametitle{Opcode Databases}
\begin{sitemize}
\item Contains opcodes across every executable and DLL in Windows
\item The new version includes over nine million records
\item Data is generated directly from the files themselves
\item Quickly cross-reference return addresses over the entire DB
\item Publicly available from http://www.metasploit.com/
\end{sitemize}
\end{frame}
\begin{frame}
\frametitle{Future Development}
\begin{sitemize}
\item Context-aware return address discovery
\begin{sitemize}
\item Demonstrated by eEye at Black Hat 2004
\item Similar project in development from Metasploit
\end{sitemize}
\end{sitemize}
\pause
\begin{sitemize}
\item Executable analysis tools for Solaris, Mac OS X, Linux, BSD
\begin{sitemize}
\item Usefulness limited compared to Windows platform
\item Static libraries are great for cross-version exploits
\end{sitemize}
\end{sitemize}
\end{frame}
%--------------------------------------%
\pdfpart{Post-Exploitation}
%--------------------------------------%
\section{Windows Payloads}
\begin{frame}
\frametitle{The Meterpreter}
\begin{sitemize}
\item Windows version uses in-memory DLL injection techniques
\item Dynamically extensible over the network
\item Extensions are standard Windows DLLs
\item Loading an extension updates available commands
\item Support for network encryption
\item Huge feature set in the public version
\begin{sitemize}
\item Upload, download, and list files
\item List, create, and kill processes
\item Spawn "channelized" commands in the background
\item Create port forwarding channels to pivot attacks
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}
\frametitle{Ordinal-based Payload Stagers}
\begin{sitemize}
\item Techniques borrowed from Oded's lightning talk from core04
\item 92 bytes and works on every Windows OS and SP
\item Staging system can chain any other Windows payload
\item Implementation also has a few size reductions:
\begin{sitemize}
\item Optimized module walked finds ws2\_32.dll
\item Functions are loaded from base + ordinal offset
\item Chained calls return to the next function
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}
\frametitle{PassiveX}
\begin{sitemize}
\item Payload modifies registry and launches IE
\item IE loads custom ActiveX control to stage the payload
\item Communications channel is via HTTP requests
\begin{sitemize}
\item Uses standard IE proxy and auth settings
\item Useful on heavily firewalled DMZ hosts
\item Providers bi-directional channel for next stage
\end{sitemize}
\end{sitemize}
\begin{sitemize}
\item Can be used to inject VNC, Meterpreter, etc
\item Fully-functional and part of version 2.4
\end{sitemize}
\end{frame}
\section{Unix Payloads}
\begin{frame}
\frametitle{Other Network Stagers}
\begin{sitemize}
\item UDP-based stager and network shell for Linux
\item UDP-based DNS request staging system
\begin{sitemize}
\item UDP shell depends on the bash --noediting option
\item Can pass through strict firewall rulesets
\end{sitemize}
\end{sitemize}
\begin{sitemize}
\item ICMP-based listener and "reverse" payloads
\item Findsock stagers being replaced by "findrecvtag"
\item Source code included in Metasploit Framework
\end{sitemize}
\end{frame}
%--------------------------------------%
\pdfpart{Improving Attack Randomness}
%--------------------------------------%
%\begin{frame}
% \frametitle{Outline}
% \tableofcontents
%\end{frame}
\section{Introduction}
\begin{frame}
\frametitle{Introduction}
\begin{sitemize}
\item Randomness, who cares?
\begin{sitemize}
\item Make IDS analysts work for their paycheck
\item Uncover flaws in your exploit code
\end{sitemize}
\pause
\end{sitemize}
\begin{sitemize}
\item Adding randomness to exploit code
\begin{sitemize}
\item Modify attacks by setting protocol options
\item Randmomize all padding and non-critical data
\item Helper functions for different types of random data
\end{sitemize}
\pause
\end{sitemize}
\begin{sitemize}
\item Adding randomness to machine code
\begin{sitemize}
\item Avoid "static" payload encoding systems
\item Substitute like instructions and reorder tasks
\item Randomize nop sleds and any other opcode fills
\end{sitemize}
\end{sitemize}
\end{frame}
\section{Conservative Polymorphism}
\newcommand{\incshi}[1]{\includegraphics[height=3in]{#1}}
\begin{frame}
\frametitle{Dynamic Payload Decoder}
\only<9>{\incshi{shi8}}
\only<8>{\incshi{shi7}}
\only<7>{\incshi{shi6}}
\only<6>{\incshi{shi5}}
\only<5>{\incshi{shi4}}
\only<4>{\incshi{shi3}}
\only<3>{\incshi{shi2}}
\only<2>{\incshi{shi1}}
\only<1>{\incshi{shi0}}
\end{frame}
\section{Building a Nop Sled}
\subsection{Tekneek}
\begin{frame}
\frametitle{Multibyte Nop Sled Concept}
\begin{sitemize}
\item Optyx released multibyte nop generator at Interz0ne 1
\item Generates instructions 1 to 6 bytes long, and uses 0x66 prefix
\item Aligned to 1 byte, land anywhere, end up the final target
\end{sitemize}
\begin{sitemize}
\pause
\item Builds the sled from back to front
\item Loops through size, prepending byte at a time
\item Generates a random byte and checks against tables
\pause
\begin{sitemize}
\item Is the instruction length too long?
\item Is it a valid instruction?
\item Does it have any bad bytes?
\item Does it modify restricted registers?
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}[fragile]
\frametitle{Backwardz}
{\footnotesize
\begin{semiverbatim}
\textbf<11>{bb} \textbf<10,11>{b0} \textbf<9,10,11>{bf} \textbf<8,9,11>{2c} \textbf<7,8,9,11>{b6} \textbf<6,7,9>{27} \textbf<5,9>{67} \textbf<4,5>{2F} \textbf<3>{4A} \textbf<2>{1b} \textbf<1,2>{f9} --- shellcode
| | | | | | | | | | | \textbf<1>{... stc}
| | | | | | | | | |____^ \textbf<2>{. sbb edi,ecx}
| | | | | | | | | \textbf<3>{......... dec edx}
| | | | | | | | \textbf<4>{............ das}
| | | | | | |____^ \textbf<5>{.......... a16 das}
| | | | | | \textbf<6>{.................. daa}
| | | | |____^ \textbf<7>{................ mov dh, 0x27}
| | | |____^ \textbf<8>{................... sub al, 0xb6}
| | |_____________^ \textbf<9>{............. mov edi, 0x6727b62c}
| |____^ \textbf<10>{......................... mov al, 0xbf}
|_____________^ \textbf<11>{................... mov ebx, 0xb62cbfb0}
\end{semiverbatim}
}
\end{frame}
\subsection{Implementation}
\begin{frame}[fragile]
\frametitle{OptyNop2 Output}
{\footnotesize
\begin{verbatim}
$ ./waka 1000 4 5 | ndisasm -u - | head -700 | tail -20
000003B6 05419F40D4 add eax,0xd4409f41
000003BB 711C jno 0x3d9
000003BD 9B wait
000003BE 2C98 sub al,0x98
000003C0 37 aaa
000003C1 24A8 and al,0xa8
000003C3 27 daa
000003C4 E00D loopne 0x3d3
000003C6 6692 xchg ax,dx
000003C8 2F das
000003C9 49 dec ecx
000003CA B34A mov bl,0x4a
000003CC F5 cmc
000003CD BA4B257715 mov edx,0x1577254b
000003D2 700C jo 0x3e0
000003D4 C0D6B0 rcl dh,0xb0
000003D7 A9FD469342 test eax,0x429346fd
000003DC 67BBB191B23D a16 mov ebx,0x3db291b1
000003E2 1D9938FCB6 sbb eax,0xb6fc3899
000003E7 43 inc ebx
\end{verbatim}
}
\end{frame}
\subsection{Analysis}
\begin{frame}[fragile]
\frametitle{ADMmutate and optyx-mutate Gzip'd}
{\footnotesize
\begin{verbatim}
# ADMmutate
$ time ./nops 1000000| gzip -v >/dev/null
27.3%
real 0m0.241s
# optyx's interz0ne mutate
$ time ./driver nop 1000000 | gzip -v >/dev/null
29.7%
real 0m0.467s
\end{verbatim}
}
\end{frame}
\begin{frame}[fragile]
\frametitle{OptyNop2 Gzip'd}
{\footnotesize
\begin{verbatim}
# C version, save ESP and EBP
$ time ./waka 1000000 4 5 | gzip -v >/dev/null
12.2%
real 0m11.900s
# save just ESP
$ time ./waka 1000000 4 | gzip -v >/dev/null
11.7%
real 0m11.277s
# save nothing (good way to crash process)
$ time ./waka 1000000 | gzip -v >/dev/null
8.3%
real 0m12.404s
\end{verbatim}
}
\end{frame}
\begin{frame}[fragile]
\frametitle{ADMmutate Distribution - 1}
\include{admtable}
\end{frame}
\begin{frame}[fragile]
\frametitle{ADMmutate Distribution - 2}
\include{admtable2}
\end{frame}
\begin{frame}[fragile]
\frametitle{OptyNop2 Distribution - 1}
\include{optytable}
\end{frame}
\begin{frame}[fragile]
\frametitle{OptyNop2 Distribution - 2}
\include{optytable2}
\end{frame}
\subsection{Conclusion}
\begin{frame}
\frametitle{Benefits}
\begin{sitemize}
\item Not very difficult to gain lots more randomness
\item NIDS vendors are still far, far, behind
\item Handles restricted bytes and registers
\item More versatile sled generation (nop stuffing, etc)
\end{sitemize}
\end{frame}
\begin{frame}
\frametitle{Possible Improvements}
\begin{sitemize}
\item Support processor flags (nop stuffing)
\item Support 2-byte opcodes and escape groups
\item Improved byte scoring systems and look-ahead
\item Output according to a given byte distribution
\item Make it faster and use less memory
\end{sitemize}
\end{frame}
%--------------------------------------%
\pdfpart{Metasploit Framework 3.0}
%--------------------------------------%
\section{Architecture of 3.0}
\begin{frame}
\frametitle{Temporarily Not in Service}
\begin{sitemize}
\item The complete presentation can be found at:
\begin{sitemize}
\item http://www.cansecwest.com/
\item http://www.metasploit.com/confs/
\end{sitemize}
\end{sitemize}
\end{frame}
%%% summary and bib has been removed %%%
\begin{comment}
\section*{Summary}
\begin{frame}
\frametitle<presentation>{Summary}
% Keep the summary *very short*.
\begin{sitemize}
\item
The \alert{first main message} of your talk in one or two lines.
\item
The \alert{second main message} of your talk in one or two lines.
\item
Perhaps a \alert{third message}, but not more than that.
\end{sitemize}
% The following outlook is optional.
\vskip0pt plus.5fill
\begin{sitemize}
\item
Outlook
\begin{sitemize}
\item
Something you haven't solved.
\item
Something else you haven't solved.
\end{sitemize}
\end{sitemize}
\end{frame}
% All of the following is optional and typically not needed.
\appendix
\section<presentation>*{\appendixname}
\subsection<presentation>*{Materials}
\begin{frame}[allowframebreaks]
\frametitle<presentation>{Materials}
\begin{thebibliography}{10}
\beamertemplatebookbibitems
% Start with overview books.
\bibitem{Author1990}
A.~Author.
\newblock {\em Handbook of Everything}.
\newblock Some Press, 1990.
\beamertemplatearticlebibitems
% Followed by interesting articles. Keep the list short.
\bibitem{Someone2000}
S.~Someone.
\newblock On this and that.
\newblock {\em Journal of This and That}, 2(1):50--100,
2000.
\end{thebibliography}
\end{frame}
\end{comment}
\end{document}