Snowflake Service Account Security, Part 1
May 26, 2020 | 5 Min Read
Author: Jacob Salassi | Contributing Authors: Jonathan Sander
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.
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
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.
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.
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.
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.
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.
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.