Snowflake Service Account Security, Part 1

Author: Jacob Salassi | Contributing Authors: Jonathan Sander

Snowflake Security

This blog post series will put you in the mind of a defender. In cybersecurity, being a good defender means thinking like an attacker. Part 1 of this blog will focus on understanding why service accounts are excellent targets in the mind of the bad guys, and the threats and attacks a bad guy may use. In Part 2, we’ll lay out how to mitigate the threats and defend against these attacks using the tools Snowflake Cloud Data Platform gives you. In part 3, we’ll show you how you can further mitigate threats by using the sample Hashicorp Vault plugin we released to manage credential rotation.

Part 1

Service accounts are nonhuman identities used by software such as applications, automation processes, operating systems, and more. 

Service accounts typically have privileged access to data that human operators do not have access to. Service accounts need this privileged access to act as part of the system, achieve automation, and orchestrate tasks, as well as to perform unattended administrative actions.

Human identity verification benefits from robust multi-factor authentication schemes, but what about service accounts? Out-of-band mechanisms such as push notifications or time-based one-time password (TOTP) tokens are difficult or impossible for service account use cases. 

By the end of this blog post series, you will be able to

  • Describe common threats impacting service accounts and understand how they relate to your business
  • Describe best-practice mitigation strategies for these threats
  • Make a determination on the best approaches for securing your service accounts

Service account threats

The following table describes a high-level threat model for service accounts:

An attacker who steals or guesses a credential is likely to misuse it. The goal of this post is to make the methods used to obtain and misuse credentials practically impossible or very costly.

To be a successful defender, you first need to understand how these attacks are carried out. 

In the next section, we’ll explore where and how service account attacks take place.

Credential theft and disclosure

Servers and applications that use service accounts

Attackers use unpatched security vulnerabilities to gain access to servers and applications. They may directly attack a server or application, or they might move laterally after compromising another vulnerable system.

If an attacker gains access to an application or server, credentials could be stolen from

  • Configuration files 
  • Log files
  • Environment variables
  • Application memory
  • Other poorly configured services using weakly protected secrets on the system 

Log files

We mentioned log files on a server above. However, most logs do not exclusively reside on a server. They are aggregated, stored, and often redistributed in many places. This gives attackers many opportunities to gain access to logs, without having direct access to applications and servers.

Logs are information-rich by definition, particularly when debugging is enabled. This means they are cheap to attack offline and expensive to defend in real time.

Network traffic

Intercepting external log sources is one way attackers can steal credentials without having access to a server or application. Another way is to intercept the network traffic from a server or application.

Attackers can leverage man-in-the-middle attacks to redirect application traffic. This could expose the credentials while they are in use.

Privileged humans

Humans are often the softest, most vulnerable targets for attackers. Phishing and other attacks can be carried out against human targets to plant malware. Social engineering attacks can cause administrators to unwittingly disclose credentials to an attacker.

Credential guessing

So far, we have discussed the many opportunities for stealing credentials, but they all require compromising either a piece of software or a human being. Guessing attacks require neither, and they cost attackers very little to attempt.

Using these examples as a starting point, consider how an attacker might carry out a guessing attack in your environment:

  • Brute forcing
  • Dictionary attacks
  • Credential stuffing

Brute forcing and dictionary attacks

Brute forcing, which involves simply trying all the possible combinations of allowed input for credentials, is the most expensive technique. It can succeed immediately or fail after trying for 100 years. 

Dictionary attacks optimize some of the problem space by incorporating known words, thereby reducing the number of combinations to try.

Actual guessing is uncommon but can succeed when weak passwords that relate to well-known facts about the business, trademarks, or social events are used.

Credential stuffing

This technique uses previously breached credentials against a large number of arbitrary services.

When administrators mistakenly use the same credentials across multiple services, attackers can take advantage of them to move laterally and uncover new attack surfaces.

Conclusion

In this post, we covered the high-level objectives of and the methods for attacking service accounts. In Part 2, we’ll discuss defense-in-depth mitigations for those methods.

Related documentation: