In episode 6 (Wintermute) of my Attacking and Defending Linux webinar series, we attack a capture the flag (CTF) exercise that follows the plot of the famed William Gibson cyberpunk novel, Neuromancer.
The Wintermute CTF is particularly interesting because it involves two virtual machines—and you have to hack the first, Straylight, before you can reach the target, Neuromancer. Once we've finished executing the attack, we discuss and demonstrate a defense to show how a proactive security hardening measure would block this cyberattack.
To complete an attack in this CTF exercise, we must exploit five vulnerabilities, one by one. One of the critical vulnerabilities in the chain is a Local File Inclusion, where we find a drop-down menu item that has four available options, "case," "molly," "armitage," and "riviera." These turn out to be files that are included into the results page, /a/directory/path/NAME.log, where NAME is expected to be one of the four items from the drop-down.
To exploit the vulnerability, we use a simple tool to submit an unexpected input, namely ../../../../../../var/log/mail, so that, instead of rendering /a/directory/path, the system renders /a/directory/path/../../../../../../var/log/mail.log, or, put simply, /var/log/mail.log. This, in turn, lets us render the mail server's primary log file. Once we send mail to the system containing PHP code in the From: field, requests for the vulnerable page cause the system to run our PHP code.
This kind of vulnerability feels particularly silly, doesn't it? The core problem is that the web application trusts the user to submit only the four values that were in the drop-down. Now, let's assume we don't know that the vulnerability is present, and have to proactively fix it. In the webinar, we take one approach, so let's now consider a different one here.
We could prevent the hostile input from reaching the server. One way to do this would be to create a block list filter in front of the application, preventing input that looks like a local file inclusion attack (../../../) or other hostile attacks. You could do this with a web application firewall (WAF) or intrusion prevention system (IPS). The free OWASP ModSecurity core ruleset would do this. Alternatively, you could create a allow list filter that prevents any input into that NAME slot that didn't match the four names from the drop-down. You could accomplish this with ModRewrite or ModSecurity, using a custom rule. Both approaches work—the former is less labor intensive, while the latter is more secure.
If you enjoyed reading about either the attack, the cyber defense, or both, check out the on-demand webinar!
