[HN Gopher] Public secrets exposure leads to supply chain attack...
___________________________________________________________________
Public secrets exposure leads to supply chain attack on GitHub
CodeQL
Author : cyberbender
Score : 132 points
Date : 2025-03-30 19:54 UTC (3 hours ago)
(HTM) web link (www.praetorian.com)
(TXT) w3m dump (www.praetorian.com)
| junto wrote:
| They weren't kidding on the response time. Very impressive from
| GitHub.
| belter wrote:
| Not very impressive to have an exposed public token with full
| write credentials...
| 1a527dd5 wrote:
| Trying my best not to break the no snark rule [1], but I'm
| sure your code is 100% bullet proof against all current and
| future-yet-invented-attacks.
|
| [1] _and failing_.
| atoav wrote:
| Nobody is immune against mistakes, but a certain class of
| mistakes1 should never ever happen to anyone who should
| know better. And that in my book is anybody who has their
| code used by more people than themselves. I am not saying
| devs aren't allowed to make stupid mistakes, but if we let
| civil engineers have their bridges collapse with an "shit
| happens" -attitude trust in civil engineering would be
| questionable at best. So yeah shit happens to us devs, but
| we should be shamed if it was preventable by simply knowing
| the basics.
|
| So my opinion is anybody who writes code that is used by
| others should feel a certain danger-tingle whenever a
| secret or real user data is put literally _anywhere_.
|
| To all beginners that just means that when handling
| secrets, instead of pressing on, you should pause and make
| an exhaustive list of who would have read/write access to
| the secret under which conditions and whether that is
| intended. And with things that are world-readable like a
| public repo, this is especially crucial.
|
| Another one may or may not be your shells history, the
| context of your environment variables, whatever you copy-
| paste into the browser-
| searchbar/application/LLM/chat/comment section of your
| choice etc.
|
| If you absolutely _have_ to store secrets /private user
| data in files _within_ a repo it is a good idea to add the
| following to your .gitignore: *.private
| *.private.*
|
| And then every such file has to have ".private." within the
| filename (e.g. credentials.private.json), this not only
| marks it to yourself, it also prevents you to mix up
| critical with mundane configuration.
|
| But better is to spend a day to think about where
| secrets/user data really should be stored and how to manage
| them properly.
|
| 1: a non-exhaustive list of other such mistakes: mistaking
| XOR for encryption, storing passwords in plaintext, using
| hardcoded credentials, relying on obscurity for security,
| sending data unencrypted over HTTP, not hashing passwords,
| using weak hash functions like MD5 or SHA-1, no input
| validation to stiff thst goes into your database, trusting
| user input blindly, buffer overflows due to unchecked
| input, lack of access control, no user authentication,
| using default admin credentials, running all code as
| administrator/root without dropping priviledges, relying on
| client-side validation for security, using self-rolled
| cryptographic algorithms, mixing authentication and
| authorization logic, no session expiration or timeout,
| predictable session IDs, no patch management or updates,
| wide-open network shares, exposing internal services to the
| internet, trusting data from cookies or query strings
| without verification, etc
| immibis wrote:
| > no input validation to stiff thst goes into your
| database
|
| I'd put "conflating input validation with escaping" on
| this list, and then the list fails the list because the
| list conflates input validation with escaping.
| atoav wrote:
| [delayed]
| toomuchtodo wrote:
| Perfect security does not exist. Their security system
| (people, tech) operated as expected with an impressive
| response time. Room for improvement, certainly, but there
| always is.
|
| Edit: Success is not the absence of vulnerability, but
| introduction, detection, and response trends.
|
| (Github enterprise comes out of my budget and I am
| responsible for appsec training and code IR, thoughts and
| opinions always my own)
| koolba wrote:
| > Success is not the absence of vulnerability, but
| introduction, detection, and response trends.
|
| Don't forget limitation of blast radius.
|
| When shit hits the proverbial fan, it's helpful to limit
| the size of the room.
| toomuchtodo wrote:
| Yeah, I agree compartmentalization, least privilege, and
| sound architecture decisions are a component of reducing
| the pain when you get popped. It's never if, just when.
| bloqs wrote:
| This sites performance is so bad i can barely scroll
| nyrikki wrote:
| No mention why this temp token had rights to do things like
| create a new deployments and generate artifact attestations?
|
| For their fix, they disabled debug logs...but didn't answer if
| they changed the temp tokens permissions to something more
| appropriate for a code analysis engine.
| declan_roberts wrote:
| I think we all know this old story. The engineer building it
| was getting permission denied so they gave it all the
| permissions and never came back and right-sized.
| azemetre wrote:
| What's the over/under that said engineer could solve two
| medium leetcodes in under and hour?
| setr wrote:
| Does any RBAC system actually tell you the missing
| permissions required to access the object in question? It's
| like they're designed to create this behavior
| levkk wrote:
| Not usually, that's considered an potential attack vector I
| believe. You're looking to minimize information leakage.
| Normal_gaussian wrote:
| Yes. Most auth systems do to the developer - GCP & AWS IAM
| give particularly detailed errors; nearly every
| feature/permission system I have implemented did. However,
| it wouldn't be unusual for the full error to be wrapped or
| swallowed by some lazy error handling. Its a bit of a PITA
| but well worth it to translate to a safe and informative
| user facing error.
|
| as a nit; RBAC is applied to an object based permissions
| system rather than being one. Simply, RBAC is a
| simplification of permission management in any underlying
| auth system.
| ryao wrote:
| I put CodeQL in use in OpenZFS PRs. This is not an issue for
| OpenZFS. None of our code is secret. :)
| atxtechbro wrote:
| Is this fixed?
___________________________________________________________________
(page generated 2025-03-30 23:00 UTC)