ゼロトラストとSASEの未来は今です!オンデマンドで視聴する

閉める
閉める
  • Netskopeが選ばれる理由 シェブロン

    ネットワークとセキュリティの連携方法を変える。

  • 導入企業 シェブロン

    Netskope は世界中で 3,000 を超える顧客にサービスを提供しており、その中にはフォーチュン 100 企業の 25 以上が含まれます

  • パートナー シェブロン

    私たちはセキュリティリーダーと提携して、クラウドへの旅を保護します。

Highest in Execution. Furthest in Vision.

ネットスコープは2023年Gartner®社のセキュリティ・サービス・エッジ(SSE)のマジック・クアドラント™でリーダーの1社として評価されました。

レポートを読む
ネットスコープは2023年Gartner®社のセキュリティ・サービス・エッジ(SSE)のマジック・クアドラント™でリーダーの1社として評価されました。
私たちは、お客様が何にでも備えることができるように支援します

See our customers
窓の外を見て微笑むメガネをかけた女性
Netskopeのパートナー中心の市場開拓戦略により、パートナーは企業のセキュリティを変革しながら、成長と収益性を最大化できます。

Netskope パートナーについて学ぶ
色々な若い専門家が集う笑顔のグループ
明日に向けたネットワーク

サポートするアプリケーションとユーザー向けに設計された、より高速で、より安全で、回復力のあるネットワークへの道を計画します。

ホワイトペーパーはこちら
明日に向けたネットワーク
Introducing the Netskope One Platform

Netskope One is a cloud-native platform that offers converged security and networking services to enable your SASE and zero trust transformation.

Netskope One について学ぶ
Abstract with blue lighting
セキュアアクセスサービスエッジ(SASE)アーキテクチャの採用

Netskope NewEdgeは、世界最大かつ最高のパフォーマンスのセキュリティプライベートクラウドであり、比類のないサービスカバレッジ、パフォーマンス、および回復力を顧客に提供します。

NewEdgeの詳細
NewEdge
Netskope Cloud Exchange

Netskope Cloud Exchange (CE) は、セキュリティポスチャに対する投資を活用するための強力な統合ツールを提供します。

Cloud Exchangeについて学ぶ
Netskopeの動画
  • セキュリティサービスエッジ製品 シェブロン

    高度なクラウド対応の脅威から保護し、あらゆるベクトルにわたってデータを保護

  • Borderless SD-WAN シェブロン

    すべてのリモートユーザー、デバイス、サイト、クラウドへ安全で高性能なアクセスを提供

  • Secure Access Service Edge シェブロン

    Netskope SASE は、クラウドネイティブで完全に統合された単一ベンダーの SASE ソリューションを提供します。

未来のプラットフォームはNetskopeです

インテリジェントセキュリティサービスエッジ(SSE)、クラウドアクセスセキュリティブローカー(CASB)、クラウドファイアウォール、セキュアウェブゲートウェイ(SWG)、およびZTNAのプライベートアクセスは、単一のソリューションにネイティブに組み込まれており、セキュアアクセスサービスエッジ(SASE)アーキテクチャへの道のりですべてのビジネスを支援します。

製品概要はこちら
Netskopeの動画
Next Gen SASE Branch はハイブリッドである:接続、保護、自動化

Netskope Next Gen SASE Branchは、コンテキストアウェアSASEファブリック、ゼロトラストハイブリッドセキュリティ、 SkopeAI-Powered Cloud Orchestrator を統合クラウド製品に統合し、ボーダレスエンタープライズ向けに完全に最新化されたブランチエクスペリエンスを実現します。

Next Gen SASE Branchの詳細はこちら
オープンスペースオフィスの様子
SASEアーキテクチャの設計 For Dummies

SASE設計について網羅した電子書籍を無償でダウンロード

電子書籍を入手する
最小の遅延と高い信頼性を備えた、市場をリードするクラウドセキュリティサービスに移行します。

NewEdgeの詳細
山腹のスイッチバックを通るライトアップされた高速道路
アプリケーションのアクセス制御、リアルタイムのユーザーコーチング、クラス最高のデータ保護により、生成型AIアプリケーションを安全に使用できるようにします。

生成AIの使用を保護する方法を学ぶ
ChatGPTと生成AIを安全に有効にする
SSEおよびSASE展開のためのゼロトラストソリューション

ゼロトラストについて学ぶ
大海原を走るボート
NetskopeがFedRAMPの高認証を達成

政府機関の変革を加速するには、Netskope GovCloud を選択してください。

Netskope GovCloud について学ぶ
Netskope GovCloud
  • リソース シェブロン

    クラウドへ安全に移行する上でNetskopeがどのように役立つかについての詳細は、以下をご覧ください。

  • ブログ シェブロン

    Learn how Netskope enables security and networking transformation through security service edge (SSE)

  • Events and Workshops シェブロン

    最新のセキュリティトレンドを先取りし、仲間とつながりましょう。

  • 定義されたセキュリティ シェブロン

    サイバーセキュリティ百科事典、知っておくべきすべてのこと

「セキュリティビジョナリー」ポッドキャスト

選挙、偽情報、治安
このエピソードでは、有権者登録と投票所での物理的な管理に関する選挙セキュリティの側面を見ていきます。

ポッドキャストを再生する
ブログ: Elections, Disinformation, and Security (選挙、偽情報、セキュリティ)
最新のブログ

Read how Netskope can enable the Zero Trust and SASE journey through security service edge (SSE) capabilities.

ブログを読む
日の出と曇り空
SASE Week 2023年:SASEの旅が今始まります!

第4回 SASE Weekのリプレイセッション。

セッションの詳細
SASE Week 2023
セキュリティサービスエッジとは

SASEのセキュリティ面、ネットワークとクラウドでの保護の未来を探ります。

セキュリティサービスエッジの詳細
4方向ラウンドアバウト
  • 会社概要 シェブロン

    クラウド、データ、ネットワークセキュリティの課題に対して一歩先を行くサポートを提供

  • リーダーシップ シェブロン

    Netskopeの経営陣はお客様を成功に導くために全力を尽くしています。

  • カスタマーソリューション シェブロン

    お客様の成功のために、Netskopeはあらゆるステップを支援いたします。

  • トレーニングと認定 シェブロン

    Netskopeのトレーニングで、クラウドセキュリティのスキルを学ぶ

データセキュリティによる持続可能性のサポート

Netskope は、持続可能性における民間企業の役割についての認識を高めることを目的としたイニシアチブである「ビジョン2045」に参加できることを誇りに思っています。

詳しくはこちら
データセキュリティによる持続可能性のサポート
思想家、建築家、夢想家、革新者。 一緒に、私たちはお客様がデータと人々を保護するのを助けるために最先端のクラウドセキュリティソリューションを提供します。

当社のチーム紹介
雪山を登るハイカーのグループ
Netskopeの有能で経験豊富なプロフェッショナルサービスチームは、実装を成功させるための規範的なアプローチを提供します。

プロフェッショナルサービスについて学ぶ
Netskopeプロフェッショナルサービス
Netskopeトレーニングで、デジタルトランスフォーメーションの旅を保護し、クラウド、ウェブ、プライベートアプリケーションを最大限に活用してください。

トレーニングと認定資格について学ぶ
働く若い専門家のグループ

Securing AWS Temporary Tokens

Aug 10 2019

In this blog, we are going to discuss an attack vector that utilizes the STS AssumeRole and GetSessionToken API calls, and focus on what you have to do differently to detect, mitigate, and prevent abuse vs handling permanent access keys.

Imagine This

An attacker has just compromised one of your AWS credentials and gained access to your production AWS account. What do you do next? Revoke the credentials, of course. But just revoking the compromised credentials is not enough to keep the attacker out of your environment. In this blog post, we’ll explore temporary tokens and how they can provide an attacker continued access to your AWS environments, even after you have revoked compromised credentials.

Temporary tokens are provided by AWS Secure Token Service (STS) and are similar to permanent access keys in functionality and have been used to implement several common AWS features such as:

  • Assuming roles, including the passing of roles to services
  • Federated identities (e.g., single sign-on and cross-account access) 
  • Authentication of IoT devices

As with all security design, there are tradeoffs and security concerns from the use of temporary tokens:

  • Temporary tokens  can cause confusion during incident handling/response versus permanent access keys because their creation and use is logged in CloudTrail using different, somewhat confusing fields and values. As an example, there is no explicit json attribute that distinguishes a temporary token from a permanent API access key–you must infer from the access key id naming convention or other fields.
  • The remediation options for Temporary Tokens can have with high impact; e.g., deletion of users
  • Temporary tokens are harder to lock down since the creation of some types of temporary tokens cannot be restricted by policy.
  • There is no tracking of which tokens have already been created, so auditing temporary token usage and identifying temporary tokens is difficult, as they must be derived from parsing CloudTrail logs. Further, there are no direct management functions (such as deletion) for temporary tokens. We’ll discuss in detail what mitigation steps apply later in the blog. This also makes it more difficult to assess exposure from credential risk because there is no easy way to list all temporary credentials that have been issued or are active/outstanding.

Temporary Tokens

Temporary tokens are implicitly created by AWS in the case of IoT device authentication or from assuming of roles by services. Temporary tokens can also be explicitly created by authenticated users calling STS AssumeRole or GetSessionToken, e.g.,

Temporary Token Created By GetSessionToken
Figure 1: Temporary Token Created By GetSessionToken

In addition to the access key id and secret, a temporary credential includes an expiration date and a session token, which must be included in any API calls (along with the access key and secret). 

Temporary tokens essentially have the same functionality and similar security exposure as permanent access keys, but with a few differences:

  • Expiration: Temporary tokens have an expiration, ranging from 15 minutes to 36 hours. This is good from a security viewpoint, as it reduces the time window for abuse in case of lost or stolen temporary tokens.
  • API Access: Temporary tokens can call any service that the original credential (that created the temporary token) has privileges for, except that:
  • within STS, temporary tokens can only call the AssumeRole API call.
  • within IAM, MFA is required.

These restrictions may not necessarily constrain attackers, since there are a large number of services that support AssumeRole [1], which combined with numerous techniques for escalating privileges [2], creates a large attack surface for lateral movement from temporary tokens to other privileged roles.

Attack Scenario

To highlight the challenges when temporary tokens are used in an attack, let’s look at a simple attack scenario. The environment has support personnel who must manage production S3 buckets, and the organization has created a specific role, MyBucketRole, that is assumed by support personnel whenever the need arises for S3 bucket support.

Attack Scenario Utilizing Temporary Tokens
Figure 2: Attack Scenario Utilizing Temporary Tokens

The Attacker:

  1. Gains initial access to the environment with stolen credentials (access key A) which was accidentally hard-coded into a script that was uploaded to Git by a support person.
  2. Generates a temporary token B using the stolen credentials (access key A) with a call to STS GetSessionToken, for persistent access i.e., backdoor access. This is not used immediately but is saved for redundant access and will be used in a secondary attack, and we will see shortly why it has different challenges than permanent keys and other temporary tokens generated by AssumeRole.
  3. Uses access key A to escalate privileges by assuming a role, MyBucketRole, that has access to an S3 Bucket. This returns temporary token C, which when used will have the permissions of MyBucketRole.
  4. Accesses sensitive data on the S3 Bucket using temporary token C.
  5. Exfiltrates data from the S3 Bucket (e.g. S3 sync to another S3 bucket)

The initial compromise and attack vector in this scenario is the compromised credential. The use of temporary tokens does not change this risk profile but it will make the detection, mitigation, and prevention steps different or more challenging, which we cover in the next section.

Defender Viewpoint

Let’s look at this attack from the defender’s viewpoint to understand any challenges that stem from the use of temporary tokens by the attacker. We’re in the middle of the attack, we’re alerted to suspicious data access patterns during the exfiltration phase, and we’ve found out that a support user called AssumeRole and is performing data exfiltration.

Detection and Remediation

1 – Delete Compromised Key A

We immediately delete or make inactive the compromised access key A, regenerate new keys, ensure key rotation is enabled:

Remediating Permanent Keys
Figure 3: Remediating Permanent Keys

Additionally, we can discuss with the support user how they can better secure their API keys and send him/her to security training if necessary.

This should at least kick out our attacker, right? Not quite.

2 – Alerts on Continued Access with Temporary Token C

We find that the data exfiltration continues because the temporary token C created by AssumeRole still exists and is valid for up to 36 hours.

CloudTrail Event for Temporary Token Use
Figure 4: CloudTrail Event for Temporary Token Use

Any access key ids will start with “ASIA”, which is the naming convention that distinguishes temporary tokens from permanent tokens (”AKIA”). [3] There is no explicit attribute to distinguish a temporary token vs access key. There is also nothing in this event that ties the temporary token back to the principal that created it — that information is contained in a different event that captures the creation of the temporary token.

3 – Mitigate by Revoking Active Sessions for Temporary Token C

Although there is no way to list, directly delete, or deactivate temporary tokens, there is a workaround. We can revoke active sessions associated with a Role i.e., sessions started by AssumeRole. The policy can be set in the Revoke sessions tab for the role assumed by the attacker (IAM service):

AWS Console Tab for Revoke Active Sessions for a Role
Figure 5: AWS Console Tab for Revoke Active Sessions for a Role

It implements a policy condition that denies any API call if the token was created earlier than the time you put the policy in place [6].

We should be done now, right? Not yet.

4 – Alerts on Continued Access with New Temporary Tokens

We continue to see data exfiltration using an AssumedRole temporary token but that is different from temporary token C:

Data Exfiltration Using AssumedRole Temporary Tokens
Figure 6: Data Exfiltration Using AssumedRole Temporary Tokens

Where are these coming from?

5 – Discover Temporary Token B

The problem is temporary token B, which is repeatedly calling AssumeRole to generate new tokens:

CloudTrail Event for Creation of Temporary Token by AssumeRole
Figure 7: CloudTrail Event for Creation of Temporary Token by AssumeRole

These new temporary tokens have creation timestamps that are newer than what was set in the Revoke active sessions policy in step #3, so they are not denied.

We could do the Revoke active sessions step again (step #3) which will update the timestamp to the current time, but that doesn’t stop the attacker, who can keep calling AssumeRole

Should we delete temporary token B, as in step #1? Unfortunately, we can’t because it’s not a permanent key, and there are no API calls or Console actions to list or delete temporary tokens.

Should we try to contain it using Revoke active sessions, which worked in step #3? Unfortunately, Revoke active sessions works only for Roles i.e. it’s only available to control sessions from tokens created with AssumeRole. It doesn’t apply to or work for temporary tokens created by GetSessonToken

What now?

6 – Delete User or Change Permissions

The recommended ways to remediate temporary tokens created by GetSessonToken, are to:

  1. Change/restrict the privileges (policies) for the user or role that created the token since the temporary token creates a session with the current privileges of the user/role at the time of use (not creation) [4].
  2. Delete the user [5], which will immediately delete all temporary tokens associated with that user. 

The user in question is the IAM user who created the temporary token i.e. the support user. So, in order to be safe, we delete the user. Hopefully, we have Cloud Formation Templates or other ways to recreate the user easily. For a single user, this may be ok. However, if the IAM User is used as a service account and has many active sessions, then deleting the user will immediately cancel all active sessions, which can have a large negative impact. 

We have finally kicked the attacker out of our AWS environment by deleting or mitigating all compromised credentials! Now, let’s look at how we can lockdown the environment to prevent this happening in the first place.

Prevention

1 – Prevent Creation of Temporary Tokens by AssumeRole

We can use IAM policies to limit who can call AssumeRole by limiting the trust relationship of the role. 

Role Trust Relationship
Figure 8: Role Trust Relationship

In this example, only support_user is able to assume MyBucketRole — no other roles, users, or other principals can assume this role.  

2 – Alert on Creation of Temporary Tokens by GetSessionToken

How about preventing GetSessionToken? Unfortunately, we cannot restrict or prevent calls to GetSessionToken, as explained in the IAM User Guide [7]:

IAM users can also call GetSessionToken to create temporary security credentials. No permissions are required for a user to call GetSessionToken. The purpose of this operation is to authenticate the user using MFA. You cannot use policies to control authentication. This means that you cannot prevent IAM users from calling GetSessionToken to create temporary tokens.

Instead, we can focus on alerts based on early detection. Since GetSessionToken‘s primary use is to MFA enable a token that can be used to call MFA-protected API calls, it should occur much less frequently in your environment.

CloudTrail Event For GetSessionToken
Figure 9: CloudTrail Event For GetSessionToken

You can distinguish MFA GetSessionToken calls by looking for the existence of requestParameters.serialNumber.

Note: Alerting on sts:AssumeRole calls is not useful because of false positives since it is validly and widely used by many services [1].

3 – Mitigate Compromised Permanent Keys

Using MFA and/or IP/VPC allow listing in IAM policies will reduce the probability of downstream abuse from temporary tokens.

MFA Condition in IAM Policy
Figure 10: MFA Condition in IAM Policy
Source IP Condition in IAM Policy
Figure 11: Source IP Condition in IAM Policy

4 – Mitigate Compromised EC2 Temporary Tokens

Dynamic allow listing the source IPs of temporary tokens generated by sts:AssumeRole (see example from the Netflix Security team[8]) can help contain and minimize the impact of stolen temporary tokens since the tokens can only be used from the EC2 instance. The tradeoff is the time and resources required to maintain additional code, which may introduce additional security bugs or vulnerabilities. Additionally, this does not prevent the stolen credentials from being used from the EC2 instance itself.

Summary

Temporary tokens are just one way an attacker can maintain persistence, evade defenses, and escalate privileges in your environment. Because they differ from permanent keys in how they are detected, remediated, and prevented, you want to take appropriate measures to manage this risk.

In the attack scenario above, you need to detect whether temporary tokens have been used by an attacker and what type of tokens they are. For those created by AssumeRole, you can revoke active sessions. For those created by GetSessionToken, you must delete the user or restrict its permissions. To prevent credential compromise, restrict the use of permanent keys with source IP allow listing and/or MFA, restrict the trust relationships for roles that are assumed, and consider a metadata proxy (IP allow listing) for EC2-generated temporary credentials.

This table summarizes the specific defensive measures you can use to prevent, detect, and remediate temporary tokens (AssumeRole and GetSessionToken) as well as permanent keys:

Table 1: Defensive Measures for Permanent and Temporary Credentials
Table 1: Defensive Measures for Permanent and Temporary Credentials

Netskope provides support in preventing abuse with continuous security assessment checks, detection with inline and API introspection, and custom auto-remediation commands.

For an attack chain perspective on managing Temporary Tokens, see our blog post: MITRE Att&ck View: Securing AWS Temporary Tokens.

This blog post is based on talks given at:

  • Defcon 27 on August 10, 2019. Slides are linked here.
  • AWS Community Day 2019, Bay Area on September 13, 2019. A recorded video of the presentation is here.

References

[1] AWS Identity and Access Management: AWS Services That Work with IAM

[2] “AWS IAM Privilege Escalation – Methods and Mitigation,” S.Gietzen, Rhino Security Labs.

https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/

[3] “Managing Access Keys for IAM Users: Auditing Access Keys,” AWS Identity and Access Management User Guide, AWS.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_access-keys-audit

[4] “Disabling Permissions for Temporary Security Credentials,” AWS Identity and Access Management User Guide, AWS.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html

[5] “My AWS account might be compromised,” Knowledge Center, AWS, October 2019.

https://aws.amazon.com/premiumsupport/knowledge-center/potential-account-compromise/

[6] “Revoking IAM Role Temporary Security Credentials,” AWS Identity and Access Management User Guide, AWS.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html

[7] “Granting Permissions to Create Temporary Security Credentials,” AWS Identity and Access Management User Guide, AWS.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_enable-create.html

[8] “Netflix Information Security: Preventing Credential Compromise in AWS,” W.Bengtson, Netflix Security Tools and Operations, November 2018.

https://medium.com/netflix-techblog/netflix-information-security-preventing-credential-compromise-in-aws-41b112c15179

author image
Jenko Hwong
Jenko has 15+ years of experience in research, product management, and engineering in cloud security, AV/AS, routers/appliances, threat intel, Windows security, vulnerability scanning and compliance. At Netskope, he researches new cloud attacks.

Stay informed!

Subscribe for the latest from the Netskope Blog