Image for post
Image for post
The RIT Security Club

RITSEC Spring 2019 CTF — Week 8

The eighth week of RITSEC’s Spring 2019 CTF has concluded. Although the official challenge write-ups for the semester CTF will be posted on RITSEC’s GitHub for those interested, I have more detailed write-ups here each week for the challenges I am able to solve. I do this because as a freshman, when I read the challenge write-ups they often went step-by-step but never elaborated on why a certain command was run or the strategy the user followed when solving the challenges. This is my effort to elaborate on the reasoning to the process.

Topic — Linux Blue Team

This week, participants were given an Ubuntu 16.04 (Xenial Xerus) virtual machine with several malware infections and misconfigurations. Points were earned by identifying and correcting these weaknesses, from PAM files to Apache backdoors and a basic Linux rootkit. Tools covered this week also touched on Linux memory forensics with an introduction to the Linux Memory Extractor (LiME) and the Volatility Framework.

Easy 1: Wait, I can login with any password???
I wonder how that’s configured?

User authentication in Ubuntu is almost always handled by PAM, the Linux Pluggable Authentication Modules. PAM is made up of many files and has incredible depth, which makes it very easy to misconfigure. Such is likely the case for this challenge. Begin by checking the PAM configuration folder at /etc/pam.d for any unusual files. As this is an easy challenge, inspecting the modification date is probably sufficient.

The files above perform the following functions:

  • common-account — Contains a list of PAM ‘modules’ that are used by other services to grant access to the system
  • common-auth — Defines general authentication methods that can be used to authenticate to the system
  • common-password — Defines shared services used to change passwords
  • common-session and common-session-noninteractive— Implements authentication tasks that need to be run at the start of a user’s or service’s session

From the screenshot above, there are no additional files — but the modification date on common-auth has changed. cat the file for the flag.

As previously mentioned, this file handles methods to authenticate to the system. The file uses the three general PAM keywords, sufficient, requisite, and required. PAM processes items in the file in a stack, using the keyword to determine what action to take if one of the authentication items should fail. The possibilities are:

  • sufficient — If the module returns success, the authentication procedure should be considered successful. The rest of the stack will not be processed.
  • requisite — If the module returns failure, the authentication process should be considered to have failed. The rest of the stack will not be processed.
  • required — If the module returns failure, the authentication process will fail if no other item further in the list causes the process to succeed.

The line auth sufficient has been added to the file. is a very dangerous item to include in this process as it defines a success, and such always returns successful. Setting the login process to consider this module’s success sufficient allows logins with an incorrect password.

The flag is RS{suffc13nt_p4m_p4ssw0rd}.

Easy 2 — A “malicious” command is being run every time you run commands. Which command?
There is more than just your .bashrc…

There are many different configuration files in Linux. These are commonly hidden and sometimes contain the suffix rc, such as:

  • .bash_profile ,.bashrc, or .profile — Shell and login configuration files (these vary depending on system and shell used)
  • .vimrc and .viminfo — Text editor configuration files (also can vary depending on any preferred text editor)

and many more. As this is an easy challenge, checking the above for any modifications should be sufficient.

The .vimrc file is interesting as it contains a Base64-encoded string. Decode the string to see what command is running with the following command:

By decoding the string, the flag is found to be RS{n4n0_1s_b3tt3r}.

Medium 1 — Set up IP Table rules to do the following:
Signoff-based (show the Tech Lead your iptables commands)

  • Allow outbound ICMP
  • Disallow outbound HTTP
  • Allow inbound ICMP
  • Disallow all inbound traffic

iptables is a Linux utility commonly used as a firewall. The following commands fit the requirements. Here is a guide to writing iptables rules.

The flag is RS{3Gr355_B4D_GrA55}.

Medium 2 — According to our logging, there’s a vuln on our WordPress site! Uhoh!
Flag is encoded with Base64, but does not end in “==”.

Since there apparently is a web server running on this VM, try viewing it at http://localhost/ or (the loopback IP address that also means localhost). Here is the aforementioned WordPress site.

An easy way to start scanning for web vulnerabilities is to use a tool like Nikto. However, this challenge specifically mentions logs. Website logs (and other files) are generally stored in the /var/www/html directory, and WordPress content in the wp-content subfolder. As an Apache server is one of the most common ways to run a WordPress site, try looking for one of the common Apache logs first. These will usually be:

  • Error Log: var/log/apache2/error.log — Apache writes all errors on the server to this file.
  • Access Log: var/log/apache2/access.log — Apache lists information about what users or addresses are accessing files on the server, and which files are accessed.

Browsing to the location, it seems that there are two of each file.

There is very little detail provided about the vulnerability, so it would be logical to simply skim the log files as a start. However, after scanning access.log.1, it appears this is all that will be necessary.

backdoor.php definitely seems suspicious. Browse to the location specified by the GET command.

Opening the file, a string of Base64 is visible:

Decoding this string gives the flag, RS{N0_0n3_w111_f1nD_M3}.

Hard 1 — Find the rootkit!

This challenge may seem very daunting at first, with seemingly countless ways to solve it and very little directions. However, with a bit of research on common tools for Linux rootkit detection, it isn’t terribly difficult. This solution uses the Linux Memory Extractor (LiME) and the Volatility memory analysis framework tools taught in RIT’s CSEC-464 Computer System Forensics class. For more on memory extraction and analysis, see here.

Creating a memory image

Many Linux rootkits operate by inserting their module into the kernel, allowing them to modify the results of most system commands and remain hidden. However, this technique only works if the rootkit is actively running on the system and watching output. To capture the current state of the system and suspend any activity, create a LiME memory image of the VM.

First, clone LiME from its GitHub repository:

Next, browse to the LiME/src folder and run make to create the kernel object that LiME uses to extract memory:

When finished, the kernel module lime-4.15.0-46-generic.ko (or similar) should exist in the src folder. Loadable kernel modules are programs that extend the functionality of the Linux kernel, and operate at the unprotected ring 0 of the operating system along with the kernel itself. While this is a dangerous functionality to grant, LiME is a very trusted utility in the forensics community and needs access to the kernel in order to create a memory image.

The following resource explains kernel modules in more detail, as well as how to load and unload them:

To load the LiME kernel module, insmod (“insert module”) is used:

The above command inserts the module and creates the image with the following options:

  • path — The location to store the memory image once it is created.
  • format — The format of the memory image. This is generally lime or raw.

When finished, unload the module with sudo rmmod lime.

Creating the Ubuntu Volatility Image

Once the memory image is created, the Volatility Framework can be used to analyze it. Volatility requires a profile for each operating system it analyzes, which is essentially a baseline to determine what changes (if any) have been made to the system.

Volatility has many prerequisites that need to be installed. They can be found here:

Once the prerequisites are installed using apt and pip, create the Ubuntu 18.04 image with the following steps:

  1. Change directories to volatility/tools/linux.
  2. Run make in the directory to create the module.dwarf file needed for the profile.
  3. Create the profile with the following command:

This command gets the file for the current kernel version and creates for Volatility’s use.

4. Copy the .zip file to Volatility’s Linux profile directory:

5. Run --info | grep Profile to ensure the image is in the list.

Searching for rootkits with Volatility

Volatility has many different plugins for analyzing different parts of a memory image. These plugins can inspect running processes, view open ports or active connections, or inspect loaded kernel modules and search for kernel taint. The latter will be used for this challenge, linux_check_modules.

Run the following command to inspect the kernel modules of the generated memory image against those of the Ubuntu profile that was created.

Part of the flag is omitted. Use Volatility’s export command to display the full text as a .json file (or any other supported file type):

Finally, open the file.

The rootkit name is s3cr3t_RS{r00tk1ts_r_str0ng}. Therefore, the flag is RS{r00tk1ts_r_str0ng}.

Hard 2: Find the rootkit a different way!
Signoff-based (show the Tech Lead your method)

There were several other simpler ways to find this rootkit:

  • Syslog — Syslog was reporting kernel taint due to the unsigned rootkit. This is visible in the syslog.1 file in /var/log.
  • Journal — The same goes for the system journal:
  • root’s .viminfo file — Traces of installing the rootkit (Diamorphine) are visible in this file:
  • Strings in memory — Running a strings dump (strings ~/Desktop/image > ~/Desktop/strings) on the memory image also displayed the rootkit:

Additionally, it seems that the tech leads had a different name in mind for this flag prior to releasing this week’s challenges. Low-level system changes such as these can persist in memory for quite a while, making memory forensics much simpler.


Blue teaming and incident response are two of the most popular focuses of computer security, typically coming in the form of Red/Blue Competitions for students such as the upcoming RIT Incident Response and Security Competition. For anyone seeking more preparation, resources such as Incident Response and Computer Forensics is an excellent introduction to the topic. In addition, those new to blue teaming can read about my previous experiences at ISTS and IRSeC and suggestions for being successful in these competitions.

There will be 7 more weeks of challenges coming from RITSEC this semester! If you want to know more about RITSEC check out their website or attend a meeting if you’re on RIT’s campus — 12–4 PM in GOL-1400 for the CTF and presentations. Until next week!

Written by

DFIR, CTFs, disinformation, STEM education, and pretty much anything else that comes to mind. RIT Computing Security ’22.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store