module04 buffer overflow

Upload: david-lay

Post on 03-Jun-2018




0 download

Embed Size (px)


  • 8/12/2019 Module04 Buffer Overflow


    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$

  • 8/12/2019 Module04 Buffer Overflow


    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$


    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 theapplication 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
  • 8/12/2019 Module04 Buffer Overflow


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


    We have the following source code written in the 0 programming language$ This code has !eenspecificall" 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 ; argvchar !uf

    printf(BCsage, Ds argumentnB3 argv

  • 8/12/2019 Module04 Buffer Overflow


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


    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$

  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    So now weHve caused a segmentation fault error when we sent /&F !"tes to the !inar"$


    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 I$ We

    open the !inar" in the de!ugger and perform the !uffer overflow again$
  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    So we see in I 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

    EJ - Extended ase Jointer 1 Joints to the !ottom of the stack

    EN3 EN3 E0N3 EN - Ieneral Jurpose 'egisters 1 Csed for storing values

    ES63 E6 - 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


    6n this scenario we will use the hardcore a specific memor" address instead of the 'ET address


    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$

    otice in the next slide we now overwrite the E6J register with four PxQ3 this is !ecause 6

    changed the string from /&& Px&/Q to /&F Px&/Q and & PxQ$ 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 I is from each column

    "ou read left to right !ut the contents of each column is read right to left$

  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    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?F to FxffffdFF 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 !insh which gives the attacker a !ash shell$x%/xcFxUFxV?x#fx#fx%xV?xV?x#fxV#xVxVex?xe%xUFxU%x?xe/x?xc#x!FxF!xcdx?F

    Final Buffer

    We need to hit the pa"load from the ver" !eginning3 !ecause of this what is generall" done is

    attackers use OJ (o 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 OJ sled

    which is +ust a series of OJ 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 OJ 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 OJ

    instructions to form a OJ 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

    OJ sled$


    R(p"thon -cHprint BxFB;//U


    FxF!xcdx?FB BxcFxd?xffxffBH)

  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    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$"out.randomi5ation

    ata Execution Jrevention (EJ) 1 What this mechanism does is it marks an area in

    memor" as non-executa!le$


    4reeS 2ails 1 This a virtualistationsand!oxing concept where a 4reeS !ased OS can !e

    split into mini-su!s"stems referred to as +ails$


    Secure 0oding 1 SL' and EJ 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


    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 previousmethod$

  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    Windows # (bility Server )*+, Stack Overflow $-e.ote



    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


    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$


    emonstration is on a Windows NJ Service Jack %

    Jrogram is !ilit" 4TJ Server version #$%&

    e!ugger !eing used is 6mmunit" e!ugger

    The username and password has alread" !een worked out to !e ftp,ftp

  • 8/12/2019 Module04 Buffer Overflow


    Fuzzing Script


    import socket

    8 0reate an arra" of !uffers3 from F to #FFF3 with increments of /FF$


  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    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 skeletonframework 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$

  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    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$ epending if the characters in the

    register is in the !ottom or top half determines which one "ou change$


    #$ 00000

    %$ 00000

    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


    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$


    usrsharemetasploit-frameworktoolspattern.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$

  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    What did we findK We found the E6J to contain FxV%#V and the ESJ is !eginning at g3 lets

    run these through pattern.offset$r! to find out where in our !uffer these locations are,

    E6J A V !"tes into the !uffer

    ESJ A ? !"tes into the !uffer


    usrsharemetasploit-frameworktoolspattern.offset$r! g

    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$

  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    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 % E 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$

  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    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 % E hosts$ 6 chose m" 27J ESJ instruction to !e FxE%U% which is

    from the CSE'%#$dll$

    We now need to generate our pa"load3 this time we have found out that we /FF !"tes to work

    with3 this is a lot of si5e in generalX So as this is a service running on a remote server3 we couldmake 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$

  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    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$

  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


  • 8/12/2019 Module04 Buffer Overflow


    Mitigation of Vulnerability

    ow 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 thevulnera!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 overwritethe 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,www$thegre"corner$com#F/FF/seh-stack-!ased-windows-!uffer-overflow$html http,en$wikipedia$orgwikiCncontrolled.format.string

    Topic Buffer Overflows

    Oll"!g (Same as 6mmunit" e!ugger except not p"thon)

    6 Jro

    6mmunit" 0anvas





    Stack Shield[algrind

    Jol"Space 0 [erifier


    Enhanced 7igitation Experience Toolkit





    0omodo 7emor" 4irewall

    0lang Static nal"5er


    0odeSonar Static nal"sis tool

    0ore 6mpact Jro
  • 8/12/2019 Module04 Buffer Overflow



    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% E machine$

    nd finall" give % recommendations for a solution to this vulnera!ilit" ranked from solution to

    recommend highl" to least$


    J07 4TJ #$F

    Sami 4TJ #$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$