Unseen Exposure – Tackling the Pervasive Server Remote Access Issue
One of my philosophies regarding the proliferation of relatively straightforward cloud security issues – those that are basically uncomplicated, yet challenging to address based on sheer volume – is that “simple doesn’t scale”.
That’s to say that while many of the problematic cloud security issues we face today are relatively predictable in terms of underlying conditions, the volume and frequency of their occurrence makes for disproportionately difficult prevention.
The second installment of our series on the Top 10 Cloud Attack Killchains highlights just such an issue – Compromised Server via Exposed Remote Access Ports – specifically, the unintended exposure of Ports 22 and 3389 across many cloud implementations.
As my research partner Shawn Harris and I touched on in our RSA presentation last month, the reality is that in nearly every cloud environment we observe, including our own, this problem remains utterly persistent. Of course, nobody seems to think they suffer from it, but just about everyone does.
The biggest culprit here is misconfiguration and a lack of visibility into the issue. This is based on the fact that, despite the well-known risk associated with exposure of admin ports to the Internet, today’s cloud platforms frequently make it difficult to prevent and detect the situation. In fact, cloud providers frequently open these ports by default in their security groups when invoking certain guided processes.
For example, creating a new instance in the Amazon console will offer the option to create a “launch-wizard” security group with ports 22 or 3389 open by default. In Azure, network security groups are not present by default and if you create a new virtual machine using the portal wizard, the default is to leave the ports open to the Internet (Azure does provide warnings).
Other factors include some organizations’ habit of ignoring recommended best practices around admin use of Internet-based access in the name of allowing greater expediency. Also, even though security groups are software-defined and easy to change in portals, even properly configured groups can become insecure over time due to editing. Instances, virtual machines and containers may, of course, also be accidentally launched into the wrong security group.
Meanwhile, attackers continuously scan the Internet for these ports and then perform both automated and manual attacks to see if they can infiltrate exposed environments. Common techniques include brute-force and software vulnerability attacks.
If you want any further proof of the scale of this issue, consider that a recent Shodan search turned up nearly 3 million SSH servers related to Amazon environments alone.
The good news is that there are also some fairly simple remedies that can be applied to unearth and solve the Server Remote Access issue. From a DisruptOps guardrails perspective the basic advice is:
- Manage Internet exposed administrative servers
- Manage internet exposed resources
Beyond that topline advice, you should focus on continuously monitoring, continuously alerting, and building this approach into your templates as you deploy in your environment – this goes a long way.
As Shawn detailed in our talk, in Azure, there is also the opportunity to manage exposure via security group audits, as the Azure Security Center vulnerability management functions will alert if you have accessible SSH or RDP systems.
My experience with AWS assessments has found that the use of available tooling, both commercial and open source – including the DisruptOps’ Cloud Detection and Response platform – allows you to isolate most of these exposures.
Given what we’ve outlined here, this work obviously needs to be performed on a continuous basis, and at-scale, which is where our approach of enlisting significant automation to cover the environment is a critical enabler of overall success.
Another key is ensuring that you have optimized related policies; while it can be harder to prevent exposure proactively in AWS using this approach, it is somewhat easier in Azure.
In general, my best advice is to continuously assess security groups/network security groups for Internet-facing ports 22 / 3389 using, among other tools and techniques:
- AWS Trusted Advisor [available even at the free/basic support level]
- AWS Security Hub via the CIS AWS Foundations compliance policy
- Writing a Config Rule to seek exposure on any security group config change
- Open source tools Prowler, CloudMapper, and Scout Suite
- Restricting ports 22 and 3389 to known IP address sources
- Avoiding use of default and weak passwords
- And keeping systems patched to reduce the risk of vulnerabilities
Hopefully this helps inform your approach as you seek to downplay this seemingly irrepressible, endemic condition. Amidst the current global pandemic, I will save you any further metaphors about the benefits of consistent testing and hygiene.
Stay safe people!