Tag: #ctf

ZeroDays CTF 2018 – “Hodor” Challenge

ZeroDays CTF 2018 – “Hodor” Challenge

Capture The Flag, Security
Another reverse engineering challenge from the ZeroDays Capture the Flag 2018 event was named "Hodor". The challenge description went as follows: Oh you said Hodor! I thought you said Harder! The first thing to do is check what the file is: The file is a 64-bit ELF which means we need to have a 64-bit support for the debugger. Before anything else however, doing "strings" shows the following output: Since the output doesn't really show anything interesting for the flag, running the executable should output: Similar to the challenge "WhattaMan", it is asking for a flag input to check if it's correct or not. By entering the command "gdb ./Hodor", GDB should load the executable for debugging: Again, similar to the challenge "WhattaMan", doing "info...
ZeroDays CTF 2018 – “Whatta Man” Challenge

ZeroDays CTF 2018 – “Whatta Man” Challenge

Capture The Flag, Security
The "Whatta Man" challenge under the "Reverse Engineering" category of the ZeroDays Capture the Flag 2018 event got me quite confused probably because I got intimidated by those system calls presented in the debugger. So to start with, the challenge description went as follows: OK ladies lets hear it for Khal Drogo First was the need to check what the file was: Another 64-bit ELF here which means the debugger has to be 64-bit too! Apart from doing the initial investigation on the file format, doing the "strings" command to extract strings in the executable gave an output of: Looking at the above picture doesn't give us any flag so the next step would be running the program to get an idea of how it works before using a debugger to do some assembly language review: ...
ZeroDays CTF 2018 – “JonSnow” Challenge

ZeroDays CTF 2018 – “JonSnow” Challenge

Capture The Flag, Security
The "JonSnow" challenge under the “Reverse Engineering” category of the ZeroDays Capture the Flag 2018 event was pretty interesting as it took me some time to realize what was obvious. So to start with, the challenge description went as follows: You know the flag? Tell me what you know Jon Snow? The first thing to see was what the file was by using the command "file": When I saw that this was a 64-bit ELF, I knew that I won't be able to play around because I was using a 32-bit Kali during the event! Talk about not being prepared. So, here I am, not being able to sleep soundly just like my OSCP days because an unsolved challenge gave me nightmares. The only thing that I was able to do apart from the "file" command was using "strings" but it honestly did not make sense:
ZeroDays CTF 2018 – “edgescan” Challenge

ZeroDays CTF 2018 – “edgescan” Challenge

Capture The Flag, Security
The "edgescan" challenge under the "Reverse Engineering" category of the ZeroDays Capture the Flag 2018 event was pretty straightforward although I wasn't able to solve it during the actual event due to time pressure. So to start with, the challenge description went as follows: So edgescan kindly sent us a small challenge, we've tweaked it slightly. Enter the key to get your flag. Enjoy! Clues: The flag is in the usual format. The flag message is XORed with the key (12 chars). The first clue says "The flag is in the usual format" which means, it should be in the format of ZD2018{???????????????????} as per example flags given in the event. The second clue on the other hand says that the flag message is XORed with a 12-character key. During the event, I actually thought tha
SickOS 1.2 Walkthrough

SickOS 1.2 Walkthrough

Penetration Testing, Security
Since I have managed to put down SickOS 1.1, I guess the next challenge would be visiting SickOS 1.2. After setting up the machine through VMWare, an initial Nmap scan towards 192.168.209.161 (Address of SickOS 1.2) has shown the following output: By the results shown, only two TCP ports were open. One SSH and another one is an HTTP service. Firing up Mozilla in Kali and typing in the IP address 192.168.209.161 should give us this output: The next things to do were: Check robots.txt (Not found) Check source code of web page (Nothing really useful) Use dirb Use HTTP Nmap scripts against the main directory (Nothing really useful)   Looking at the HTTP headers when browsing the website, it was also found that the server was using lighttpd 1.4.28 (als...