4 ms·

A bit unrelated, but if you ever find a malicious use of Anthropic APIs like that, you can just upload the key to a GitHub Gist or a public repo - Anthropic is

A bit unrelated, but if you ever find a malicious use of Anthropic APIs like that, you can just upload the key to a GitHub Gist or a public repo - Anthropic is a GitHub scanning partner, so the key will be revoked almost instantly (you can delete the gist afterwards). It works for a lot of other providers too, including OpenAI (which also has file APIs, by the way). https://support.claude.com/en/articles/9767949-api-key-best-practices-keeping-your-keys-safe-and-secure#h_9689e97cd8 https://support.claude.com/en/articles/9767949-api-key-best-... https://docs.github.com/en/code-security/reference/secret-security/supported-secret-scanning-patterns https://docs.github.com/en/code-security/reference/secret-se...

sebmellen 9mo ago
Pretty brilliant solution, never thought of that before.
- j45 9mo ago
  Except is there a guarantee of the lag time from posting the GIST to the keys being revoked?
  - sk5t 9mo ago
    Is this a serious question? Whom do you imagine would offer such a guarantee? Moreover, finding a more effective way to revoke a non-controlled key seems a tall order.
    - j45 9mo ago
      If there’s a delay between jets being posted and disabled they would still be usable no?
- blks 9mo ago
  If we consider why this is even needed (people “vibe coding” and exposing their API keys), the word “brilliant” is not coming to mind
  - darkwater 9mo ago
    To be fair, people committed tokens into public (and private) repos when "transformers" just meant Optimus Prime or AC to DC.
deleted 9mo ago
[deleted]
mucle6 9mo ago
Haha this feels like you're playing chess with the hackers
- j45 9mo ago
  Rolling the dice in a new kind of casino.
- subjectsigma 9mo ago
  “Hack the hackers back” is a pretty old idea with (IIUC) very shaky legal grounds and not a lot of success. It would be much better if Anthropic had a special reporting function for API abuse.
lanfeust6 9mo ago
Could this not lead to a penalty on the github account used to post it?
- bigfatkitten 9mo ago
  No, because people push their own keys to source repos every day.
  - lanfeust6 9mo ago
    Including keys associated with nefarious acts?
    - edoceo 9mo ago
      Maybe, the point is that people, in general, commit/post all kinds of secrets they shouldn't into GitHub. Secrets they own, shared secrets, secrets they found, secrets they don't known, etc. GitHub and their partners just see a secret and trigger the oops-a-wild-secret-has-appeared action.
trees101 9mo ago
why would you do that rather than just revoking the key directly in the anthropic console?
- mingus88 9mo ago
  It’s the key used by the attackers in the payload I think. So you publish it and a scanner will revoke it
  - trees101 9mo ago
    oh I see, you're force-revoking someone else's key
    - rswail 9mo ago
      Which is an interesting DOS attack if you can find someone's key.
      - OJFord 9mo ago
        The interesting thing is that (if you're an attacker) your choice of attack is DoS when you have... anything available to you.
  - freakynit 9mo ago
    Does this mean a program can be written to generate all possible api keys and upload to github thereby revoke everyone's access?
    - kylecazar 9mo ago
      They are designed to be long enough that it's entirely impractical to do this. All possible is a massive number.
      - freakynit 9mo ago
        That's true tho... possible, but impractical.
securesaml 9mo ago
I wouldn’t recommend this. What if GitHub’s token scanning service went down. Ideally GitHub should expose an universal token revocation endpoint. Alternatively do this in a private repo and enable token revocation (if it exists)
- jychang 9mo ago
  You're revoking the attacker's key (that they're using to upload the docs to their own account), this is probably the best option available. Obviously you have better methods to revoke your own keys.
  - securesaml 9mo ago
    it is less of a problem for revoking attacker's keys (but maybe it has access to victim's contents?). agreed it shouldn't be used to revoke non-malicious/your own keys
    - nebezb 9mo ago
      The poster you originally replied to is suggesting this for revoking the attackers keys. Not for revocation of their own keys…
      - securesaml 9mo ago
        there's still some risk of publishing an attacker's key. For example, what if the attacker's key had access to sensitive user data?
        avarun 9mo ago
        [flagged]
        throwawaysleep 9mo ago
        All the more reason to nuke the key ASAP, no?
nh2 9mo ago
So that after the attackers exfiltrate your file to their Anthropic account, now the rest of the world also has access to that Anthropic account and thus your files? Nice plan.
- DominoTree 9mo ago
  For a window of a few minutes until the key gets automatically revoked Assuming that they took any of your files to begin with and you didn't discover the hidden prompt
Davidzheng 9mo ago
I'm being kind of stupid but why does the prompt injection need to POST to anthropic servers at all, does claude cowork have some protections against POST to arbitrary domain but allow POST to anthropic with arbitrary user or something?
- pleurotus 9mo ago
  Yeah they mention it in the article, most network connections are restricted. But not connections to anthropic. To spell out the obvious—because Claude needs to talk to its own servers. But here they show you can get it to talk to its own servers, but put some documents in another user's account, using the different API key. All in a way that you, as an end user, wouldn't really see while it's happening.
- rswail 9mo ago
  In the article it says that Cowork is running in a VM that has limited network availability, but the Anthropic endpoint is required. What they don't do is check that the API call you make is using the same API key as the one you created the Cowork session with. So the prompt injection adds a "skill" that uses curl to send the file to the attacker via their API key and the file upload function.

sebmellen 9mo ago

Pretty brilliant solution, never thought of that before.

j45 9mo ago
Except is there a guarantee of the lag time from posting the GIST to the keys being revoked?
- sk5t 9mo ago
  Is this a serious question? Whom do you imagine would offer such a guarantee? Moreover, finding a more effective way to revoke a non-controlled key seems a tall order.
  - j45 9mo ago
    If there’s a delay between jets being posted and disabled they would still be usable no?
blks 9mo ago
If we consider why this is even needed (people “vibe coding” and exposing their API keys), the word “brilliant” is not coming to mind
- darkwater 9mo ago
  To be fair, people committed tokens into public (and private) repos when "transformers" just meant Optimus Prime or AC to DC.

deleted 9mo ago

[deleted]

mucle6 9mo ago

Haha this feels like you're playing chess with the hackers

j45 9mo ago
Rolling the dice in a new kind of casino.
subjectsigma 9mo ago
“Hack the hackers back” is a pretty old idea with (IIUC) very shaky legal grounds and not a lot of success. It would be much better if Anthropic had a special reporting function for API abuse.

lanfeust6 9mo ago

Could this not lead to a penalty on the github account used to post it?

bigfatkitten 9mo ago
No, because people push their own keys to source repos every day.
- lanfeust6 9mo ago
  Including keys associated with nefarious acts?
  - edoceo 9mo ago
    Maybe, the point is that people, in general, commit/post all kinds of secrets they shouldn't into GitHub. Secrets they own, shared secrets, secrets they found, secrets they don't known, etc. GitHub and their partners just see a secret and trigger the oops-a-wild-secret-has-appeared action.

trees101 9mo ago

why would you do that rather than just revoking the key directly in the anthropic console?

mingus88 9mo ago
It’s the key used by the attackers in the payload I think. So you publish it and a scanner will revoke it
- trees101 9mo ago
  oh I see, you're force-revoking someone else's key
  - rswail 9mo ago
    Which is an interesting DOS attack if you can find someone's key.
    - OJFord 9mo ago
      The interesting thing is that (if you're an attacker) your choice of attack is DoS when you have... anything available to you.
- freakynit 9mo ago
  Does this mean a program can be written to generate all possible api keys and upload to github thereby revoke everyone's access?
  - kylecazar 9mo ago
    They are designed to be long enough that it's entirely impractical to do this. All possible is a massive number.
    - freakynit 9mo ago
      That's true tho... possible, but impractical.

securesaml 9mo ago

I wouldn’t recommend this. What if GitHub’s token scanning service went down. Ideally GitHub should expose an universal token revocation endpoint. Alternatively do this in a private repo and enable token revocation (if it exists)

jychang 9mo ago
You're revoking the attacker's key (that they're using to upload the docs to their own account), this is probably the best option available. Obviously you have better methods to revoke your own keys.
- securesaml 9mo ago
  it is less of a problem for revoking attacker's keys (but maybe it has access to victim's contents?). agreed it shouldn't be used to revoke non-malicious/your own keys
  - nebezb 9mo ago
    The poster you originally replied to is suggesting this for revoking the attackers keys. Not for revocation of their own keys…
    - securesaml 9mo ago
      there's still some risk of publishing an attacker's key. For example, what if the attacker's key had access to sensitive user data?
      - avarun 9mo ago
        [flagged]
      - throwawaysleep 9mo ago
        All the more reason to nuke the key ASAP, no?

nh2 9mo ago

So that after the attackers exfiltrate your file to their Anthropic account, now the rest of the world also has access to that Anthropic account and thus your files? Nice plan.

DominoTree 9mo ago
For a window of a few minutes until the key gets automatically revoked Assuming that they took any of your files to begin with and you didn't discover the hidden prompt

Davidzheng 9mo ago

I'm being kind of stupid but why does the prompt injection need to POST to anthropic servers at all, does claude cowork have some protections against POST to arbitrary domain but allow POST to anthropic with arbitrary user or something?

pleurotus 9mo ago
Yeah they mention it in the article, most network connections are restricted. But not connections to anthropic. To spell out the obvious—because Claude needs to talk to its own servers. But here they show you can get it to talk to its own servers, but put some documents in another user's account, using the different API key. All in a way that you, as an end user, wouldn't really see while it's happening.
rswail 9mo ago
In the article it says that Cowork is running in a VM that has limited network availability, but the Anthropic endpoint is required. What they don't do is check that the API call you make is using the same API key as the one you created the Cowork session with. So the prompt injection adds a "skill" that uses curl to send the file to the attacker via their API key and the file upload function.