Cyberattacks targeting resource credentials such as session tokens are on the rise
Recent high-profile cases such as the source code leaks of Slack's GitHub repositories in January 2023, CircleCI in January 2023, and before that GitHub accounts in April 2022, and Okta in December 2022 are evidence of this trend. In this short blog, we briefly review the attack and explain how the use of online and secured Containerized Development Environments (CDEs) is a great way to protect your DevOps process and implement a robust code development infrastructure to support DevSecOps practices.
Session tokens are the general mechanism used to identify and authenticate users in web applications such as GitHub. They store a unique identifier for a user's session and allow him to log in and use the app. Stored on the client side, if a malicious user gets hold of a token, it can be used to retrieve data and perform actions on the web application. This is what happened in the cases above. For example, for CircleCI, machines were compromised using malware that bypassed antivirus solutions.
In the above instances, token theft led to source code leaks because they were used to access code repositories. Code leaks have serious consequences for organizations, including security risks, intellectual property theft, reputation damage, legal issues, and financial losses. But more generally, any web application used by the organization, including the ones containing personal information can be accessed using the same technique. So victims may be in for some hefty fines from regulators.
The theft of session tokens often results from a successful phishing attack - see (1) in the next diagram. The attack infects the victim's device with malware that conducts the theft.
Once infected, the malware steals a session token by capturing it while in transit as it is transmitted between the client and server or by injecting malicious code into the client-side application to steal the token from the user's device. The token is then exfiltrated to a remote attacker-controlled server. This happens during steps (2) to (5) below.
Once in possession of the token -see (6) and (7)- the hacker effectively bypasses multi-factor authentication (MFA) and starts an illegitimate session. In addition to accessing proprietary information, the token might enable him to elevate privilege on the target application with potentially disastrous results. Then, the hacker might carry out privileged actions such as modifying or deleting data or even altering system configurations.
Preventing the theft of session tokens is a challenging task, in particular, because of the breadth of the attack surface, i.e. all the endpoints used by developers. Keeping a close eye on them is daunting for both small and large firms.
Containerized Development Environments (CDEs) are typically Docker or Podman containers that define complete development environments as code. Developers can use CDEs on their laptops to isolate code dependencies and make applications easily portable.
More recently, vendors such as Microsoft and Google started to offer online accessible CDEs (i.e. as opposed to locally installed). They provide the perfect way to deploy an efficient DevOps process. Online CDEs are particularly convenient for companies with distributed or remote workforces. The CDEs are accessed via a Cloud IDE such as Microsoft Visual Studio Code, a terminal, or a locally installed IDE that supports remote CDEs.
However, for organizations in need of an efficient DevSecOps process, the Kubernetes-based CDE management platform that we have developed here at Strong Network goes a step further and offers online CDEs with embedded security against data exfiltration. This includes in particular a single sign-on (SSO) mechanism for developer resources such as GIT repos, network services, etc. Embedded security combined with the ubiquitous online access of CDEs allows DevSecOps to work at scale, regardless of the developer’s location. Our platform is the only platform with such a mechanism and is available on all major Cloud services.
Because developers are frequently targeted by phishing and other social engineering techniques, from the start the use of online CDEs for development removes development data from their laptops. Hence source code in the container is out of reach from locally installed malware. However, tokens need to be handled separately,
Here is how our CDEs (via their embedded security) are an efficient mechanism to thwart the theft of session tokens.
First, they leave tokens to the organization’s resources out of the reach of the developers and their environment.
Protecting tokens needs a multi-faceted approach due to the diversity of credentials used to authenticate the interaction between developers and the tools across the DevOps process. In this case, we focus on GIT-based code repository management tools.
We first need to protect the session token returned as the result of a credential-based authentication with MFA. This token is kept under the organization’s control using delegated authentication via an identity provider (think of Azure AD or Okta), jointly with accessing the Web app, e.g. GiHub via remote browser isolation and URL whitelisting.
We use a secured version of the Chrome browser as part of our platform to authenticate the user to GitHub and keep the login token under isolation in the browser. Even if there was a way to compromise the remote browser, the whitelisting of accessible URLs will prevent an infection.
Once the developer is authenticated to the code repository application, we need to protect the credentials used to push and pull code using the GIT protocol. These operations can be carried out using SSH keys or OAuth tokens. In both cases, we keep these credentials out of reach from developers via the use of a proxy mechanism that determines access control rights via an RBAC model for the user and the permissions associated with the CDE. This two-tier mechanism above takes care of protecting any repository credentials from leaking and is illustrated in a simple manner in the diagram below.
Now we need a way to protect the login token from our platform web UI. This platform gives access to the developer’s workspaces, secure browser apps, and other tools. Hence, here is the second part of the recipe:
We monitor access to the Strong Network web UI with dynamic client attestation
One way to prevent the theft of the token for our application is to determine with a certain amount of confidence that the client using the token is the one that originally requested it. This is referred to as Client Attestation and works by measuring a series of “signals” from the clients that allow the back-end to determine the legitimacy of the requests.
Sure, a very motivated and resourceful attacker might be able to bypass attestation by reproducing the right footprint. However, this would require an analysis of the client-based mechanism (hence full access to it), in addition to lifting the key used to encrypt the attestation payload (not trivial if white-box cryptography is used). If that complex endeavor succeeds and the attacker gets access to our platform via a stolen token, credentials to the organization’s resources are still out-of-reach (see the diagram below.)
And even in the case where the malicious user makes it to our platform, the insider threat mechanism in place will detect any anomalous developer’s behavior. Such a behavior would be, for example, zipping the entire code base and sending it to an unrecognized server.
We hope that this short article was useful and informative, in particular, how online code development platforms that provide CDEs are a first line of defense for organizations’ resources, provided that the right security mechanisms are in place.
In our security blog series, we will continue to discuss some of the recent hacks and explore how our platform of online secure CDEs can constitute a first line of defense for organizations with a security mindset.
Orignial post / Source : Blog Post | Preventing the Theft of Session Tokens (strong.network)
Would love to get your feedback 🙂
