Results 1 to 8 of 8

Thread: bindshell shellcode

  1. #1
    Just burned his ISO
    Join Date
    Jul 2009
    Posts
    6

    Question bindshell shellcode

    for most of the exploits i tested on my machines i tried with different shellcodes with some help from this i have seen how calc.exe shellcode works but when i tried shellcodes for bindshell and my browser crashes.
    how do I capture the shell and create a session ?
    can you help me with that

  2. #2
    Member
    Join Date
    Jan 2010
    Posts
    81

    Default

    hi..

    I think you'r bindshell is bigger that the calc shellcode.. so you overwrite the ret adress..(and crash you Prog.)
    now you can change the NOPs or use a shellcode that is so big how your calc shellcode..

    ozzy

  3. #3
    Good friend of the forums
    Join Date
    Feb 2010
    Posts
    328

  4. #4
    Super Moderator lupin's Avatar
    Join Date
    Jan 2010
    Posts
    2,943

    Default

    Quote Originally Posted by kalyanboga View Post
    for most of the exploits i tested on my machines i tried with different shellcodes with some help from this i have seen how calc.exe shellcode works but when i tried shellcodes for bindshell and my browser crashes.
    how do I capture the shell and create a session ?
    can you help me with that
    The solution will be exploit specific. As operat0r mentioned, changing the size of the shellcode you send can affect which bytes end up overwriting EIP and potentially where the shellcode will be placed in memory. You may need to restructure the buffer you send so that the proper bytes are still placed in RET and the instruction at RET still redirects execution to where your shellcode sits in memory.

    Its also possible that the particular exploit you are using could have restricted bytes or there may not even be space to store your bind shell shellcode, in which case you will need to encode the shellcode and/or use a stager to access your shellcode.

    If you haven't done this already, you probably want to find a basic buffer overflowing guide online and spend some time working at it with a debugger so you can understand this process better.
    Capitalisation is important. It's the difference between "Helping your brother Jack off a horse" and "Helping your brother jack off a horse".

    The Forum Rules, Forum FAQ and the BackTrack Wiki... learn them, love them, live them.

  5. #5
    Just burned his ISO
    Join Date
    Jul 2009
    Posts
    6

    Default

    The exploit which i used was
    exploits/9137 from milworm Mozilla Firefox 3.5 (Font tags) Remote Buffer Overflow Exploit
    but when i tried to change the shellcode from calc.exe to shellbind the browser crashed
    i used the bindshell code from metasploit to try it later i saw a post on milworm with the appropriate bindshell code (which i havn't tested yet)
    what i wanted to do is --
    store the return address in a database and open it as a session later. can you guide me ?

  6. #6
    Super Moderator lupin's Avatar
    Join Date
    Jan 2010
    Posts
    2,943

    Default

    Quote Originally Posted by kalyanboga View Post
    what i wanted to do is --
    store the return address in a database and open it as a session later. can you guide me ?
    In the context of buffer overflow exploitation, this makes no sense at all.

    You need a bit of background knowledge about how the process works. Hence my post from earlier...

    Quote Originally Posted by lupin View Post
    If you haven't done this already, you probably want to find a basic buffer overflowing guide online and spend some time working at it with a debugger so you can understand this process better.
    Do that first.

    Once you have learned how a buffer overflow works you can come back to this problem with the required background knowledge. There are some useful links in my last post to AnActivists "Pentesting Documentation" thread, try reading those.

    Now once you do have the required knowledge - what you want to check for your particular problem is that (1) your shellcode isnt being mangled, (2) that EIP is being overwritten correctly, and (3) that EIP is being overwritten with a value that allows re-direction of code execution on your system.

    For the first, insert a breakpoint (\xcc) just before your shellcode and check memory contents in a debugger to see if all of your shellcode is making it in and that none of the characters are missing or modified. If it doesn't, you need to fix that by recoding your shellcode or using a stager shellcode.

    For the second, replace the ret address with some easily discernable value (e.g. "\x41 * 4 " or 4 'A' characters) and make sure that the program stops execution with EIP pointing to that value. If it does, change it back to the original value. If not, restructure your buffer until it does.

    For the third, check that the memory location used to overwrite EIP references an instruction that will redirect execution to wherever your shell code is in memory. If it doesnt you need to find a predictable location in memory that contains such an instruction. For example, if the shellcode is located memory at the location specified by the ESP register, find a reference to a JMP ESP opcode in one of the dlls loaded by your program. I usually do this in the debugger, but the Metasploit opcode database can also be used.
    Capitalisation is important. It's the difference between "Helping your brother Jack off a horse" and "Helping your brother jack off a horse".

    The Forum Rules, Forum FAQ and the BackTrack Wiki... learn them, love them, live them.

  7. #7
    Member
    Join Date
    Jan 2010
    Location
    The new forums
    Posts
    462

    Default

    The new remote exploit wiki has some great video links to writing shell code and buffer overflows.

    https://wiki.remote-exploit.org/back...er%20Overflows

  8. #8
    Junior Member
    Join Date
    Jan 2010
    Location
    Canada
    Posts
    84

    Default

    Think of it this way man:

    You have a buffer, it is on the stack, if vulnerable to buffer overflwos and no SE Linux or such is running (and assuming no canaries) itll look like this:

    Buffer|Possibly Other Data|EBP|EIP|

    You need to overflow this with deadly precision, of course, thats why we have NOP Sleds

    so a succesful buffer overflow will look like this:

    Buffer|Possibly Other Data|EBP|EIP|
    NOP Sled | Shellcode |Estimated place in buffer

    When the Function you are n returns it pops the local variables using a shortcut

    MOV esp,ebp

    It then pops the EBP Off the stack

    POP ebp

    and returns

    RET

    the return call looks like this on the inside:

    POP eip

    The Aim here is to have the RET pop a location off the stack that points to the NOP sled (or the shellcode)

    So taking an even simple version of the diagram up top:

    |Buffer|EBP|EIP|

    and making the buffer 40 bytes

    you will want "/x90 times (44 - sizeof(shell code))","Shellcode","estimated return address"

    (the extra four is for the not used EBP)

    Of course, 40 is an awful small buffer to try and fit a nop sled inbut thats where more advanced techniques come in. Like using a larger buffer thats not vulnerable to store the NOP's and Shellcode and use the vulnerable buffer to jump there.)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •