Live data from Hacker News

Google API keys weren't secrets, but then Gemini changed the rules

trufflesecurity.com

91–100 of 326 posts

Re: Google API keys weren't secrets, but then Gemini changed the rules

#91

ChatGPT writing a blog post attacking Gemini security flaws. It's their world now, we're just watching how it plays out.

How do you know that this blog post was written by ChatGPT?

The fact that according to this reply section most of HN can't tell means that predictably, all hope is lost and there's no point in writing anything by hand any more if you're in it for money/engagement.

While writing this I suddenly realized that marketers and writers probably do a better job at recognizing it than developers and engineers, so maybe all hope isn't.

For those who want to know the tells: overall cadence and frequency of patterns - especially infrequency of patterns - are the biggest ones. And that means that we can't actually give you the best tells, because they're more about what is absent than what is present. What's absent is a single sentence pattern that falls completely out of the LLM go-toes. Anything human written has at most a good mix of both. LLM-written text just entirely lacks it. Humans do use the LLM-preferred patterns, but not for every single sentence. But anyway, here we go.

> Transparently, the initial triage was frustrating; the report was dismissed as "Intended Behavior”. But after providing concrete evidence from Google's own infrastructure, the GCP VDP team took the issue seriously.

^ Fun fact - The ";" would've originally been an em-dash but was either rewritten or a rule was included for this.

> Then Gemini arrived.

^ Dramatic short sentences, a pattern with magnitudes higher LLM-frequency than human frequency, but hasn't reached the public conscious yet a la "not just X but Y".

> No warning. No confirmation dialog. No email notification.

^ Another such pattern. Not just because it's three of them, but also because of the content and repetition. Humans rarely write like that because it again sounds overly dramatic. It's something you see in fiction rather than a technical writeup. In a thriller.

> Retroactive Privilege Expansion. You created a Maps key three years ago and embedded it in your website's source code, exactly as Google instructed. Last month, a developer on your team enabled the Gemini API for an internal prototype. Your public Maps key is now a Gemini credential. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill. Nobody told you.

This style of scenario writing is another one.

> Nobody told you.

Absolute drama queen.

>The UI shows a warning about "unauthorized use," but the architectural default is wide open.

Again.

> The attacker never touches your infrastructure. They just scrape a key from a public webpage.

Again.

> These aren't just hobbyist side projects. The victims included major financial institutions, security companies, global recruiting firms, and, notably, Google itself.

..

> A key that was deployed years ago for a completely benign purpose had silently gained full access to a sensitive API without any developer intervention.

Surprised it hasn't gained consciousness by now. Maybe that's a future plot point.

Here's a great example to train your skills on, because it's rare in that the ratio of "human : straight from LLM" increased gradually as the article goes on: https://www.wallstreetraider.com/story.html

It started at heavy human editing (or just human-written), but less and less towards the end.

The author confirmed this upon pointing it out, FWIW [0].

[0] https://news.ycombinator.com/item?id=47013150

Re: Google API keys weren't secrets, but then Gemini changed the rules

#92
This totally reminds me of SSN use, when initially they were just a number (not secret) to identify a person, and then suddenly people started to use them as a key for authorisation, because someone had a bright idea how to implement things fast/simple/cheap (cheap part comes at expense of others)

Re: Google API keys weren't secrets, but then Gemini changed the rules

#93

This seems so… obvious? How can a company of this size, with its talent and expertise, not have standardized tests or specs preventing such a blatant flaw?

First of all, Google is a shell of the company it used to be. That said, I’d actually argue there’s an evolutionary explanation behind this where at a certain size, and more importantly complexity, an oversight like this becomes even more likely, not less.

I feel it in a smaller but forced growing organization as the combination of atomised responsibilities and confused/overloaded coordination. For - a certian kind of - efficiency people are isolated into their responsibility area that they are able to oversee/comprehend - with accountability - that a manegement layer is supposed to coordinate. If the mangemenet layer is now overloaded or poorly executed - confused in case of evolution and growth and any kind of restructuring - but the atomic responsibility areas are having basically no (other than anecdotic employee chatter) oversight then troubles, even obvious ones, go undetected.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#94
post #26

Earlier quoted context omitted.

It feels generated to me too. It’s this: When you enable the Gemini API (Generative Language API) on a Google Cloud project, existing API keys in that project (including the ones sitting in public JavaScript on your website) can silently gain access to sensitive Gemini endpoints. No warning. No confirmation dialog. No email notification. Specifically, the last bit - “No warning. No confirmation dialog. No email notif…

I’m not a native speaker so my level of AI recognition is already low. I find it very interesting what patters people bring up to declare it’s AI. The 3 punchline one for instance is a pattern I use while speaking. Can’t say I would write like this though.

I'm not a native speaker and my level of AI recognition is higher than 99.999% of native speakers - and I'd be happy to be tested on it for proof.

The biggest factor is simply how long you've been using LLMs to generate text, how often, how much. It's like how an experienced UI designer can instantly tell that something is off by a single pixel off upon first seeing a UI, whereas if you gave me $200 to find it within 10 minutes I might well fail.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#95
post #15

Earlier quoted context omitted.

Yeah its tremendously unclear how they can even recover from this. I think the most selective would be: they have to at minimum remove the Generative Language API grant from every API key that was created before it was released. But even that isn't a full fix, because there's definitely keys that were created after that API was released which accidentally got it. They might have to just blanket remove the Generative…

The Gemini API is not enabled by default, it has to be explicitly enabled for each project. The problem here is that people create an API key for use X, then enable Gemini on the same project to do something else, not realizing that the old key now allows access to Gemini as well. Takeaway: GCP projects are free and provide strong security boundaries, so use them liberally and never reuse them for anything public-fac…

Isn't there a limit to the number of projects you can make and then you have to ask support to increase it?

Re: Google API keys weren't secrets, but then Gemini changed the rules

#96

Earlier quoted context omitted.

Seems like they ought to be dedicated security teams monitoring for exactly this: does a key to X give users access to not-X. Even more bizarre is their VDP team not immediately understanding the severity of the issue.

That's how you slow down development to a crawl

Yeah, lets just start building a house and don't wait for architects to finish the blueprints :) They just slowing us down with all that thinking things through stuff.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#97
post #47

> 2,863 Live Keys on the Public Internet It will be more interesting if they scan GitHub code instead. The number terrified me. Though I am not sure how many of that are live.

2k feels very small considering the number of business sites that embed Google Maps. I guess a lot of those sites use other website building services that handle the Google API keys for them, and/or they're old and untouched enough that no one enabled Gemini on them.

I had the same thought. I guess a lot of those keys may belong to dormant/deleted accounts and only a % of people who have enabled Gemini (presumably it required user action)

Re: Google API keys weren't secrets, but then Gemini changed the rules

#98
Explain It Like I'm Five.

From TFA:

> Last month, a developer on your team enabled the Gemini API for an internal prototype. > The result: thousands of API keys that were deployed as benign billing tokens are now live Gemini credentials sitting on the public internet.

Benign, deployed openly without any access restrictions whatsoever, billing tokens can be used to bill for a service under the account it is enabled for. That's the intended behavior, literally. Maps API keys are used to give your users access to Google Maps on your credit card.

What's the problem here? Yes, the defaults could have been stricter, but it's not like it costs anything to create a bunch of internal projects that do not have good-for-billing access keys floating around open internet. People moved fast, deployed LLM generated code, broke things and then blame everyone else but themselves?

Re: Google API keys weren't secrets, but then Gemini changed the rules

#99

What's frustrating is that a lot of these keys were generated a long time ago with a small amount of GCP services that they could connect to. (Ex. Firebase remote config, firestore, etc.) When Gemini came around, rather than that service being disabled by default for those keys, Gemini was enabled, allowing exploiters to easily utilize these keys (Ex. a "public" key stored in an APK file)

Gemini API is not enabled by default, a project owner has to go explicitly enable it. The problem described here is that developer X creates an API key intended for Maps or something, developer Y turns on Gemini, and now X's key can access Gemini without either X or Y realizing that this is the case. The solution is to not reuse GCP projects for multiple purposes, especially in prod.

Or usecase: developer X stopped using Maps/etc N years ago, and is long gone, and then developer Y stumbles into the company's google api console.

Of course, Google is full of smart anti-fraud experts, they just handle 80% of this shit on the back-end, so they don't care about the front-end pain.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#100

ChatGPT writing a blog post attacking Gemini security flaws. It's their world now, we're just watching how it plays out.

They may have used ChatGPT or similar to help with the prose but the technical content (as discussed elsewhere on this page) is good, so does it really matter if they did?

The problem with AI slop (to me) is more that the technical content is not good or is entirely the product of the LLM. At that point, there's no point in me reading it, I can just prompt the question if I'm interested.

This is original research which wasn't public before, so the value is still there and I didn't think whichever combination of a human and LLM that generated it did a bad job.

Post reply on HN