Unconventional attack surfaces

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.

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.

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.

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. 

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.

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.

Figure 2: Security risks associated with remote working

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.