Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Public secrets exposure leads to supply chain attack on GitHub CodeQL

praetorian.com

Post reply on HN
Print view View original

21–30 of 66 posts

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#21

Post by toomuchtodo »

koolba wrote: post #18
toomuchtodo wrote: post #7

Earlier quoted context omitted.

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)

> 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.

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.

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#22

Post by timewizard »

toomuchtodo wrote: post #7
belter wrote: post #3

Earlier quoted context omitted.

Not very impressive to have an exposed public token with full write credentials...

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)

> Perfect security does not exist.

Having your CI/CD pipeline and your git repository service be so tightly bound creates security implications that do not need to exist.

Further half the point of physical security is tamper evidence. Something entirely lost here.

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#23

Post by 8note »

Normal_gaussian wrote: post #17
setr wrote: post #14

Earlier quoted context omitted.

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

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 sys…

ive never seen aws give a useful error where i could say which resources need a handshake of permissions, or which one of the two needs the permission granted, or which permission needs to be granted.

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#24

Post by milch »

8note wrote: post #23
Normal_gaussian wrote: post #17

Earlier quoted context omitted.

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 sys…

ive never seen aws give a useful error where i could say which resources need a handshake of permissions, or which one of the two needs the permission granted, or which permission needs to be granted.

AWS throws errors that look like `arn:aws:iam:... is not authorized to call "$SERVICE_NAME:$API_NAME" on resource arn:aws:$SERVICE_NAME:...`. I think it's more complicated when you go cross account, and the receiving account doesn't have permissions set up (if the calling account doesn't have it set up you get the same error). In any case you would still find that information in the CloudTrail logs of the receiving account

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#25

Post by belter »

toomuchtodo wrote: post #7
belter wrote: post #3

Earlier quoted context omitted.

Not very impressive to have an exposed public token with full write credentials...

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)

> Their security system (people, tech) operated as expected

You mean not finding the vulnerability in the first place?

This would allow:

- Compromise intellectual property by exfiltrating the source code of all private repositories using CodeQL.

- Steal credentials within GitHub Actions secrets of any workflow job using CodeQL, and leverage those secrets to execute further supply chain attacks.

- Execute code on internal infrastructure running CodeQL workflows.

- Compromise GitHub Actions secrets of any workflow using the GitHub Actions Cache within a repo that uses CodeQL.

>> Success is not the absence of vulnerability, but introduction, detection, and response trends.

This isn’t a philosophy, it’s PR spin to reframe failure as progress...

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#26

Post by toomuchtodo »

belter wrote: post #25
toomuchtodo wrote: post #7

Earlier quoted context omitted.

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)

> Their security system (people, tech) operated as expected You mean not finding the vulnerability in the first place? This would allow: - Compromise intellectual property by exfiltrating the source code of all private repositories using CodeQL. - Steal credentials within GitHub Actions secrets of any workflow job using CodeQL, and leverage those secrets to execute further supply chain attacks. - Execute code on inte…

This is not great based on the potential exposure, but also not the end of the world. You’re free to your opinion of course wrt severity and impact, but folks aren’t going to leave GitHub over this in any material fashion imho. They had a failure, they will recover from it and move on. It’s certainly not PR from me, I don’t work for nor have any financial interest in GH or MS. I am a security person though, these are my opinions based on doing this for ~10 years (I am consistently exposed to security gore in my work), and we likely have an expectations disconnect.

As a customer, I’m not going to lose sleep over it. I’m going to document for any audits or other governance processes and carry on. I operate within "commercially reasonable" context for this work. Security is just very hard in a Sisyphus sort of way. We cannot not do it, but we also cannot be perfect, so there is always going to be vigorous debate over what enough is.

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#27

Post by hobs »

milch wrote: post #24
8note wrote: post #23

Earlier quoted context omitted.

ive never seen aws give a useful error where i could say which resources need a handshake of permissions, or which one of the two needs the permission granted, or which permission needs to be granted.

AWS throws errors that look like `arn:aws:iam:... is not authorized to call "$SERVICE_NAME:$API_NAME" on resource arn:aws:$SERVICE_NAME:...`. I think it's more complicated when you go cross account, and the receiving account doesn't have permissions set up (if the calling account doesn't have it set up you get the same error). In any case you would still find that information in the CloudTrail logs of the receiving a…

Right, you can go to cloudtrail and probably get it, but I have definitely ran into things like service says you do not have access to resource or it does not exist - randomly providing the account some other tangentially related permission magically fixes it, I've found sometimes trying the UI and the API will give different errors to help, and neither is particularly more useful than the others.

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#29

Post by Aeolun »

timewizard wrote: post #22
toomuchtodo wrote: post #7

Earlier quoted context omitted.

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)

> Perfect security does not exist. Having your CI/CD pipeline and your git repository service be so tightly bound creates security implications that do not need to exist. Further half the point of physical security is tamper evidence. Something entirely lost here.

I find that this is always easy to say from the perspective of the security team. Sure, it would be more secure to develop like that, but also tons more painful for both dev and user.

Re: Public secrets exposure leads to supply chain attack on GitHub CodeQL

#30

Post by winwang »

Normal_gaussian wrote: post #17
setr wrote: post #14

Earlier quoted context omitted.

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

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 sys…

Slightly disagree at least for GCP. It will error with a detailed permission, but you're not just going to add that -- you're going to add a role (standard, unless you have custom roles), which you technically have to map back to the permission you need. But also, those (standard) roles have many permissions in one, so you likely overprovision (though presumably by just a bit).

...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep.

Post reply on HN