Home > Guides > Security > General Security and Privacy

Security Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

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.

Superficial Security

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.

There are also numerous security features that are valuable to the software's owner. For example, there is a user/pass protected backend that is used to manage the galleries. In addition, the client galleries can be password protected to keep out unwanted visitors. The site is also fully protected by JavaScript to prevent unauthorized image downloads.

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.

By Passing JavaScript Protection

Within each gallery you can see a list of images on the left, and the main image on the right. The main image is a fairly large picture and is meant for viewing pleasure only. Any attempt to right click/save the image is prevented with a little JavaScript that subtly tells the user to buy the image (Figure 1).

Figure 1

Figure 1: JavaScript popup warning

While this warning might scare away some Internet users, any protection based on JavaScript is very easy to bypass using one of the following two methods:

  1. Using the browser, view the source of the page and copy out the location of the image and load it directly to the screen.
  2. Disable JavaScript in the browser, which prevents any code from executing, thus allowing you full access to the images.

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

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:

Go directly to the image folder without any need for authentication by manually typing in the folder name in the address bar (e.g. http://www.site.com/OnlineViewing/galleries/<gallery name>/images/image1.jpg). Not only will this bypass the gallery password, but you also bypass the JavaScript protection mentioned previously.

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

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

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?