Table of Contents
Web Application Security
- Unexpected Input
- Administrator Error
- Account Control and Management
- Ensuring Data Availability Compliance with WebWatchBot
- XSS Explored
- XSS Evolved
- MAXSS: Cross-Site Scripting Just Got a Voice
- Learning How to Burp – The Web Application Testing Proxy
- Code Injection Explained
- Mass Automated SQL Injection Attacks
- Inside a Real World Web-Based Attack
- How Bugs Can Give Attackers Access to Protected Portions of a Web App, Part 1
- How Bugs Can Give Attackers Access to Protected Portions of a Web App, Part 2
- The Wonderful World of Web Backdoors
- Web-Based Coupon Systems
- Web Application Firewalls
- What Can a WAF Do for You?
- Password Auditing with Hydra
- How to Create an Asymmetric Encryption-Based Form
- Practical Web Application Security with WebGoat
- PHP-Based File Inclusion Attacks
- Operating System Security
- Network Security
- Hardening Your System
- Wireless Security
- Mobile Security
- Data Forensics
- Legal and Ethical Issues of Security
- Home User Security
- Job Security for the IT Security Industry
- A Biased Book Review: Chained Exploits: Advanced Hacking Attacks from Start to Finish
- Security of Mechanical Locks
- Information Security in Academics
- Holiday Security: Hackers Don’t Take Holidays
- Gary McGraw on Building Secure Software
- Gary McGraw on Exploiting Online Games
- A Student-Hacker Showdown at the Collegiate Cyber Defense Competition
- The Collegiate Cyber Defense Competition Year 3: Revenge of the Red Cell
- Questions from RSA 2007
- How to Steal 80,000 Identities in One Day
How Bugs Can Give Attackers Access to Protected Portions of a Web App, Part 2
Last updated May 23, 2003.
Once an attacker has access to the administration screen, they can control a wide number of options and settings. In fact, all of these settings are available in a world readable file located at http://www.site.com/OnlineViewing/configuration/galleryConfig.txt. We first targeted the settings that we knew were on the main gallery page, such as business name, URL, and email address. However, these particular fields were converted to safe characters on the main page. Then we noticed and tested the Title option, which sets the value in the Title Bar of the website. The question was this: what would happen if we inserted a value outside the realm of expectations. As we discovered, the results were nothing less than a fully exploitable cross-site scripting vulnerability. The following illustrates one successful cross-site scripting injection value.
Figure 5: Cross-site scripting vulnerability in EZPhotoSales
Since the program strips out quotes, we had to use the String.fromCharCode function to represent the letters 'XSS', which would be displayed to each user on each gallery page. While this is harmless, the ability to do this means we can insert any code into the website that we want – including malware.
At this point, we now know that an attacker can gain access to any gallery, the administration backend, and infect clients that visit the site with malware of their own choosing. However, it appears as if the attacker is locked into this program and has no real way to get into the server – or do they?
Gaining Shell on the Server
EZPhotoSales is a program that helps a photographer sell their photos online via personalized galleries that the photographer creates through the web interface (figure 6). Since the software is fairly straightforward, the photographer does not have to be a computer expert to setup their online galleries.
Figure 6: User interface for gallery creation
Unfortunately, there is no file verification built into the software to prevent a user from uploading files other than images, such as HTML files and MP3's. To the valid user, uploading anything but an image makes no sense, but to a malicious hacker, failure to restrict file types means they can upload files such as phpterm or php-shell, either of which will give an attacker remote shell access to the server.
Since all the files are uploaded to static folders, it is trivial to locate the file once it has been uploaded. Just point your browser to http://www.site.com/OnlineViewing/galleries/test/images/phpterm.php, and have a web based shell console ready for your interaction (figure 7).
Figure 7: PHPTerm showing site.com/OnlineViewing/ file listing.
While this does give an attacker shell, they are extremely limited because the script is running in the 'nobody' account. For example, they can't even get a listing of the /etc/passwd file via a 'cat' command to learn what accounts exist on the system. However, what they can do is create a new PHP file that includes the following:
<?php system(’cat /etc/passwd > results.txt’); ?> (or they could just copy the file using "cp /etc/passwd results.txt")
Once the PHP file is requested in the browser, the script will execute and will dump the /etc/passwd file into the results.txt file, which will then give the attacker a full listing of all accounts on the server. From here an attacker can systematically locate and get a directory listing of all the other clients of the web server the EZPhotoSales software is located. Once a total listing is complete, the attacker can use PHPTerm to then view all the files of each client on the server, include the PHP, Perl, and other script files that hold valuable secrets such as usernames and passwords, account data, and more. Essentially, the server is compromised – and all because of one seemingly innocent web application.
Fixing the Holes
Obviously, this software is a huge risk to run on any server it is installed on, not to mention a liability for the clients whose pictures are in the gallery. As a result, I needed to find a way to protect the Achilles heel in this program, mainly the plaintext files. I couldn't simply change the permissions, because then the program wouldn't work. So, I did the next best thing and added an .htaccess file to each of the folders that contained sensitive data (configuration & data) with the following information:
AuthUserFile /home/<user>/.htpasswd AuthGroupFile /dev/null AuthName ByPassword AuthType Basic require valid-user
I then went to the /home/user directory and typed in the following command:
htpasswd –c .htpasswd user
This prompted me for a password, which I entered twice. As a result, the folders containing the sensitive data are protected and require a user/pass to authenticate. Granted, this is not 100% fool proof, especially if someone can capture the BasicAuth value passed in the header when the administrator. However, that is one risk that I can control.
Let's review how this web application led to system compromise. First, an attacker was able to locate the vulnerable application by doing a search on Google for 'Powered by EZPhotoSales'. Next, they located the config.dat file, which holds a hashed copy of the user/pass needed to gain access to the administration backend. Using Burp to create a fake request, the attacker plugged in the hashes and was able to access the administrative backend. Then they created a new gallery and uploaded a PHP script via the image upload feature, which gave the attacker a limited shell to the server. Finally, the attacker obtained the /etc/passwd file by creating a new PHP script through the shell that copied the /etc/passwd file to the local directory. Finally, with the account names in hand, the attacker has full read access to every client's files on the server.
Obviously, this is not something you want to have happen. If you do use this software, we suggest you contact the vendor and complain. We tried this approach, and although the vendor was nice, it appears as if there is no fix in the works – but perhaps enough complaints will force the vendor to do something responsible. Unfortunately, these kinds of problems are not isolated to just EZPhotoSales. There are thousands of similarly vulnerable applications out there that can lead to the same results. So, before you install any web based application, be sure to find out if it has a record for solid security. If it doesn't, find a solution or look for another program.