Don’t Shortchange Your Organization’s Security With URL Shortener Services

FROM SHORTENED LINKS TO FULL COMPROMISE

A key value of continuous testing through Continuous Attack Surface Testing (Cosmos) is having a team of diverse experts that are always looking for new weak points in your attack surface. Once they find these weak points, they aren’t just leaving it there, they’re digging into how that finding can be used by an attacker to further compromise your systems. Additionally, with Cosmos, you’re not relying on a single individual’s expertise, but a team of experts with diverse backgrounds. Backgrounds that allow them to work off one another’s findings to achieve high-impact results.

SETTING THE SCENE – THINKING LIKE A RED TEAM IN THREE ACTS

The organization at the center of this investigation, which we’ll call “The Company,” had a somewhat unique attack surface. It was different than the typical legacy environments that are built using Windows Active Directory and other services you would typically find in a well-established organization. Looking from the outside, there weren’t many threads for our team to pull on because everything was built using a micro-service architecture living in a cloud environment serving mainly mobile application requests. In situations where our internal scanning tool struggles to give us leads, our team of talented Analysts roll up their sleeves to find alternative methods to generate leads for our Cosmos Operators to investigate.

ACT I - THE INTERNET NEVER FORGETS

Recently, while conducting some research on URL shortening services, one of our Analysts came across a tool called URLHunter. This publicly available open source tool allows users to automate the download and search of large indexes of shortened URLs and their fully resolved counterparts (i.e., bit.ly/BF -> https://www.bishopfox.com) These indexes are generated daily and uploaded to the Internet Archive thanks to another group of individuals that call themselves the URL Team. The URL Team uses a technique called brute-forcing to identify valid links with these URL shortener services and store the full path real URLs in their archives for future reference.

URL shortening services are not new; many have been around for well over a decade. They provide a convenient way for users to share long and hard to remember links, but it is also well-known that security risks arise from short URL usage. This time around, however, the internet’s ability to always remember, combined with an individual’s misunderstanding of another service’s security controls, gave our Analyst a treasure trove of information.

ACT II - ALL THAT IS PRIVATE MAY BE SECRET, BUT NOT ALL SECRETS ARE PRIVATE

Using URL archives identified previously, our Analyst ran a few keyword searches looking for resources related to the “The Company” as part of their investigation. To their surprise, they identified a few dozen URLs pointing to gist.githubusercontent.com for a GitHub user associated with “The Company.”

Before we go any further, let’s briefly talk about what a gist is and what types of content gist.githubusercontent.com can hold. A gist is a repository that stores content created under a GitHub user’s account. There are two types of gists: public and secret. Public gists are discoverable by other users on the GitHub platform. A user who creates a public gist doesn’t even need to share them because, by definition, their visibility is set to public, and they are automatically shared in GitHub’s Discover dashboard for others to see. Secret gists, on the other hand, are not public but they are not private either. Secret gists hide behind hard to guess URLs but, once a secret gist link is shared with another person or posted on a platform, the content of this secret gist is no longer a secret and can be accessed by anyone who discovers the link.

At first, the nature of the content in the gists and the intended visibility of the discovered links wasn’t obvious to the Analyst, however, after a careful review they quickly realized that they were in possession of VPN configuration profiles generated by an employee of “The Company.” These VPN profiles contained user email addresses and passwords as well as the certificate needed to authenticate with the organization’s VPN server.

While sharing such sensitive data, it is fairly common for users inside an organization to send links to other parties via email or messaging platforms and, since communications via such platforms are generally protected by authentication and authorization mechanisms, this method is considered a safe way to share sensitive information. It is when sensitive information is shared via platforms that do not require authentication or authorization like URL shortening services, users can find themselves in a lot of trouble unwittingly disclosing sensitive data.

ACT III - THE CARNAGE PART I

With access to VPN user profiles the case was then turned over to our Operators for further investigation. Operators quickly determined a set of active user accounts and gained access to the internal company network without much effort. Using each active account, Operators determined VPN access level for the user profiles. Looking for the highest level of access on the internal network, our Operators scraped LinkedIn profiles of users and tried making educated guesses on the level of access each user may have been given based on their job title and role. At the end of this effort, the team had found less than a handful of profiles with unlimited access to the organization’s internal network via this VPN connection.

Once on the VPN, the team had access to multiple subnets on the internal network. Based on the subnet sizing, the team determined it would be infeasible to visit every IP and every open port to discover what was available to them internally. However, a quick ping scan on one of the subnets revealed a service discovery endpoint – which listed every other microservice in the internal network. This service acted like a map for our team for the rest of the investigation.

Using the service discovery platform, our team was able to identify over 7,000 unique targets (scheme://host:port) that the team internally had access to, the majority of which were not password protected.

One service in particular, Apache Airflow, caught the team’s attention. Apache Airflow is an open-source platform that is used to manage and orchestrate complex workflows. In this instance it was accessible without any authentication, allowing the team to execute or terminate business critical tasks in the service with the single click of a button from the user interface. Organizations should ensure they’re not leaving a mechanism that runs day-to-day business operations without security controls in place.

After initial reconnaissance was over, the team had access to the following services and more:

• Apache Airflow (workflow manager)

• Celery Flower (message queueing system)

• Consul (microservices management framework)

• Salt Stack (config management)

• Kubernetes (container orchestration)

• SonarQube (Static code analysis)

• Kibana (ElasticSearch visualization)

• AWS metadata (AWS keys / deploy scripts / ssh keys)

• Internal DNS server

THE CARNAGE PART II - FULL COMPROMISE

During the post-exploitation phase one of the Operators identified an outdated Elasticsearch instance against which they were able to achieve remote code execution on the service’s host. At that point, the Operator retrieved AWS credentials from the service’s metadata endpoint as well as an SSH deploy key with read/write access to deployment scripts.

Using the SSH key obtained from the previous step, the Operator was also able to fetch a repository that contained deployment scripts for the organization’s entire infrastructure including their development and production environments. In an effort to validate the severity of their discovery, Cosmos members communicated their findings with the customer who responded back with surprise at how much information the Cosmos team was able to obtain. They commended our efforts and said we’d achieved a “full compromise of their environment.”

BUSINESS IMPACT

The user error that caused the leaking of the sensitive information could have allowed an attacker to obtain extensive access to the organization’s infrastructure and critical data. Because the Operators acted as an extension of the client’s security team, they were able to offer guidance on how to deal with these risk areas before attackers could exploit them. Beyond that, the write access the team was able to achieve on the private deployment repositories could have allowed attackers to backdoor code used to deploy all infrastructure within the environment to gain persistence. It’s important to remember this all started with a shortened URL.

This investigation illustrates the full depth of risk presented by URL shortening services. They may seem like a helpful utility, and most of us may just take them for granted, but they can represent a serious risk to your organization. What other taken-for-granted utilities might be leaving your network open to risk?

KEY TAKEAWAYS

• Do not share sensitive documents and information on platforms that are not protected by authentication and authorization mechanisms. Services utilizing hard to guess URL schemes to hide resources do not provide safety for those resources but simply obscure their visibility until their presence is leaked via other means.

• Do not use URL shortener services. The shortened URLs are indexed by third parties, and even if the final destination of the actual URL resides behind a protected network, there may still be ways to obtain a lot of information just from the URL. In some cases, query parameters used in URLs can leak a great deal of information.

• Build systems with "defense in depth" principle.

  • Put critical/sensitive services on an internal network that is not publicly accessible.

  • Provide access to such networks via a tightly controlled and audited VPN connection.

    • Make two factor authentication mandatory for VPN users.

    • Limit user access to these networks with access control lists.

  • Segment critical services away from others and log and monitor all activity between services to detect unusual patterns.

  • Password protect and enforce two factor authentication for all services that allow user interaction.

  • Always use the most up to date versions of software to limit exploitation and privilege escalation.

  • Pay extra attention to proper credential storage on hosts and never reuse credentials across different services or environments.