Magnet Weekly CTF Challenge Week 6 Writeup

Here comes the week 6 challenge of the Magnet Weekly CTF challenge. For the first time, the challenge was divided into a two-parter. Participants would need to solve the 1st part of the challenge in order to view and solve the 2nd. The 1st part was relatively easy, as a gentle warm-up to the 2nd part.

Part I

The 1st part of the challenge asked the following:

Because the flag was a numerical error code attributed to a failed Hadoop dependency installation, the first thing to check had to be the Linux package manager logs. Since "apt" package manager was used on all nodes, the directory "/var/log/apt" on both HDFS secondary nodes should be inspected carefully:

From the contents of "history.log" file, there were errors occurred during the installation of Oracle Java 7 and 8 packages and the "dpkg" subprocess returned a "1" error code.  So the answer to part 1 challenge should be "1" and sadly it was not the correct answer. Since there was also a "term.log" file under the "/var/log/apt" directory,  the "term.log" file was inspected as well:

Judging from the contents, the "term.log" file was a log file for the "apt" package manager terminal output. The lines highlighted in yellow from the above screenshot showed a previously unseen factor (Oracle Java 7 installer download failed due to not found JDK7 tar.gz file on Oracle servers) contributing to the failed installation of Oracle Java 7 package. Therefore, the HTTP error code "404" was the answer to the 1st part of the challenge.

Part II

The 2nd part of the challenge asked the following:

The way I approached this question was to break it down into smaller sub-questions and tackle all the sub-questions one by one. With the benefit of hindsight, it is of utmost importance to have a grip on the keywords and their contexts:

1. "Don't panic about the failed dependency installation."

 From Part I, it was clear the "failed dependency installation" refers to Oracle Java 7.

2. "A very closely related dependency was installed successfully at some point, which should do the trick. Where did it land?"

Contrary to the "history.log" file, the "term.log" file also recorded the successful installation of Oracle Java 8 and 9. The installed Oracle Java 8 could be found at "/usr/local/jdk1.8.0_151", somewhere next to the Hadoop directory ("/usr/local/hadoop").

3. "In that folder, compared to its binary neighbors nearby, this particular file seems rather an ELFant."

Things got interesting from here. This sub-question suggested to look for a possibly gigantic binary ELF file from the dependency folder specified from sub-question 2. However, there was no binary ELF file immediately available from "/usr/local/jdk1.8.0_151". As the Java 8 binary ELF file should be inside "/usr/local/jdk1.8.0_151/bin" directory, the "bin" directory should be checked and it turned out that the "unpack200" was the largest binary ELF file (227 KB) under that directory.

4. "Using the error code from your first task, search for symbols beginning with the same number (HINT: leading 0's don't count)."

The next step to take would be searching for symbols beginning with "404". Linux built-in tool "readelf" could accomplish that easily and by using "readelf -s unpack200 | grep 404", the following result could be obtained:

 The second column shown in the screenshot above was symbol value, it was clear that there were exactly 3 symbol values began with "404", which led to the ultimate answer of the part 2 challenge.

5. "There are three in particular whose name share a common word between them. What is the word? "

The word "deflate" could be found from the three symbol names and thus could be concluded as the ultimate correct answer.

Extra - The Wrong Turn

Before arriving at the correct answer, I took a wrong turn at sub-question 3 and it quickly evolved into a sticky situation.

My first thought was to look for ALL binary ELF files under "/usr/local/jdk1.8.0_151" and its sub-directories. Then choose a binary ELF file with the largest file size. With that in mind, a gigantic "libjfxwebkit.so" shared library file (74,363 KB) was found.

When the "readelf" tool was used on "libjfxwebkit.so", it did not give the distinctive and clear results as the one of "unpack200" and I did get lost in search of a non-existent answer in the wild. For some reason, I had a funny feeling that this happened to a lot of the participants.

Eventually I decided to take a step back and look at the bigger picture and it was the necessary push for me to get back into the right track.