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 1
Last updated May 23, 2003.
There are thousands of web applications available for anything from simple file uploads to complex forums. All of these programs are created to be easy to install and even easier for a client to use, which is why they are very popular with the average non-technical customer. While the benefits of these programs are typically obvious and worth the cost, there are often some serious risks associated with using these web applications because they are built by people who are not security experts. In this section we are going to look at one such program that came across my radar and the simple fact that by installing this program you could be exposing every other user of the hosting server to major security problems.
One day my wife, who does professional photography as a side job (in addition to organist and full time mother/teacher of three), came to me with a program she wanted to install on her website. So, being a good geek husband, I complied and helped her setup the software. It was during this process that I picked up on the security features built into this program, EZPhotoSales.
What caught my attention first was that the program was encrypted and protected with the ionCube PHP file encoder that converts each PHP file in the program into an encrypted file containing nothing but bytecode. As a result, anyone who purchases this software will not be able to see the actual source code in the PHP files. This essentially keeps people from stealing the software or modifying it for their own personal needs, unless they are willing to pay a small fee to an online decryption company who will convert all the bytecode back to PHP code.
The point is this: the software developers have taken extensive measures to protect their own investment, and have provided a seemingly secure program for their clients. However, after a little probing of our own, we realized that any security within the EZPhotoSales program is an illusion. As we discovered, the software is full of holes and will actually give an attacker all they need to gain access to the files of the client and to other sites that might be sharing resources on the server. The following will examine each of the problems we found in order of complexity and potential damage.
- Using the browser, view the source of the page and copy out the location of the image and load it directly to the screen.
Still, all this assumes that a person can gain access to the gallery, which is protected by a password — or is it?
Bypassing the Gallery Password Protection
When a photographer wants to upload their pictures for viewing/sales, they will use the administration function of the EZPhotoSales program to build a gallery. One of the options in this process is to password protect the gallery to keep out unwanted visitor's for privacy sake. When enabled, the web client will get a prompt similar to the following asking them for the password (figure 2).
Figure 2: Password prompt for gallery access
Unfortunately, there are numerous problems with how this password is used to protect the images. The following lists the ways we found that essentially makes this security "feature" little more than a bump in the road:
If the user has not manually removed the admin account, which is probably the case, simply type "admin" to gain access to ANY of the galleries.
If the user has not manually specified an alternate location for the gallery password file, you can view ALL the gallery passwords by visiting http://www.site.com/OnlineViewing/data/galleries.txt.
Regardless, this only gives someone access to the gallery images, which is at most an invasion of privacy. EZPhotoSales still has a secure backend that is protected by an unbreakable user/pass — or is it?
Gaining Access to the Administration Interface
To allow the owner of the software the ability to create new galleries and change the look/feel of the clients interface, EZPhotoSales includes a backend component. Gaining access to this interface requires a user/pass that is setup upon installation, which means there are no defaults to crack. The following provides a screen shot of the login page:
Figure 3: Administration interface login
While it would be possible to brute force your way into the account, or create a situation where you can steal the credentials as they are sent plaintext over the network, we discovered two other ways to bypass this protection scheme.
Both of these methods are possible because the user/pass information is stored in a world readable text file at http://www.site.com/OnlineViewing/configuration/config.dat/. However, it is important to note that this file contains hashes of the user/pass, not the actual values. The following is an example of one such hash pair (note that these values have been changed):
Unfortunately, hashing the values is not going to prevent us from gaining access to the administration interface. In fact, if you look close at these values, they look very similar to a MD5 hash. We tested this theory and found that John the Ripper got right on the job and could decrypt a weak user/pass in no time at all, assuming the password was weak. However, if the user of EZPhotoSales created a strong user/pass, then cracking the information will take far longer than one’s life and as such is a useless route to take.
Instead of cracking our way through the interface, we decided to look for a backdoor. In particular, we monitored how the program kept a users session authenticated while they used the web interface using a proxy program called Burp. The following is a screen shot of one such page request. Do you notice anything amiss?
Figure 4: Burp capture of POST request
If you look closely at this request, you can see that it includes a ConfigLogin and ConfigPass variable, which, of interest, holds the same values contained in the previously discovered config.dat file. In other words, if an attacker wanted to gain access to the administrative backend of EZPhotoSales, they only need to view the world readable config.dat file and send a POST request via Burp with the hash values.
At this point, the attacker has full control over the program. However, this doesn't give them the ability to do any real harm to visitors — or does it?