Monthly Archives: May 2016

ImageMagick – Take-aways

Do your applications accept file uploads? More specifically, image uploads? Do you use a site that allows you to upload images? If you haven’t been following the news lately, there was recently a few vulnerabilities found in the ImageMagick image library. This library is very common in websites to perform image processing. The vulnerability allows remote code execution (RCE) on the web server, which is very dangerous. For more specific details on the vulnerability itself, check out this post on the Sucuri Blog.

There are a few things I wanted to focus on that are less about ImageMagick and more focused on better security solutions.

Application Inventory

I know, enough already. I get it, I mention application inventory all the time. It is with good reason. We rely heavily on 3rd part components just like ImageMagick and there are bound to be security flaws identified in them. Some may be less critical, while others demanding the highest priority. The issue at hand is that we cannot defend against the unknown. In this case, even if we are aware of a vulnerability, it doesn’t help us if we are not aware we use the vulnerable component. Time is important, especially when it comes to critical type issues. You need to be able to quickly determine if your company uses the vulnerable component, which apps are effected, and what types of data resides in those systems. Performing fire drills for every vulnerability announced is very inefficient. Being able to quickly identify the effected areas allows for a better understanding of any risk changes.

Permissions

When you are configuring your applications, think about the type of permissions the application has on the server. Does it have the ability to write to specific folders, execute specific files, read data, etc.? Does the application run as an administrator with full rights? To help reduce the attack surface we must understand what the app needs to do, and then make sure the permissions are aligned with those needs. In this case, the files may be stored on the file system to be used later so write permissions may be required. It is still possible to limit those write permissions to specific folders and even limiting execution permissions.

Application Configuration

How you design and configure your application plays a significant role in how security is handled. In regards to allowing file uploads, how do you handle storing the files? Are they on the file system or in the database? How are features configured? In the case of ImageMagick, there are configuration settings that can be set to limit the vulnerabilities. Make sure that you are only accepting file types that are needed and discarding others. These configurations can take many forms, but will help provide security when they are truly understood.

Importance of Input Validation

The vulnerability in ImageMagick highlights the importance of sanitizing input and performing solid validation. In this case, the file name is not properly handled which allows an attacker to run unintended commands. We have to check to make sure that the data passed to our applications is what we are expecting. If it is not, then it must be discarded.

This is not the last time we will see a vulnerable component that is used by lots of applications. It is part of the risk of using external components. We can do more on our side to make sure that we know what we are using and preparing for the event that something goes wrong. Take the time to understand your applications and think about the different ways security may be effected.

Reliance on 3rd Party Components

It was just recently announced that Apple will no longer be supporting QuickTime for Windows. Just like any other software, when support has ended, the software becomes a security risk. As a matter of fact, there are current known vulnerabilities in QuickTime that will never get patched. The Department of Homeland Security has an alert recommending removal of QuickTime for Windows.

For users, it may seem simple: Uninstall QuickTime from your Windows system. But wait.. what about software they rely on that may require quicktime? There are times when our users are locked into some technologies because of the software we create. How does our decision to use a specific technology have an effect on our end users when it comes to security?

If you have created an application that relies on the installation of QuickTime for Windows this creates somewhat of an issue. It can be very difficult to justify your position to end users to continue using a component that is not only known vulnerable, but is also past the end of life. This brings up a few things to consider when using third party components in our solutions.

Why use the component/technology?

The first question to ask is why do we need this component or technology. Is this a small feature within our application or does our entire business model rely on this. What benefit are we getting by using this component. Are there multiple components by different sources? What process was used to pick the used component? Did you look at the history of the creator, the reviews from other users, how active development is, etc.? When picking a component, more is required than just picking the one with the prettiest marketing page.

How do we handle Updates?

The number of breaches and security vulnerabilities documented is at an all time high. You need to be prepared for the event that there are updates, most likely critical, to the component. How will you handle these updates. What type of process will be in place to make sure that the application is compatible with all of these updates so the user is not forced to use an out-dated version? What would you do if the update removed a critical feature your application relies upon?

What if the component is discontinued?

Handling the updates and patches is one thing, but what happens if the component becomes end of life? When the component is no longer supported there is a greater possibility of security risks around it that will not get fixed. In most situations this will probably lead to the decision to stop using that component. I know, this seems like something we don’t want to think about, but it is critical that all of these possibilities are understood.

We use components in almost any software that we create. We rely on these components. Taking the time to create a process around how these components are selected and how they are maintained will help reduce headache later on. We often focus on the now, forgetting about what may happen tomorrow. Take the time to think about how the component is maintained going forward and how it would effect your business if it went away one day. Will you ask your users to continue using a known vulnerable component, or will you have a plan to make the necessary changes to no longer rely on that component?

Security in Testing Environments

When it comes to creating applications, there is a need for multiple environments to support the development process. It typically starts on the developers own computer, then on to an integration environment, a QA testing environment, possibly a UAT (User Acceptance Testing) environment, and then finally production. Depending on your organization, you may have some, none, or all of these different environments.

When it comes to security, the focus is typically on the production environment. This is where the instances that all of the users use are on a daily basis. This has all the “real” data. It is where real credit card numbers or social security numbers may reside. There is a lot of effort put on securing the production environment.

What about the test environments?

If your testing environments are externally exposed, the security of those environments are just as important. Anything exposed externally is a target and needs to be considered. Just recently there was an article about a test database being exposed that resulted in leaked data. This is an opportunity for us to look at our own systems to understand what we are doing with our test environments.

Some things to think about within your test environments:

  • What do we actually have exposed externally – Keep an inventory of the software, services and devices that are exposed. This includes any databases, web servers, ports, etc.
  • Ensure the endpoints are properly locked down – Make sure that your systems are not left wide-open. Don’t leave default passwords in place, make sure they are changed to be unique. If you are running some form of database server, make sure it is not exposed and that it has authentication enabled on it.
  • Check the validity of data – What type of data do you use in your test environment? Are you using a straight copy of production (shame on you)? What type of data scrubbing are you performing? Are you performing data scrubbing? What types of sensitive information may be stored in the environment.
  • Who has access to the environment – Is the environment limited to specific IP addresses or clients? Is it open to anyone that has a valid username and password? Who should it be open to?
  • Where are the servers – Consider where these servers are located. Are they in the same environment as the production servers? What about the corporate network?

These lower-level environments produce risk and should be tracked accordingly. Don’t discount them just because they are “test”.