Image for post
Image for post

RITSEC Spring 2019 CTF — Week 2

Welcome back to RITSEC for the Spring 2019 semester! Despite not having a club meeting in the first week of the semester due to ShmooCon, the CTF is well underway with the second week having 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.

As always, let me know of any errors!

Topic — Advanced Web

Spring semester challenges are typically more advanced than those of the previous fall semester, given that most club members will have gained a bit of experience with CTFs and various security topics at this point.

This week, participants are provided with several URLs that have security vulnerabilities on their back end, such as LFI and RCE. Points can be gained by exploiting the vulnerabilities to obtain flags on the remote servers. There are two easy challenges, two medium challenges, and a hard challenge this week.

Easy 1: web1.ritsec.club
Flag is at web1.ritsec.club/getFlag

Upon visiting the provided link the following message is displayed:

Websites send and receive several different types of requests when transferring data. The most common request for a web browser to send is a GET request, which instructs the website to send the file at the requested location to a user’s PC. It failed at this URL, but the hint for this challenge states that the flag is there. Begin inspecting the domain by removing the page name from the URL to see what is at the main page:

Image for post
Image for post
Image located at http://web1.ritsec.club/

The image is a Post-It note, which is a hint that the previous URL should probably send a POST request. The hint is trivial if you are familiar with the types of HTTP methods. A POST request tells the server to create or update information at a URL as opposed to a GET request which expects information to be available without having to request it be created. While POST requests can be done in a web browser, they usually aren’t done manually, so it will be simpler to use a command-line tool called wget to send the request needed to retrieve the flag. The command needed to run to retrieve the flag is:

wget --post-data --D http://web1.ritsec.club/getFlag

where:

  • wget invokes the tool
  • --post-data tells wget to get the data sent from the server in response to the POST request we are sending
  • --D indicates that we are going to specify the domain next
  • http://web1.ritsec.club/getFlag is the page to send the POST request to

The results of the request can be seen below.

Image for post
Image for post
Results of executing the “wget --post-data --D http://web1.ritsec.club/getFlag" command

The request for web1.ritsec.club is first resolved to the IP address 192.21.128.23 through DNS, then wget attempts to connect to the site on port 80, which is the standard port for HTTP (if the website were using HTTPS, it would be port 443). It then sends the POST request for /getFlag , and a 200 OK response code means that the request was successful and it received some data. The data will be saved in the current directory as the (most likely text) file getFlag. All that is needed to do now is open the file. You can do this with cat, or concatenate, which prints the contents of a file.

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

The flag is RS{N0T_G3T_R3QUEST}. All flags for the weekly RITSEC challenges will be in the RS{} format.

Keep in mind that there is always more to a website than can be viewed through a browser or the developer console! Many command-line tools are also useful for viewing web data.

Easy 2: web2.ritsec.club
I can read! But what do I read? How is this configured?
(Update 1/27: emphasized the word CONFIGURED)

Upon visiting the URL, a basic webpage is displayed:

Image for post
Image for post
http://web2.ritsec.club/

There are three links here:

  • Easy2 is the link to the challenge.
  • common is a PHP directory that’s probably irrelevant.
  • index.php is the site we are currently on. If /index.php were appended to the URL, it would be the same webpage.

Click on Easy2. A new page appears:

Image for post
Image for post
http://web2.ritsec.club/Easy2

This is where things start to get interesting. We are presented with a text box and two PHP errors referencing the command include(). Entering data in the text box attempts to call the command include(/usr/local/lib/php/<data>) and display data from that file on the web page. Of course, if it doesn’t exist, PHP can’t display the file.

Image for post
Image for post

PHP (recursive acronym for PHP: Hypertext Processor) is a scripting language used for web development. There are a lot of security vulnerabilities applicable to PHP (especially old versions) and numerous configuration mistakes can be made. Since the only information given concerns the include() function, see if there are any vulnerabilities that revolve around using it.

One important notice that can be found by simply searching the web or the PHP documentation is that the command should not usually be used for accepting user input or anywhere the user can modify the string sent to include(), which is precisely what has been given. This opens up the possibility of Local File Inclusion (LFI). LFI allows a user of a webpage to change the file that is viewed through include() simply by specifying a new file path. However, the catch is that the path must be known already, as there is no way (in the scope of this challenge) to view a list of files or directories. Therefore, if the path to the flag is known, it can be viewed.

No file paths are currently known. However, by looking at the current directory /usr/local/lib/php/test, it can be assumed that this is a Linux system. Linux has a root /usr (user) folder. Start by identifying any files that should be on any Linux system, such as the passwd file. passwd can be recalled from Week 1 of last semester’s challenges. It stores users and their home directories, and is a file that should be present on any Linux system. Try to view it by navigating up to the root directory (/) by using the “up one level” command (..) in Linux several times. The file path on this server would be

, which is what we see below:

Image for post
Image for post
Contents of web2’s passwd file

This is definitely a vulnerability as most website operators would not want their user list to be publicly accessible. The second part of the hint for this challenges acknowledges the fact that files can only be read, and even then only if the path is known, making this more difficult to use as an advantage. Note the easy2andmedium1 path as well as that this is Debian Linux. In addition, the www-data folder probably indicates that this web server is probably run from one of two very popular programs, Apache or nginx.

Fortunately, lots of other people have encountered this issue. Lists with common paths for useful directories (passwd, history, SSH keys, logs, processes, etc.) in an LFI attack are available online. Assuming the web server is Apache, there are two very important log files that can be found:

../../../../var/log/apache2/error.log — Apache writes all errors on the server to this file.

../../../../var/log/apache2/access.log — Apache lists information about what users or addresses are accessing files on the server, and which files are accessed.

These files are important because they can be used for Remote Code Execution (RCE), an “upgrade” to LFI. As soon as commands can be executed, the web server is significantly easier to traverse or exploit further. More on this later. View both log files for any useful links to other directories.

Image for post
Image for post
The Apache access.log file

There is an interesting URL in the first line of the access.log file. Go to the page indicated there.

Image for post
Image for post
Easy 2 flag

The flag is RS{Easy2_T00_E4SY_4_ADV_W3B_W33K}.

Always be sure to gather as much data as possible (such as operating system, version, user list, and HTTP server type, as done above) of any accessible system to make it quicker to identify relevant files that could be vulnerable. Use lists or scripts available online if they would make this process faster.

Medium 1: web2.ritsec.club
Hint is located with the Easy2 flag :)…

With LFI, you can start browsing the file of the machine within your privilege.
Downside is that you need to know the file path. What files usually have common path?

What important files should you look out for? Would there be any way to change the content of the file, just by ge... looking at it?

Find flag.txt for Medium 1’s flag.

The hint suggests attempting to change a file on a website just by “ge[tting]…looking at it.” This is known as Remote Code Execution (RCE), and is a vulnerability regarding any files that a user can manipulate. Two logs that change based on user action have already been discovered, access.log and error.log. Try using cURL, a tool for transferring data on protocols such as HTTP, to send a GET request that can place executable code in the server’s error.log file. Formatting for such an example can be found online and may look like the one below that uses the PHP shell_exec command.

Image for post
Image for post
A PHP RCE using cURL

This command does several things:

  • curl invokes cURL.
  • -a tells cURL to append to a specified file the PHP code in quotation marks. This code will execute in the log to check for a RCE vulnerability.
  • web2.ritsec.club/… is the website to target
  • > log.txt tells cURL to place the output of the command in a log.txt file.

Run the script and wait for it to complete. Next, open the log.txt file and search for the string hellofriend. This will show the contents of the log file created by the server. Sure enough, the command was executed on the remote server and confirms that it is vulnerable to RCE.

Image for post
Image for post
The log.txt file (some contents omitted).

After confirming vulnerability, create a new command. Now that code can be executed on a shell on the remote server, all Linux commands that the remote user is able run are available, including the powerful find and grep commands. Start by replacing the test string hellofriend in the previous cURL command with the command find / -name "flag.txt" to search for Medium 1’s flag.

Image for post
Image for post
A PHP RCE using cURL with the find command.
Image for post
Image for post
The results of the RCE find command.

The file is found at ../../../../usr/local/share/man/flag.txt. Why not request the file with cURL, since it is already being used?

Image for post
Image for post
The GET request for flag.txt

The flag is RITSEC{poison_all_the_logs}.

In Conclusion

While I was not able to solve all the challenges this week, I still learned a significant amount about various forms of PHP exploitation and remote code execution. RIT CSEC students will learn more about this topic in their third year when taking Principles of Web Application Security (CSEC-380). In the meantime, here are some excellent resources that I used while completing the challenges above:

  • OWASP — The Open Web Application Security Project contains information on various web application exploits (and examples!) for many different platforms, including LFI and RCE such as above, session hijacking, DoS, and many more.
  • JDow’s Web App Pentesting Cheat Sheet — Provides helpful strategies for scenarios such as only being able to read, common browser indicators that a website is vulnerable, and a list of commands that can usually be exploit across various platforms.

There will be 14 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