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.