(I found a security vulnerability in some code that Stoyan recently released. I worked with Stoyan to resolve the issue. Nothing in this post still works. Usually stuff like this happens all the time and is never made public. Stoyan has very graciously allowed me to discuss the issue publicly so others can learn and avoid the same mistake. Thank you Stoyan. You Rock.)
Yesterday Stoyan released an alpha version of a cool tool he wrote, chuckview.php, which helps people visualize how web pages are delivered to the client. There is an excellent article to go with the tool and everyone should read it.
But this post isn’t about chunked encoding. This post is about how trivial mistakes in web applications can have serious consequences.
Under normal operation chunkview.php looks like this (click for larger view):
Now, I’m a very curious person. I want to know how things work. Nothing makes me happier than to poke and tinker with technology (not necessarily my own) and see what happens. So about 3 seconds after looking at this tool I thought “what happens if I don’t give it a URL?” So I typed “> into the textbox and clicked enter. Here is what came back (click for larger view):
Now this is getting interesting! I get some PHP errors! This starts to answer some questions about the how the application functions:
- What: Stoyan is using PHP to fetch the URL the user supplies, parse the contents, and display the contents to the user.
- How: Stoyan is using fopen() to fetch the contents of the URL. It also appears that PHP magic quotes is in use because while I input the string “> the application tried to open “>.
- Where: I have the absolute file system path of the PHP file. This tells me where the files are, as well as the username of Stoyan’s account, w3clubs.
So what can we do? Well, Stoyan has essentially created a “view this resource” application. He intended for the application to be used to view the contents of HTTP responses. However he is using fopen() to read the contents of the URL. fopen() can also access files on Stoyan’s web server. It is possible that Stoyan actually created a “view any file on this computer or any remote URL” application!
Let’s test this theory. We are going to try to use chunkview.php to view the source code of chunkview.php! I typed chunkview.php into the textbox and hit enter. Here is what I got (click for larger view):
Well that did not work. PHP gives us a nice error message telling us it could not find the file chunkview.php. Hmmm. Perhaps there is a problem resolving the path. Maybe if I input the absolute path and filename for chunkview.php we will be able to read the file. I typed /home/w3clubs/public_html/tools.w3clubs.com/chunkview/chunkview.php into the textbox and hit enter. Here is what I got (click for larger view):
Awesome! I am now looking at the source code for chunkview.php! I can also immediately see Stoyan’s mistake. It’s the line fopen($_GET[‘q’]). He is passing input from an untrusted source (i.e. me) directly to a command that opens a file! This is known as a Local File Inclusion Vulnerability. (If this sounds familiar it should. We talked about how PHP scripts that combine multiple CSS or JavaScript files at runtime often contain Local File Inclusion vulnerabilities in The Challenge of Dynamically Generating Static Content post.)
From Vulnerability to Compromise
So what can an attacker actually do with this? So far all we have found is a toe hold. We have a way to read any file on the disk. But reading files != a hacked web server. At least not yet. I will now guide you through what an attacker would do to take this seemly small bit of unintended program behavior and leverage it into a compromised system. You should never never never do what I am about to describe. It is a crime.
The first thing I do is get a list of users that have accounts on the computer. That way an option we have would be to brute force their passwords and gain access to their account. We can see a list of users on the system by reading the contents of /etc/passwd.
Ok, we see a lot of these accounts don’t have shell access (because their login shells are set to /sbin/nologin). But we do know the name of an important account though that is probably used quite a bit: w3clubs! Let’s fetch the .bash_history file for this account, which should give us all the commands Stoyan has run on the system. We will view the source of the “web” page chunkview.php returns to see the contents of .bash_history file more clearly.
That much better. Notice the scroll bar. We have captured a list of approximately 1000 commands that Stoyan has run on this machine. I gain lots of valuable information by scrolling through the command history list:
- He accesses several different MySQL databases. I know the database names and the user accounts to access them.
- I see he is using WordPress on the box. I know where his wp-admin directory is and the names of all configuration files.
- He has SSHed or SCPed into different boxes. I know the hostnames and the usernames he has used. Any passwords I find on this box I will use to try and break into more computers.
(Everything from here on I did not actually do. As soon as I confirmed the security issue existed I immediately stopped probing and contacted Stoyan to help him fix the vulnerability. Again, don’t ever ever ever do any of this!)
The next thing I would do is start fetching important files from his system. I grab his Apache configuration file, his raw MySQL databases, his PHP configuration file, his WordPress configuration files and plug-ins, his SSH keys, etc. I download the source every PHP file I know about on the system looking for any file that allows me to either upload a file or execute arbitrary PHP code. My goal is to find a username and password, or some way of getting a file or content from me onto the system.
An easy target is WordPress. The web-based administration portal has exactly the functionality I need. Gaining access to it is not very difficult given that I can read all his configuration files and the WordPress database. Let’s assume I leverage all this information and can login to Stoyan’s WordPress admin panel. Now what? I use the Editor feature in admin panel for WordPress and add a back door. This is fair simpler than it sounds. By including a bit of PHP code like system($_GET[“command”], $blah) I can run any command I want to on Stoyan’s computer by passing it to his WordPress application through a query string. I can use this back door to upload files onto Stoyan’s web server (by running a command like wget to fetch it) and also use the backdoor to unzip, or untar, or execute what I upload.
Pwn3d
At this point it’s game over.
I can upload and execute arbitrary programs onto Stoyan’s computer. I can modify his web site. What I do now depends on my goals. I might modify his website to serve malware to 1 out of every 1000 visitors . I might create a hidden directory and use his computer to serve porn or stolen software. I might do nothing and simply use his computer as a platform to launch attacks against other systems.
Conclusions
You should never take user supplied data and just blindly use it. User supplied data means anything that comes from the user: query string values, POST data, Cookies, uploaded images or other files, and even HTTP headers like User-Agent or Referer (sic). Before you use any input you must validate it using whitelist input validation! In this case Stoyan and I fixed the issue by validating that URLs must start with http:// or https://. If you want to know more about Web Security I suggest these resources:
- Hacking Exposed, Web Applications 2nd Edition.
- Ajax Security
- OWASP (Open Web Application Security Project)
The point of this is not to publicly beat Stoyan. (thanks again for being a good sport Stoyan!) He’s a bright guy who has done amazing work in the web performance field. The point of this post is to show how a trivial mistake can lead to a complete failure and how easy it is for even smart people like Stoyan to make trivial mistakes. Please make sure you are validating all input in your web applications! It does not matter if you application is performant or not if the application is insecure.
The post Hacking Stoyan and the Importance of Web Security appeared first on Zoompf Web Performance.
