Clouded Judgment: how mismanaged cloud infrastructure can expose users to cyber risks

Introduction

Organizations today are no longer restricted to their geographic location to conduct business. The continued adoption of cloud technologies by companies across the globe has made their growth ubiquitous with on-demand access, improved team-wide collaboration and communication, low maintenance and operating costs, unlimited data storage and upkeep, processing, etc.

Having said that, accessing these cloud platforms requires users to tread carefully. Lax security while configuring these services can very well lead to exposed vulnerabilities.

And while the cloud security risks increase, the information available on the subject is scarce. In our new blog, we shed light on the common mistakes users and management make when configuring their public cloud environments; focusing on public buckets and user repositories and demonstrating how these vulnerabilities can be eliminated.

With over 19 years of experience in researching cybercrime, we aim to leverage our extensive expertise in providing security assessment services for a wide range of objects such as portals, cloud services, and different infrastructures.

The goal of this blog is to assist cybersecurity professionals in establishing robust protection for their information systems by providing a better understanding of the techniques and tactics employed by threat actors during external network reconnaissance. For this reason, the article is written from the perspective of a specialist conducting such reconnaissance. It does not disclose vulnerabilities that could be exploited to harm companies.

Our focus is on SaaS solutions*, which are specific to each region of use. Building upon our knowledge, we aim to assist cybersecurity professionals on the defensive side in understanding the services their company may use, the potential threats they may face, and, most importantly, how to protect them.

Public bucket*  is a directory or storage container created by a cloud service provider that is accessible to the public.

Saas solutions* are cloud-based software applications that businesses can access over the internet through various subscription models. These solutions are centrally-hosted and managed by the cloud service provider.

Data visibility and security in the cloud context

Clouds often provide the services related to continuous integration, continuous deployment (CI/CD), orchestration, custom buckets, and content delivery networks (CDNs).

Beyond traditional SaaS solutions, businesses rely on various cloud-based services such as CRM systems, email services, corporate messengers, and wiki platforms. While these services offer operational efficiency, they can also introduce potential vectors through which threat actors can exploit vulnerabilities in your infrastructure.

To prevent this from happening, organizations need to defend their network from unwarranted intrusion by attackers.

But how? To begin with, all cloud service client companies need to ask themselves three simple questions:

• do all our users have two-factor authentication enabled?
• have we implemented a strong password policy?
• are our pages anonymized to make it more difficult to determine the ownership of a company resource?

Furthermore, it is important to understand what kind of services can be found in the cloud and how they are searched for.

Let’s begin by analyzing the most popular cloud service solutions used by companies that hold mission-critical data which needs to be guarded. IT departments are far from always being aware of all SaaS solutions that a company uses, which means they cannot control how users access their accounts. This significantly increases the level of risk if, in a SaaS solution, employees give out VPN configs, account passwords, or exchange sensitive information.

Learn how the improper utilization of these platforms can put your data, operations, and business integrity at risk.

SaaS cloud services: security gaps due to inadequate usage

Slack

Slack is a popular corporate messaging platform that improves team collaboration, and efficiency by supporting every day discussions about work-related tasks and processes. It is also a good tool for integrating with access control systems, as Slack allows organizations to create bots that can issue VPN credentials, etc.

The Slack workspace* has its web address in the format: <company name>.slack.com. By adding a logo to the workspace, a company can create a clear identifier for its Slack workspace and confirm its ownership.

Workspace* – a collaborative space reserved for the company, which consists of various channels through which employees communicate.

Figure 1: Example of an existing workspace

Slack enables Single Sign-On (SSO)* through Google or Apple. A potential vulnerability in Slack’s registration process is that it only requires a corporate email, making it possible for attackers to self-register in a workspace by obtaining the login credentials of a low-privileged user (such as an account for sending email notifications). Cybercriminals may acquire such credentials from public leaks or other sources.

If an attacker conducting reconnaissance (information-gathering stage of a cyberattack) is unable to locate a Slack workspace using the company name or is uncertain whether a particular workspace is owned by the company, they may resort to using Google Dorking* or search on GitHub.

Developers sometimes share their bots on these platforms, providing a potential means of discovering the relevant Slack workspace. Also, as a rule, they usually collect the main domains of the company first and then try to get a workspace through ffuf, which is a utility designed to quickly discover directories, and header values ​​and automatically enter unexpected data in a web application (fuzzing).

ffuf -u https://FUZZ.slack.com -ignore-body -w domains.txt -mc 200

• ignore-body – allows you to not receive the response body
• mc 200 – (match code) Show only requests that received a response with code 200 (OK)

SSO* is an authentication scheme that allows a user to sign in with one identity from one section of the portal to another, or from one system to another unrelated system without re-authentication.

Google Dorking* is the use of search engine-specific commands and query syntaxes for more accurate searches.

Atlassian

To improve the security of a cloud service, it is important to be aware that companies can host various services like Jira, Confluence, and Bitbucket in the Atlassian cloud.

Unfortunately, some companies may not distinguish between the workspaces within the same Confluence (which is a collection of articles and materials), and may use it as an onboarding tool for new employees, granting access to all Wiki sections.

To avoid such a situation, it is necessary to correctly configure the access rights of various users, restricting it to the data necessary for business processes, along with implementing two-factor authentication and a strict password policy.

Also noteworthy is that through Confluence, one can access a list of all existing users, and in Jira, along with the list one can also access their email ids.

For enumeration and validation, one can also use ffuf for collecting through the primary domains of the company:

ffuf -u https://FUZZ.atlassian.net/login.jsp -ignore-body -w domains.txt

If an organization does not use Atlassian cloud services, then the perpetrator will see this picture:

Figure 2: What an invader sees when accessing a non-user organization’s Atlassian account

If it does, it will redirect to the address:

https://<subdomain>.atlassian.net/login?application=jira

It is important to mention that the value of the “application” parameter can be iterated over Confluence, Trello, Jira, etc.

Salesforce

Salesforce is a CRM system that details information about a company’s operations, sales, and customers. On the platform, all new users are assigned a temporary password, which they can subsequently change.

This presents an opportunity for attackers to engage in password guessing, as users tend to change the password to the one that is easy to remember, as well as duplicate passwords that are already used for personal accounts.

To access a company’s Salesforce cloud, one must navigate to <company name>.my.salesforce.com and search for subdomains, such as using the utility zdns:

zdns alookup –name-servers=8.8.8.8 -input-file domains.txt -output-file resolved.json

Alternatively, keyword searches can be conducted on various DNS record databases, such as rapiddns.io or omnisint.io.

Figure 5: Keyword search for Salesforce organizations’ domains in the DNS record database

Figure 6: Tag value when organization is non-existent on Salesforce

MS Office365

Microsoft Office365 offers a wide range of services, including Mail, Azure, Sharepoint, OneNote, Microsoft Teams, Skype, and OneDrive.

Single Sign-On (SSO) is used to log in to any of the Office365 services, which allows an attacker to gain access to certain information and sift through the company’s users.

Determining whether an organization uses Azure AD is relatively simple, i.e., by making a request to: https://login.microsoftonline.com/getuserrealm.srf?login=username@company.com&xml=1, one can check the NameSpaceType tag. If the tag returns a value of “Managed” then the company’s domain name is valid for the Office365 platform.

Figure 7: The “Managed” tag confirming the the domain is federated

Conversely, if the value is “Unknown,” the domain name is not valid.

Figure 8: The “Unknown” tag indicating the domain is not federated by Microsoft services

However, It is not necessary to know the valid email id, as one can check usage by simply entering the company’s domain, for example wwdwdwdwd@company.com

To know more about Office365 in detail, O365 Enum and tool are some of the recommended materials worth perusing.

Zendesk

Another CRM/ITSM system that uses cloud hosting for its services is Zendesk hosting domain (hosted at <company_name>.zendesk.com).

In case the company’s domain doesn’t exist, there will be no NXDOMAIN response, but the address of the CloudFlare server will be shown. The value of the “Location” header in the response to the request is used to determine the existence of the domain.

If the domain exists, the user will be redirected to it;  if there is no such domain, then the user will be redirected to the zendesk.com page or to the address: https://www.zendesk.com/app/help-center-closed/. 

The brand logos that the company places on the authorization page can greatly help in determining whether the domain belongs to the company or not. It is important to avoid guessing and instead follow best practices (more in the recommendations section below).

To determine the existence of a company using the ffuf utility, you can use the following command:

•  -r (redirects) option allows ffuf to request the page when redirecting (302,301)
• -H (header) option allows you to insert a header, such as User-Agent. By default, ffuf uses Fuzz Faster U Fool <version> as the user agent, which detects Cloudflare and blocks the request

Proofhub

Proofhub is a project and team management platform similar to Wrike, Trello, Jira, etc. As with Zendesk, a company can be identified by its subdomain on Proofhub. The existence of a company is checked with the following command:

-fs (filter size) option allows you to filter responses by size (between 60- 70 is the size of the response if the company does not exist).

S3 cloud services: security gaps due to inadequate usage

In this part of the blog, we will look at the possibilities to conduct reconnaissance of S3 (Simple Storage Service) solutions that provide organizations with the ability to store unstructured data in the cloud at scale.

Scaleway

Scaleway is a popular French cloud service provider which has Amazon S3-compatible object storage service. It has endpoints for buckets’ support – both virtual hosts and path-style URLs, which are used in the following format:

• https://<bucket>.s3.<region>.scw.cloud
• https://s3.<region>.scw.cloud/<bucket>

Scaleway S3 is represented in the following regions:

• nl-ams (Amsterdam, The Netherlands)
• fr-par (Paris, France)
• pl-waw (Warsaw, Poland)

It also supports CNAME, but with the catch that the CNAME mode is available for http only, which makes the transfer of files non-secure.

Figure 13: Screenshot from an official documentation on http only

To enable public access to Scaleway buckets, one needs to change the Access Control List (ACL) to “public-read” as indicated in their documentation. This can be done using the following command:

From the Amazon documentation linked above, you can see that public-read is granted to the AllUsers group, which is a predefined group consisting of authenticated and anonymous users, meaning that you either should have an AWS account or no account at all which makes storage publicly accessible.

Figure 14: Screenshot from documentation on public-read permissions

It is a no-brainer that this poses several risks. In the following screen, you can see publicly accessible storage with the listing of files:

Figure 15: Tag value indicating that the file listing is available on this bucket

In case the bucket exists but has no public access, an “access denied” message will be displayed. However, even in this scenario, it is possible to perform a brute-force attack to find existing keys.

If the bucket does not exist, the users will see “nosuchbucket”

Figure 18: The bucket doesn’t exist

Scaleway currently does not provide built-in encryption for their services, and encryption can only be implemented on the client side using external tools. However, Scaleway has encryption features in its backlog and is actively working on developing them, as stated on its feature request page.

Exoscale

Exoscale is a Swiss-based cloud provider, offering object storage service with data centers located in four different countries – Germany, Austria, Switzerland, and Bulgaria. The main endpoints for Exoscale’s object storage service include the path-style endpoint, which is in the form of https://sos-<datacenter-code>.exo.io, and the virtual-host style endpoint, which is in the form of https://<custom-domain>/sos, making it easy to access the service from different locations

• https://sos-ch-dk-2.exo.io/<bucket> (Zurich)
• https://sos-bg-sof-1.exe.io/<bucket> (Sofia)
• https://sos-de-muc-1.exo.io/<bucket> (Munich)
• https://sos-de-fra-1.exo.io/<bucket> (Frankfurt)
• https://sos-at-vie-1.exo.io/<bucket> (Vienne)
• https://sos-ch-gva-2.exo.io/<bucket> (Geneva)

Figure 19: View of the open bucket

If a bucket exists but its Access Control List (ACL) denies public access, the user will receive an “access denied” message.

Figure 20: No public access to the ACL

If the bucket doesn’t exist then the user will get a “specified bucket does not exist” message.

Figure 21: The message indicating that the bucket does not exist

OVHCloud

This French cloud service provider offers a range of choices for storing data in object storage and provides customers with different storage classes including standard, high performance, and object storage SWIFT – Standard – Legacy. Each storage class varies in hardware and accessibility, using either SWIFT or S3 API.

Endpoints in the regions are:

• s3.gra.io.cloud.ovh.net (Gravelines)  Object Storage S3 – Standard
• s3.sbg.io.cloud.ovh.net (Strasbourg) Object Storage S3 – Standard
• s3.bhs.io.cloud.ovh.net (Beauharnois) Object Storage S3 – Standard
• s3.rbx.io.cloud.ovh.net (Roubaix) Object Storage S3 – Standard
• s3.gra.perf.cloud.ovh.net Object Storage S3 – High Performance
• s3.sbg.perf.cloud.ovh.net Object Storage S3 – High Performance
• s3.bhs.perf.cloud.ovh.net Object Storage S3 – High Performance
• s3.sbg.cloud.ovh.net Object Storage SWIFT – Standard – Legacy
• s3.uk.cloud.ovh.net (London) Object Storage SWIFT – Standard – Legacy
• s3.de.cloud.ovh.net (Frankfurt) Object Storage SWIFT – Standard – Legacy
• s3.waw.cloud.ovh.net (Warsaw) Object Storage SWIFT – Standard – Legacy
• s3.bhs.cloud.ovh.net Object Storage SWIFT – Standard – Legacy
• s3.gra.cloud.ovh.net Object Storage SWIFT – Standard – Legacy

OVHCloud supports only virtual-host style endpoint so the format for bucket enumeration is:

https://<bucket>.s3.<region>.cloud.ovh.net

An upside is that OVHCloud supports server-side encryption of object storage data. Below is the image of how the buckets can be enumerated, so that if the bucket exists and has public access enabled, one can view the files listed.

Figure 22: The tag value when public access is enabled

If the bucket doesn’t exist then you will get the following message:

Figure 22: The tag value when the bucket doesn’t exist

The positive aspect of defensive measures is in case that a key does not exist, it will not indicate it in the error message, which will simply state “access denied.”

Figure 24: No key enumeration is possible when bucket is not publicly accessible

Ionos

Ionos is a German cloud hosting service provider that offers S3 object storage. It supports both path-style and virtual-host-style URLs for accessing buckets. Additionally, Ionos provides server-side encryption for its customers’ data, which ensures an additional layer of security for sensitive information.

This feature encrypts the data on the server-side and allows customers to manage their encryption keys, adding an extra layer of control and protection over their data.

The IONOS S3 Object Storage Service endpoints are listed below:

• https://s3-eu-central-1.ionoscloud.com (Frankfurt, Germany (EU Central))
• https://s3-eu-central-2.ionoscloud.com (Berlin, Germany (EU Central))
• https://s3-eu-south-2.ionoscloud.com (Logrono, Spain (EU South))

And legacy endpoints (data may be replicated)

• https://s3-de-central.profitbricks.com
• https://s3-eu-central-2.profitbricks.com
• https://s3-eu-south-2.profitbricks.com

Interestingly, when a bucket is publicly accessible on Ionos, one can, at times view the bucket owner’s email address.

Figure 25: Public access is enabled and reveals the owner’s email address

If a bucket exists, it states access denied; no key enumeration is possible.

Figure 26: No key enumeration is possible when access is denied

If a bucket doesn’t exist, it states “The specified bucket does not exist.”

Figure 27: Tag value indicating that the bucket doesn’t exist

Linode

This US cloud provider supports server-side encryption and both virtual-host and path-style URLs for accessing object storage. The object storage is represented in following endpoints:

• https://us-southeast-1.linodeobjects.com (Atlanta, GA, USA)
• https://eu-central-1.linodeobjects.com (Frankfurt, Germany)
• https://us-east-1.linodeobjects.com (Newark, NJ, USA)
• https://ap-south-1.linodeobjects.com (Singapore)

An image of the publicly accessible bucket:

Figure 28: Tag value of a publicly accessible bucket

As you can see in <DisplayName> attribute, there is no owner’s email address but there is canonical user ID, as stated in official documentation of Linode:

“Each Object Storage account is given its own canonical user ID, which can be used to identify a specific account or share resources between accounts. This ID consists of a long string of letters, dashes, and numbers, such as a0000000-000a-0000-0000-00d0ff0f0000.”

This helps improve security by not disclosing the owner’s email address. However, it would’ve been much more substantive if no information was disclosed, not even a canonical user ID. The positive aspect of the defensive side is that there is no key enumeration if access is denied.

Figure 29: No key enumeration is possible when bucket is private

Vultr

Another US cloud provider, Vultr, doesn’t offer server-side encryption in its object storage service but supports both path-style and virtual-host style URLs. Object storage of Vultr is served with following endpoints:

• https://ams1.vultrobjects.com (Amsterdam)
• https://blr1.vultrobjects.com (Bangalore)
• https://ewr1.vultrobjects.com (New Jersey)
• https://sjc1.vultrobjects.com (Silicon Valley)
• https://sgp1.vultrobjects.com (Singapore)

One Vultr, the owner’s <Display Name> is the same as <ID>, and It’s presumed that they represent the user’s ID in the Vultr’s system and consist of only digits.

Figure 30: User ID is revealed with open public access

Key enumeration is not possible but bucket enumeration is

Digital Ocean

Digital Ocean provides a service called Spaces which is an S3-compatible object storage. It supports both path-style and virtual-host style URLs. The files on hard disks are said to be encrypted. Moreover, you can encrypt them as well with client-side encryption.

Digital Ocean has following endpoints:

• https://nyc3.digitaloceanspaces.com
• https://fra1.digitaloceanspaces.com
• https://sfo2.digitaloceanspaces.com
• https://sfo3.digitaloceanspaces.com
• https://ams3.digitaloceanspaces.com
• https://sgp1.digitaloceanspaces.com

It doesn’t allow key enumeration if access to the bucket is denied and also shows leakage of the owner’s ID if the bucket is public.

Figure 33: Tag value indicating a publicly accessible bucket

No key enumeration is possible when public access is denied.

Upcloud

No enumeration of buckets is possible in Upcloud. Enumerating the buckets is not possible if the storage is private; all the existing and non-existing bucket will only produce an “access denied” message. It is only possible to guess the pair of the bucket.storage and hope for it to be publicly available.

Group-IB experts also found 2 projects with an interesting mechanism of creating buckets and making them public – Fuga and Contabo cloud providers. Their object storage systems have the following format:

https://<endpoint>/<project id>:<bucket name>/

The Project ID is just a random alphanumeric string that is almost impossible to guess. Important to note is that guessing the bucket name concurrently makes buckets protected from enumeration. The only thing to do is leverage Google Dorking to uncover the mentions of direct URLs to buckets in GitHub, Google, etc.

Checking the conventions: naming buckets and protection of SaaS cloud solution

While we mentioned the most prevalent cloud services, there are almost an infinite number of options available, making it impossible to cover them all due to their sheer volume and regional specificity. Therefore, to aid readers in their search for the services discussed in this article, Group-IB experts have created a dedicated tool.

The tool serves a dual purpose – firstly, it can help determine the predictability of bucket names and personal domains used by SaaS companies. Secondly, it can be used to check whether any particular service has expanded beyond the realm of IT services.

It is crucial to address the vulnerabilities associated with the discovered domains and custom buckets, which can widen the attack surface and potentially expose sensitive information to unauthorized access.

Therefore, to enhance protection for companies using SaaS cloud solutions or S3 storage, we have outlined the primary ways of gathering essential “intelligence.”

Checklist: 7 essential steps to protect your public cloud data now

Step 1: Leave no room for guessing for perpetrators. Depersonalize the company as much as possible while using a SaaS solution. Despite any objections from teams, prioritize security by removing the company logo and minimizing the use of corporate identity in drop-down windows/dies/stubs. Ideally, a name distinct from the company’s name should be used to create more uncertainty for the threat actors regarding the relevance of an attack.

Step 2: Set a strict password policy for SaaS accounts and control its implementation. Employees tend to use easy passwords or reuse passwords they have for personal accounts, which are often leaked to the public or compromised. To encourage better password hygiene, implement an identity federation (possible in Zendesk, Atlassian, Slack, and Salesforce).

Step 3: Add a robust layer of security with two-factor authentication (2FA) on accounts in SaaS solutions. Identity federation can also help with this.

Step 4: Ensure that the buckets are correctly authorized and not publicly accessible as they may contain sensitive information. The use of CSPM-class solutions can assist with proper authorization settings. Additionally, enabling data encryption in buckets using KMS or AWS SDK.

Step 5: Regularly monitoring the shadow zone (also known as Shadow IT) is crucial. Investing in an Attack Surface Management solution can identify all IT devices, softwares, and services in the organization that are not maintained/forgotten by the IT department and pose security risks. These resources are not part of the IT department’s inventory and may be unknown to them. Therefore, their status and operation are not properly regulated, which paves the way for additional vulnerabilities that can be exploited.

Step 6: Penetration testing is strongly advised, as it includes simulating intrusions to test your cyber resilience. Another step forward would be conducting  Red Teaming exercises to thoroughly cover all potential attack vectors. This step should be predicated on existing security measures of the company to identify any previously undiscovered opportunities for attacks. By doing so, the overall risk of a successful breach can be minimized.

Step 7: use advanced detection solutions, such as Threat Intelligence, to map and analyze information about potential threats to an organization’s assets. It also helps the security teams regularly check for logins, email addresses, and passwords of the company’s employees in leaks and public Github repositories.

For the most robust and specific threat protection, it is important to tailor any threat intelligence platform to your company’s needs and the threat landscape that is unique to your industry and region. This helps businesses stay ahead of cyber risks and reduce the disruptive impact of security breaches, if they take place.