What happens if a secure token is provided to a trusted party that gets compromised

Information Security Asked by user855 on January 25, 2021

Take for example – AWS STS token or JWT tokens.

Let’s say node A got a token for accessing a resource of account X on behalf of account X. Access includes read/write privileges.

Let’s say few minutes later the node A got compromised.

Nothing else knows that A got compromised.

Question Account X is also compromised now. Correct?

Question We will continue to provide renewed tokens to access account X to node A because we have not detected that node A is compromised yet. Correct?

Question What should we do to detect that node A is compromised?

One Answer

There's not really enough information to determine the specifics here, but there are some general answers that can be provided.

In your scenario, the assumption by default should be that node A has had the ability to access and modify account X within the scope of the permission of its token. This is, generally, why tokens are usually limited to certain scopes, so that, for example, if node A needs to access directory information about account X, it cannot abuse that to also modify other information on the account.

This is also why automated tokens tend to be time limited—so that the abuse of account X by node A is limited to the life of its tokens—and why credential issuance is usually logged—so that any misuse can be easily determined and the extent of access can be readily discovered. If tokens are issued using sufficient entropy, it is also common to log their access using a hashed version of the token so that actions taken by a bad actor can be determined.

Whether, in this situation, it means that account X is compromised (that is, under the control of the attacker) depends on what data the attacker had the ability to access or modify, both due to the scopes and duration of the token and the design of the system. If, for example, the token grants the attacker the ability to do only cosmetic changes, like change personal names or avatars, then the account is, while potentially defaced, probably not compromised.

If your system permits the issuance of additional tokens to node A, then you may well provide it additional tokens. That, of course, depends on the design of the system.

To detect compromises, you will generally want to have some sort of automated measurements or metrics that detect indicators of compromise. What those are depend on the system. For example, if you know that nodes are generally only supposed to handle about 20,000 accounts per day, you may set up a dashboard or an alert to detect large numbers of issued tokens or tokens issued for many accounts, so you notice it's acting strangely. You may also monitor other indications of compromise, such as loading of additional kernel modules, unusual usage of sudo, or access from or connections to unexpected systems. All of this depends on what you know about your instances and systems and requires that you build in suitable metrics and monitoring that are appropriate for your scenario based on suitable threat modeling. You will need to balance good detection and prevention of threats with gracefully handling the occasional anomalous but harmless traffic pattern and avoiding major inconvenience for staff.

Correct answer by bk2204 on January 25, 2021

Add your own answers!

Related Questions

Ways to configure a router

3  Asked on December 8, 2021 by user136026


Can firewalls decrypt SSL packets?

3  Asked on November 30, 2021 by iancool


Associate API key with user

3  Asked on November 30, 2021 by brad-stevanus


Polymorphic Analysis

1  Asked on November 23, 2021 by user109889


Getting the hostname of devices in the local lan

0  Asked on November 23, 2021 by gilad-naaman


Ask a Question

Get help from others!

© 2023 All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP