Secrets disclosed in /my?key=%23asset

[josephwhenry]

Bug Description The /my?key=%23asset endpoint returns the config property of each asset. For authenticated integrations, this includes the cleartext credentials. Any authenticated user can pull this data:

Steps to Reproduce

1. Complete an integration that requires authentication (Azure, GCP, CrowdStrike, NS1, GitHub, Gitlab).
2. Make the /my?key=%23asset request.
3. Observe the credentials in the response.

Expected Behavior Not a huge deal, but we may consider tightening this down in the future. Ideally, Chariot wouldn't return cleartext credentials anywhere in the platform.

[privateducky]

yea... note that any authorized user can pull the same credentials from the account/integration area.. the only option would be to make credentials only addable but not editable after the fact (so we'd never return them to the UI). We'd take a UX hit if we did that though, as you couldn't spot check/edit your creds.

This is a topic we'd want to hammer out when/if we open up role-based access.. but most systems like ours will have max 15 users in a given account, so I'm not sure that'll rise up on the priority list.

[AnthonyPraetorian]

I propose taking the UX hit as a priority item The compromise of a Chariot account should not result in pivoting to other critical assets

[privateducky]

I propose taking the UX hit as a priority item The compromise of a Chariot account should not result in pivoting to other critical assets

Maybe.

Let's say I run a security scan and determine that CVE-XYZ is on HOST-A or that I've exposed a secret in GitHub for your domain controller. This data is available to authenticated users, as it's needed to validate findings.

This would be similar to other tools (especially in security) where if you gain access to them, they can be used to data mine for information or creds to other systems. Crowdstrike, for example, offers root remote access into all Falcon instances if you can compromise an account. AWS can offer significant access into a network if you pop an account there.

We want to harden our ability to avoid that possibility (it helps that we have an internal offensive security team of our size!). Forcing MFA or SSO is one good way to limit this further (we don't require these today). Re-authenticating users when they pull up sensitive data is another thing we could do (although if you've already compromised the account, that would be futile).

Another avenue we've taken on recently is adding robust detection/response in the platform. For example, we noticed one user attempting to do a file path traversal attack, so we rolled in the ability to notify our team immediately when someone attempts this -- and we can suspend or remove the user immediately (if we choose to do so).

[privateducky]

We decided to close the loop on this one, just to avoid having to explain ^^ in the future :)

It'll get rolled out in the next deployment (probably tomorrow).

[noah-tutt-praetorian]

https://github.com/praetorian-inc/chaos/pull/1006