DevelopSec

Archives for August 2015

by Leave a Comment

Tips for Securing Test Data (Scrubbing?)

An application typically has multiple environments from development through to full production. It is rare to find an application that doesn’t use some form of data. Some applications may use just a little data with a very simple database, while others may have very complex database schemas with a lot of data. Developers usually load just enough data to test the features/functions being implemented in the current iteration. Production systems contain actual customer information which may be very sensitive in nature. Finally, we have the test environments. These environments need to be fully functional, requiring lots of data, but where should the data come from?

In many cases it is common to see data from production copied into the test environments. Due to many test systems having less security controls in place, this may inadvertently expose sensitive data. In addition to securing the environment, here are a few tips to help protect the sensitive data when trying to populate lower level environments.

  • Don’t Use Production Data
  • Disassociate Sensitive Information
  • Remove Sensitive Information

Don’t Use Production Data
The safest solution is to not use actual production data in any other environments. Like any other security control, if you don’t have the information you have less risk. While this data may be most realistic to indicate how the system is used, it often comes with a high risk exposure. There are benefits to using scripts to generate test data because it is less likely to contain sensitive information and it can be easier to make test automation more successful. It is also possible to script in values that may be edge cases or less common in real data that can help enable better test cases.

Disassociate Sensitive Information
If you have (or decide) to use data from production one option is to make sure sensitive data is disassociated. There are many ways to do this, depending on how your system works. Some places will just scramble the fields so the data is real, but the different columns are re-arranged so that data for any given row is actually not related. The following table shows the initial data (Note: This data is made up):

First Name Last Name Tax ID Phone
John Smith 333-33-3333 904-555-6588
Debra Jones 111-11-1111 301-555-2395
Jason Walker 999-99-9999 011-138-9443

The following table shows the same data from above, but it has been disassociated. Notice how the data is no longer related to any specific person. Keep in mind that the data here is a very small sample so the combinations to get the real data would not be that difficult. However with a large dataset, it could be enough to help slow an attacker.

First Name Last Name Tax ID Phone
John Walker 111-11-1111 904-555-6588
Debra Smith 999-99-9999 011-138-9443
Jason Jones 333-33-3333 301-555-2395

Depending on features of the system, this may not be ideal. Imagine that the system actually sends emails or ships items. Of course you have disabled these features so they don’t actually function in test, right? Either way, data like phone numbers, addresses, email addresses, etc could lead to an incident if executed against this random data. Customers would be confused if they received a notification that had some of their information but also someone else’s information. A headache you don’t want to deal with. On another note, things like email addresses can be self identifying all by themselves. This might be information that should be removed or further mangled as to protect your user identities.

Remove the Sensitive Data
One option is to remove any data considered to be sensitive. It is important to check with the corporate guidelines or data classifications for the specific requirements for sensitive information. The sensitive data could be replace by just place holder generic data. For example, replace all phone numbers with (999)999-9999 or emails with test@sometestexample.com.

It can be more difficult when a sensitive field is used as a search field or a unique identifier. If that phone number is used as a search field, setting all phone numbers to the same value won’t work well in the test environment because you can’t really test the search feature. It would return all or nothing, which would not be a desired test case.

Check with your internal security office to understand the policies and procedures that are in place regarding production data. If no policies exist, work with the security team to help define them. By working together it is possible to understand the risks and hopefully reduce them. Determine a procedure that will work in your situation.

by

Tips for Securing Test Servers/Devices on a Network

How many times have you wanted to see how something worked, or it looked really cool, so you stood up an instance on your network? You are trying out Jenkins, or you stood up a new Tomcat server for some internal testing. Do you practice good security procedures on these systems? Do you set strong passwords? Do you apply updates? These devices or applications are often overlooked by the person that stood them up, and probably unknown to the security team.

It may seem as though these systems are not critical, or even important, because they are just for testing or don’t touch sensitive information. It is common to hear that they are internal, so an attacker cannot get to them. The reality is that every system or application on a network can be an aide to an attacker. No matter how benign the system may seem, it adds to the attack surface area.

What Can You Do?

There are a few things to think about when any type of application server or device is added to the network.

  • Change Default Passwords
  • Apply Updates
  • Remove Default Files
  • Decommission Appropriately

Change Default Passwords

While this seems simple, it is amazing how often the default password is still in use on systems on a network. This goes beyond unused systems or rogue systems, but to many other production devices. It only takes a moment to change the password on the device. It may not seem like it, but a quick Google search for default passwords for just about any device/COTS application can yield quick results.

Fortunately, many recent systems have switched to not use default passwords, rather they force you to set a password during setup. This is a great step in the right direction. It is also a good idea to change the default administrator account name if possible. This can make it a little more time consuming for an attacker to attempt brute forcing the password if they don’t know the user id.

If you develop software or devices that get deployed to customers you should be thinking about how the setup process works. Rather than setting a default password, have the user create one during the setup process.

Apply Updates

One of the most critical controls for security is patching. Many organizations will have patching procedures for the systems and software they know about, but if you are standing up an unknown device it may not get patched. Software patches often times contain security fixes, some of which are critical. Make sure you are keeping the system updated to help keep everyone safe. It is also a good idea to let the team that handles patching and system maintenance know about the new application/device.

Remove Default Files

If the application is deployed with default files or examples, it may be a good idea to remove them. It is common to see these types of files, meant only for testing purposes, not be very secure. Removing the files will help tighten the security of the system, leading to a more secure network.

Decomission Appropriately

If you are done using the system, remove it. I can’t tell you how many times I have found a system that hadn’t been used in months or even years because it was just to try something out. No one even remembered it, security didn’t know about it, and it was very vulnerable. By removing it, you no longer have to worry about patching it or the default passwords. It reduces the attack surface area and limits an attackers ability to elevate their privileges.

Is the Risk Real?

You bet it is. Imagine you have left an old Tomcat server on the network with default credentials (tomcat/tomcat) or something similar. An attacker is able to get onto the internal network, lets just assume that a phishing attack was successful. I know.. like that would ever happen. They log into the management console of Tomcat and deploy a WAR file containing a shell script.

I have a video that shows deploying Laudanum in just this manner that can be found here.

Now that the attacker has a shell available, he can start running commands against the operating system. Depending on the permissions that the Tomcat user is running under it is possible that he is running as an admin. At this point, he creates a new user on the system and even elevate that user to be an administrative user. Maybe RDP is enabled and remote login is possible. At the very least it will be possible to read files from the system. This could lead to getting a meterpreter shell, stealing administrative hashes, even leading to gaining domain admin access if a domain admin has logged into that system.

That is just one example of how your day may go bad with an old system sitting on the network that no one is maintaining. The point is that every system on the network needs to be taken care of. As a developer who may be looking to try a new application out, take some time to think about these risks. You may also want to talk to your security team (if you have one) about the application to see if there are known vulnerabilities. Let them know that it is out there so they may help keep an eye out for any strange behavior.

This doesn’t mean you can’t stand different things up, but we need to be aware of the risks to it. You may find that there is a network segment that is heavily controlled that the application or device will be put on to help reduce the risk. You don’t know until you ask. Keep in mind that security is everyone’s job, not just the team that has the word in their title. They can’t help protect what they don’t know about.

by Leave a Comment

Disabling Paste for Passwords?

Passwords, while a simple concept, are one of the most complex issues in security. A majority of user authenticated systems rely on a password to verify the end user. Over the years we have seen many different recommendations for strong passwords. I have talked about this subject many times.

The complexity, while difficult to define, has gotten more difficult over time. At first, it was 8 characters with upper, lower case characters and a number or special character. The focus has shifted away from the types of characters and toward the length of the password. Common recommendations now say a strong password is at least 15 characters.

A popular recommendation from security professionals has been to use a password manager. A password manager allows you to store your passwords and protect them with a master password. The master password means that you only have to remember one long, complex password.

Using a password manager has many benefits. First, it allows you to store long, complex passwords without worrying about forgetting them. Second, it allows you to just copy and paste your passwords when signing into an application. This may not seem like that big of a deal, but many malicious programs use key loggers to steal passwords. If you paste the password in, and don’t type it, a key logger is useless. There are ways to grab data from the clipboard, but they are a less used tactic.

Some applications have started disabling the paste feature on password fields. This exists on some change password forms. The concern is that a typo entered in the password field would go unnoticed if pasted into the verify password field. The risk is the escalated customer support costs for lost passwords or account lockouts. Whether this is a valid risk is up to you. Few good reasons exist for disabling the paste feature on a password field.

The concern of recent is that the password field on the login form disables paste. In turn, this breaks many password managers. The benefits of good password management become degraded. Often, the reasons are due to a misunderstanding of how passwords are attacked.

Attackers do not rely on paste functionality for brute force attempts. In most situations, the attacker doesn’t even use the user interface for the attack. These type of attributes become useless against an attacker. Unfortunately, they only have a negative effect on the end user.

Don’t confuse disabling paste with disabling the autocomplete feature of a password field. Autocomplete is used for browsers to remember data for specific fields. While this is like what a password manager does, they are different. Autocomplete has been abused in the past and represents different issues.

Applications should be encouraging the use of password managers. They provide better password hygiene and ultimately help reduce the risk to the application. If you are making the decision to block the paste feature, prepare to answer to that decision. If the decision is well thought out and understood it will be easier to accept. Understand the reasoning behind the decision. It will generate a more enjoyable user experience.

If you experience an application that blocks your password manager, let them know. It is possible that they don’t even know it is an issue. As a customer, your opinion should matter. Stay positive and provide accurate information. Stay away from a negative stance. It will just make the business ignore your position.

by Leave a Comment

The FTC’s “Start with Security: A Guide for Business” Document

The FTC recently released a document to help companies learn from others’ security mistakes. The document titled Start with Security: A Guide for Business. It provides ten (10) different security lessons learned by other companies, included below:

  1. Start with security.
  2. Control access to data sensibly.
  3. Require secure passwords and authentication.
  4. Store sensitive personal information securely and protect it during transmission.
  5. Segment your network and monitor who’s trying to get in and out.
  6. Secure remote access to your network.
  7. Apply sound security practices when developing new products.
  8. Make sure your service providers implement reasonable security measures.
  9. Put procedures in place to keep your security current and address vulnerabilities that may arise.
  10. Secure paper, physical media and devices.

The thing I find unique about this document is that it is not technical, actually quite the opposite. It is a high-level description of the security lesson. Additionally, it identifies businesses that have had cases brought against them.

It is great to see a new approach to identifying why security is important. Using lessons from other companies shows a direct relation to the security lesson. It is no longer a matter of theory, these things do have consequences.

I have recorded a 20 minute podcast providing an overview of the document. I will also be breaking down a few of the topics to cover them in a little more detail. I recommend taking a moment to take a look at the document the FTC has provided. It is a quick read.