This is a real world story around the dangers of not following proper change control processes when placing new systems in production. In this blog I will discuss how one person’s actions could have resulted in an attacker gaining complete access to the organization’s internal network. I am hoping this example will cause organizations to take their change control processes a little more seriously!
It’s Just a Ticketing System…What’s the Worst That Could Happen
I recently completed an external attack and penetration assessment for an organization that had a web application sitting on their external presence. This application contained a major vulnerability. In fact, it gave me the ability to run commands on the underlying operating system of the server. This application was placed on the organization’s externally facing network by a person who needed to test the application in order to determine whether its functionality could fulfill a particular business need. This individual made a unilateral decision to place the application on the organization’s externally facing network without obtaining approval from any other group within the organization. The organization did nothave a change management process in place. When this person placed the application on the externally facing network, it was falsely assumed that this action posed a minimal risk to the organization. They had come to this conclusion because the web application contained no missing patches, and after an initial review of the application, the extent of the application’s functionality appeared to be limited to that of a ticketing system. At first glance, the application seemed to pose no major risks to the organization, so this individual did not feel it was important to lock the application down before placing it on the Internet. As a result, the password on the default administrator account was never changed. The security department, without knowing this application was on the external presence, contacted SecureState to have their annual external attack and penetration assessment performed.
Ticketing System Makes Attacker Very Happy
While performing the external attack and penetration assessments, one of the standard processes is to review all externally facing web applications for default credentials. When I found a ticketing system exposed to the Internet, I tried to log in with a username and password of “admin.” To my delight, these credentials gave me full administrative access to the ticketing application. I looked through the application, and found that under the setup tab, there was a menu named “Database.” This menu contained information regarding how the application connected to the backend database the ticketing system used. I was especially interested in a text field named “Backup Command.” I found that any commands that were placed in this text box would be executed on the underlying operating system, whenever the “Backup Now” button on the page was selected. Using this text field, it was possible to create a VB script which downloaded a payload from a web server of my choice. When the client found out what was happening, they quickly pulled the server from their external presence; however, SecureState confirmed that it would have been possible to gain full access to the client’s internal network, had the organization not taken the server offline.
Before Placing In Production I Should…
It is important that organizations learn from stories like this! No one person in an organization should be able to make the decision to place an application on the organization’s external presence, without going through an approval process. The organization’s information security department should need to approve the placement of a new web application on an organization’s external presence. Additionally, the organization should fully understand what the application can/cannot do as well as what risks the application’s capabilities pose to the organization. The process for placing new applications on the external network should also include requirements around system hardening before the application is made public. Once this system hardening is complete, it should be assessed in order to test the effectiveness around these security controls! It should be noted that these are just a few of the important processes that should be followed when placing a new application on an organization’s external presence!
There Was Not Even a CVE For That!
A second important takeaway from this story is that, just because an application has no vulnerabilities listed for it in the National Vulnerability Database,SecurityFocus, or The Open Source Vulnerability Database, does not mean the application poses no risk to the organization. Many times applications contain “features,” which may be exploited by an attacker to gain control of the underlying operating system, or obtain sensitive information residing on the application. This means that just because no “vulnerabilities” are listed for a particular server (such as CVEs), does not mean that the server poses no potential risks to the organization. The organization must review ALL the capabilities of the application, as well as perform testing on the application, in order to verify the application’s “features” cannot be used to gain control of the server the application is running on.
Don’t Play the Fool
The last item that should be noted is that this organization should not be viewed as having a below average security program. In all actuality, most organizations do not follow proper change control processes, thoroughly review the functionality of web applications, properly harden the application, and/or perform an assessment to try and bypass the security controls before placing the application in a production environment. If these processes are not in place, the organization could be opening themselves up to major vulnerabilities, which an attacker can use to gain access to their internal network! Remember, “A wise man learns by the mistakes of others, a fool by his own,” so the question is, are you a wise man…or a fool?