Image for post
Image for post
The RIT Security Club Logo

RITSEC Spring 2019 CTF — Week 4

The fourth 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 — Advanced Linux

This week participants were given terminal access to an Ubuntu 16.04 LTS virtual machine, with the flags in various hidden and/or restricted files and logs. To score points, participants were required to study and manipulate logs and cron jobs, escape restrictive shells, and identify unusual file placement or configuration. A heavy focus this week was on file permissions and attributes.

Easy 1: A cronjob is trying to write to easy1.txt!
Why is it still this fake flag :( ?

The fake flag easy1.txt

The file easy1.txt is in the RITSEC user’s home directory. Files may be inaccessible for several reasons, such as:

  • Another process has locked the file because it is currently using it. lslocks, flock, lsof
  • The file permissions do not allow programs like cron to access it. chmod
  • The file attributes are set improperly. chattr lsattr

First, see which commands this user is allowed to run as root with the command sudo -l. This saves time trying to check all possible options.

Image for post
Image for post
Output of “sudo -l” command

Permission is given to run chattr as root, so the file attributes are most likely to be the source of the problem. Run lsattr ~/easy1.txt to see the file’s attributes.

Image for post
Image for post
Output of the “lsattr ~/easy1.txt” command

There are 2 of the 14 attributes currently applied to the file. A table of attributes is available here or in the man page. From the site, the attributes that are applied to the file are:

  • i (Immutable) — Files with this attribute cannot be deleted or renamed; hard links cannot be made to this file; most of its metadata cannot be changed; data cannot be written to the file.
  • e (Block Extends) — Indicates that a file should be stored using block extents. Data is stored contiguously between two blocks, and only those two blocks must be known to find the file’s data.

The immutable attribute is most likely the source of the problem. Using chattr and sudo (since we are allowed to use sudo only for the chattr command), remove the attribute from the file. Syntax definitions for the following command can be found at the link above or in the man page.

sudo chattr -i ~/easy1.txt
Image for post
Image for post
Results of “lsattr” after removing the immutable attribute

The immutable attribute is removed. Wait a few moments for the cronjob to run again and then view the file.

Image for post
Image for post
Results of the “cat” command

The flag is RS{4ttr1but3s_m34n_s0m3th1ng}.

Easy 2 — I hid some popcorn, can you find it?

At first glance, this hint means nothing. However, remember that this is an Easy challenge, so it’s not going to be incredibly difficult. It turns out this hint is simply wordplay, because popcorn is made of kernels.

One of the simple files to view that concerns the Linux kernel is the kernel log, which contains all events that involve the kernel. To view this log, use dmesg. Since the kernel log is very large and only the start of the flag is known, use the following grep command to filter for the flag:

dmesg | grep "RS{"
Image for post
Image for post
Results of the “dmesg” command

The flag is RS{m0dul4ting_p0pc0rn}.

Medium 1

  • Part a: Give medium1 the password for the flag!
    Update: What’s my password? (password for the binary in /home/ritsec/)

The medium1 file in the home directory of the RITSEC user is an executable. To execute it, use ./. It does this:

Image for post
Image for post
Output for ‘./medium1’ command

A script would be the simplest way to solve this.

  • Part b (signoff): Solve Medium 1 with a Bash script :)

Bash scripts are incredibly quick and easy to make. Here’s a tutorial and a syntax reference. The completed script that will solve this challenge is below.

#!/bin/bashfor i in {a..z};
do for j in {a..z};
do for k in {0..9};
do for l in {0..9};
do
command="./medium1 $i$j$k$l"
answer="$(`echo` `eval` $command)";
if [ "${answer:0:4}" != "Nope" ]
then
echo $answer
fi
done;
done;
done;
done;

When run, this script produces:

Image for post
Image for post
Output for script

The flags are (a) RS{ne71} and (b) RS{b4sh_scr1pt1ng_rul3z}.

Medium 2 — Read medium2.txt in medium2’s home directory. Easy, right?

Change directories to /home/medium2 and attempt to cat the file, which from running ls is medium2.txt.

cat /home/medium2/medium2.txt

The result is:

Image for post
Image for post
Result of ‘cat’ command

Check the permissions of the file to see who can access it by running ls -la.

Image for post
Image for post
Results of ‘ls -la’ command

The permissions for medium2.txt are set to -r--------, or read by owner only. The following helpful image from HackingArticles explains how to read Linux file.

Image for post
Image for post
Linux file permissions

However, Linux also uses advanced file permissions, such as:

Image for post
Image for post
Advanced permissions
  • SUID or “Set User ID” — This bit allows users to run an executable with the rights of the executable’s owner.
  • SGID or “Set Group ID” — This bit allows users to run an executable with the rights of the executable’s group.
  • Sticky — This bit only allows the owner to delete the object, regardless of permissions other users have to read or modify it.

Information about how to set these bits can be found at LinuxConfig, but since the ritsec user isn’t allowed to execute chmod (file permissions modifier), this challenge will likely focus on finding and using files that already have these attributes set. SUID and SGID are most interesting in this case because they will allow a user to act as the medium2 user temporarily, and possibly view the flag.

Start by finding the files medium2 owns that could have SUID/SGID set. If there exists an executable file owned by the user that has the SUID bit enabled, executing it might give the user permission to act as medium2 and view the flag. By looking at the etc/passwd file, this account has its own group, which is 1002.

Image for post
Image for post
Results of ‘cat /etc/passwd’ command (partially omitted)

More on how to read /etc/passwd here. Now run the find command in the root directory for medium2’s group. Since ritsec doesn’t have sudo privileges, be sure to filter the errors to dev/null so they won’t be displayed. This will allow for output that is significantly easier to comprehend.

find / -group medium2 2>/dev/null

The results are:

Image for post
Image for post
Results of the ‘find’ command

All files in the /medium2 directory are normal parts of the operating system, plus the flag. However, /sbin/cat2 is very interesting. View the permissions of the file.

Image for post
Image for post
Results of the ‘ls’ command

cat2 is in red, which is a warning that the SUID bit is enabled on this file. By the name, this appears to be an alternative cat program that has the permissions of the medium2 user. Try running it on the flag.

cat2 /home/medium2/medium2.txt 

The results are shown below:

Image for post
Image for post
Results of the ‘cat2’ command

The flag is RS{s3t_u_i_d33}.

Hard 1 — Login to hard (hard:hard) and read hard.txt in their home directory!

Upon logging in, a message is presented:

Image for post
Image for post
Message upon logging in to hard

Notice that ubuntu has been replaced with [SHELL]. This might indicate that the shell is no longer Bash, which is the default shell for most Linux distributions. Try entering some commands:

Image for post
Image for post
Failed commands

From the output of the export command, this is actually a Bash script simply blocking access to the real terminal. Trying to run bin/bash doesn’t work, so how can this be circumvented? As with similar types of challenges, it helps a lot to know how the check is being handled. Keeping it simple to start with, assume the command entered is just being checked for the word bash to prevent it from being run. Therefore, it should be possible to start Bash from inside this script by calling it something else.

Linux allows for symbolic linking (“symlinking”) of files, which is similar to the function of a shortcut in Windows. It is not possible to create a symlink in this limited shell because it will contain the word bash and be blocked, so log back in as the ritsec user and create a symlink with that account. The symlink created will be

ln -s /bin/bash ~/er280652

where

  • ln — creates a link
  • -s— specify symbolic link
  • /bin/bash — the file to link to (in this case the Bash shell executable)
  • /home/hard/<filename> — the location to put the symlink of name <filename>. In this case the file name is er280652.

It can be seen from earlier that the Bash script currently running is in the /bin folder, so navigate up to the root directory and then down to the ritsec folder like so:

/../../home/ritsec/er280652

The Bash shell is presented:

Image for post
Image for post
Bash shell for hard user

However, it looks like the path is configured improperly.

Image for post
Image for post
Results of ‘ls’ command

To add the proper path (location for available commands) to the Bash shell, run the following PATH= command.

PATH=$PATH:/bin

This will make the proper commands available once again. Now run ls.

Image for post
Image for post
Results of `ls` command

View the flag with cat.

Image for post
Image for post
Results of the `cat` command

The flag is RS{3v1l_sh3lls_sc4re_m3}.

Bonus: A significantly easier (but I think unintended) way to access the Hard 1 flag is to simply run source hard.txt in the limited terminal. Escaping the shell was much more interesting.

In Conclusion

Challenges such as these become significantly easier as participants gain experience with the Linux operating system. As with the challenges this week and previously, many of the hints point to what type of research must be done or what process must be performed, rather than simply executing a command or greping for the flag. After knowing a few simple commands for filtering through the system (such as sudo -l or find command syntax) to find information relevant to the topic, the challenges become significantly easier. Scripts to find common vulnerabilities and manuals that cover exploit techniques are helpful as well.

An RIT advanced computing security elective that would help with these types of challenges is Computer Forensics (CSEC-464), taught in both the spring and fall semesters. This class assists in developing the analytical mindset to complete such challenges, although hands-on experience is always the best learning opportunity.

There will be 11 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. wyatttauber.com

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