Dream Diary - Chapter 1

can someone write hear enviroments from remote host?

Type your comment> @reisraff said:

how can I write the 0x7f ?

I couldn’t… but if you launch the exploit 50 times, you sometimes get the libc in 0x7d or 0x7e, and the the exploit works.

I’m kind of stuck on this one, can someone PM me for some hints please? I will explain my state of the challenge in private.

Type your comment> @julianjm said:

Type your comment> @reisraff said:

how can I write the 0x7f ?

I couldn’t… but if you launch the exploit 50 times, you sometimes get the libc in 0x7d or 0x7e, and the the exploit works.

libcbase=0x7efff7a0d000 ???

Type your comment> @Skajd said:

can someone write hear enviroments from remote host?

you could use this snippet to fake the production environment:

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

@reisraff said:

Type your comment> @Skajd said:

can someone write hear enviroments from remote host?

you could use this snippet to fake the production environment:

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

thanks i have perfect exploit :slight_smile: works all the time :slight_smile:

Spoil!!! 0x7F = Delete …
atoi?

I managed to get a shell, but i could not make a reliable exploit. Someone who managed to get through that 0x7f restriction, please PM me, I’m curious how could it be done.

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.

@tare05 Everything you need for these challenges can be learned from how2heap! Really nice challenges btw… wish HTB had more of these.

So I just solved this - it was my first ever heap exploit.
A really great challenge that taught me heaps!
From the flag, it seems I did it an unintended (and I think easier) way. I was going along the intended route previously, but then had a eureka moment and saw an easier option…
I’d be really interested to hear how other people solved this.
My exploit is maybe 95% reliable, and I don’t think I can do any better than that.
Anyone’s welcome to DM, especially to maybe get a fresh set of eyes on a problem!

Hello i tried to pwn this challange and looked similar ctf write-ups and understand behind the attack. I can trick the malloc and i can anyaddress address which i want. But i am doing these with ASLR close and i have no idea how to leak any addresses from binary cuz similar ctf problems containing print options which in this case i have not. Any help would be greateful

secret#6195 feel-free to pm on discord please

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! :wink:

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.

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 ?

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.

@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

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