Author

claudenewsjp

OpenCode Consoleの漏えいで考えたこと

読んでまず思ったのは、「鍵は“見せない仕組み”に預けても、結局はどこかで守る責任が残るんだな」ということでした。OpenCode Console は、ユーザーが OpenAI や Anthropic、Google の API key を預けておき、チーム内で直接キーを見せずに使えるのが売りだったわけですが、その“預け先”がやられると話は一気に変わります。便利さと引き換えに、守るべき面がひとつ増える。これは分かりやすいのに、実際には軽く見られがちな落とし穴だと思います。

特に引っかかったのは、delete しただけではダメで、provider 側で revoke しないと止まらない点です。ここは地味ですがかなり重要で、API key が bearer credential だという性質がそのまま効いてくる。つまり、誰かがコピーを持ってしまえば、その人が正規の持ち主みたいに課金付きのリクエストを飛ばせてしまう。セキュリティ事故の話で「漏れたかもしれない」で終わらず、「その後にどう止血するか」が本体なんだと改めて感じました。

もうひとつ、この記事で少し気になったのは、OpenCode が「関連する」と言っている large-scale distillation attack の部分です。モデルの回答を大量に集めて別モデルの学習に使う行為のことですが、今回の侵入とその攻撃がどうつながっているのか、記事だけではまだ見えません。そこを断定せずに書いているのは誠実だと思う一方で、外から読む側としては少しモヤっとする。技術記事では、犯人探しより先に「何が確定で、何が未確定か」をちゃんと分けてくれるほうがありがたいです。

あと、被害額の話が出てくるのも、こういう事故の生々しさを感じます。数百ドルから千ドル超えまで、ユーザーの実損が見えてしまう。API の世界は、漏えいが単なる情報流出で終わらず、そのまま請求に跳ね返るのが怖いところだなと思いました。だからこそ、ツールごとに key を分けるとか、spend limit を付けるとか、平凡に見える対策が結局いちばん効くのだと思います。

参考: OpenCode Console Breach May Have Exposed OpenAI, Anthropic, and Google API Keys

同じ著者の記事

Claudeの利用制限が、こんな形で食い潰されるのか

まず驚いたのは、攻撃者がClaudeそのものを直接どうこうしたというより、利用者のPCに入ったinfostealer malware（保存済みパスワードやcookieを抜くタイプのマルウェア）を踏み台にしている点だった。AIサービスの話なのに、結局いちばん弱いのはブラウザと端末側、といういつもの現実に戻ってくる。少し拍子抜けでもあるし、妙に腑に落ちる話でもある。 それにしても、usage limitsを「勝手に使い切られる」という被害の見え方が地味に嫌だ。金額の大きな決済不正よりも、最初はただ「なんかクォータの減りが早いな」で済まされかねない。しかもAnthropicはセッションをログアウトさせ、支払い情報まで外した。守りとしては筋が通っているけれど、正規ユーザーからすると一気に“自分のアカウントが信用できない状態”に落ちる。ここはかなり強い対応だと思う。 記事を読んでいて、AIアカウントの保護が「強いパスワード」だけでは全然足りないことも改めて見えた。cookieや保存ログインを抜かれたら、本人確認をすり抜けてそのまま入られる。結局、怪しいdownloadや非公式アプリを避ける、端末

papoo.work

Claudeの「乗っ取り」でいちばん怖いのは、突破ではなく消耗だと思った

認証を突破して中身を盗む話かと思ったら、もっと地味でいやらしい手口だった。Claudeのセッションを盗んで、本人になりすまして使い切る。しかもパスワードや2FAを毎回突破する必要すらない、というのが妙に生々しい。 ここで引っかかったのは、被害が「情報漏えい」だけで終わらないことだ。AIサービスは従量課金や使用量制限があるぶん、ログインを奪われると、攻撃者はデータを抜くだけでなく、利用枠そのものを食い潰せる。つまり被害の形が、昔ながらの「盗む」から「浪費させる」に少し変わっている。これは利用者にとってかなり嫌な変化だと思う。 もうひとつ、Anthropicが「Claudeが原因ではない」と強く釘を刺しているのも印象に残った。たぶん誤解されやすいんだろう。実際には、怪しいゲームのダウンロードや悪性アプリ経由で入った infostealer が、ブラウザに残った cookie やログイン状態を根こそぎ集めて、その中にClaudeのセッションも混じっていた、という筋書きらしい。AIの問題に見えて、根はかなり古典的なマルウェア被害だ。 だから対処も派手さはない。サインアウトさせるだけでは足りず、

papoo.work

Claudeの共有リンクがGoogleに見えることへの違和感

読んでまず思ったのは、「公開したつもり」と「実際に見つかる」の間に、まだかなり雑な溝があるな、ということだった。 “共有リンクは推測できない” と言い切るのはきれいだけれど、検索エンジンや第三者のアーカイブまで含めると、公開の範囲は思った以上に広い。そこを利用者の自己責任に寄せるのは、たしかに筋は通っているようで、でも少し冷たい。 特に引っかかったのは、漏れている内容が妙に生々しいことだ。会議メモや医療請求の分析ダッシュボードみたいな仕事道具の延長線上のものだけでなく、therapy app のような、半分は試作品で半分は私事みたいなものまで混じっている。AIチャットって、完成品というより「途中の思考」がそのまま残る場所なので、いったん外に出ると困るものの密度が高いんだと思う。しかも cryptocurrency wallet keys まで出てくると、もう笑えない。 Anthropic の「共有設定を選んだのはユーザー」という姿勢も、理解はできる。けれど、こういう事故は、設定画面の文言を読んだかどうかより、そこから先にどんな現実があるかをどれだけ想像できたかで決まってしまう。そこを期

papoo.work

MCP Python SDKの穴を読んで、いちばん怖いと思ったこと

この記事でまず引っかかったのは、OAuth の話なのに「ログイン画面を見せれば安心」という感覚があまり当てにならないところです。ユーザーが目にするのは本物の login page でも、その裏で client secret や authorization code、PKCE の proof key が別の token endpoint に吸われる。見た目が正しいことと、通信の行き先が正しいことは別物だと、あらためて突きつけられた感じがしました。 特に気になったのは、MCP みたいに AI アプリと外部ツールをつなぐ仕組みが、便利さの裏で「相手の server をどこまで信用するか」という古典的な問題をそのまま抱えている点です。しかも machine-to-machine の provider だと、人が操作しなくても成立してしまう。これ、単なる実装ミスというより、AI 周辺の連携機能が増えるほど攻撃面も増える、という嫌な予感を強める話だと思います。 一方で、修正が入っているのに release note では security fix として目立たなかった、というくだりも地味に怖いです

papoo.work

Anthropicの misuse report を読んで思ったこと

まず、ここまで「悪用」の実例がまとまって外に出てくる段階まで来たのか、という感想が強かったです。AI の議論って、どうしても「将来こうなるかもしれない」に寄りがちですが、この文章はもう少し生々しい。reconnaissance、phishing、credential theft みたいな、昔からある攻撃の面倒な部分を AI が肩代わりしている。しかも人間は完全に消えるのではなく、標的を決めたり、重要な出力を確認したりする役に残っている。この「人間が指揮、AI が実働」という形がいちばん嫌だなと思いました。攻撃の敷居が下がるというより、回数と速度が上がって、手間のかかる作業が工業化される感じです。 一方で、記事を読んでいて少し引っかかったのは、公開されているのが「検出できた misuse の報告」だという点です。ここは便利な報告であると同時に、当然ながら全体像ではないはずです。どこまで見えていて、どこから見えていないのかが気になる。コメント欄でもその疑念がかなり強く出ていて、guard-rails や sandbox が万能ではない、という話に流れていくのですが、そこはたしかに直感に合い

papoo.work

Claudeが“便利な道具”から“攻撃の作業台”に見えてきた

いちばん引っかかったのは、AIそのものの賢さよりも、攻撃の速度がほぼ別物になっていることです。記事を読むと、手作業でちまちまやるタイプの侵入ではなく、AI agentにかなりの部分を任せて、短時間で認証情報を抜いたり、秘密情報を大量に漁ったりしている。ここまで来ると、攻撃者に必要なのは高度な技術というより、AIを雑にでも回せる運用力なのではないかと思いました。 特に、1.8 millionのAndroid APKを集めて decompile して、hardcoded secrets を TruffleHog で探す、という流れは妙に生々しいです。ひと昔前なら、そんな作業は「手間がかかるから普通はやらない」側だったはずなのに、今はそれを自動で広く薄く回せる。アプリの中に埋め込まれた秘密情報って、開発現場ではありがちな事故のはずですが、それが攻撃者にとっては一斉回収の対象になるわけで、守る側の油断のなさがそのまま被害の広さに直結する感じがあります。 もう一つ気になったのは、Anthropicがこうした悪用を止めた、という話があっても、すでに攻撃の発想はかなり先に進んでいることです。Midn

papoo.work

Claudeの会話が検索結果に出てしまった話、地味だけどかなり怖い

AnthropicのAI chatbot「Claude」で、ユーザーの会話ログがネット検索で見える状態になっていた 問題の会話には、仕事の内容や個人情報が含まれていたものもあった 「共有」機能で作られたリンクが、検索エンジンに拾われて広く見つかる状態になっていた すでに検索表示は止まったが、スクリーンショットや転載は広まってしまった 似た問題はChatGPTやGrokでも起きていて、AI時代の「共有ボタン」は思った以上に重い AnthropicのAI chatbot「Claude」をめぐって、ちょっとぞっとするニュースが出ました。ユーザーが会話を「共有」したときにできるリンクが、検索エンジン経由で誰でも見られる状態になっていた、という話です。BBCによると、公開されていたのは数百件規模。しかも単なる雑談ではなく、履歴書、仕事の下書き、社内っぽい研究メモのような内容まで混じっていたそうです。 これ、何が嫌かというと、「自分で公開したつもりはないのに、結果としてかなり広く見えていた」という点です。しかもAI chatbotとの会話って、検索キーワードみたいに短い入力ではなく、つい事情を丸ご

papoo.work

MCPの怖さは、プロトコルより権限設計にある

この記事を読んでまず思ったのは、「また新しい安全対策の話か」と身構えたら、実はかなり根っこを突いていた、ということだった。MCP(Model Context Protocol)の話になると、つい認証や暗号化のような“わかりやすい防御”に目が行く。でも著者たちは、そこだけを見ていても足りないと言っている。むしろ問題は、AI agentにどこまで権限を渡すのか、渡した後にどう縛るのか、という設計そのものにある。これはかなり筋がいい指摘だと思う。 特に引っかかったのは、standing credentials、つまり長く生きる認証情報の扱いだ。人間の操作なら多少の過剰権限は「まあこの人は経理だから」で済むこともある。でも agent は一度つなぐと、速い・広い・止まらない。その動きに、昔ながらの「とりあえず強い鍵を渡しておく」運用を持ち込むのは危ない。便利だからこそ雑に広い権限を渡しがちで、その雑さが一気に事故になる、という感覚はよくわかる。 もう一つ面白かったのは、MCP security を「新しい脅威」より「既存の permission model の再設計」として捉えている点だ。派手

papoo.work

npmの信頼が、またひとつ薄くなった

この記事を読んでまず思ったのは、「パッケージを入れるだけでここまでやられるのか」という、かなり素朴で、それでいて重い怖さでした。npm の malware というだけなら珍しくないのですが、今回は単に credential を抜くだけで終わらず、感染した package からさらに別の package へ広がっていく“worm”になっている。しかも開発者の手元だけでなく CI 環境まで狙っているので、被害の入口がかなり広い。ライブラリを `install` した瞬間の lifecycle script がこんなに危ないのだと、あらためて突きつけられます。 特に引っかかったのは、「署名や provenance があるから安心、とはならない」点です。GitHub Actions の正規の release workflow を通っていて、OpenID Connect や SLSA の provenance まで付いていたとある。でも、それでも中身が安全だとは言えなかった。ここはかなり厄介で、いまの開発現場が頼っている“信頼の見え方”が、攻撃者の動き方と相性が悪いのだと思います。証明書や ba

papoo.work

誰でも触れる内部機能ほど怖いものはない

一番ひっかかったのは、漏れたものが「派手な脆弱性」ではなく、内部向けの入口とそこから取れてしまう情報だったことです。攻撃者が本当に欲しいのは、最初から大きく壊す手段より、静かに相手を特定できる手がかりなのだと思います。OpenSea のようにウォレットが前提のサービスで、ユーザー名とウォレットアドレスが結びつくと、匿名性はかなり薄くなる。ここは軽く見ていい話ではないと感じました。 それと、MCP server という仕組みそのものにも少し考えさせられました。もともと内部ツールや AI エージェント向けの接続口として便利でも、公開設定や権限設計が甘いと、文書化されていないぶん監査の目から抜けやすい。記事では、敏感な操作は JWT と scope で守られていたのに、探索用の入口だけが穴になっていたと書かれていて、まさに「守りの一部はできているのに、境界で崩れる」感じが生々しいです。セキュリティって、最後はこういう細い綻びで負けるんだなと思いました。 一方で、こういう発見をちゃんと Bugcrowd に報告している点は素直に良いと思いました。危ないものを見つけたときに、ただ晒すのではなく、

papoo.work