Unconventional attack surfaces
An attack surface is the name given to all the targetable assets owned by an organization that could provide access to internal networks or sensitive information if they were compromised.
Organizations often focus on conventional assets like domains, subdomains, IP addresses, and IP ranges when managing their attack surface because these are relatively easy to monitor and track.
However, unconventional types of attack surface are often overlooked. Unconventional attack surface assets wouldn't typically be in scope of a standard penetration test or included in your asset lists, but they can give an attacker information or even lead to them gaining a foothold. They are things like public GitHub repositories and job adverts.
Information is power
Traditionally, security teams focus on conventional vulnerabilities, but unconventional assets can be dangerous too. If, for example, an attacker can look at a job listing for an in-house cyber security specialist and see that the role requires proficiency in a certain EDR product, the attacker can gain an immediate useful insight into your environment without sending any traffic into it or triggering any defenses at all.
Our attack surface management team have outlined several examples of unconventional attack surfaces they have seen in their day-to-day work.
Example 1: Postman
The Postman platform is used for developing and building APIs, which can be done collaboratively. The workspaces are set to private by default, meaning only the owner and specifically selected users can access the workspace and the information within it. However, users can make their workspaces public. If they do, information such as API keys, usernames, and passwords become exposed and accessible via the internet.
Katie Inns, a Security Consultant in our Attack Surface Management team, told us how she took advantage of one instance of this type of public exposure when working with a client.
“An employee we’ll call ‘Tom’ was developing a new API with his global team, using Postman to collaborate on the project. Tom was on a hard deadline and wasn’t really thinking about security, so he set his workspace to public so that everyone on the team could access it.
As a result, lots of information was disclosed to the internet. We found a username and password, and we had a hunch that these credentials would be used across other applications. We tried the logins and initially they were invalid, but then we incremented the number at the end of the password by two (because it had been two months since these credentials were disclosed), and they worked. That easily, we had access to the client’s internal applications.”
Katie found the Postman workspace simply by searching for it with a Google query, entering site:www.postman.com “password”. You can include any other relevant keywords in a search like this, such as APIkey, username, or the name of the company.
Figure 1: Searching for a Postman workspace
In the long term, we recommend that you consider not using externally facing tools for development, and instead use internal solutions for collaboration.
Example 2: Code formatters
Security professionals often talk about not putting sensitive data into external websites, because you never know where it will end up.
Our team shared some of the information they have found in the past just by looking in the right places. For example, security analysts, developers, and service desk employees using popular services like code formatters and converters often input sensitive information, but when that is saved it is available to be detected by Google Crawlers and may be indexed in the Google engine.
Members of our team have found payroll information, password manager outputs, and credentials that have been mistakenly made public in this way.
To remediate cases where information has been unintentionally exposed, we recommend removing sensitive information that has been disclosed, making repositories and workspaces private, and assuming credentials are compromised and cycling them regularly.
Example 3: Remote working and VPNs
Jake Knott, a Security Consultant in our Attack Surface Management team, is used to finding misconfigured endpoints when assessing client’s environments. However, he has recently found indicators of client assets popping up in unexpected locations.
“One of our clients is based solely in the UK, but we found endpoints from their environment in India, Hong Kong, and Spain. It was unusual, and we eventually realized it was being caused by remote workers, who were working in those countries and were exposed on their residential broadband.
Because these exposures were caused by remote working, when we did an internet-wide scan during UK working hours we had very different results to scans conducted at other times.
We found misconfigured endpoints that did not restrict remote desktop protocol (RDP). We found employees using free VPN software that exposed their corporate assets in weird places like Panama. We also saw onboarded personal devices that had not undergone hardening checks.”
Figure 2: Security risks associated with remote working
Putting it together
Each of the three examples described above are problematic, but consider a scenario where some or all of these exposures exist in one organization.
Tom is still using his public workspace in Postman to develop his API. His domain credentials are exposed through Postman, and so is his RDP through his residential broadband. An attacker can use the credentials found in Postman to authenticate an RDP session, gaining access to Tom’s corporate network and the sensitive information within it.
To avoid a scenario like the one described above, we recommend you lock down RDP to internal ranges only and monitor incoming RDP from non-corporate ranges, restrict the use of free VPNs or third-party VPN solutions, and develop standards around the use of personal devices for work, including requiring hardening for any devices that will connect with the network.
Packet Total allows users to upload PCAP files, which can include captured traffic from within their corporate internal environment. Anyone can access these PCAP files, download them, open them in Wireshark, and access the internal network communications, including information like naming conventions and Active Directory structures.
Our team have seen a boom in the number of images being put on the Docker Registry. If you are not using Docker Pro, these images are public by default, so they can be mined for credentials. Our team have previously found hard-coded licenses and keys and gotten access to paid professional tools, which gave them several major insights into the environment and would have (had they been malicious attackers) given them a leg up on the competition.
Public Kanban boards like Trello are a classic source of information. Our team often see credentials disclosed within Trello boards, similarly to in the Postman example.
This blog aimed to challenge your assumptions regarding your attack surface. We recommend that you reassess how everyday activities, such as collaboration between developers and the use of free online tools, can contribute to the external attack surface and increase risk.
Performing regular self-assessments against your organization will help you to identify possible exposures, so give internal teams incentives to investigate and report issues without the threat of negative consequences. Open lines of communication can and will benefit the organization in the long run.
This blog was adapted from a presentation given by Katie Inns and Jake Knott. You can view the full talk here.