Masquerade VM Walkthrough Part 1
I recently made a VM for students at a CTF in London, sadly some reportedly used hex editors to get some flag values, it’s a shame for them that they couldn’t find the last two flags because they involved reverse engineering. I decided to release this to the public before the event, but let the event run before releasing to ensure no one got ahead. There are a load of different challenges aimed to make the most intelligent student question wtf is going on. This VM was intended to be one of the harder ones compared to other virtual machines available to students. I made this VM in my free time and am a bit busy at the moment, I apologise for any errors or if anything is broken! Note: I’ve wrote this in the evening, there will be errors.
This is what the VM looks like when you boot up, you aren’t supposed to login. I add a little bit of art on the login to keep it unique 😉 This is the first CTF VM I’ve developed and had a lot of fun creating it. It may be a little mangled in logic, I will say that.
When you find the IP address of the VM you will probably see this result if you port scan (It depends how intensive of course). The VM is called masquerade for a reason, parts of the VM are supposed to slow you down, such as useless ports.
Port 1 shows nothing but debug output used to help me understand what’s going on under a live event, 21 and 22 are emulated ports, they do not respond to anything but the intial responses a FTP and SSH server would. These allow Nmap to identify them as VsFTPd and OpenSSH which can slow down a hacker in trying to connect or exploit them, when in actual fact, they are nothing. Port 135 spits out random bytes which are pretty much useless for a user, this port is essentially supposed to confuse the user.
Port 8080, what Nmap identifies as a proxy port actually has something useful. It essentially wants a client to send it some data to open a port. I’ve given some hints with stating a “python chr byte” and user string. I also give away the fact that chr(1) opens a port. The user essentially has to bruteforce the port with the python chr byte 1 prepended on it. This involves the user to develop an understanding of python sockets, and basic understanding of how a client and server respond to eachother. A lot of CTF’s rely on copy and paste exploits which I don’t like, get them thinking, not all Metasploit!
A simple bruteforcer should be able to get the flag and the port open, in this script there is no bruteforce functionality (lucky for me, I actually know the user which is accepted ‘admin’). I don’t need to recieve that amount, but it’s habit by now I guess.
After the client script has been run sucessfully doing a network connection to the server you should get a reponse with your first flag and the message that your port has been opened! Back to Nmap..
After probably an intensive scan, you will find another TCP port which wasn’t open beforehand (1337). For everyones information, NGINX isn’t actually being run, it’s being spoofed like many of the other services, the web server is apache. It’s time to access the VM through the web server port 1337 now that is open.
Viewing the website in web browser you will be greeted with something like this, congrats, you’ve made it to the main part of the CTF.
If we continue to the link which starts the web server CTF we get a very strange response, a nag screen which just shows plain text in the browser, for those who don’t fully understand it. You should probably try using CURL or WGET to retrieve the web server response, Javascript is menace sometimes!
The function called “loading()” is essentially stopping us from viewing the page, which a timeout of 10, it almost instantly rewrites the whole document, only showing the angry nag message, this, will only work inside a browser. If you download the page you can remove the javascript and rerun it from a browser.
When inspecting obfuscated code in the browser we can get a few clues into whats happening here, the obfuscator isn’t too hard as it saves the strings at the end of the code. It has been obfuscated multiple times making the size of the obfuscated code quite sizeable. The loadimg() function seems to be loading “here.gif”. If we don’t use the web browser correctly we may not of understood the result. We now need to try and request for an image on the web server.
The image has some EXIF data that could be interesting, if we look at the “headline” we find the flag that we want.
We also have some other obfuscated code at the bottom of the page with a cryptic comment, the comment is caesar cipher which can easily be bruteforced. The result of this cryptic message is a wikipage to esoteric programming languages which will give you a hint on what the obfuscated code is which looks crazy.
The obfuscated code is called JSFuck and is pretty characteristic when we see ![]+]()[+]
There is a tool called JSUnFuck so we don’t have to deal with understanding all of the complexities of the obfuscation. The deobfuscated text shows us a apparent file listing which we should probably try and visit.
Going into the javascript of this page we see a function called “rotateit”, this is a hint to the user to use “rot” when trying to understand another cryptic message. Bruteforcing will suffice, the page actually does a barrel roll when being viewed on a browser.
The Amiga Voyager was a web browser, there are only a number of user agents out there, the message is hinting to view the page with Amiga Voyager, but we can of course, spoof this with a user agent.
After spoofing the user agent we get a link “to the next” and a flag that rewards us for our hard work so far!
The next page requires us to understand what unix time looks like, these numbers look random but they are not, the unix time is jumping every two years. The next answer for the domain would be the unix time for the last domain + 2 years.
You get a flag for your good work in identfying unix time and the text for the next challenge after form submission.
Visiting this page gives you a 4 pixel bmp picture, it’s important that you check the header when viewing this page as well, it allows you to understand whats going on by viewing the instructions and also gives you the hint not to include padding bytes for the 4 byte alignment. Essentially this challenge has you trying to understand the bmp file format in a little more depth.
You can move the offset of the data essentially anywhere (“A2” in offset position for 4 pixels) , if you don’t look at the file format properly, you may not fully understand what the hex is saying. The “F” next to “bant” is supposed to throw someone off by looking like it’s included but it’s not. The red is what we want, and the padding bytes in blue are things we don’t want to include when hashing our values. The instructions are clear, get the values of the 4 pixels and hash them with “.php” to get the next page.
Instructions that probably make more sense than me right now.
Hashing to the right page will leave you with this page, you may notice if you’re cool that a parameter has been appended at the end of your request “?quote=quote.txt”, interesting some web app sec hackers may think. Is that an LFI?
Of course it is! Gives you youre flag and your next URL! Note, you can see from the code this will only work for these two files.
You will arrive at this page, which may look a bit like a web shell many may know 😉
end of part 1