Deathstar:1 Vulnhub Walkthrough

Updated: Jun 3

In this article we are going to solve a very interesting challenge DeathStar:1 a medium rated box from vulnhub.


IP of the target :

As said in the description on vulnhub website that port scanning will not take us anywhere ( but my mind said I will do nmap scan).

sudo nmap -sC -sV -Pn -p-

Okay now my mind will not interfere again :)

After some time I thought to capture the packet on the target ip address using wireshark | filter used , ip.adddr == <Target-IP>

umm this information looks very useful for us.

Protocol : UDP

message1 : DS-1@OBS


what if 1440 is the UDP Port and DS-1@OBS is something like a key or a message that we have to send .

Okay for that we used nc to connect on port 1440 and send the message "DS-1@OBS" and then saved it in a file to analyze later if we got something.

nc -u 1440 > mymsg.txt then send message DS-1@OBS

this looks like a base64 encoded text , lets decode it and again save it in new file

okay we have a image , lets open the image by changing the extension to .jpeg

This looks super cool :)

Information gained =>

[+] Hangar Bay 327

[+] Thermal Exhaust Port (2-meter-wide)

[+] code to unlock : 197719801983 , looks like some years (1977 1980 1983)

Okay with this information we got nothing even port knocking doesn't worked on "1977" , "1980" and "1983" . So now we used steghide tool to find some hidden file if we can.

steghide extract -sf newmsg.jpeg , passphrase:******* 

I have spent a lot of time in this machine , so I am not going to tell you the passphrase in just 5 minutes .

after this we found a .txt file with a message that we need to use a particular sequence to unlock the port 10110 , this clerly means port knocking , we used a python script that I found on github for port knocking and after using the correct sequence we opened the port 10110 .

okay means SSH port is open , now we can connect on port 10110 and can gain access to user shell.

information gained =>

[+] username : erso

[+] password hint: #TryHarder :)

after doing some OSINT on the pass hint , we found the user pass on internet and used that password to connect to SSH as user erso.

first of all we checked for the user privileges using sudo -l but got nothing , now we checked for the SUID binaries using the command find / -perm -u=s -type f 2>/dev/null

I don't know why /usr/bin/mtr doesn't worked , but /bin/dartVader looks intersting for us and we tried couple of things on this binary but failed .now if we run strings command on this binary then we found some good information .

this looks vulnerable to buffer overflow attack .

to check if we are on right track we transferred this binary in our local machine and will analyze it through gdb :)

we pass the argument "AAAAA" and it exited normally and if we use "A" 100 times then it crashed and we overwrite the EIP with 0x41414141 , this means we are on right track , to find the exact byte where it crashed we used a ruby script available in kali linux system and run it as .

now we copy this string and use it in gdb to pass it as argument like this :

the program crashed again but returned a different address this time , we used this address to find the exact offset match using the ruby script as :

This means that if we send 76 "A" then program will crash and above 76 bytes we can overwrite the EIP . looks like other buffer overflow attack , but after trying some common methods we failed to exploit this binary , I am not good in exploit writing so As usual we disassemble the main using command disas main

I am not good in understanding assembly code but what I found that it is using strcpy() function .

using the command x/wx $eax we checked the Return address of EAX , umm this means we can't execute our shellcode loaded on the stack . As I am not good in understanding assembly languages I started to search around the internet and found that "A non-executable stack can prevent some buffer overflow exploits, however it cannot prevent a return-to-libc attack since in a ret2libc attack only existing code is used." This means this binary should be vulnerable to return-to-libc attack and to perform this attack we need couple of things like

system address

exit address

/bin/sh address

base address

to find these addresses I go through a blog that is explaining this attack and after following the blog I succeed in finding these 3 addresses and also making a exploit.

base address : 0xb75a6000

to find system address we use the command readelf -s /lib/i386-linux-gnu/ | grep system and same for exit

try harder to find the /bin/sh address and after that we made a simple python script

the exploit was fine but even after that I am not getting the root shell , so one of my friend told me to check for the base address ( memory address of libc binary) again and again and I found that sometime it using the same address , means here we can think of bruteforce and for that we modified the python script a little bit

we can see that after 510 tries we got the root access

And this completes our challenge! Hope you like the walkthrough :)

I am not good in exploit writing and all so if you find any mistake then please tell me I will correct it soon :)

Subscribe to HacLabs newsletter

Get priority notification on the release of the latest articles.

  • YouTube
  • Twitter
  • Instagram
  • Linkedin

© 2020 by HacLabs.