Slapdash Safeguards

にわか仕込みのセキュリティ

Googleが公開しても良いって言っていたAPIキーが公開したらヤバイものになっていた話

Google Cloud系のAPIキーで公開前提のものがあり、以前は公開されていても問題無いとされていた。

以前から「本当に公開状態でも問題無いのか」という議論はあったようだ。デフォルトの権限が制限されていないキーであれば、他人がそのキーを使ってMaps APIやTranslation APIを大量に叩いて課金したりできると。

それでも、特に変わらなかった雰囲気が遂に動いた。

trufflesecurityの研究者は権限が制限されずに公開されているAPIキーを調査したところ、Google Geminiに関連するエンドポイントで使用できることを発見した。

使えるだけなら勝手に課金するだけ?と思うかもしれないが、geminiでアップロードしたもの、geminiで入力した情報が見えたりしちゃうことも。

Geminiの登場によって「お金だけの問題」に加えて「機密情報漏洩の問題」が追加されたと。

trufflesecurity.com

全部のAPIキーがヤバイわけじゃなくて、権限を制限していないキーがヤバイ。

Google Cloud API key

ここでいうAPIキーとは、「Google Cloud API keys」とか「Google API keys」と言われるようなもの。GCPプロジェクトに紐づくAIzaから始まる形式のAPIキー。

例えば、Google MapのAPIキーとか。

Google Maps Platform公式より(https://developers.google.com/maps/documentation/javascript/add-google-map-wc-tut?hl=ja&gl=1mvl9pmupMQ..gaMTk2OTk4MjUyMC4xNzcyMzM5MjE4ga_SM8HXJ53K2czE3NzIzMzkyMTgkbzEkZzAkdDE3NzIzMzkyMTgkajYwJGwwJGgw_ga_NRWSTWS78N*czE3NzIzMzkyMTgkbzEkZzEkdDE3NzIzMzkzNDMkajIyJGwwJGgw#full_example_code)

これらがデフォルトだとUnrestricted(無制限)で作成されるらしい。サービス側からは注意書きがあるのだが。

trufflesecurityの記事より。 (https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules)

注意書きがあっても無視して使用する人たちは居るし、テスト用に使っていたものをそのまま本番で使用する人たちもよく居る。「そのパスワード危険だから気を付けてね」的なサービス側からのメッセージが表示されているのに、そのまま使用してインシデントに合うのも調査することあるし。

この無制限状態だと「Generative Language API」での使用が許可されており、Gemini関連の情報参照や実際にGeminiを使用できてしまうということ。無制限ではなくても、許可リストに「Generative Language API」が含まれると同じことになる。

なので、Google Map、Youtube、Firebaseなどなどのためと思って使っていたAPIキーが実は制限されていないキーの可能性があり、その状態だと誰かに勝手にGeminiを使われたり、Geminiでのやり取りを盗み見られる。

geminiで勝手に色々?

無制限のAPIキーを手にしてしまえば、geminiのやり取りでアップロードしたファイル、geminiとのやり取りの記録(キャッシュされたコンテキスト)とかを盗まれる。

APIキーを公開しているってことは基本的に企業環境だろうし、顧客対応やら社内業務関連やらのデータが沢山含まれていそうな予感。

あとは、geminiを勝手に使えるので無課金Gemini勢が現れるわけですな。

もしかして、時々話題に挙がるGeminiを使用した攻撃者って、こういうところで拾ったAPIキーを使って攻撃に使っているんでしょうかね。

身元がバレずに課金Geminiが使われていることは、APIキーの公開は攻撃に加担していることになるかもしれない。

APIキーの公開に関してはサービスごとに案内がちょっと違う

trufflesecurityの記事ではFirebase公式の「APIキーは非公開ではない」の箇所がピックアップされているが、本来のページの1つ下にはキーの制限に関しても記述されている。

Firebase セキュリティチェックリストより(https://firebase.google.com/support/guides/security-checklist?hl=ja#api-keys-not-secret)

ただし、上記のようにFirebaseだけ「キーは非公開ではない」の強調は明らかで、他のサービスはセキュリティチェックリストやベストプラクティスで一番上にAPIキーの制限から話が始まっている。

Google Cloud公式より(https://docs.cloud.google.com/docs/authentication/api-keys-best-practices?hl=ja)

Google Maps Platform公式より(https://developers.google.com/maps/api-security-best-practices?hl=ja)

こういう感じだと、今回の件で一番被害多そうなのはFirebase関連サービスかなぁと想像している。

APIキーの公開に関しては以前から色々とあったらしい

stackoverflowやgithubの色々なところで議論されているが、大体はFirebaseの記事を参照して「公開大丈夫だよ」が目立っているように見える。ただし、よくよく読むと「APIキーは絶対制限して」ってどこかしらに書いてある。
stackoverflow.com

github.com

github.com

どちらかというと、「データ漏洩にはつながらない」という点で深刻度が低く見積られ続けてきたような印象を受ける。

バグバウンティプラットフォームでは認められたり、認められなかったりのようで。勝手にAPIを使って大量課金攻撃できるようなケースでも、一度「情報提供レベル」のラベルが貼られてしまうと無視されたケースもあるとのこと。にしても、APIキー露出だけでも頑張ったら$3000稼げるんか。
ozguralp.medium.com

trufflehog

trufflesecurityは今回のような「APIキーやらがソースコードのどこに埋まっているか検知する」ようなツールを公開している。
github.com

これを使えば、今回のようなことが起こるような忘れたAPIキー無いかチェックしたり、$3000稼げるかも。

trufflesecurity.com

chintalatarakaram.medium.com

dev.to

medium.com

ところで気になったのは「Common Crawl」

trufflesecurityは、利用可能なAPIキーがどれほど公開されているのかを調査するためにCommon Crawlのデータを使用した。
commoncrawl.org

これ初めて知りました。

おそらく、Common Crawlが自分たちのインフラで世界中のWebサイトをスキャンしたのだと思われる。

つまり、これ使ったら対象のWebサイトに自分でアクセスしなくても情報収集できちゃうわけですな。

攻撃者は、ShodanやCensysも同じような使い方をするわけだが、こういうのもあるのかぁ。