Securing Third Party Web Applications

Many Organizations Assume Third Party Web Applications Are Secure

Just as internally coded web applications should go through a standard Software Development Life Cycle (SDLC), third party web applications should also be subjected to an SDLC. For example, an organization’s SDLC may dictate that all newly coded web applications must go through a grey box assessment before going live.

Mobile ApplicationsOnce the initial grey box assessment is completed, a black box assessment must be performed on the web application every quarter thereafter. In most cases, the SDLC, which applies to internally coded web applications, should also apply to third party web applications.  Many organizations install third party web applications without subjecting them to a formal web application security assessment. These third party web applications are not likely to be scanned with a basic web application scanner and unfortunately a full greybox assessment is out of the question. These organizations purchase a third party web application, configure the web application for their purposes, and then place it on their production network.


Many Third Party Web Applications Are Not Secure

In some cases, these organizations do not even realize the device they plug into their production network has a web management interface with a default username and a password of “admin.” These default credentials can result in an attacker gaining access to the web application’s configuration, sensitive data, and in some cases even grants the attacker the ability to run commands on the underlying operating system. Default passwords are a common vulnerability. Third party web applications also can contain all of the same vulnerabilities that any internally coded web application contains (Cross Site Scripting, SQL Injection, Poor Access Restrictions, etc.).


Real Life Example Of Insecure Third Party Web Applications

I recently participated in an Internal Attack and Penetration Assessment where I encountered a third party web application which contained various vulnerabilities. These vulnerabilities could be linked together in such a way that remote code execution on the underlying operating system was possible. The following is a brief real life example of how vulnerabilities in third party web applications, as well as internally coded web applications, can be linked together in such a way that code execution is possible on the underlying operating system:


Directory Listings Are Not That Bad, Right?

It all started while I was reviewing the HTML of a third party web application I had discovered while performing the Internal Attack and Penetration Assessment. I noticed that a graphic was referenced in the code which was located in the images directory. I pointed my browser at the image directory to see if I could obtain a list of all the images installed in the web application. Upon pointing my browser at the “images” directory, I was met by a large list of images referenced by the web application. I thought to myself, “If the images directory is vulnerable to directory listings, maybe other directories will be vulnerable to directory listings as well.” I pointed a tool named DirBuster at the site and waited to see what other directories I may be able to access. Within a few minutes, I had a small list of directories which were part of the web application; to my delight, all of these directories were vulnerable to directory listings as well.


Information: An Attacker’s Best Friend

I started looking through one of the directories which was vulnerable to directory listings when I came across a log file which revealed various SQL commands used to INSERT data into the underlying database. One of these database entries was an INSERT statement in which the web application’s administrator account was inserted into the underlying database. This INSERT statement revealed the name of the table where the web applications stored its users, the name of the administrator account, and the column names inserted into the table for each user (username, password, etc.).


The Compromise

I looked in a second directory which was vulnerable to directory listings and found a tool that allowed commands to be run against the underlying database. Using the information I had already found regarding the database table names, column names, and the name of the administrator account, I was able to change the web application administrator’s password to any value I wanted. At this point, I could use the administrator account to log in to the web application. This was a small victory, but I really wanted complete access to the underlying operating system (Windows 2003). Using the tool which allowed running commands against the underlying database, I was able to craft SQL queries in such a way as to obtain command execution on the underlying operating system. With access to the underlying operating system, it was possible to dump password hashes, use tokens already on the machine to create a domain account, and use the machine as a hopping point to access other boxes on the domain. In the end, it was not a missing patch, Blank SA account, or weak password that brought victory. It was a vulnerable third party web application.


In Summary

It is extremely important to perform a web application assessment on your third party web applications.  I would recommend something like a grey box. You may have your custom made web applications locked down, all your systems patched, and a strong password policy, but just one poorly coded third party application can provide the type of door an attacker needs to compromise your network.


Leave a Comment...

Your email address will not be published. Required fields are marked *