DevelopSec

network

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

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.

by Leave a Comment

The Importance of Baselines

To understand what is abnormal, we must first understand what is normal. All too often we have overlooked the basic first step of understanding and recording our baselines. Whether it is for network traffic, data input, or binary sizes it is imperative we understand what is normal. Once we have an understanding of what normal is it becomes easier to start identifying abnormalities that can be of concern.

Related podcast: Ep. 24: The Importance of Baselines

Take a moment to think about how we determine if our body is healthy or not. Of course, healthy can be relative. In general, we have some baselines. We know that the normal body temperature is 98.6 degrees with a slight deviation. WE have ranges for good pressure, cholesterol, blood/sugar, etc. With the body there are usually “normal” ranges for many of these values. This is true for our information systems as well.

What is the average size of a 302 redirect from a web server: 1 KiloByte, 100 KiloBytes, 1 MegaByte? Lets say that it is less then 1kb, this makes it easier to understand that if you have 302 redirects that are 500kb then something may be going on and an investigation is in order. While this doesn’t always mean there is a problem, it is that initial event to look at the situation to determine if something is going on.

Having a baseline of the size of applications that are installed on your system may also help identify if an application binary has been modified. Maybe a malicious application has been placed on the system that replaces calc.exe but is 2MB larger than the original one. It may be possible that this was just a software update, but could also mean it is an imposter.

These same questions apply to network traffic as well. Understanding the types of traffic and amount of traffic that generally pass through the network is critical when it comes to identifying an attack. It is not enough to just say a spike in traffic at any given time is a potential concern. It may be possible a legitimate event was happening. Imagine if your backups ran between 3 and 5am every morning and the network saw a spike in traffic. If you didn’t usually watch the traffic and saw that spike one day you might have serious concern. However, if you understand the traffic patterns it may turn out to be an ordinary event.

Once you understand these baselines it is possible to start creating events for things that are now abnormal. No guarantee that these events are malicious or of concern, but it is the starting point to what you are going to investigate. With so many things going on in our applications and networks, these baselines turn out to be critical for securing our systems.

The truth is, creating these baselines is going to be time consuming. Obviously a lot of that depends on your systems and the complexity of them. The time will be required, but is necessary for being able to detect many security related events. The good news is that you don’t need a security group to do this. The network administrators or engineers can do most of this since it is the lifelines of their networks that you will be measuring. The application developers and QA can certainly understand what is normal for the application. It doesn’t have to be a complex task. Start out small, use a spreadsheet or some other collaborative solution to record these values. Of course, that isn’t easy to trigger alerts off of, but that can be an initial first step. Once you get that maturing, then looking at solutions to identify these abnormalities and trigger events becomes imperative.