1

I have to exploit an application and I have only the 32-bit ELF excecutable, which is also stripped. Its a suid root application and when it is executed practically run the ls -al command for a specific directory that normally is inaccessible for normal users.

Any advice about how to handle this problem?

Improve this question
8
  • what are the inputs that you control? can you effect the arguments of ls -al?
    – user23101
    Mar 2, 2018 at 11:56
  • Check for how can you influence that command, it's most likely a system() call. Environment variables and command line arguments are the candidates. However, without disassembly, it's impossible to say.
    – joxeankoret
    Mar 2, 2018 at 12:05
  • I have tried a lot of inputs with patterns but I cannot spot any influence in memory. I can show you disassembly but because of the fact that the file is stripped has no info about functions.
    – John Rewei
    Mar 2, 2018 at 12:24
  • how do you know it's exploitable?
    – Paweł Łukasik
    Mar 2, 2018 at 12:26
  • 1
    its an exercise and it says it is
    – John Rewei
    Mar 2, 2018 at 12:27

1 Answer 1

Reset to default
4

If the program is setuid, you can use the fact that it is calling the command ls -al /tmp through system() from the main() function.

  1. Create a file ls which contains:

    #!/bin/sh
/bin/sh

  2. Set it as an executable script:

    #> chmod +x ./ls

  3. Modify your PATH to point to the current directory:

    #> export PATH=.:${PATH}

  4. Run the weak software (where you have the fake ls script):

    #> /path/to/test

Just a remark, the rest of the software seems to have been obfuscated, at least by renaming the subroutines into sub_xxxx. It may also contain other obfuscations.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.