Dream Diary - Chapter 1

2»

Comments

  • thats the correct os information who try to solve this challange. I solved this one but i don't like bruteforce like these challanges i hope challange makers take care of these situation. Here the correct os information i hope its help to you

    Ubuntu 16.04.2 LTS
    885acc6870b8ba98983e88e578179a2c libc-2.23.so
    885acc6870b8ba98983e88e578179a2c libc.so.6
    76cd3cc05bfdd87982ce2dea5f26a6cf ld-2.23.so

  • Type your comment> @0xcursed said:

    Finally managed to get shell on remote. For those got it locally but not remotely; Make sure libc version is correct and debug it on socat environment as @reisraff said.

    Major hint: Socat is not innocent and restricted chars can be bypassed.

    i have a local exploit working, and i can leak an address (to calculate another) and the address of my payload, but i can't write certain chars. any hints on how to bypass the restricted chars? PM me

  • just got it. you don't have to bypass anything, just don't use them! ;)

  • Type your comment> @dreamertr said:

    thats the correct os information who try to solve this challange. I solved this one but i don't like bruteforce like these challanges i hope challange makers take care of these situation. Here the correct os information i hope its help to you

    Ubuntu 16.04.2 LTS
    885acc6870b8ba98983e88e578179a2c libc-2.23.so
    885acc6870b8ba98983e88e578179a2c libc.so.6
    76cd3cc05bfdd87982ce2dea5f26a6cf ld-2.23.so

    Where can I find the exact libc version? I installed Ubutu 16.04.2 TLS but when I execute md5sum I got a different hash.
    I have downloaded several versions of libc-2.23.so and I get different addresses for one_gadget. I think HTB should provide the lib with this kind of challenges.

  • edited December 2019

    Hope it's not spoiler. It took me a while to find the correct libc
    The correct package version for it is: libc-bin_2.23-0ubuntu9_amd64
    It can also be found inside ubuntu-16.04.3-server-amd64.iso (That's how I found it)

    I'm not sure if the author reads the posts (couldn't find him in the list of users), but
    I would provide exact libc package version unless you expect people to bruteforce
    with all release libraries (currently Xerus Xenial doesn't list this libc as option in apt list -a libc-bin)

  • any clue to get arbitrary write-what-where ?

  • edited April 8

    Hi all
    What simplest way crate local environment with libc-bin_2.23-0ubuntu9_amd64?
    Chroot? All vagrants box have more newer libc at now.

  • edited April 8

    @fr0ster
    Ok doing all of these challenges (and some of the boxes) requires a lot of LibC changes. The best "environment" I've been able to find that allows me to work on pwn's as well as systems like rope is this:

    Tools

    https://github.com/skysider/pwndocker
    This is a docker that you can spin up on any docker supported system. This docker has most of the tools needed for stack/heap exploit. Follow the instructions but in the run script you'll see the -v $(pwd)/${ctf_name} option set. This will link a local directory (in this case your current working directory and whatever name you give it) to the docker.
    For example. I've created a pwndocker.sh that contains the following:


          docker run -d \
              --rm \
              -h pwn \
              --name pwn \
              -v /home/gridith/challenges/pwn/docker:/ctf/work \
              -p 23946:23946 \
              --cap-add=SYS_PTRACE \
              skysider/pwndocker
    

    So any boxes, challenges I'm working on I make sure to create a subdirectory under /home/gridith/challenges/pwn/docker. Then they will show up inside the docker under /ctf/work
    Next is how to use this environment now that its "spun up". Easiest way to work with this is to have two or three terminals into the docker and to modify any pwntools scripts to allow for gdb to work. To do this I've created another bash script file (simple one) called pwnshell.sh


                    docker exec -it pwn /bin/bash
    

    All this does is get you to the bash prompt on the pwn docker. I typically have two terminal windows up and in each I've run the above script so I'm at the pwn docker bash prompt.
    Now once there in one window you can work on your pwntools script and in the other window you will load GDB.

    Configuring The Docker

    The docker contains a /glibc directory. In here you'll find most of the common glibc compiled bins. so, for example, if you need to work with 2.27. You can have your pwntools script reference:
    /glibc/2.27/64/lib/ld-2.27.so
    But follow the directions on the github page. They show two ways to refernce libc. One is by copying it around to say the tmp dir and the other is to use pwntools ability to force load environments. Either way works. Dont forget to patch the elf if needed as well to make sure its using the proper libc.

    Debugging

    In one of your terminal windows run tmux (no parameters just tmux). In the other you will run your scripts. If you're using pwntools I add this to all my scripts


                if args.GDB:
                        context.terminal = ['tmux', 'new-window']
                        heapEXE = process('./someELF')
                        debugger = gdb.attach(heapEXE, '''
                        break * 0x4011123
                        c
                        ''')
    

    Now when I run the script I can just add GDB to the args to force gdb to open, set break points, and automatically continue.


          python pwnHeapEXE.py GDB
    

    because tmux is running in the other terminal window that is where GDB will load and auto attach to your process. You can step through and when you're ready quit GDB, make changes to your script and run again.

    Vi is not my editor of choice so I typically have a third terminal window open and have nano up editing my script as the docker doesn't contain nano.

    Hopefully this was helpful. This is at least he process I've used on almost all of the HTB challenges and boxes that involve Heap for sure and some that are Stack popping.

    Gridith

  • @Gridith thanks, it’s very useful information
  • edited April 13
    I try use socat for execute chapter1 and when I connect to local host by pwn tools that r.recv() get string with "\n" string separator but from docker.hackthebox.eu I get string with "\r\n". How can I have same behavior on local host? How I should configured socat?
  • edited April 13

    @reisraff said:

    you could use this snippet to fake the production environment:

    #!/bin/sh
    socat TCP4-LISTEN:9000,reuseaddr,fork EXEC:/root/chapter1,pty,stderr
    

    Thank @reisraff for tips about socat starting way, I reread topic and find him post

  • Oh no my old Ubuntu has updated.... Is the real box also updated? And where to find an article to pass the pty (0x7f) thing?

  • Type your comment> @gh0stm5n said:
    > Oh no my old Ubuntu has updated.... Is the real box also updated? And where to find an article to pass the pty (0x7f) thing?

    I think you won’t need to pass 0x7f at all if you use function that different from some function in GOT by low byte only.

    I’ve not tried it yet but I’m gonna try it tomorrow with one_gadget parameters —near.
  • It is a good idea, but I think the character 0x0d is also written....

  • Type your comment> @gh0stm5n said:
    > It is a good idea, but I think the character 0x0d is also written....

    I don't try but I read about writing address for several steps
    It was some like it
    address1: AAAA
    address2: BBBB
    address3: CCCC
    address4: DDDD
    And you have ABCD it right place
    I read it in James C Foster book in chapter about formatting string
  • edited April 14

    I have tow problem:
    1) when I exploiting on local host, I get libc_base but execve raises dump because I don't have system with libc-2.23
    2)when I exploiting on remote host I cant get libc_base :(

    Can somebody give any tips about way of getting libc_base on remote_host?
    It really socat breaks all but I while don't know how it pass.
    If somebody give any tips abowt socat passing I'll be very grateful

  • Can anyone confirm that libc-bin_2.23-0ubuntu9_amd64 (885acc6870b8ba98983e88e578179a2c libc-2.23.so) is still valid for this challenge.

  • I downloaded glibc from other PWN challenge and it precisionally this version.
    885acc6870b8ba98983e88e578179a2c lib/libc-2.23.so
    I think here one version of glibc for all challenge but surprises coming.

  • I feel problem has relation to PTY parameters in socat command line, they doesn't return printf out with leaked address. But I until don't know right way to pass it.

  • Found writeup of babyfs which helped me. The version glibc is still the same: 885acc6870b8ba98983e88e578179a2c libc-2.23.so

  • edited April 16

    I’ve done it.
    It’s really difficult and interesting challenge.
    Thanks @gh0stm5n for tips.

  • Done & Dusted!

    Yes its a hard challenge! but once you've cracked it, you'd have learnt to try different heap exploits, see them fail and have greater understanding of their "requirements" for the exploit to fully work. Eventually you tweak something and bingo you have write! but then ALSR is waiting for you..... The pain / study was worth it !!

    Wx

  • After spending 2 hours trying to set up the environment, I can attest that the least painless method is to just set up a Xenial Xerus Docker container with socat to connect out. I was able to just switch the hostnames when my exploit was done, much easier than fiddling with LD_PRELOAD etc.

    clubby789

    • GCIH
      If you need help with something, PM me how far you've got already, what you've tried etc (I won't respond to profile comments, or on box release night). And remember to +respect me if I helped you ; )
Sign In to comment.