5 ms·

The article has answers > It seems that the original author > - Briefly added the authorization token to their source code > - Ran the source code (Python sc

by ketch 2y ago

The article has answers > It seems that the original author > - Briefly added the authorization token to their source code > - Ran the source code (Python script), which got compiled into a .pyc binary with the auth token > - Removed the authorization token from the source code, but didn’t clean the .pyc > - Pushed both the clean source code and the unclean .pyc binary into the docker image

bheadmaster 2y ago
> - Pushed both the clean source code and the unclean .pyc binary into the docker image Oof. Honestly, I can't blame the guy for a mistake like this, it's just so easy to make. But then again, deploying images built on a development laptop is generally an error-prone activity. This is why build and deployment servers exist.
- sitkack 2y ago
  Why does one person have admin on all those repos? Why is Python still running any classic access tokens? Why is the access token EVER in the source code? What other stuff is “running on their laptop”? No pass! People with access to the repos shouldn’t also have access to push bits to the world. It puts those people with that access in grave physical danger. Edit, https://blog.pypi.org/posts/2024-07-08-incident-report-leaked-admin-personal-access-token/ https://blog.pypi.org/posts/2024-07-08-incident-report-leake... This token has been in the wild for 15 months! The JFrog post cannot say that disaster was averted because we do not know.
  - andrewSC 2y ago
    This is the correct set of questions to be asking. I’m a little more than surprised there aren’t some defined processes and automation around high viz workflows/stuff like this. When are people going to take cybersec and opsec seriously? Esp. In big projects?
    - sitkack 2y ago
      And the logs are gone for both GitHub and docker hub. We should assume anything that could get compromised is compromised.
      - salawat 2y ago
        ...There is a reason why those crazies that tell you to build everything from source you personally audit, and to read everything exist. Y'all want the convenience of "can't someone else just gimme something that works"? Which is fine, but you have to verify the thing is what the other person claims it is. It's the curse of high-trust systems. They are only as trustworthy as the least trustworthy member. We've done everything we can to rope in everybody. Everybody includes people who are actively malicious to the ecosystem as a whole. Thus the high-trust system has raced to the bottom in transitioning through a low-trust system, to eventually zero-trust; as computer networks in all their forms are just too juicy a set of targets to leave untapped by malicious/selfish actors. The only defense is everyone looking out for themselves on top of everyone else. It's fcking hard. It's a slog. It makes the act of maintaining computing systems that much less sexy. It's also what keeps you* safe from the wolves in sheep's clothing. My journey in computing has branched out far and wide, only to crunch back to a narrow set of tools that I can vouch for personally. My trust of the denizens of the Net has plummeted, if only because the spaces in the cracks where belief rather than knowledge lie are just such fertile ground for skulduggery now.
        yupyupyups 2y ago
        I think the inefficency of zero-trust can be applied to many other things in life. Like > The only defense is everyone looking out for themselves on top of everyone else. It's fcking hard. It's a slog. It makes the act of maintaining relationships that much less sexy.
    - coldpie 2y ago
      Computer security requires humans to do 500,000 things perfectly, and one slip up means everything they did was worthless. It turns out, humans aren't perfect. The result is inevitable: there is no such thing as computer security.
  - belter 2y ago
    > This token has been in the wild for 15 months! The JFrog post cannot say that disaster was averted because we do not know. "Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagine" The above comment from them sounds as weird, as the whole ecosystem security based out of a developer laptop...
  - hirako2000 2y ago
    Exactly. More than one bad practice in there. note the secret was never in the repo though. Only in the container image.
    - sitkack 2y ago
      That token gives admin access to all the repos they have access to.
js2 2y ago
It's probably a good idea for Python developers to disable pyc files in their development environments with PYTHONDONTWRITEBYTECODE=1 in their shell profile, dotenv file, or otherwise. In this case, perhaps it should also be set in the Dockerfile along with entries in .dockerignore to exclude pyc files and __pycache__ directories.
- hirako2000 2y ago
  Or just have a good `.dockerignore` When I create a project now I automatically place a catch all ignore for both git and docker. Binaries, .env files have a far lower chance to end up tracked in a repo or copied over to a container image.
  - zihotki 2y ago
    Or just use CI/CD on a build server to create release artifacts and a proper security setup (no PAT's, or use short living one)
  - deleted 2y ago
    [deleted]
playingalong 2y ago
That's why I consider writing any secrets into code base a security malpractice. Just for a minute or I am sure I won't commit it, is not an excuse. Use environment variables or better yet - store the secret on the disk outside of your repo and make the code read it. It's a one liner in plenty of languages.
sans_souse 2y ago
Great reply thank you. This is totally relatable even to me, as a non-coder. He essentially crafted a shortcut to bypass redundancies, but with the foresight to go back and remove what he thought were all references to that shortcut. He was unaware or forgot there was one last reference and BOOM

by ketch 2y ago

bheadmaster 2y ago

> - Pushed both the clean source code and the unclean .pyc binary into the docker image Oof. Honestly, I can't blame the guy for a mistake like this, it's just so easy to make. But then again, deploying images built on a development laptop is generally an error-prone activity. This is why build and deployment servers exist.

sitkack 2y ago
Why does one person have admin on all those repos? Why is Python still running any classic access tokens? Why is the access token EVER in the source code? What other stuff is “running on their laptop”? No pass! People with access to the repos shouldn’t also have access to push bits to the world. It puts those people with that access in grave physical danger. Edit, https://blog.pypi.org/posts/2024-07-08-incident-report-leaked-admin-personal-access-token/ https://blog.pypi.org/posts/2024-07-08-incident-report-leake... This token has been in the wild for 15 months! The JFrog post cannot say that disaster was averted because we do not know.
- andrewSC 2y ago
  This is the correct set of questions to be asking. I’m a little more than surprised there aren’t some defined processes and automation around high viz workflows/stuff like this. When are people going to take cybersec and opsec seriously? Esp. In big projects?
  - sitkack 2y ago
    And the logs are gone for both GitHub and docker hub. We should assume anything that could get compromised is compromised.
    - salawat 2y ago
      ...There is a reason why those crazies that tell you to build everything from source you personally audit, and to read everything exist. Y'all want the convenience of "can't someone else just gimme something that works"? Which is fine, but you have to verify the thing is what the other person claims it is. It's the curse of high-trust systems. They are only as trustworthy as the least trustworthy member. We've done everything we can to rope in everybody. Everybody includes people who are actively malicious to the ecosystem as a whole. Thus the high-trust system has raced to the bottom in transitioning through a low-trust system, to eventually zero-trust; as computer networks in all their forms are just too juicy a set of targets to leave untapped by malicious/selfish actors. The only defense is everyone looking out for themselves on top of everyone else. It's fcking hard. It's a slog. It makes the act of maintaining computing systems that much less sexy. It's also what keeps you* safe from the wolves in sheep's clothing. My journey in computing has branched out far and wide, only to crunch back to a narrow set of tools that I can vouch for personally. My trust of the denizens of the Net has plummeted, if only because the spaces in the cracks where belief rather than knowledge lie are just such fertile ground for skulduggery now.
      - yupyupyups 2y ago
        I think the inefficency of zero-trust can be applied to many other things in life. Like > The only defense is everyone looking out for themselves on top of everyone else. It's fcking hard. It's a slog. It makes the act of maintaining relationships that much less sexy.
  - coldpie 2y ago
    Computer security requires humans to do 500,000 things perfectly, and one slip up means everything they did was worthless. It turns out, humans aren't perfect. The result is inevitable: there is no such thing as computer security.
- belter 2y ago
  > This token has been in the wild for 15 months! The JFrog post cannot say that disaster was averted because we do not know. "Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagine" The above comment from them sounds as weird, as the whole ecosystem security based out of a developer laptop...
- hirako2000 2y ago
  Exactly. More than one bad practice in there. note the secret was never in the repo though. Only in the container image.
  - sitkack 2y ago
    That token gives admin access to all the repos they have access to.

js2 2y ago

It's probably a good idea for Python developers to disable pyc files in their development environments with PYTHONDONTWRITEBYTECODE=1 in their shell profile, dotenv file, or otherwise. In this case, perhaps it should also be set in the Dockerfile along with entries in .dockerignore to exclude pyc files and __pycache__ directories.

hirako2000 2y ago
Or just have a good `.dockerignore` When I create a project now I automatically place a catch all ignore for both git and docker. Binaries, .env files have a far lower chance to end up tracked in a repo or copied over to a container image.
- zihotki 2y ago
  Or just use CI/CD on a build server to create release artifacts and a proper security setup (no PAT's, or use short living one)
- deleted 2y ago
  [deleted]

playingalong 2y ago

That's why I consider writing any secrets into code base a security malpractice. Just for a minute or I am sure I won't commit it, is not an excuse. Use environment variables or better yet - store the secret on the disk outside of your repo and make the code read it. It's a one liner in plenty of languages.

sans_souse 2y ago

Great reply thank you. This is totally relatable even to me, as a non-coder. He essentially crafted a shortcut to bypass redundancies, but with the foresight to go back and remove what he thought were all references to that shortcut. He was unaware or forgot there was one last reference and BOOM