Security Problems Put Survey App on Sidelines

Design flaws leave a Web-based survey application open to compromise.

Much of my normal routine has been put on hold while I attend to a legal matter that requires generating mirror images of about 30 employees' laptop hard drives. In response to a request from a federal agency, we're using Pasadena, Calif.-based Guidance Software Inc.'s EnCase Forensic Edition to obtain those images.

It takes about five hours to create each compressed 40GB drive image. Fortunately, the imaging process can run unattended. That has given me enough time to squeeze in a security review of a new Web survey application -- a process that revealed several unpleasant surprises.

First, however, I had to get the disk images going. EnCase creates a boot floppy disk that write-protects the hard drive, then it lets you manually or automatically detect the destination storage device. I used the network port to connect to my forensics workstation via an Ethernet crossover cable and began acquiring the image for storage on a DVD-ROM.

Survey Insecurities

Our legal counsel requested a security assessment for a new Web-based customer survey tool. Members of the deployment team questioned why we needed to assess a survey tool at all. "It's not like we're collecting credit card data, personal information or storing source code," one staffer said.

He had a point. The application is being used so that our customers can complete surveys to assist us in providing a better experience for them. It doesn't collect any personal or financial data. But we might ask our customers to evaluate our performance and to specify deficiencies in the way we do business. We don't want such information falling into the hands of our competitors. Because of this issue, our general counsel determined that the data should be considered confidential.

Not only are we worried about the compromise of the survey results, but this application will also have a Web server residing on the Internet-facing demilitarized zone (DMZ) segment of the network. The application itself uses a three-tier architecture consisting of a front-end Web server, a midtier application server and a back-end SQL database server.

If hackers were to compromise any of the infrastructures, they could access other information such as server configurations, user identifications and passwords, which can usually be cracked. They could also install packet-sniffing software to capture traffic and use it to gain access to other areas of our infrastructure.

For example, if a hacker ran a sniffer on a compromised Web server and the server administrator accessed another resource on the same network, the hacker might be able to obtain the administrator's log-on credentials. Even on a switched network, it's still possible to capture traffic and compromise even encrypted protocols such as Secure Shell and HTTPS. If you don't believe this (and I didn't at first), read the Ettercap program specifications at http://ettercap.sourceforge.net/.

Exploiting Deficiencies

Assessing the security of the application is always more of a challenge than assessing the server and operating system on which the application is installed. The latter typically involves checking for open ports and vulnerable services. But an assessment should attempt to exploit deficiencies in the way an application was written or configured. I used several methods to try to gain access, including two common exploits: SQL injection and directory traversal.

SQL injection attacks occur when, for example, the application doesn't validate the data entered into forms. If a hacker enters SQL statements into a Web-based form and the application passes the inputted data to the database server, it's possible for the database server to actually execute the SQL statements it receives. If the database contains credit card numbers or other financial data, a properly crafted SQL query can retrieve it.

Directory traversal also works as a result of insufficient data validation. It's possible to issue commands from the address line of a Web browser that will let a hacker view any file on a Web server by traversing outside the normal directory of the application. For example, it might look like this: http://www.webserver.com/../../../../../etc/shadow.

In an unprotected machine, a hacker could use this Web address to view the shadow file, which contains the encrypted password for user accounts on most Unix systems. From there, it's a simple matter of copying the data into a text file and running a password-cracking tool against it. These vulnerabilities are normally easy to mitigate, but discovering them can be difficult. I use Sanctum Inc.'s AppScan for this purpose.

I found the results of my application assessment quite alarming. There were several directory traversal and SQL injection vulnerabilities. In addition, the application stored account information in clear text. All these vulnerabilities will have to be mitigated before I give the application a clean bill of health.

Next, I plan to review all of our public-facing Web-based applications and review administrative access to our critical DMZ servers, which appear to have serious deficiencies.

What Do You Think?

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com, or join the discussion in our forum: QuickLink a1590

To find a complete archive of our Security Manager's Journals, go online to computerworld.com/secjournal.

Related:

Copyright © 2003 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon