[dead]
A Roblox cheat and one AI tool brought down Vercel's platform
41–50 of 186 posts
Re: A Roblox cheat and one AI tool brought down Vercel's platform
#42This 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.
The author’s site is on Vercel.
So I believe the author has exposure to the issue and interest in understanding it, that’s more than AI alone has got.
Re: A Roblox cheat and one AI tool brought down Vercel's platform
#43Feels like the bigger issue here is how much implicit trust we’re starting to place in these AI-integrated workflows.
Tools that sit in the middle (like Context.ai) end up becoming a pretty large attack surface without feeling like one.
Re: A Roblox cheat and one AI tool brought down Vercel's platform
#44This article is LLM authored and full of hallucinations. "Let that sink in for a second."
[deleted]
Re: A Roblox cheat and one AI tool brought down Vercel's platform
#45This 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 don't know why you are downvoted. The article is AI blogspam, it doesn't have any more factual information than eg https://www.darkreading.com/application-security/vercel-empl... and is full of empty LLMisms. It's depressing people are willing to read this.
[dead]
Re: A Roblox cheat and one AI tool brought down Vercel's platform
#46Earlier quoted context omitted.
They said "encrypted at rest", which they almost certainly are. If you spin up an EC2 instance with an ftp server and check the "Encrypt my EBS volume" checkbox, all those files are 'encrypted at rest', but if your ftp password is 'admin/admin', your files will be exposed in plaintext quite quickly. Vercel's backend is of course able to decrypt them too (or else it couldn't run your app for you), and so the attacker…
Hmm, that's confusing. So they're eventually encrypted but plain-text at some point? Doesn't sound good TBH.
Env vars are not secure. Anything that has root access can see all env vars of all applications via /proc.
(And modern Linux is unusable without root access, thanks to Docker and other fast-and-loose approaches.)
Re: A Roblox cheat and one AI tool brought down Vercel's platform
#47I think this is wrong about what “sensitive” means here. AFAIK, all Vercel env cars are encrypted. The sensitive checkbox means that a develop looking at the env var can’t see what value is stored there. It’s a write-only value. Only the app can see it, via an env var (which obviously can’t be encrypted in such a way that the app can’t see it, otherwise it’d be worthless). If you don’t check that box, you can view th…
I don't know how it works on Vercel, but on other platforms it usually means that the value will be redacted in logs as well.
Re: A Roblox cheat and one AI tool brought down Vercel's platform
#48Earlier quoted context omitted.
Hmm, that's confusing. So they're eventually encrypted but plain-text at some point? Doesn't sound good TBH.
There isn't really a way around it.
There is -- you can expose a UNIX socket for serving credentials and allow access to it only from a whitelist of systemd services.
Re: A Roblox cheat and one AI tool brought down Vercel's platform
#49I don't want to do the easy finger-pointing and scapegoating but honestly, what should happen to the Context.ai employee that thought it was a good idea to play games in their work machine and, on top of that, install cheats which are by definition of dubious provenance? I know defense in depth, security layers etc etc but there is also some personal responsibility at play here. We can chalk up the Vercel's employee mistake to a defense in depth failure that's on the whole company and management, but installing a cheat...
Re: A Roblox cheat and one AI tool brought down Vercel's platform
#50Earlier quoted context omitted.
Hmm, that's confusing. So they're eventually encrypted but plain-text at some point? Doesn't sound good TBH.
If a company says “encrypted at rest” that is generally compliance-speak for “not encrypted, but the hard drive partition is encrypted”. Various certifications require this, I guess because they were written before hyper scalers and the assumed attack vector was that someone would literally steal a hard drive. A running machine is not “at rest”, just like you can read files on your encrypted Mac HDD, the running prog…
How does that transalte to VMs? If "encryption at rest" is done at the guest level, instead of (or in addition to) host, that would be pretty close to minimal "encrypted except when it use" time and protect against virtual equivalents of pulling a hard drive out of a data center.