Safe

Again, we start with nmap -sC -sV -p- -Pn -oA ./Safe 10.10.10.147

We start with SSH and Apache.  There's a "waste?" port on 1337 as well.  Looking at the Apache page, it looks like the default page, but check the source code on it anyway.  Somebody was sneaky and points us to that 1337 page.

Someone set a binary download and an "echo" page.  Let's check out the binary first.  Running file on it shows us that it is an ELF executable.  That usually means reverse engineering or buffer overflow.  Did I mention I suck and despise reverse engineering and buffer overflow?  Really all things assembly?  Let's see if GDB can do anything with it and list out the functions and any binary protections.

OK. So we're dealing with an ELF that imports system() and gets() and of course main is primary drop in point with an additional test function.  We can also see with checksec that No Execute is set.  We need to bypass that.  The only way that I know to bypass that is to use Return Object Programming (ROP) chains.  We need to know what the buffer size is in the register so we can build our ROP chain.  So, in gdb use disassemble main.

It looks like the buffer is 0x70 bytes loaded into rax and then kicked over into rdi.  It looks like we can overflow it with really anything over 112 (0x70) bytes, but will it be enough.  The answer to that is no.  We need to kick it up to 120 bytes in order to try and control the [rip+0xe9e] above. So, we add some B's.  Instant seg fault.

Let's see what the test function looks like.

It looks like test() moves rdp to rdi and jumps to whatever address exists in r13.  That means we should be able to set r13 as system() and use that to run system commands.  To do that, we need to find the pop r13 call that moves the top of the stack into the right register.  It took a minute to find (and I'm sure there are easier ways to do it and if you know any drop me a message) but I finally found pop r13 in the __libc_csu_init function at 0x0401206.

Awesome.  Time to break out some pwntools to build the ROP chain.

Now we can run the scriot, output the chain to a file, and feed that file into the ELF.  It of course throws another seg fault, but we see that system() is called at r13 like it should be.

We can add the right pointer into the script by adding:

system = p64(0x40116e)
binsh = "/bin/sh\x00"

'''
0x0000000000401156 <+4>: mov rdi,rsp
0x0000000000401159 <+7>: jmp r13
'''

test = p64(0x401156)

chain = buf + pop_r13_garbage + system + "BBBBBBBB" + "CCCCCCCC" + test + binsh

Run the script again, outputting it to a file.  We need to test it locally to see if it works.  To do that, we run:

$ (cat rop ; cat) | ./myapp

and whaddya know, shell works locally.  Let's add a remoting line to the script (final script in the Explotation node to the CTB file) and run it. Foothold shell and remote works too.

This shell is EXTREMELY limited.  One thing I can do though, is create a public key on my attacking machine (which I already have) and copy it over to the target using echo. 

echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDOTqkT+Qm51ei <REDACTED> kali@kali' >> authorized_keys

Then, we can ssh user@10.10.10.147 with the passphrase for our key and have a better shell.

Now that we have a somewhat better shell, we can see what is in the user folder and (more importantly) SCP those files over to our machine. 

Now that we have them on our machine, we can quickly look at them to see what they are.  Obviously, the .kdbx file is a KeePass database and user.txt is the user flag, but what is in the JPGs?  They seem to be just pictures, but that doesn't mean there's not more to them.  When we did BigHead (retired May 2019), we used an image as a keyfile to crack the database.  This is probably a similar situation.  With there being 6 JPGs, let's write a short script to do it for us (hackers are lazy creatures, remember).

So now we have the hashes of the files.  Let's see if we can crack them with John and our trusty rockyou.txt list.

john --fork=4 -w=/usr/share/wordlists/rockyou.txt hashes

We do find a password!  The password is literally "bullshit"...... No comment. So we know one of those JPGs is the keyfile, but which one?  To find that out, we can use kpcli.  If you don't have kpcli, you can get it with "sudo apt-get install kpcli -y and you'll be set.  Again, there are 6 images. So, instead of trying each on individually, let's write a script that will do it for us.

Now that we have the keyfile, we can use kpcli to open the DB using:

kpcli --kdb MyPasswords.kdbx --key IMG_0547.JPG

and using the "bullshit" password.  From there, ls the Groups, change into the MyPasswords Group, and show the root password. 

From here, we go back to the ssh terminal that we had earlier and su to root with that password.  Grab your flags and you're done.  For some reason, Another One Bites the Dust - Queen is running through my head right now.

©2020 Phoenix Computing Solutions | Powered by Coffee, Sarcasm, and Insanity
  Everything included in the site is the intellectual property of Chris Ruggieri (Neocount Phoenix) and Phoenix Computing Solutions.
  This information should not be construed as legal advice. The owner can not be held liable for anything another entity does with this information.
  This information is solely the opinions and experiences of myself (Chris Ruggieri) and should not be construed as endorsement of any product, service, or of illegal activity

(GET WRITTEN PERMISSION PEOPLE!!)
  Any links I provide as a convenience and for informational purposes only; they do not constitute an endorsement or an approval by the owner of this site for any of the products, services or opinions of the corporation or organization or individual.
  Contact the external sites for answers to questions regarding its content.
  This Includes any links posted by Chris Ruggieri in any other websites, Social Media networks, Online Groups and Online sharing Websites.