Live data from Hacker News

How to gain code execution on hundreds of millions of people and popular apps

kibty.town

91–100 of 350 posts

Re: How to gain code execution on hundreds of millions of people and popular apps

#91
post #73

Earlier quoted context omitted.

If you don't network isolate your build tooling then how do you have any confidence that your inputs are what you believe them to be? I run my build tools in a network namespace with no connection to the outside world. The dependencies are whatever I explicitly checked into the repo or otherwise placed within the directory tree.

You don't have any confidence beyond what lockfiles give you (which is to say the npm postinstall scripts could be very impure, non-hermetic, and output random strings). But if you require users to vendor all their dependencies, fully isolate all network traffic during build, be perfectly pure and reproducible and hermetic, presumably use nix/bazel/etc... well, you won't have any users. If you want a perfectly secure…

> But if you require users

I'm not suggesting that a commercial service should require this. You asked "In what world do you have ..." and I'm pointing out that it's actually a fairly common practice. Particularly in any security conscious environment.

Anyone not doing it is cutting corners to save time, which to be clear isn't always a bad thing. There's nothing wrong if my small personal website doesn't have a network isolated fully reproducible build. On the other hand, any widely distributed binaries definitely should.

For example, I fully expect that my bank uses network isolated builds for their website. They are an absolutely massive target after all.

Re: How to gain code execution on hundreds of millions of people and popular apps

#92

Earlier quoted context omitted.

With privileged access, the attackers can tamper with the evidence for repudiation, so although I'd say "nothing in the logs" is acceptable, not everyone may. These two attack vectors are part of the STRIDE threat modeling approach.

They don’t elaborate on the logging details, but certainly must good systems don’t allow log tampering even for admins.

[deleted]

Re: How to gain code execution on hundreds of millions of people and popular apps

#93
post #85

Earlier quoted context omitted.

I don't think the lesson is lost. The opposite. If you get a slap on the wrist, do you learn? No, you play it down. However if a dev who gets caught doing a bad is forced to resign. Then all the rest of the devs doing the same thing will shape up.

Under what theory of psychology are you operating? This is along the same lines as the theory that punishment is an effective deterrent of crime, which we know isn’t true from experience.

While I think that resigning is stupid here, asserting that "punishment doesn't deter crime" is just absurd. It does!

Re: How to gain code execution on hundreds of millions of people and popular apps

#94

Earlier quoted context omitted.

Isn't it really common for build machines to have outbound internet access? Millions of developers use GitHub Actions for building artifacts and the public runners definitely have outbound internet access

Indeed, you can indeed punch out from an actions runner. Such a thing is probably against GitHub's ToS, but I've heard from my third cousin twice removed that his friend once ssh'ed out from an action to a bastion host, then used port forwarding to get herself a shell on the runner in order to debug a failing build.

> probably against GitHub's ToS, but

Why would running code on a github action runner that's built to run code be against ToS?

If it was, I'm sure they'd ban the marketplace extensions that make it absolutely trivial to do this: https://github.com/marketplace/actions/debugging-with-ssh

Re: How to gain code execution on hundreds of millions of people and popular apps

#95
post #73

Earlier quoted context omitted.

If you don't network isolate your build tooling then how do you have any confidence that your inputs are what you believe them to be? I run my build tools in a network namespace with no connection to the outside world. The dependencies are whatever I explicitly checked into the repo or otherwise placed within the directory tree.

You don't have any confidence beyond what lockfiles give you (which is to say the npm postinstall scripts could be very impure, non-hermetic, and output random strings). But if you require users to vendor all their dependencies, fully isolate all network traffic during build, be perfectly pure and reproducible and hermetic, presumably use nix/bazel/etc... well, you won't have any users. If you want a perfectly secure…

Most banks and larger enterprises do exactly this. Devs don't get to go out and pick random libraries with out a code review and then it's placed on a local repository.

There are just far too many insecure and 'typo' malware to pull off the internet raw.

Re: How to gain code execution on hundreds of millions of people and popular apps

#96

Earlier quoted context omitted.

Firebase let's anyone get started in 30 seconds. Details like proper usage, security, etc. Those are often overlooked. Google isn't to blame if you ship a paid product without running a security audit. I use firebase essentially for hobbyist projects for me and my friends. If I had to guess these issues come about because developers are rushing to market. Not Google's fault ... What works for a prototype isn't produc…

> Google isn't to blame if you ship a paid product without running a security audit. Arguably, if you provide a service that makes it trivial to create security issues (that is to say, you have to go out of your way to use it correctly) then it's your fault. If making it secure means making it somewhat less convenient, it's 100% your fault for not making it less convenient.

What if I need to hack together a POC for 3 people to look at.

It's my responsibility to make sure when we scale from 3 users to 30k users we take security seriously.

As my old auto shop teacher used to say, if you try to idiot proof something they'll build a better idiot.

Even if Google warns you in big bold print "YOU ARE DOING SOMETHING INSECURE", someone out there is going to click deploy anyway. You're arguing Google disable the deploy button, which I simply disagree with.

Re: How to gain code execution on hundreds of millions of people and popular apps

#97
post #61

Earlier quoted context omitted.

It is and regardless a few other commenters saying or hinting it isn't...it is. An air gapped build machine wouldn't work for most software built today.

Sounds like a problem with modern software build practices to me.

Ya too many people think it's a great idea to raw dog your ci/cd on the net and later get newspaper articles written about the data leak.

The number of packages that is malicious is high enough, then you have typo packages, and packages that get compromised at a later date. Being isolated from the net with proper monitoring gives a huge heads up when your build system suddenly tries to contact some random site/IP.

Re: How to gain code execution on hundreds of millions of people and popular apps

#98
post #85
post #81

Earlier quoted context omitted.

This is the wrong response, because that means that the learning would be lost. The security community didn't want that to happen when one of the CA's got a vulnerability, we do not want it to happen to other companies. We want companies to succeed and get better, being shameful doesn't help towards that. Learning the right lessons does, and resigning means that you are learning the wrong ones.

I don't think the lesson is lost. The opposite. If you get a slap on the wrist, do you learn? No, you play it down. However if a dev who gets caught doing a bad is forced to resign. Then all the rest of the devs doing the same thing will shape up.

> However if a dev who gets caught doing a bad is forced to resign.

then nearly everyone involved has incentive to coverup problem or to shift blame

Re: How to gain code execution on hundreds of millions of people and popular apps

#99
post #41

This is the second big attack found by this individual in what... 6 months? The previous exploit (which was in Arc browser), also leveraged a poorly configured firebase db: https://kibty.town/blog/arc/ So this is to say, at what point should we start pointing the finger at Google for allowing developers to shoot themselves in the foot so easily? Granted, I don't have much experience with firebase, but to me this just…

I don't think Firebase is really at fault here—the major issue they highlighted is that the deployment pipeline uploaded the compiled artifact to a shared bucket from a container that the user controlled. This doesn't have anything to do with firebase—it would have been just as impactful if the container building the code uploaded it to S3 from the buildbot.

Agreed. I recently stumbled upon the fact that even Hacker News is using Firebase for exposing an API for articles. Caution should be taken when writing server-side software in general.

Re: How to gain code execution on hundreds of millions of people and popular apps

#100
post #93

Earlier quoted context omitted.

Under what theory of psychology are you operating? This is along the same lines as the theory that punishment is an effective deterrent of crime, which we know isn’t true from experience.

While I think that resigning is stupid here, asserting that "punishment doesn't deter crime" is just absurd. It does!

> While I think that resigning is stupid here, asserting that "punishment doesn't deter crime" is just absurd. It does!

Punishment does not deter crime. The threat of punishment does to a degree.

IOW, most people will be unaware of a person being sent to prison for years until and unless they have committed a similar offense. But everyone is aware of repercussions possible should they violate known criminal laws.

Post reply on HN