Netskope debütiert als Leader im Gartner® Magic Quadrant™ 2024 für Single-Vendor Secure Access Service Edge Den Bericht erhalten

Schließen
Schließen
  • Warum Netskope? Chevron

    Verändern Sie die Art und Weise, wie Netzwerke und Sicherheit zusammenarbeiten.

  • Unsere Kunden Chevron

    Netskope betreut weltweit mehr als 3.400 Kunden, darunter mehr als 30 der Fortune 100

  • Unsere Partner Chevron

    Unsere Partnerschaften helfen Ihnen, Ihren Weg in die Cloud zu sichern.

Leader im Bereich SSE.
Jetzt ein Leader im Bereich Single-Vendor-SASE.

Erfahren Sie, warum Netskope im Gartner® Magic Quadrant™️ 2024 für Single-Vendor Secure Access Service Edge als Leader debütiert

Report abrufen
Kundenvisionäre im Rampenlicht

Read how innovative customers are successfully navigating today’s changing networking & security landscape through the Netskope One platform.

Jetzt das E-Book lesen
Kundenvisionäre im Rampenlicht
Die partnerorientierte Markteinführungsstrategie von Netskope ermöglicht es unseren Partnern, ihr Wachstum und ihre Rentabilität zu maximieren und gleichzeitig die Unternehmenssicherheit an neue Anforderungen anzupassen.

Erfahren Sie mehr über Netskope-Partner
Gruppe junger, lächelnder Berufstätiger mit unterschiedlicher Herkunft
Ihr Netzwerk von morgen

Planen Sie Ihren Weg zu einem schnelleren, sichereren und widerstandsfähigeren Netzwerk, das auf die von Ihnen unterstützten Anwendungen und Benutzer zugeschnitten ist.

Whitepaper lesen
Ihr Netzwerk von morgen
Vorstellung der Netskope One-Plattform

Netskope One ist eine cloudnative Plattform, die konvergierte Sicherheits- und Netzwerkdienste bietet, um Ihre SASE- und Zero-Trust-Transformation zu ermöglichen.

Erfahren Sie mehr über Netskope One
Abstrakt mit blauer Beleuchtung
Nutzen Sie eine Secure Access Service Edge (SASE)-Architektur

Netskope NewEdge ist die weltweit größte und leistungsstärkste private Sicherheits-Cloud und bietet Kunden eine beispiellose Serviceabdeckung, Leistung und Ausfallsicherheit.

Mehr über NewEdge erfahren
NewEdge
Netskope Cloud Exchange

Cloud Exchange (CE) von Netskope gibt Ihren Kunden leistungsstarke Integrationstools an die Hand, mit denen sie in jeden Aspekt ihres Sicherheitsstatus investieren können.

Erfahren Sie mehr über Cloud Exchange
Netskope-Video
  • Edge-Produkte von Security Service Chevron

    Schützen Sie sich vor fortgeschrittenen und cloudfähigen Bedrohungen und schützen Sie Daten über alle Vektoren hinweg.

  • Borderless SD-WAN Chevron

    Stellen Sie selbstbewusst sicheren, leistungsstarken Zugriff auf jeden Remote-Benutzer, jedes Gerät, jeden Standort und jede Cloud bereit.

  • Secure Access Service Edge Chevron

    Netskope One SASE bietet eine Cloud-native, vollständig konvergente SASE-Lösung eines einzelnen Anbieters.

Die Plattform der Zukunft heißt Netskope

Intelligent Security Service Edge (SSE), Cloud Access Security Broker (CASB), Cloud Firewall, Next Generation Secure Web Gateway (SWG) und Private Access for ZTNA sind nativ in einer einzigen Lösung integriert, um jedes Unternehmen auf seinem Weg zum Secure Access Service zu unterstützen Edge (SASE)-Architektur.

Netskope Produktübersicht
Netskope-Video
Next Gen SASE Branch ist hybrid – verbunden, sicher und automatisiert

Netskope Next Gen SASE Branch vereint kontextsensitives SASE Fabric, Zero-Trust Hybrid Security und SkopeAI-Powered Cloud Orchestrator in einem einheitlichen Cloud-Angebot und führt so zu einem vollständig modernisierten Branch-Erlebnis für das grenzenlose Unternehmen.

Erfahren Sie mehr über Next Gen SASE Branch
Menschen im Großraumbüro
Entwerfen einer SASE-Architektur für Dummies

Holen Sie sich Ihr kostenloses Exemplar des einzigen Leitfadens zum SASE-Design, den Sie jemals benötigen werden.

Jetzt das E-Book lesen
Steigen Sie auf marktführende Cloud-Security Service mit minimaler Latenz und hoher Zuverlässigkeit um.

Mehr über NewEdge erfahren
Beleuchtete Schnellstraße mit Serpentinen durch die Berge
Ermöglichen Sie die sichere Nutzung generativer KI-Anwendungen mit Anwendungszugriffskontrolle, Benutzercoaching in Echtzeit und erstklassigem Datenschutz.

Erfahren Sie, wie wir den Einsatz generativer KI sichern
ChatGPT und Generative AI sicher aktivieren
Zero-Trust-Lösungen für SSE- und SASE-Deployments

Erfahren Sie mehr über Zero Trust
Bootsfahrt auf dem offenen Meer
Netskope erhält die FedRAMP High Authorization

Wählen Sie Netskope GovCloud, um die Transformation Ihrer Agentur zu beschleunigen.

Erfahren Sie mehr über Netskope GovCloud
Netskope GovCloud
  • Ressourcen Chevron

    Erfahren Sie mehr darüber, wie Netskope Ihnen helfen kann, Ihre Reise in die Cloud zu sichern.

  • Blog Chevron

    Erfahren Sie, wie Netskope die Sicherheits- und Netzwerktransformation durch Security Service Edge (SSE) ermöglicht

  • Events und Workshops Chevron

    Bleiben Sie den neuesten Sicherheitstrends immer einen Schritt voraus und tauschen Sie sich mit Gleichgesinnten aus

  • Security Defined Chevron

    Finden Sie alles was Sie wissen müssen in unserer Cybersicherheits-Enzyklopädie.

Security Visionaries Podcast

Die Konvergenz der Rollen von CIO und CISO
Seien Sie bei der neuesten Folge von Security Visionaries mit Moderator Max Havey dabei, wenn er sich mit Gast Jadee Hanson, CISO bei Vanta, zusammensetzt.

Podcast abspielen
Die Konvergenz der Rollen von CIO und CISO
Neueste Blogs

Lesen Sie, wie Netskope die Zero Trust- und SASE-Reise durch Security Service Edge (SSE)-Funktionen ermöglichen kann.

Den Blog lesen
Sonnenaufgang und bewölkter Himmel
SASE Week 2023: Ihre SASE-Reise beginnt jetzt!

Wiederholungssitzungen der vierten jährlichen SASE Week.

Entdecken Sie Sitzungen
SASE Week 2023
Was ist SASE?

Erfahren Sie mehr über die zukünftige Konsolidierung von Netzwerk- und Sicherheitstools im heutigen Cloud-dominanten Geschäftsmodell.

Erfahre mehr zu SASE
  • Unternehmen Chevron

    Wir helfen Ihnen, den Herausforderungen der Cloud-, Daten- und Netzwerksicherheit einen Schritt voraus zu sein.

  • Leadership Chevron

    Unser Leadership-Team ist fest entschlossen, alles zu tun, was nötig ist, damit unsere Kunden erfolgreich sind.

  • Kundenlösungen Chevron

    Wir sind für Sie da, stehen Ihnen bei jedem Schritt zur Seite und sorgen für Ihren Erfolg mit Netskope.

  • Schulung und Zertifizierung Chevron

    Netskope-Schulungen helfen Ihnen ein Experte für Cloud-Sicherheit zu werden.

Unterstützung der Nachhaltigkeit durch Datensicherheit

Netskope ist stolz darauf, an Vision 2045 teilzunehmen: einer Initiative, die darauf abzielt, das Bewusstsein für die Rolle der Privatwirtschaft bei der Nachhaltigkeit zu schärfen.

Finde mehr heraus
Unterstützung der Nachhaltigkeit durch Datensicherheit
Denker, Architekten, Träumer, Innovatoren. Gemeinsam liefern wir hochmoderne Cloud-Sicherheitslösungen, die unseren Kunden helfen, ihre Daten und Mitarbeiter zu schützen.

Lernen Sie unser Team kennen
Gruppe von Wanderern erklimmt einen verschneiten Berg
Das talentierte und erfahrene Professional Services-Team von Netskope bietet einen präskriptiven Ansatz für Ihre erfolgreiche Implementierung.

Erfahren Sie mehr über professionelle Dienstleistungen
Netskope Professional Services
Mit Netskope-Schulungen können Sie Ihre digitale Transformation absichern und das Beste aus Ihrer Cloud, dem Web und Ihren privaten Anwendungen machen.

Erfahren Sie mehr über Schulungen und Zertifizierungen
Gruppe junger Berufstätiger bei der Arbeit

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