Pay Attention to Your Non-Production Subdomains

It’s common for security teams to focus their best efforts on an organization’s primary production domain. After all, the application that carries the most traffic for that organization generates revenue. The data exposed there is the biggest target for attackers. It makes sense that securing this is the most important thing, but it’s not everything.

If you’re not convinced, then it’s time to think like an attacker for a little bit. What might be accomplished by aiming at a target that’s (on the surface) less valuable? Is it possible that a vulnerable lesser target can help you make inroads to reach the primary target?

Let’s find out.

Attack Strategy: Find the Weak Points

When thinking about how to get into a well-defended fortress, no intelligent attacker would walk right up to the front door and try to knock it down. This wouldn’t be their sole attack strategy. Instead, they would try to find the weak points in the defenses.

Web security is no different. This is especially true in the world of cloud computing, as today’s organizations are leveraging cloud portability for flexibility and easy scaling. For example, with Linode, you can spin up a new instance of an application with the simple click of a button.

However, the conveniences of cloud computing need to be accompanied by secure practices. Rather than adding functionality to the main application, which has all of the strong security around it, some engineering sub-teams might find it easier to build a new application and deploy it to a subdomain. Sure, these sub-teams aren’t trying to expose their organization to an attack. However, by expanding their organization’s web footprint with new applications and subdomains, they’re increasing the attack surface and making it more challenging to secure the entire environment.

Keep in mind also that non-production application instances on subdomains probably need to communicate with the main application or at least with its datastore. This is where an attacker can find a path from a less secure system into a more secure system.

Defense Strategy: Know Your Perimeter

Let’s return to our fortress metaphor. One of the best ways for an attacker to find weaknesses is to scout out the entire perimeter of the target. So, if you’re thinking like an attacker, then finding all the possible points of attack is a great first step in making sure the systems are well-secured.

Tools like Sublist3r are designed for security teams and penetration testers. They help you monitor your perimeter and know what has been deployed. However, an attacker can also use them to enumerate all of the subdomains that are in use.

Nonetheless, the starting point for setting up defenses is to monitor all of the ways into your system.

Learning from Others’ Mistakes

I recently encountered a perfect example of this type of situation with a site that I was analyzing. The company had gone through great pains to ensure that its main site was well-defended, secured with TLS 1.3, and even certified as PCI-DSS compliant. That’s a lot of work!

But… they also ran a content management system on a subdomain that wasn’t even secured with SSL/HTTPS. 🤦🏻‍♂️ All traffic to this CMS—even authentication—was running completely in the clear.

Even Google Chrome knows this is a problem, and it puts up the big “Not Secure” warning on the URL bar. Since this is a login page, the username and password will be transmitted in plain text over the wire. Any sufficiently motivated attacker could get this by intercepting traffic at the ISP or network level. Then, they could use those credentials to attack another system owned by the same company. What are the chances that some credentials on this subdomain are reused in other apps within the same company? I’d say they’re pretty high.

Alternatively, the attacker could gain access to the CMS and embed malware or malicious JavaScript into the application, subsequently exposing customer data when employees access other systems.

A great deal of effort went into securing this company’s main application, its pride and joy. The front gate is locked down with guards posted everywhere. Meanwhile, the back door is wide open, and nobody is watching it.

Conclusion

Most people don’t think that sub-production domains are a huge risk. “It’s security through obscurity,” they say. Hopefully, this simple example has made it clearer as to why that’s a poor security strategy. It doesn’t matter how small the system or application is. If your business deploys it, then it needs to be part of your security focus.

Here are some practical steps you can take today:

1. Scan your domains to create an inventory of all the subdomains that are currently in use.
2. Rank each subdomain for both ease of exploitability and impact on your business if it is exploited.
3. Deploy security tools to lock down the subdomain that is most easily exploitable and would most impact your business.
4. Work your way down the list as you have the resources and bandwidth to do so.

It’s okay to start by securing your subdomains a little bit at a time. That’s certainly better than not doing anything at all! Don’t let perfection be the enemy of the good. The important thing is to keep in mind that any solutions you have deployed to the internet introduce a degree of risk. And anywhere that you have risk, you should pay attention to its security. Attackers don’t need to take over your whole company to cause significant damage, so even non-critical systems are worth treating with the gravity your company deserves for continued health.

Thinking like an attacker is a great start. Staying vigilant for vulnerabilities and rooting out any place where someone could gain a foothold and lurk for a while before expanding their attack is a huge step toward ensuring your business doesn’t become the next big cybersecurity news story.

To learn more about security, check out Linode’s extensive library of security-related docs and guides.