The Challenge

NOTE: This challenge was taken down shortly after the conclusion of the CTF due to vulnerabilities in the web server. You can read about the challenge and solution below, but you won’t be able to perform it. This write-up will be longer than most as a result.

Here we are; the final level! Here we have an interesting looking page with a text field that we can type in. It looks as though it will possibly perform a DNS Lookup on whatever we type in the box.

Well, let’s give it a try. I entered in google.com to see what happened.

Sure enough, it behaved as expected. The real question here is whether or not we can make this do other commands besides the Linux dig command (which is what this output is). In Linux, you can write multiple commands on a single line by separating them with semicolons, so let’s give that a try. The below screenshot is the result of typing google.com; ls -la

It worked! At the end of the DNS results for google.com, we get a directory listing for the webserver itself. Doing some other Linux commands, such as id will tell you that you are running as a user account called www-data which is for the webserver itself. For the most part, this account should have limited permissions.

Right there in the directory listing you will see a file called .hey. You can also access this file by going to http://ctf.infosecinstitute.com/levelfifteen/.hey since the console above is no longer operational. If we open it up, we get some kind of encoded text string.

Miux+mT6Kkcx+IhyMjTFnxT6KjAa+i6ZLibC

Not only does the name of it make it stand out, but this string looks similar to a base64 encoded flag. Unfortunately, putting it through a base64 decoder yields no result. If it’s not base64, let’s find some other decoders and try those as well. A decent website with a large number of encoders/decoders (both common and uncommon) can be found here. We can’t tell a whole lot about the text above, and we don’t have a key, so let’s try putting it through every decoder they have that doesn’t require a key. You will eventually find one that works.

There we go, apparently it was encoded with ATOM-128. I would encourage you to learn a bit more about the algorithm now that you know what it is and have seen it used. You know that it looks similar to base64, but can you catch anything else? If you try encoding a few test messages with the algorithm, you will notice that they always end in one or more C’s. So, if you see something that looks like base64, but it doesn’t decode properly as base64, and ends in a C, you know it’s probably ATOM-128!

More than you need to know about ATOM-128:

Having never heard of ATOM-128, I was very curious to learn how it worked and why it seemed so similar to base64. There is extremely little documentation out there about it, but apparently it is a base64-encoded string that is encrypted with a substitution cipher and an extra ‘C’ added at the end. Remember that a substitution cipher is just assigning one letter to replace another (e.g., a=f, b=s, c=k). This picture below explains the substitution that ATOM-128 makes compared with the Base64 character set:

So, if our first three letters of the encrypted flag were Miu, then the decrypted first three letters would be aW5 — see how that works? Once you go through each letter and strip off the final C, you can decode it like you would any Base64 string.

Here is another example: let’s say that we have the text Hello_InfoSec — let’s encode it via Base64 and ATOM-128. I have the results of both below.

Now compare the ATOM-128 result with the Base64 result, letter-by-letter. For example, the first letter of the ATOM-128 result is D, and the first letter of the Base64 result is S. Looking at the substitution cipher two pictures up, you will notice that this substitution lines up.

TL;DR: ATOM-128 just takes your plaintext, Base64-encodes it, does the substitution, and adds a C at the end (or replaces trailing = with C).

Bonus Flag

After doing some more exploring, you’ll find some familiar directories in your parent folder, such as /img and /misc. Other levels utilized these folders a lot, but we were never able to access them to see all of their contents. Here is a screenshot after entering ; ls -la ../misc

All of these files should be very familiar, except for one. After going through all of the levels, I had never encountered readme.wav before. I opened it up and played the sound file in the browser; you immediately identify the sound as Morse code tones, and it plays for nearly a minute. I opened up notepad, started the audio over, and began keeping track. Assuming that the flag starts like normal, I didn’t track the first set of letters, assuming it to be “infosecflagis” (Morse code doesn’t have underscores). This is what I ended up getting:

The x’s designate the letters that I skipped for the known part of the flag. After copying down the dots and dashes, I went over to a table that had the conversions (though I could have copied it into a converter online) and got the result on the second line above: infosecflagismorsecodetones (or in the usual format: infosec_flagis_morsecodetones)

Lessons Learned

This level was an example of command injection. We were given a useful tool on a website, but we injected our own malicious commands into it that made the tool behave differently than how it was designed, giving a lot of control to the hacker.

Stressed throughout nearly every level, attention to detail is incredibly important. This required navigating the website structure and picking out a file that you hadn’t seen yet. This is also a good example showing that you should always go back and make sure that you didn’t miss anything if you get advanced access later.

You also learned how to identify and decode an ATOM-128 string. It looks very similar to Base64 and always ends with a C. Being able to spot these at a glance will save a significant amount of time.

The Challenge

Looks like we’re back to downloading files for offline analysis again. Check on the source code to make sure you don’t waste any time, and then go ahead and download the file.

The file will open in your browser, but I chose to copy it into a file so that I could open it offline. As explained at the top of the file, this is a phpMyAdmin SQL dump, or a dump of everything in all of the databases for some webpage running phpMyAdmin. One of the first things that caught my eye was some administrator usernames and passwords.

Moving on past that, there was a flag? table that, of course, warranted some exploring. The image below contains the dump of the flag table as well as the friends table.

Because the flag table was more enticing, I tried cracking the admin password hash with john, but I wasn’t able to get anywhere very fast. While the dictionary attack was running, I noticed the very odd line on the bottom of the friends table. It looks like a bunch of hex values, although separated by \\u00 every time, and notice that many are in the 60s-70s, which is again a good indicator that these are hex-encoded ASCII characters. Let’s strip off the \\u00 parts and decode the remaining hex. This gives us our flag infosec_flagis_whatsorceryisthis

Lessons Learned

This was a lot of text to sift through, and unfortunately just doing a search for the flag comes up empty. This again comes down to recognizing when something seems odd or interesting; knowing what is normal versus not normal. The usernames, passwords, and hashes were interesting, but we weren’t provided a login prompt to use them. The line at the end of the friends table was definitely odd-looking, and deeper inspection showed a pattern of hex values in the 60s-70s which should raise some red flags, as this was the third or fourth time now that we’ve seen a pattern of ASCII characters encoded as hex.

The Challenge

The main page of level 13 has nothing but a block of text telling us that we are apparently on the wrong page. Nothing is clickable, there are no pictures or other files to be seen, and the source code does not reveal anything notable.

It is hinting to us that there may be a backup of the correct webpage on here. Looking at the URL, we are on /levelthirteen.php as expected, so perhaps there is another page for the backup?

Let’s just give some common names a try… some of the methods I tried was directing the browser to some guessed folders of the website, such as /archive, /backup, /backups, etc. No luck; none of these existed. Then I tried looking for similarly named files within the same folder instead, such as /levelthirteen.php.backup and /levelthirteen.php.old. The later guess was valid, and I was able to download the backup for analysis.

Opening this file in a text editor to see the source code. Since we are viewing the contents of a PHP file, we are able to see the PHP code as well, which isn’t visible when viewing the source in a browser.

  < clipped >
  <div class="hero-unit lvlfour">
    <h1>
    What the heck happened here? It seems that the challenge here is gone?
    Can you find it? Can you check if you can find the backup file for this one?
    I'm sorry for messing up :(
    </h1>
    <?php
    /* <img src="img/clippy1.jpg" class="imahe" /> <br /> <br />
    <p>Do you want to download this mysterious file?</p>
    <a href="misc/imadecoy">
      <button class="btn">Yes</button>
    </a>
    <a href="index.php">
      <button class="btn">No</button>
    </a>
    */
    ?>
  </div>
  < clipped >

It refences a file called “imadecoy” but I downloaded it for analysis anyways. Not knowing what the file type was, I ran it through file:

$ file imadecoy
imadecoy: tcpdump capture file (little-endian) - version 2.4 (Linux "cooked", capture length 65535)

Looks like it’s a packet capture. Let’s open it up in Wireshark. We see a lot of HTTP (unencrypted) traffic, so I try examining a list of the HTTP objects that were downloaded in these packets. You can do this in Wireshark by clicking File –> Export Objects –> HTTP. Doing so will give you a listing.

You can’t really tell if there is anything valuable in here just by looking at the names, so let’s start digging through all of them. I export them all to a folder and immediately notice that one appears to be a single line of text like our flag. I opened it up to be sure, and as luck would have it, found the flag infosec_flagis_morepackets

Lessons Learned

A very common convention to backup files in Linux is just to add .old to the end of the file. This isn’t a requirement, but knowing the common convention is really the only way correctly guess the name of the backup file. Checking for backup files can be valuable; maybe the old file had some credentials hard-coded in it that they removed in the current version, or perhaps you can use it to view PHP source code that is otherwise invisible to you.

We also used the file command again, this time really proving its worth because it would have been very difficult to determine the filetype for imadecoy without it.

We learned some new Wireshark skills as well: exporting HTTP objects that were downloaded throughout the duration of the packet capture.

The Challenge

Our main page for level 12 is very simple; we just have the same picture of Yoda as level 1, and the text “dig deeper!”

Let’s jump into the source code for some more in-depth analysis than normal. If you have been looking at the source code of nearly every level up to this point, you should find something different than normal in the <head> section.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="description" content="a ctf for newbies">
    <title>Infosec Institute n00bs CTF Labs</title>
    <link href="css/bootstrap.css" rel="stylesheet">
    <link href="css/custom.css" rel="stylesheet">
    <link href="css/design.css" rel="stylesheet">
  </head>

We have an extra CSS file than we did in any of the other levels. CSS files are rarely suspicious, but I decided to look into design.css because this was the first time seeing it there.

.thisloveis{
	color: #696e666f7365635f666c616769735f686579696d6e6f7461636f6c6f72;
}

This isn’t normal. This is all that’s in the file, and that is not a valid color code. Also notice all the 6’s; that’s an indication that this is hex-encoded ASCII text, just like in a previous level. Decode it with your choice of hex-to-ascii tool and you’ll get the flag infosec_flagis_heyimnotacolor

Lessons Learned

Attention to detail…

CSS files normally won’t contain anything interesting, but if all else fails, it’s another place you could look. In this case, it was suspicious because no other challenge used it. Why should this one be any different?

Seeing that long of a color value in a CSS file should also raise your suspicions, even if you are unfamiliar with CSS. This is also another case of noticing a pattern; there are a significant number of 6’s in that string, which tells us that this probably a hex-encoded ASCII string, just as in previous levels.