9 ms·

Apparently there was a "blogpost" of a developer showing of their code, where they accidentally leaked access tokens in a piece of commented code: https://archi

Apparently there was a "blogpost" of a developer showing of their code, where they accidentally leaked access tokens in a piece of commented code: https://archive.ph/mP3bh https://archive.ph/mP3bh This is completely unverified though, so take it with a grain of salt.

bilekas 4y ago
It's incredibly disappointing actually how often this happens. I can't count the amount of SO questions I've had to edit from others posting live API Keys for everything from custom services to AWS.
- swimfar 4y ago
  When you do this is there a way to completely get rid of the information? Usually you can go back an look at the edit history to see the original post.
  - bilekas 4y ago
    Yeah mods can clear the review history - for this very reason! But as mentioned below - Still advised to change your keys for obvious reasons
  - aembleton 4y ago
    Change the keys.
  - capableweb 4y ago
    Wouldn't matter. Tons of bots are scraping every inch of the internet all the time, and if something been online for five seconds, it has been cached/stored somewhere. Always assume that anything you've put up on the internet, can forever be accessed by someone. The only thing you can do is rotating the token/secret.
    - teddyh 4y ago
      http://www.threepanelsoul.com/comic/on-that-guy http://www.threepanelsoul.com/comic/on-that-guy
- TecoAndJix 4y ago
  I wonder if you could make a luhn-like check that would require an additional approval step to post if it comes back positive. Something like "It looks like you may be posting a secret *****. Do you wish to continue?
  - bilekas 4y ago
    I was thinking about that too, but it's actually tricky, even the example given, they use the var `accessId` but you could filter for all that, even the standard ones, but you couldn't have enough confidence in it so that if someone did post with a typo or even a random var name, they would think "Okay, no warning so must be okay". Something like giving false confidence to the user. Not the best idea.
  - jewel 4y ago
    If vendors agreed to a common prefix on all secret key values then it'd be easy for everyone to add checks, to everything. Something like "_SECRET88_". Of course, then your secret key checker would need to build that string by concatenating so that it wouldn't set off itself.
    - zricethezav 4y ago
      More and more providers have been adding unique prefixes to their tokens and access keys which makes detection much easier. Ex, GitLab adds `glpat-` to their PAT. A project I maintain, Gitleaks, can easily detect "unique" secrets and does a pretty good job at detecting "generic" secrets too. In this case, the generic gitleaks rule would have caught the secrets [1]. You can see the full rule definition here [2] and how the rule is constructed here [3]. [1] https://regex101.com/r/CLg9TK/1 https://regex101.com/r/CLg9TK/1 [2] https://github.com/zricethezav/gitleaks/blob/master/config/gitleaks.toml#L1139-L1147 https://github.com/zricethezav/gitleaks/blob/master/config/g... [3] https://github.com/zricethezav/gitleaks/blob/master/cmd/generate/config/rules/generic.go https://github.com/zricethezav/gitleaks/blob/master/cmd/gene...
    - pitched 4y ago
      How about scanning for any string with high entropy? Might be easier to get buy-in if we don’t all have to bike-shed over what the prefix is.
- segudev 4y ago
  Indeed, last year we detected on average 84 AWS IAM creds for every 10k commits pushed to GitHub https://res.cloudinary.com/da8kiytlc/image/upload/v1646148528/GitGuardian_StateOfSecretsSprawl2022.pdf https://res.cloudinary.com/da8kiytlc/image/upload/v164614852...
sebazzz 4y ago
Remember when we still used password Windows Authentication and a private shielded network you could only get into with VPN instead of public cloud services with generic access credentials. It still didn't make leaking credentials right, but it was one extra layer of protection.
haasted 4y ago
Binance CEO confirmed this version: https://twitter.com/cz_binance/status/1543905416748359680 https://twitter.com/cz_binance/status/1543905416748359680
- throwaway787544 4y ago
  Starting today, this will be known as "Shanghai'd credentials" and be reason #1 why we use ephemeral credentials (e.g. AWS STS/SSO) rather than static credentials (e.g. IAM Users)
  - throwaway2037 4y ago
    I never heard about "ephemeral credentials" before your post. I have some Googling to do!
    - krageon 4y ago
      It's essentially an access token with a very short expiry time.
    - toomuchtodo 4y ago
      The other term of art is “dynamic secrets.” https://www.vaultproject.io/use-cases/dynamic-secrets https://www.vaultproject.io/use-cases/dynamic-secrets
      - 0des 4y ago
        Good lookin out, thanks for the link
  - compumike 4y ago
    Doesn't the client still need to know a long-lived secret (or a long-lived refresh token) in order to generate the ephemeral credentials?
    - toomuchtodo 4y ago
thrdbndndn 4y ago
The consensus in Chinese community is while this is likely how the token got leaked, this alone isn't enough. To visit private Alibaba Cloud instance you can't just use some random IP. It's isolated from the Internet in certain way.
- rfoo 4y ago
  And we all know isolations based on network perimeter eventually falls apart, and because it encourages insecure opsec practices like this, people are going to have a big surprise when it happens.
zricethezav 4y ago
Assuming this unverified version of the story is true, the danger of accidentally leaking credentials in code is enormous and one of the reasons I continue to maintain and develop gitleaks. Those credentials[1] would have been caught by the gitleaks' generic rule [2] [1] https://regex101.com/r/CLg9TK/1 https://regex101.com/r/CLg9TK/1 [2] https://github.com/zricethezav/gitleaks/blob/master/config/gitleaks.toml#L1139-L1147 https://github.com/zricethezav/gitleaks/blob/master/config/g...
- alias_neo 4y ago
  How were the words selected for the regex? It's interesting that "pass" is not there and breaks detection in your first link, but I assume they were chosen based on the statistics? Is it covered by a different rule perhaps?
  - zricethezav 4y ago
    `pass` by itself might introduce false positives. `passwd` and `password` are common and more likely to be in the ROI of a secret. That said, I'm not opposed to `pass` by itself. I'll have to think about this one... > but I assume they were chosen based on the statistics? Nope, not statistics. Identifiers and keywords are chosen based on what I see out in the wild being a software engineer.
- asdff 4y ago
  It doesn't help that so many tools are like "give me your secret key in plain text in the config file" without at least offering a link to a webpage on the github of how you could secure your keys and use this software
  - zricethezav 4y ago
    hardcoded creds in example documentation... T_T Use vault, env vars, GitHub/GitLab secrets, anything but string literals!!!
    - 4y ago
truthwhisperer 4y ago
poor developer. He may spend this life at a "re-education camp"
deleted 4y ago
[deleted]

bilekas 4y ago

It's incredibly disappointing actually how often this happens. I can't count the amount of SO questions I've had to edit from others posting live API Keys for everything from custom services to AWS.

swimfar 4y ago
When you do this is there a way to completely get rid of the information? Usually you can go back an look at the edit history to see the original post.
- bilekas 4y ago
  Yeah mods can clear the review history - for this very reason! But as mentioned below - Still advised to change your keys for obvious reasons
- aembleton 4y ago
  Change the keys.
- capableweb 4y ago
  Wouldn't matter. Tons of bots are scraping every inch of the internet all the time, and if something been online for five seconds, it has been cached/stored somewhere. Always assume that anything you've put up on the internet, can forever be accessed by someone. The only thing you can do is rotating the token/secret.
  - teddyh 4y ago
    http://www.threepanelsoul.com/comic/on-that-guy http://www.threepanelsoul.com/comic/on-that-guy
TecoAndJix 4y ago
I wonder if you could make a luhn-like check that would require an additional approval step to post if it comes back positive. Something like "It looks like you may be posting a secret *****. Do you wish to continue?
- bilekas 4y ago
  I was thinking about that too, but it's actually tricky, even the example given, they use the var `accessId` but you could filter for all that, even the standard ones, but you couldn't have enough confidence in it so that if someone did post with a typo or even a random var name, they would think "Okay, no warning so must be okay". Something like giving false confidence to the user. Not the best idea.
- jewel 4y ago
  If vendors agreed to a common prefix on all secret key values then it'd be easy for everyone to add checks, to everything. Something like "_SECRET88_". Of course, then your secret key checker would need to build that string by concatenating so that it wouldn't set off itself.
  - zricethezav 4y ago
    More and more providers have been adding unique prefixes to their tokens and access keys which makes detection much easier. Ex, GitLab adds `glpat-` to their PAT. A project I maintain, Gitleaks, can easily detect "unique" secrets and does a pretty good job at detecting "generic" secrets too. In this case, the generic gitleaks rule would have caught the secrets [1]. You can see the full rule definition here [2] and how the rule is constructed here [3]. [1] https://regex101.com/r/CLg9TK/1 https://regex101.com/r/CLg9TK/1 [2] https://github.com/zricethezav/gitleaks/blob/master/config/gitleaks.toml#L1139-L1147 https://github.com/zricethezav/gitleaks/blob/master/config/g... [3] https://github.com/zricethezav/gitleaks/blob/master/cmd/generate/config/rules/generic.go https://github.com/zricethezav/gitleaks/blob/master/cmd/gene...
  - pitched 4y ago
    How about scanning for any string with high entropy? Might be easier to get buy-in if we don’t all have to bike-shed over what the prefix is.
segudev 4y ago
Indeed, last year we detected on average 84 AWS IAM creds for every 10k commits pushed to GitHub https://res.cloudinary.com/da8kiytlc/image/upload/v1646148528/GitGuardian_StateOfSecretsSprawl2022.pdf https://res.cloudinary.com/da8kiytlc/image/upload/v164614852...

sebazzz 4y ago

Remember when we still used password Windows Authentication and a private shielded network you could only get into with VPN instead of public cloud services with generic access credentials. It still didn't make leaking credentials right, but it was one extra layer of protection.

haasted 4y ago

Binance CEO confirmed this version: https://twitter.com/cz_binance/status/1543905416748359680 https://twitter.com/cz_binance/status/1543905416748359680

throwaway787544 4y ago
Starting today, this will be known as "Shanghai'd credentials" and be reason #1 why we use ephemeral credentials (e.g. AWS STS/SSO) rather than static credentials (e.g. IAM Users)
- throwaway2037 4y ago
  I never heard about "ephemeral credentials" before your post. I have some Googling to do!
  - krageon 4y ago
    It's essentially an access token with a very short expiry time.
  - toomuchtodo 4y ago
    The other term of art is “dynamic secrets.” https://www.vaultproject.io/use-cases/dynamic-secrets https://www.vaultproject.io/use-cases/dynamic-secrets
    - 0des 4y ago
      Good lookin out, thanks for the link
- compumike 4y ago
  Doesn't the client still need to know a long-lived secret (or a long-lived refresh token) in order to generate the ephemeral credentials?
  - toomuchtodo 4y ago

thrdbndndn 4y ago

The consensus in Chinese community is while this is likely how the token got leaked, this alone isn't enough. To visit private Alibaba Cloud instance you can't just use some random IP. It's isolated from the Internet in certain way.

rfoo 4y ago
And we all know isolations based on network perimeter eventually falls apart, and because it encourages insecure opsec practices like this, people are going to have a big surprise when it happens.

zricethezav 4y ago

Assuming this unverified version of the story is true, the danger of accidentally leaking credentials in code is enormous and one of the reasons I continue to maintain and develop gitleaks. Those credentials[1] would have been caught by the gitleaks' generic rule [2] [1] https://regex101.com/r/CLg9TK/1 https://regex101.com/r/CLg9TK/1 [2] https://github.com/zricethezav/gitleaks/blob/master/config/gitleaks.toml#L1139-L1147 https://github.com/zricethezav/gitleaks/blob/master/config/g...

alias_neo 4y ago
How were the words selected for the regex? It's interesting that "pass" is not there and breaks detection in your first link, but I assume they were chosen based on the statistics? Is it covered by a different rule perhaps?
- zricethezav 4y ago
  `pass` by itself might introduce false positives. `passwd` and `password` are common and more likely to be in the ROI of a secret. That said, I'm not opposed to `pass` by itself. I'll have to think about this one... > but I assume they were chosen based on the statistics? Nope, not statistics. Identifiers and keywords are chosen based on what I see out in the wild being a software engineer.
asdff 4y ago
It doesn't help that so many tools are like "give me your secret key in plain text in the config file" without at least offering a link to a webpage on the github of how you could secure your keys and use this software
- zricethezav 4y ago
  hardcoded creds in example documentation... T_T Use vault, env vars, GitHub/GitLab secrets, anything but string literals!!!
  - 4y ago

truthwhisperer 4y ago

poor developer. He may spend this life at a "re-education camp"

deleted 4y ago

[deleted]