DevelopSec

vulnerability

by Leave a Comment

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.

by Leave a Comment

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?

by Leave a Comment

Introduction to Penetration Testing for Application Teams

In this presentation, James Jardine focuses on educating application teams on what a penetration test is and how to extract the most value from it. Application teams learn how to participate in the engagement and better understand the report.

You can watch the recorded session at any time at: https://youtu.be/I1PukF8Glh0

https://youtu.be/I1PukF8Glh0

by Leave a Comment

What is a Penetration Test

You spend all day looking at requirements, creating functionality and doing some testing of the code you just created. You have been working for months on this application making sure it worked as expected. The testers have been diligently working to ensure that the requirements have been fulfilled and the application will work as expected and allow the end users the capability to solve a specific set of tasks. Then it happens… You find out that a penetration test is coming. Unfortunately for many, they really don’t understand what that means. Often times it is met with anger or resentment. How many people are actually excited to see the “pen testers” coming?

A penetration test, or pen test, is nothing that should be feared. While it is considered to be an adversarial act, the end goal is to assess the security of the environment or application to identify security risks before the “bad guys” do and help provide recommendations to reduce that risk.

That doesn’t sound that bad right, or does it? I may have left out the fact that a pen test may include exploiting your applications, retrieving your sensitive data, or even social engineering staff members to get what they want. But seriously, that is not as bad as it sounds and a pen test done right can be a very positive experience.

A big issue with a pen test is that in different companies and communities it has a different meaning. Sure the simple definition above should always fit that, but the scope that is defined and the results that are received can be very different. Here are some examples of some different types of pen tests (network and application specific).

Basic Pen Test (Scanner Only)
In my opinion this is not a pen test, but rather a vulnerability scan. In this situation, the “testers” will run a tool like Nessus or Qualys and then provide the results of that scan. The test is usually started by providing a set of IP addresses or URLs and then the scanner is configured and let loose. A few hours later, or maybe days, you get a report from the tool that is then passed on to the client. This type of assessment can make it difficult to identify the true risk of the vulnerabilities identified because they were not fully exploited. Maybe the scanner identified that there was SQL injection, but it didn’t follow through with the vulnerability to see how much access that provided.

Limited Scope Pen Test (Fairly Typical)
This type of test has scope limitations, meaning that it might just include a subset of IP addresses, specific functionality of an application, or how far you can take an exploit if one is found. This is fairly typical as it is rare to find a pen test that is fully open with everything on the table. The scope is defined in the rules of engagement as to what can and cannot be performed.

Full Pen Test (Not as Common)
Everything is game in this type of test. Be prepared to receive phishing emails or phone calls trying to get you to fall for a malicious attack. Your social profiles may also be a concern for you as when everything is game, a tester will use any avenue they can to try and gain access. All IP’s or the entire application is in scope. It can be very difficult to stop the testers from gaining access to systems when everything is in play.

Both the Limited and Full scope pen tests usually consist of both automated tools and lots of manual testing to identify the security risks.

In addition to the types of tests, we need to think about the different goals the client may have for requesting a pen test. Here is a quick rundown of some of the goals we see during a test.

Compliance Check Box
This is commonly seen by organizations that fall under some form of compliance, like PCI. “We are required to do this, so lets just get it done.” Often times the client is not really looking for security risks, but rather just trying to check the box. This doesn’t mean you should short change the testing efforts. The purpose of having a test performed is to help identify and reduce risk to the company.

Assess the Security of the Endpoint
This is seen in most tests where the client wants a vulnerability assessment of their endpoint, whether it is an IP or an application, so they can work to mitigate the risks identified. This type of test can be broken down into multiple levels, depending on how far the client wants to go. Some pen tests with this goal may not allow exploitation, making the goal just to identify vulnerabilities. Others, however, have higher goals of gaining access to internal networks, exploiting vulnerabilities, or gaining domain admin rights. This all depends on the goal of the organizer of the test.

High Stakes Goals
Some tests have very limited, yet high stakes goals. For example, many tests just want to see if the tester can gain domain administrator rights to the domain. In these types of tests, many of the other “vulnerability assessment” type findings may be overlooked. While they may be identified to help reach the ultimate goal, the goal is not to identify all, or as many as possible, of the risks to the endpoint.

In most tests, it is the assessing the security of the endpoint that we see the most. The goal is to identify the different risks, and while gaining internal access or domain administrator rights is great, the client is looking for more actionable results to it.

When testing occurs, often times the development teams have very little involvement. They may know it is going on, or have to provide some support if the applications are not configured properly, but that is usually the extent of it. It is important that we understand the goal and type of testing that is being performed. Also understand the purpose of the test should be to provide insight we didn’t have previously that could help us decrease the risk to our company.

Penetration tests, while “adversarial”, should be a collaborative effort with a positive feel. Don’t look at it as an “us” vs. “them”. The team was brought in for a specific task. The task should produce actionable results that are relevant to the environment. If they don’t, then it may be time to switch testing companies. Keep an open line of communication and a positive attitude.

by Leave a Comment

Verizon Email API Insecure Direct Object Reference Thoughts and Takeaways

It was recently announced that there was a flaw identified (and since fixed) in the Verizon API that allowed access to Verizon customer email accounts. The way this worked was that there was an ID parameter with the email account’s user ID specified. If a user supplied a different user’s ID name, that user’s email account would be returned. This is known as an Insecure Direct Object Reference. It was also found that the attacker could not only read another user’s email, but also send email from that account. This could be very useful in spear phishing attacks because users are more trustful of emails from their contacts.

Take-Aways

  • Understand the parameters that are used in the application
  • Use a web proxy to see the raw requests and responses for better understanding
  • Create test cases for these parameters that check access to different objects to ensure authorization checks are working properly
  • Implement row-based authorization to ensure the authenticated user can only see his information

The issue that is presented is that the API is not checking if the authenticated user has permission to access the specified mailbox. It would appear that it is only checking that the user is authenticated. Remember that authentication is the process of identifying who the requesting party is. Authorization is the process of determining what the authenticated user has access to. In this situation, the API should first validate that the user is authenticated, and then when a request is made for a resource (email account in this example) verify that that user is authorized to access that account before allowing it.

Unfortunately, many API’s are vulnerable to this type of attack because there is an assumption that the user can’t change the parameter values due to a lack of user interface. It is imperative that developers and QA testers both use a proxy when testing applications to be able to manipulate these types of parameters. This allows testing for unauthorized access to different objects. This is a very simple test case that should be included for every application, and not just for APIs. If you see a parameter value, make sure it is being properly tested from a security standpoint. For example, and ID field that may be an integer may get tested to make sure that the value cannot be any other type of data, but must also be checked to see if different values give access to unauthorized data.

It was also mentioned that the API didn’t use HTTPS for its communication channel. Using HTTP allows other user’s along the communication line to intercept the request and response data, potentially opening up the user to a variety of vulnerabilities. Make sure you are using the proper communication channel to protect your users in your mobile applications as well as the web applications.