Vercel セキュリティチェックポイント

• 意味のある本文情報がなく、事案の正体や経過を確認できない
• Hacker News のタイトルでは、Roblox のチートと AI ツールが Vercel プラットフォームに影響を与えたと記されている
• 原文タイトルは Vercel Security Checkpoint と示されている
• 具体的な原因、影響範囲、対応方法は、本文の根拠がないため確認できない
• 提供された情報だけでは、事案の重要性や技術的詳細を 要約できない

---

内容なし

[GN⁺]

Hacker Newsの意見

• 文章がAI生成物っぽく強すぎると感じた。わざと文法をぎこちなく混ぜて隠そうとしたようにも見えるが、それが内容の正確性と無関係かどうかまでは確信が持てない

  • 私は読んでいる途中でやめた。もうLLM口調に敏感になりすぎていて、これは実質「ChatGPT、この記事を読んでカジュアルに書き直して」と言ったレベルに見え、実際の著者性がほとんど感じられなかった。こういう種類の投稿なら、HNではできるだけ一次情報を持ってくるべきだと思う
  • なぜ低評価されているのかわからない。この投稿はAIブログスパムに近く、https://www.darkreading.com/application-security/vercel-employees-ai-tool-access-data-breach のような記事より事実情報が多いわけでもなく、中身のないLLM的な言い回しで埋め尽くされているように見えた。こういう文章を人々が喜んで読む空気は少し憂鬱だ
  • 投稿者のサイトがVercel上で動いているのを見た。だからこの問題に実際にさらされていたし、利害関係もある人だと思う。その点だけでも、AI単独生成物よりは一段ましだと思う
  • 文体は明らかにLLM散文っぽいが、全部がそうではないように見えた。おそらく一部だけ書き直したのだと思う。もっと気になるのは、HNのようにLLMに慣れた人が多い場所ですら、こういう文章がそのまま通ってしまうことだ。これが標準になるのは嫌だが、AI生成文が真面目な反応をたくさん受けるHNの例は今回が初めてでもないという点がさらに気になる。コードにAIを使うのは、人間が十分に検証するなら構わないと思うが、LLM散文がフロントページをどんどん占拠していくのは本当に嫌だ
  • 私もまったく同じように感じた。普通の人はあんなふうには書かない

• ここで言う「sensitive」の解釈は間違っていると思う。私の知る限り、Vercelのenv varは保存時にはすべて暗号化されていて、sensitiveチェックボックスは開発者がUI上でその値を再表示できないようにする意味だ。つまりwrite-onlyに近い概念で、アプリはenv var経由で値を見られないと困るのだから、アプリすら読めないように暗号化するのはそもそも無意味だ。チェックを外せばプロジェクトUIで値を見られ、DEFAULT_TIME_ZONE のような一般的な設定値ではその方が実用的だ。だからsensitiveは暗号化の有無ではなく、UI上の露出可否を意味すると理解している。Vercel社員ではないが少し使ったことはあり、この点を批判するのは藁人形論法に見える

  • そう、その部分は私も混乱した。プログラムが実際に使うenv varは、結局平文で注入されるしかない。保存時の暗号化はできても、実行前には最終的に復号しなければならず、これはVercelの問題ではなくシステム構造そのものの限界だ。いつか完全準同型暗号で改善されるかもしれないが、プログラム全体に対するオーバーヘッドが大きすぎて、まだ現実的ではない
  • 流出事故が起きるたびに「暗号化すべきだった」と叫ぶ人は多いが、実際には暗号化の限界を原理面でも実務面でも理解していないことが多いと感じる。暗号化はsecureやsafeの同義語ではない
  • Vercelで正確にどう動いているのかは知らないが、他のプラットフォームでは通常、この表示があるとログでもマスキングされる意味であることが多かった
  • 私の職場ではVaultを使い始めていて、vault key参照用のキーは通常の非秘匿env varに入れている。この方式の方がたぶん堅牢な構成だと思う
  • これは他のクラウドでも似たようなものだ。たとえばDigitalOceanも同じような方式だ

• 安易なスケープゴート作りはしたくないが、それでもContext.aiの社員が業務用端末でゲームをして、しかも出所の怪しいチートプログラムまで入れた件はどう見るべきかと思う。defense in depthや多層防御の話が正しいのはもちろんだが、ここには個人の責任も明らかにあると思う。Vercel側のミスは会社や経営陣レベルの防御失敗と見なせても、チートの導入は本当に別件として深刻に見える

  • AIを導入する企業全般でOpSecレベルが低いと思う。今はセキュリティが意思決定の中核機能ではないからだ。2年前のMcDonalds侵害事例を見ても似た流れがある
  • その社員が本当に業務用端末にそれをインストールしたのかは、まだわからないと思う。少なくともこの記事には書かれておらず、他の情報源でも見つけられなかった。多くの会社は社内VPN接続や一部内部システムへのインターネットからの直接ログインを許していたりもするが、望ましくはなくても思ったよりよくある。Disneyのハッキングも個人PCに入れた侵害済みソフトウェアが発端だったことを思い出す。私が直接見てきた限り、多くの会社のITは思ったよりずっとずさんだ
  • 私ならむしろ、ユーザーが任意のソフトウェアをインストールできるようにしていたIT部門をもっと責める
  • 私も全面的に同意する。仕事用と私用を1台のノートPCで兼ねるという発想自体、すでにかなり無理があると感じる。時価総額で世界上位10社級のある企業では、エンジニアの机にインターネットにつながらない業務用コンピュータと、別ネットワークにつながったインターネット用コンピュータを別々に置く構成を使っていた。私の主作業端末は音も出ない。音声機能すらない。ほとんどの人は、音の出ないメイン業務マシンでも十分働けると思う。私はテクノロジー嫌いではないし、NUCやRaspberry PiやノートPCもたくさん使うが、メイン業務端末でYouTubeを見たりゲームをしたりする必要はまったくない。会議用は別のノートPC、動画視聴も別のノートPCでよい。カフェにも会社にも持ち歩くそのノートPCでゲームまでやる文化がVercelを倒したのであり、これからも多くの会社を倒すと思う
  • それは複数ある原因の一つにすぎないと思う。もちろん悪い選択だが、他のシステムのセキュリティが「業務用ノートPCは絶対に侵害されない」ことだけに依存すべきではない。それが唯一の防衛線なら、結局問題は起きる

• この記事には不正確な部分があると思う。Vercelのenv varはすべてat rest暗号化されていて、sensitive チェックは設定後に値を再取得できなくする意味なので、今回のような状況ではむしろ役に立ったはずだ。そして出典リンクが一つもないまま、こういう記事を読むのもかなり気になった

  • ここのUIの判断は少し興味深い。環境変数一覧がまるでパスワードのように隠されていて表示ボタンもあるので、advisoryを読む前はsensitiveフラグがどれほど重要かがすぐには目に入りにくかった。こちらでも機密表示されていない秘密値があって、今そのローテーション作業で忙しい
  • ただ、一部の顧客env varが実際に露出したのは事実なのだから、では暗号化されていなかったのではないかという気もした

• この1年で私が自分で承認したAIツールをざっと12個見直してみたが、そのうち9個がGoogle Workspaceで全メールの読み取りとDrive全体へのアクセス権を要求していた。しかも私はオンボーディング中で忙しく、権限もろくに読まず全部承認していた。技術に詳しい人たちも本当にこんなふうにやっているのか気になる。私は誰かにメールとGoogle Driveへのアクセスを与えるのは夜も眠れないほど嫌で、権限もできるだけ細かく分けて与え、使っていないアプリはすぐ取り消したいと思っている。あのレベルなら、メール内のNDA情報や機密はすでに流出したものと考えるのが妥当に感じる

  • 職場で、別チームが買ったAI議事録ツールとGoogle Workspaceを連携するのを手伝ってほしいと頼まれた。ベンダーはメールやDriveファイルの読み書きのためにDomain-wide Delegationを設定しろと言ってきて、それをやると組織全体のユーザーが自動的にopt-inされ、拒否もできなかった。そこで私はベンダーに連絡し、各ユーザーが自分でログインしてOAuth権限画面を承認する「より推奨されない」方式も使えるようにしてくれと頼んだ。ところがその間ずっと、ベンダーも自組織もこれを時間の無駄のように扱っていた。広い権限を自発的に与えたい人がいるならそれは各自の選択だが、コアツールでもないのに全社員に拒否権なしで有効化するのは非倫理的だと感じる。セキュリティ上の懸念は言うまでもない。さらに怖いのは、AIと少しでも関係すると人々が思考停止することだ。5年前ならこんな要求はしなかったはずの賢い人たちが、今ではみんなやっているから大丈夫だと考えている
  • 私は個人的にはそうしない。数日前に見た「安全であろうとする人は、結局Stallman風の修道院コンピューティングに収束する」という言葉が頭に残っている。https://news.ycombinator.com/item?id=47796469#47797330 本当に笑えるが、同時に事実でもある気がする。自分の個人データを好き放題扱うエージェント自動化の利便性は享受したいが、私は我慢している。逃している面白い機能が惜しくはあるが、権限は今だけの問題ではない。一度与えると、事実上ずっと持たれ続ける
  • そういうことは非常によくあると確信している。権限疲れやポップアップ疲れは現実だ。今のアプリやWebサイトは、ユーザーが本来やりたいことにたどり着く前に何十ものポップアップを投げつけてくる。そのかなりの部分はマーケティング、一部は愚かな法務要件で、重要なのはその一部だけだ。結局人は「はいはい、わかったから進める」を押すようになり、セキュリティは窓の外へ飛んでいく。私が常に覚えているのは、コンピュータセキュリティというものは実質的に幻想に近く、ネットワーク接続されたコンピュータ上のデータは準公開情報のように扱うべきだということだ。現代インフラの大半がインターネット接続されたコンピュータの上に成り立っているという事実は、あまり深く考えない方が精神衛生上よい
  • 現実はこんなものだと思う。上司は「今日の午後の大事な会議までに、とりあえず雑でも作って」と言い、エンジニアは設定中に全部同意して後で整理すればいいと考える。そして6か月後、その急ごしらえのデモがそのまま本番になる
  • 私はそれを「忙しくて読まずに承認した」とは見ない。実際にはオンボーディングが権限を要求し、拒否する機会自体がなかったからだと思う。拒否すればアプリが使えないのだから、事実上の強制だ。この概念自体が間違っていると感じる。ユーザーが「拒否」を押しても、その事実がアプリに伝わるべきではなく、単に要求データが空だったように見えるべきだ。そうすればアプリは望む権限を問い合わせられ、ユーザーは権限を与えないままアプリを使い続けられる。それが本当の解決策だと思う

• 推測するに、これは単なるGoogle Workspaceアプリではなく、おそらくGmailアクセス権の問題だった可能性が高い。攻撃者は被害者の受信トレイに広範にアクセスし、その後magic linkやワンタイムコードで一部の内部システムにログインしたのだと思う。そうだとすると、なぜ2FAがなかったのか、そしてそもそもなぜそれほど広範なアクセスを許していたのかが気になる。そうでないなら、別の可能性はGoogle Workspace内にAPI資格情報を保存していた場合くらいだが、あり得なくはないにせよかなり奇妙な構成に感じる

• たかがRobloxチートだったとは呆れる。うちの息子もRobloxチートが原因でアカウントを乗っ取られたことがあり、深刻だと感じたが、その時はGamepassクッキーを抜かれてMinecraftのライセンスを4本買われ、Microsoftがすぐ返金してくれた程度だった

  • これは実質、Vercelが10代のスクリプトキディにやられたと言っているように聞こえる。ただ前向きに考えれば、逮捕のニュースも近いうちに出るかもしれないと期待している
  • そもそも、なぜゲームチートが実行できたのかが気になる。こういう会社はデバイス統制がないのか、あっても気にしていないのかと思ってしまう。社員がLastPass Plex事件のようなミスを繰り返した感じだ

• この記事ではブラウザ検証失敗エラーが出ている

  • 皮肉なことに、そのサイトがVercelホスティングだという点が笑える

• 「そのチェックボックスの存在を知っていた開発者が何人いたのか、そしてDB資格情報やAPIキーがデフォルトで暗号化されていると何人が思い込んでいたのか」という一文を見て、私は逆に考えた。秘密値の入力欄に伏せ字表示がなければ、保存ボタンなんて押さない。プログラム経由で投入した可能性はあるが、その場合でも最低限secretフラグのようなものは明示すべきだったと思う。Vercelのような会社でこんな問題が起きたこと自体、少し奇妙に感じる

  • こういう入力欄には、誰かが機密情報を入れることを前提にすべきだ。だからデフォルト暗号化が唯一合理的な選択だと思う
  • 橋の技術者に「橋脚補強を忘れていませんか」とは聞かないように、セキュリティ知識が乏しかった頃ですら、こういうのは基本中の基本だと思っていた。機密情報を平文で保存してその結果を受けた人たちが怒るのは理解できるが、結局は自分たちの慣行の代償を払った面もある。だからといって被害者非難だけをしたいわけではなく、Vercelもこのばかげた状況への責任を明確に負うべきだと思う。それでも結局、FAFOという感覚は残る

• 本当に皮肉なことに、今ではセキュリティチェックをさらに強化したようだ。旧版Firefoxで元記事を読もうとしたら、Failed to verify your browser と Code 11, Vercel Security Checkpoint という表示しか出なかった。正直かなりいら立った