00:00
こんばんは、Replay.fm第111回です。
こんばんは。
いやー、お互いあくびをしながらの収録。
いやー。
別に遅くないんだけどね。
まあねー、今日ちょっと疲れましたね。
ふんふんふんふん。お疲れっす。
全然仕事とかじゃないとこで疲れましたね、という話だった。
お休みして、お休みしたはずが疲れて帰ってきたって。
まあ、それもまだ休みだよね。
うーん、まあ言うてでも別に自分ではそんなに大したことしてないんだけど。
作業自体は人にやってもらってたから。
なるほどね。
なんか謎々みたいでいいな、これ。
何をしたか明かさずに行こう。
どうやら人に作業してもらったらしいって。
休みを取ったらしいって。
さて、私は何をしたのでしょうか?何をしていたのでしょうか?
やり足のことをネトスとすれば、結構答えはだいぶ絞られそうな感じがする。
まあ、そんな感じがするね。
いやー、まあお疲れ様ですわ。
いやー、今日はロックホールド記事があるが、もうなんか報道番組みたいな内容になりそうだね。
前回の収録でもちょっと話してた。
いやー、なんか別にこれ読みてえっていうのはなかったな、正直個人的には。
あのー、なんかさ、ただただ摂取する系のインプットが多いというかさ、なんかその、なんだろう。
あの、ウィラインゼリー的なニュースがわかるかな、この伝え方。
なんか普通に、あ、うまそうみたいな感じで食べるっていうよりかは、あーはいはい、あーオッケーオッケーって感じでチューチューチューチューって。
あれー、あれはGitHubのCLIのトークンが有効期限付きになるようなパブリックプレビューの記事は入ってないんだっけ。
そうだね、want to share、入ってる入ってる。
これもじゃあ入れときますか。
あー、入れとくか。
さらっと。
見落としてた。
うん、それぐらいかな。
えー、じゃあ、はい、やりましょう。
お便りお待ちしております。
Google Home X見て、いつでもどうぞ。
じゃあ1個目から行きますか。
もうね、スルッと、さらっと、さらっと行かないとね。
私もか、えー、ジャックさんのブログで、えーとこれなんだっけ、ムードラだっけ。
eMoodlerらしいですよ。
eMoodler。
会社で読み方聞かれて、マージャラとかじゃないですかねってすげえ適当に言ったんです。
インドっぽい響き。
もうなんか全然、なんかあれやな、全然かぶってない。
eMoodlerのインシデントはウェブにとって何を意味するのかっていう記事ですね。
まあそもそもeMoodlerのインシデントの話を、とは何とかっていうのを、多分今日この他に紹介しないんで、めちゃくちゃさらっと触れると、
03:11
TLSの証明書を発行する、eMoodlerっていうインドの会社がその証明書を発行してたんですけど、
その中間証明書が、漏洩とか侵害されて漏洩とかをしたわけじゃないんだけど、
キーリセレモニーの時にプログラムにバグがあって、めちゃくちゃ暗号強度の弱い証明書を作って、ずっとそれを運用しちゃってたっていうのが発覚して、
どれぐらい弱いかで言うと、何トリだっけな、もうでも全然スペックの低いPCでも層あたりで余裕で秘密書き導出できるぐらいの強度しかないものが
中間CAの証明書として使われてましたよっていうのが、ことの大体の全貌って感じですね。
実際の鍵は4つですね。
このJackさんのブログは、この今言った事件の部分に合わせて、そもそもCAってなんだっけとか証明書ってなんだっけとか、
この証明書の秘密書きがバレてしまう、ほぼ漏洩みたいなことになってしまって、どういうことっていうのを書いてくれてる記事、
かつ、この事実自体に対するJackさんの試験みたいなものも触れていて、
このTLS証明書を信頼できるきちんとした会社が発行して、それをトラストチェーンみたいな言い方をしますけど、
入れ子で入れ子で証明していって、
WebのHTTPSの通信相手が本当にサーバーを提供している事業者本人であるってことを証明するっていう仕組みなのに、
キーセレモニーの簡単なバグでこのようなことが起きてしまったこととか、
あとそれを受けて、結論そのイムドラは事業撤退をすることになってるんですけど、
その事業撤退、幕引きの仕方にも結構不審感があるなみたいな話とか、
じゃあ同じような事業展開している、広く主要ブラウザで信頼されるような証明書を提供している会社って
世界中にあるけど百何十社が全社が全社、例えばクラウドフレアとか、
ちょっとパッといい会社が見つかるんですけど、
ここやられたらしょうがないよねってみんなが言うような会社と同等レベルのレベルで証明書の運用ができているかとか、
06:04
同じようなことが起きないかとか、そういうものを考えたときに結構Webの信頼、
何かみたいなことを書いているような記事って感じですね。
いつも通りとっても読みやすく、なんか証明書よくわからんみたいな人も多分読んだら、
あーなるほど、これっていうか、何がやばかったのかっていうのが結構理解しやすいんじゃないかなと思うんで、
その面でもお勧めではありつつ、どう思いました?
せやなーぐらいの。
まぁせやなーではありつつ、難しいな、これをトラストアンカーである以上、
信頼に至るだけのあれが必要だよねみたいなのは、わからんでもないけど、
まぁね、そうは言ってもどっちかっていうと、
CRLとかOCSPみたいな仕組みがちゃんと機能しないとか、
そういう実装の方をもっと言うべきなんじゃないかなとは思ったけどな、
これ一連のいろんなものを見てて思ったのは、
なるほどね。
だってどこまでいってもそこのリスクがゼロにはできないから、
そうだね。
ってなった時にどっちかっていうと執行の方をじゃあ確実にやるべきだよねっていう方が、
個人的には生産的なんじゃないかなと思ってて。
確かにね、なんかそれこそ仕事で実際に対応したりとか、
まぁ個々人でも対応してる人はいると思うんですけど、
イムドライズ何たらみたいな多分みんなが見てるページが、
あれは誰が有志の開発者なのかな、
イムドラリンク貼っとこ、
imdrawehaveproblem.comっていう、
wehaveproblem.comが何なんだこれ。
よくわかんないね。
よくわからず使ってお世話になっているけど、
何なのかはよくわかってないです。
なんかすごい汎用的な名前の、
これインシデント起きるたびに使うのかな、
まぁいいや、
これに書いてある対応しなきゃいけない量を見ると結構、
今々は同じことがじゃあもう一回起きたときに結構、
エンドユーザーの負荷は高いし、
うちの端末、うちのソフトウェア大丈夫ですっていうまでのリードタイムがどうしても伸びちゃうっていう部分がある気がするから、
おっしゃることは確かに。
結構対照的だなって対応しながら思ったのは、
初めから始めで組み込んでいる言語とかソフトウェアがあって、
09:01
それはもうパッチが降りてくるのを待つ以外なすべがない。
パッチが降りてくるまでCtuneは使わないとか、
あとmacOSの組み込みのやつとかも結構、
組み込み変わるが無理だみたいな話で、
あれも今日ちょうどOSアップデート、
macOS狂ってきて見たんだけど、
その対応まだ混ざってなくて、
まだ自前でパッチが降り続けるしかないっていう状況なんですけど、
そういうのがある一方で、
ChromeとかFirefoxは爆速でバージョンアップしなくても、
署名書ストアを動的に取るような仕組みになってるから、
それこそ執行が速やかにされて、
多分何も知らない人でも使ってて安全みたいな状態になってて、
理想的には全部がそういう風な形になってくれた方が、
嬉しいよなっていうのは、
対応しながらしみじみ思ってはいるって感じだね。
気がなさすぎて。
そう、なんかさ、そうなんだよね。
でも一方で、
これちゃんとしてないソフトウェアは使うの先をってなるかというと、
結構こういう風に事件が起きないと、
顕在化しないみたいな話もあるから、
ソフトウェア作る側がここまで想定して、
作ってくれるかでいうと、
あんまり、これをきっかけにやってくれるとかやってくれると思うけど、
忘れ去られて、
別に特に想定せずにまた同じこと起きて、
で、また長いパッチ当てなきゃいけないリストができるみたいな、
繰り返しそうだなって気はしてて。
ちょっと古時代があるなって。
そうだね。
ある種繰り返してる歴史だと思うからさ。
そうね。
にも関わらずそうなってるっていうのは、
もうそういうことなのかなとは思うし。
話めちゃくちゃでかくしちゃうような発言かもしれんけど、
セキュリティのこういう性質にいつも切なさを感じるわっていうか、
こういう性質っていうのは、
こういうことが起きたらこういうことで困るよねっていうのがあって、
それ自体の同意は得られるんだけど、
じゃあそれの優先度が上がるかとか、
あとは世の中でいろんなものがつかれている中で、
広くそれが適用されるかっていうのとはなんか全然別の話というか。
ほとんどのケースでは、
別に証明書が機体化した時のためにソフトウェアを作ってるわけではないから、
そのソフトウェアの価値を高めるとか便利にするとか、
売っていくための取り組みに投資がなされていくし、
それ自体は別に自然なことだと思うんだけど、
こういう時に割と割り送るのは使ってる側だよなっていう気もしちゃうし。
12:02
うまいことこの構造変わらんかなーって気持ちはたまーになったりしつつ。
逆に時間はかかるけど解決してるともいえるなと思ってて、
即座に解決がしないだけであって。
例えばだけど、もうHTTPS使うのがデフォルトだよねっていう時代になったじゃん。
実際になって。
確かにね。
時間はかかってるけど、別に進んではいると思うし、
良くなっていってると思うから、
別にそんなに悲観するほどでもないかなとは思うけどね、
この辺の領域に関しては。
なるほどね。
言われてみよう、確かに。
この辺も良くなっていくといいなー。
大枠の仕組み自体を変えようっていう話にまでは多分ならないと思うけど、
まあもうトラストハンカー自体は必要なものだと思うし、
そうだね。
そこ正直投稿できるものではないかなとは思いますね。
皆さんお疲れ様ですって感じですね。
各意味いろいろ対応している最中だと思うんで。
そんな感じかな。
ういっす。
あざっす。
じゃあ次お願いするか。
GitHub CLIのオプトイン・エクスパイリング・オートリフレッシング・オーストークンズっていう、
これはリリース、チェンジログかGitHubの。
ごめんちょっと記事読んでなくてさ、
ざっくりしか知らないんだけど、
とりあえず何が言いたいかというとGitHubのCLIのオースのトークンが、
有効期限付きで自動更新される、
オプトインが設定ができるようになってるっていう話ですね。
で、パブリックプレビューになってて、
GHオースログインのときにオプション付けたり、
コンフィグだとかで有効化するみたいなことができるようになってる感じなのかな、多分。
GHコンフィグってやると全サインインに適用できてなってるから、
これは何だ何かだからアカウント全体で有効になるみたいな話なのかな、きっと。
オプション付けなくても大丈夫になるんじゃないかな。
再ログインとかするときにオプション付け忘れちゃっても、
そっちのほうで有効になってるから。
これもう誰でも使えるのかな。
最終版落とせば使えるよ。
私は一応全マシンで再ログインしておいた。
再ログインするまで生きてるのかな、これ。
あんまちゃんと検証してないな。
そうそう、全然関係ないけど、
GHオースログインするときのワンタイムコードが自動でクリップボードにコピーされるようになったのが、
神アプデだなって思いました。
15:01
そうなんですか。知らなかった。
それ気づかずに手動でコピペしてた。
前は手動でコピペだったんですよ。
いいね。
これ有効期限ってどっかで確認できるのかな。
GHオースステータスで。
GHオースステータスに出るようになったわ。
ログインし直すと出るね。
なるほどね。
いいですね、これ。
期限伸ばせないのかな。
でもアクセストークンの更新は自動でやってくれるから、
期限伸ばすモチベーションないんじゃないかな。
そうか。
リフレッシュトークンが特にあるね。
リフレッシュトークンが6ヶ月。
ちょうど別の鈴木俊介さんの記事で言及されてるんだけど、
リンクを貼りましたけど、
GHトークンっていう、
GitHubを認証のおもととしてGHコマンドみたいな
操作ができるやつを作ってる方がいて、
これアクセストークン単名になったけど、
まだGHトークンのほうが優位性あるよっていう、
ポジショントークっちゃポジショントークなんだが、
書いてあることはなるほどって感じの記事で、
リフレッシュトークンは残るは残るし、
キーチェインストアにはあるんだけど、
キーチェインストアのセキュリティコマンドって
一度信頼したアプリからは再認証なしで叩けちゃってる気がするから、
これがあるからローカルに入られても
安全とはまだ言えないって感じ。
まだというか言える、言い切るのって
めちゃくちゃ難しいと思うんですけど。
ただアクセストークンが、
例えばAIエージェントが開発してアクセストークンなんかで
API叩くために勝手にGHコマンド系で取ってきて
通信しちゃったとかコミットしちゃったって時に
そのリスクが緩和されるっていう意味では
全然あって嬉しいアップデートかなって感じですよね。
助かりますね。
コツコツやってほしいですね。
これがデフォルトになってくるのもありがたいね。
既存の分もな、組織レベルで本当だから
でも待ってたらデフォルトの挙動になるから
再ログインしないとさ、みたいなのがダリいなと思って。
GitHub CLIのトークンだけを狙い撃ちして
一旦全部無効化にしたいんだよな。
そのデフォルトになるタイミングで。
確かにその機能は今ないね。
確かにアナウンスで頑張るしかないかも。
もしくはもう一回破壊をするしかないかな。
巻き込みで全部落としに行くっていうのを
多分やらないといけないよね、もしやるんだったらね。
でもその上でも結局GHOSTログインで
18:02
有効期限付きのものを使ってくれてるかどうかっていうのは
担保できないから。
オプターアウトできるだろうかね。
そうじゃなくて、今は少なくともさ。
なんか別にデフォルトになってないじゃん。
オプターアウトできるも確かにそうなんだけど。
本当は組織レベルとかで強制できるといいんだけど。
別にいいんだよね。GitHubのトークンだけは生きててよくて
そのSSO部分だけ落としてくれればいいから。
GitHubエンタープライズクラウドミンとしては。
チームとかの人たちは知らないけど。
めっちゃアップデート起きそうだけどね、その辺もごまごま。
もしくはコンフィグだからJAMFとか
MDM入ってるようなパターンだったらコンフィグ
どっかローファイルあると思うから
巻いちゃうとかはありかもしれないね。
これどこに入るのかな。
ズームイン完了してないですね。
どこに入るんだろうな。
ドットコンフィグとかに入りそうな気がするけど。
今ドットコンフィグ入ってるわ。
個人のコンフィグもあると思うから
どう競争させるかとか考えることはあると思うけど。
でも一行ぺろっと追加する。
でもこのコンフィグを見ればいいっていうのが
分かってればなんとかなりそうだけどね。
この設定ファイル全然活用できてないな。
あんま触る必要ない気はするな。
Aliasとか便利そうだよね。
確かにね。
KITのAliasとか
ドットファイルめちゃくちゃ作ったけど
結局6種類ぐらいしか使ってないんだよな。
6種類も使ってんの?
2種類ぐらいしか使ってないな。
6種類使ってるというかよく叩くGitコマンドが
6種類というだけっていう感じ?
もうちょっとあるな。
GitD、GitS、GitPがあるわ。
あとGitSCとGitLがある。
いいね。
俺のGitとAliasバトル。
そんな感じですか。
そんな感じです。
ありがとうございます。
お次も自信ネタということで
PHPファンデーションアナウンスメント記事でしょうか。
Today's PHP Security Release and How We'reStrengthening PHP Securityという記事ですね。
21:01
あまり説明も不要だと思いますが
世間を探してPHP
もはや総理大臣も言及するPHPの
CV2つについての
アナウンスメントって感じですね。
いろんな記事が出てるんでこれだけさらっと紹介ですけど
これ
税食戦会は正直調べてくださいって感じなんですけど
バチャってない人がもしいたら
死ぬ気でバチャって感じなんですけど
ケブリも無事乗ったんでね。
どうやって見つけたかの流れが
興味深いというか
そうなんですねって感じなんですけど
2024年にセキュリティの問題を炙り出すために
外部監査を受けたっていうのがあったらしくて
2年前なんですよ。
この外部監査きっかけで指摘があったっていうのが
一番最初の
ステップだったらしいんだけど
ただこの2024年時点では
メモリ周りがちょっと怪しいぞぐらいの感じで
確かに怪しそうなんだけど
これって本当に成り立つの?みたいな話とか
本当に本気で直そうと思った時に結構
シンプルに大変。いろんな場所に影響が出ちゃうし
そこをバグらないように
慎重にやらなきゃいけないっていう部分で大変だし
あとはそもそも別の脆弱性の対応とかにも
結構追われちゃってる部分があって
何かの記事で見たのは
特定の期間で受け取った脆弱性の報告が100あったうち
結局有効だったのが5から10ぐらいしかなかったみたいな
AIストップが起きる前から
そういう取り味をしてたっていう部分があって
指摘がされたものの結構進みが遅い
中かめちゃくちゃちゃんと動けてはなかったっていうのが
一番最初ありました。
これはチェーンガードだったかな
が指摘して
ウィズカチェーンガードが指摘してて
叩いてるっていうよりかは
リソース足りないと初動動けないよね
みたいな話でそこは課題だよねみたいな話をしてて
それは振り返ればそうだったんだろうなっていう感じですと
これがどう対応は進んでたかで言うと
温度感が変わったターニングポイントがあったのかちょっとわからんけども
直さなきゃまずそうだよねっていうので
修正を進めてる過程で
オープンAIとかWiz あとはCalifっていうマスキディベンダーのところから
同じ部分に対する指摘が相次いで
多分ほぼ同じタイミングで指摘されて
その辺で割とパズルのピースじゃないけど
その辺の断片的な情報を全部組み合わせると
まあ確かになりますよねっていう部分と修正方法も
修正が必要だなっていうのが分かって修正を進めて
24:02
この事前告知とパッチ公開に至りましたという感じですと
なんかちょっとてんやわんやしてた部分にも言及があって
てんやわんやっていうのは
一つは多分これはもしかしたら知らない人多いかもしれないですけど
この2つのCVE自体の情報を公開する予定日より
2日ぐらい早く公開されちゃったらしくて
この辺は何か事務手続きの間違いらしいんですけど
CVEが先に公開されちゃったことで
脆弱性の具体的な内容は書いてないものの
PHPにやばいものがありそうとか
どの辺がありそうかっていう部分を匂わせるような情報は
先に出ちゃったっていうのが一つ
これ受けて慌ててパッチ公開日を
そもそも1日前倒ししたっていうのが一つありましたよって話と
あとはプラスアルファでカリフ社
さっき指摘していただいた会社のうちのカリフ社が
そのPOCを再現してるキャプチャーみたいなのを
間違ってSNSで公開しちゃったらしくて
すぐ消したけど案の定拡散されて
それもヒントになっちゃってまずいまずいってなったのが一つ
あったのとあともう一つはチェーンガード社ですね
チェーンガード社がパッチ出しますって言ってた予定時間より
4時間前ぐらいにチェーンガードが提供する
多分コンテナなんでしょうね
コンテナかなんかでパッチが当たったPHPを先に出しちゃって
そのせいで攻撃者目線だとそれを解析することで
脆弱性の詳細を調整できる状態になるんじゃないかみたいな部分で
そこでちゃんとしたコミュニケーションがなかったみたいな
ところがPHPファンデーションの主張としてはあるし
チェーンガード社的には攻撃観測されてたから
いち早くやることが顧客のためになると思って判断したし
今後もコミュニケーション頑張りますみたいなこと言ってて
ちょっとすれ違いというか
どっちも正義ではあるような難しい判断だね
自分がチェーンガードの中の人の立場だったら
どっちが正しいとも正直言い切れないかなとは思うけど
ちょっと分からん
あまり深く考えずに喋ってるから
まだこの先自分の考えが変わる可能性あるかもしれないけど
パッと聞く限りだと結構難しい判断だね
そうだね
出ちゃったものはしょうがねえっていうのは確かにしょうがないよなと思うし
調整してる時間もなかっただろうしね
あとは一つなるほどというか
思ったのはAmazonの共有分析チームが
このCVが公開される4日前に
これを狙ってそうな攻撃を観測したっていうレポートを出していて
ただ攻撃者がその情報をどうから取ったかっていうのは
27:00
当然分からないっていう部分があるんで
いろいろ見ると結構どっから漏れたか分かんないけど
攻撃者が先に見つけたとは考えづらいと仮定するんだったら
いろんな会社のどっかのプロセスから何かしらに漏れちゃったみたいな可能性はある
CV公開の4日前かだから結構前か
もともと予定しては公開日の6日前ってことだよね
そうだね
ちょっと守る側としては嫌だなっていう感じですね
攻撃の難易度は情報ができる前だから
もしかしたら成立したみたいなものはレポートでは研究されてなかったから見えないんですけど
背景書としてはそんな感じのあれだったみたいですという感じですね
PHP提供してる事業者は
特定の脆弱性でここまで多くのサービスがメンテに入るっていうのは
いやー結構
こんだけのことが起きてたらセキュリティの仕事してなくてもたぶん気づいてると思うから
社会人なんて初めてなんじゃないかなぐらい
そうだね覚えてる限りでもここまでの初めてだなと思うし
一連のいろんなものがあったからこそのこの反応なんだろうなと思うし
同レベルのものって正直今までもあったよなとは思っていて
ちょっと前にリアクトのあれとかもさ
刺さる広さで言うとたぶん似たようなもの近いものが結構あったなと思っていて
まあでもそれで言うと言うてもでもやっぱPHPの方がシェアが圧倒的すぎるのと
あとはそのこれはなんか完全な邪推なんだけど
そのPHPって歴史がめちゃくちゃ長いじゃん
だからその語形はまあさすがにやめてほしいけど
PHPの7使ってるけどちょっと古いバージョンとか8使ってるけどちょっと古いバージョンとか
結構レガシーシステムで身動き取りづらいシステムでとか
またそのなんだろうな一応流れを受けてってのもあると思うけど
そのノーメンテで乗り切るだけのなんか準備が整ってないみたいな
なんかその事業者の数を考えた時に結構ありそうだなっていう
なんか個人的にすごい感じたのがその自分が使ってるサービスにもいくつかメンテ入ってたけど
そのメンテを開けるまでの時間にかなりの差があって
多分サッとパッチ当てて終わってたサービスも朝起きたら全然動いてたサービスもあれば
30:00
おかつか遊んでたやつとか遊んでるやつが遊んでる某
ポケモンスリープ行っちゃうとポケモンスリープすごい楽しく遊んでるんですけど
丸1日か1日半くらいメンテ入ってて
しかもポケモンスリープかなり新しめのサービスなのにとか思うと
まあいろいろ事情はあるんでしょうけど
そういう部分もあるんだろうなっていうのは思いましたね
あーこれもPHPだったんだみたいな
そうだね
あったよね
あったね
ちなみにそのメンテ入ったリストはピオログの記事でめちゃくちゃまとまってて
なんかすごい面白い
なんかすごい縦に長くて
そうですね
あの自治体国の機関金融機関求めてるとこあったみたいだねインフラ
ゲームポケモンスリープ入ってるかな
入ってないな
PHPって研究は確かにメンテでなかったから確定はできないんだけど
そうニコニコそうですねバンダイチャンネル
なんで結構な数がね
これも多分全部じゃないでしょうから
はい
フナッシーの公式サイトもメンテ入ってたみたいです
とりあえずいけないよね
あいこの我ら
そうだね
あいこのサイトもメンテ入ってたし
お祭りでしたね
結構止めてた時間に開きがあったのはなんか多分いろいろかなと思ってて
夜中に対応したところもあれば
とりあえず夜にパチ出るらしいから
もう今日は一旦止めて帰ろうぜって言って
翌日対応したところも結構多かったなと思って
確かに
それでなんでその所要時間がどれくらいだったか正直外からだと読めないかなと思っていて
確かにね
まあなんで
求められるサービスレベルもバラバラだもんね
そうそう別にいいじゃん明日の朝やればで
いい会社とかサービスは全然あると思うから
夜中にバタバタするよりそっちのほうがいいよねみたいなのが全然あったかなと思うんで
一概にそのなんて言ったらいいんだろうこう
なんていうか止まってた時間が長いからダメっていう話でも正直ないかなと思うんで
確かに確かに
本当に皆さんご対応お疲れ様でした
まああとは会社によってはなんかその
任天堂とかはさなんか
ポケモンスリープって言ったもん任天堂
カブポケどっちかわからんけど
カブポケだね
カブポケか
なんか
まあわからんけどそういうところもしかしたらなんか本当にパッチ当たってるのかみたいな気にしてたかもね
中身を見てた
中身っていうのもそうだけどそのなんて言ったらいいんだろうこう
問題をふさげてるのかっていう観点で
刺さんないことを確認する
33:00
そうそう結局そのなんていうか実はこれだとカバーできてませんでしたみたいな話がやっぱ出回ったじゃん
あるね
なんかPHPじゃなくてもなんか
なんか稀によくあるやつ
今回も実際あったじゃん
実はそれだと不完全でみたいなのがある
よくある話だし
そうだね
いやー
なかなか
なんかあの先週か今週分かわせたけどピックしようと思って
もうなんかあまりに短い記事とも言えないからいいやと思ったんだけどその
多分某海外の
まあわかんない知ってる方は知ってる有名な方なのかわかんないけど
なんかそのツイートで
今で過去30年で
作り上げてきたその人間が作り上げてきた不細のセキュリティの脆弱性をひたすら見つけてるフェーズ
だよねみたいなツイートがあって
なんか結構個人的には一定同意する部分があって
それはなんか半分期待もあるんだけど
ここまではもうその人間が作って人間のミスでいろんな脆弱性があったりとか
セキュリティの重要性がもしかしたらその今より相対的に
まあ脅威が全然違うから
前提が違う中で作られたソフトウェアのアラを
ポンポンポンポン見つけて時になんかこういうやばいものが出てきてみたいな
海を出し切る頑張って出し切ってるみたいな
フェーズと捉えるんだったら
まあ過渡期ですねっていう気持ちと
まあその過渡期を超えた先は
AIコーディングがセキュリティだとは断じて言えないが
なんかもうちょっとなんだろうな
まあ幸いフロンティアモデルを開発している部分
会社たちはセキュリティにもかなりモチベーションがあるようなので
そもそもこういうものの物量が減るといいなって気持ちも
ありますけどね
なんでこれを言おうと思ったか忘れちゃった
いやなんか多分先週話した話からじゃない
ずっとこうなのかなみたいな話とかに対して
まあなんか仮にその説が正しいのであれば
なんかずっとはこうじゃないっていう方向だろうし
まあわかんないけど
このバグ自体もなんかすごい
発見は2024年だけど相当前に仕込んだやつっぽいんだよね
言及どっかにあったけど忘れちゃった
まだ対応中の人もいるかもしれないですけどお疲れ様でした
じゃああとは私かな
次はハッカーニュースの記事で
ハッカーズユースは
オートナマス
これごめん
次のピオログの方でいいややっぱり
ほぼ同じ内容をちゃんと
36:00
日本語できれいにまとめたピオログの方を読んじゃうと
こちらAIペネトレーションテスト基盤
カリンの公開パネルから見えた攻撃活動について
まとめてみたっていう記事ですね
お腹いっぱいトークではあると思うんですけど
AIペネトレーションテスト基盤のカリンっていうものがあるらしいと
これを攻撃者が運用してるらしいんですけど
その攻撃者が運用してるやつのたまによくあるやつで
設定がミスっててパブリックインターネットで
誰でも見える状態になってたのでそれを観測してみて
実際に行われた攻撃の内容とか傾向を分析しましたっていうレポートが
どこだっけな
ノーフォージっていう会社から出ていて
それが一時ソースになってるっていうような記事です
不正アクセサーAIだみたいな話は個人的にはうんざりしつつ
いくつか具体的なデータがあって
しさはあるなと思ったんで
軽く紹介できればと思っていて
そうですね
このカリンを運用してそうな攻撃グループが
具体的に3つありますよって話があって
その3つの攻撃グループの
実際の攻撃の痕跡を丸っとまとめて分析したっていう前提なんですけど
一つある
いくつか僕が気になるなと思ったのは
このカリンの使い方がどういうものかっていうと
最初に目標を設定するんですよね
侵入相手に対して例えば
資料を取るところまでやってくださいとか
あと具体的に何か書いてあるんだけど
データを盗んでくださいとか
3つ目のグループとかはデータベースのアクセスの取得を明示するとか
そんな感じで目標を設定して
ターゲットを設定すると自律的に動いて
攻撃をするっていうような仕組みになってるんですけど
その前提において与えた目標に対して
このカリンで動くAIアジェントが成功した成功率みたいなのは
平均10%ぐらいでしたよっていうのが一つですと
これを高いと見るか少ないと見るかですけど
こんな感じですね
平均10%の失敗してるほうの90%のほうは
基本的には目標を達成できなかったか
目標を達成できなかったけど周辺情報を収集して
多分AIアジェントのループが終わってみたいなものになってるらしいと
あとは目標を与えて動かしたときに
動き出してからそれは目標を達成しましたっていうまでの
平均時間みたいなのは23時間で
39:00
長いと5日間かかってるものもあって
長いものは直感的にもそうだよって感じなんだけど
与えてる目標が結構難易度が高かったり
攻撃先の構成が複雑だとか
単純にタスクの難易度に比例して
伸びる傾向はありそうですよっていう話ですね
これに関しては3つのグループじゃなくて
ナンバリングされている3つのグループのうち
1番目のグループで目標としては
認証不要のRCを発見するのと
Webシェルの設置っていうのを目標として与えたときに
このデータが出てる 平均23時間っていうのが出てるって感じですね
観測できた期間としては9月25から10月19なんで
ほぼ1ヶ月の間に1200社に対して攻撃をしかけていて
そのうち100社で侵入に成功してるっていう状態ですと
個人的にこれは1番しんどい話だなと思ったのは
この3つのグループのうち1つのグループのデータを見ると
さっき言った目標与えてひと回しするっていうのを
タスクって表現したときに
その1タスクあたりにかかるトークンのコストっていうのが
平均5ドルぐらいに収まってる
ばらつきはあってそのものによっては
多分さっき言った5日かかるようなやつとかは
100ドルとか超えてるものもあるんだけど
平均7社だと5ドル
で トークン総額だと5000ドルなんだけど
さっき言ったとおり成功率10%なんで
成功1件あたりにならしちゃうと50ドル
50ドル払えば1個成功するっていうふうな
推定ではあるんですけど
割合になってるっていう感じですね
他細かい数字は本件のレポートぜひ
かなり分厚いんで読んでみてくださいって感じなんですけど
これきついよね
これ設置して50ドル払えば
1つのタスクは成功しちゃうって話だから
それは使うよねっていうふうに
シンプルに思ったし
あとは1ヶ月の間に1200社に試行していって
100社侵入できちゃうっていうのは結構
これがなんかなんだろうな
成功するけど与えてる目標がしょぼいとか
与えてる目標がRC見つけるとかになると
コストが上がってペイしなくなるとかだったら
まあまあって思うんだけど
この目標の立て方で100社侵入できて
1個の成功あたり50ドルは
ブラックハッカーにとってのサイバー攻撃の
民主化じゃないけど金さえ払えばみたいな
ところに来てるんだなっていうのを
痛感するデータだなと思います
厳しい時代ですね
42:03
厳しい
レポート読んだら
ちょっとレポート読めてないですけど
レポート読んだら書いてあるかもしれないけど
多分もう1歩踏み込んで気にするとしたら
成功してる100社の事例が
まあそれやられるよねっていう脆弱性だったのか
もっと結構高度なことをやられてるのかによっても
心構えは変わってくるよね
直感的にはまだそんな高度なことを
この値段ではできないんじゃないかなとは
思ってるんだけど
どうなんでしょう
なんかでも結構いけちゃう気はするけどな
その感覚的には
この値段でも結構いけちゃう気はするな
今のモデルなら
確かにね
今雑にジェミニに
実際の脆弱性何使えたか元気あるって聞いてるけど
CVEとかマジェントのCVE複数組み合わせてみたいな話とか
CVEで要は基地の脆弱性で
エクスプロイとかも転がってるものだったら
拾ってきて終わりじゃん
そうだね
ほぼトークの商品ないよね
手数がAIって圧倒的に違うから
そこがシンプルに強そうだよな
攻撃において
これダメならあれ試すが
人間には出せないスピードで
でもそんだけ色々やってくれるんだったら
気づきやすくはあるかな
確かにね
それはそうか
だから基本的にはもう
もう再三言ってるけど
やるべきとは変わんないんだけど
中小企業だからやられないとか
この業界だからやられないっていうのは
ないですよっていう
これ自体はもう多分
何年も前から言われてることが
本当の本当に目の前に
あなたは目の前に来てますよっていう気持ちで
備えなきゃいけないっていうのは
改めてっていう感じですね
でもすごいありがたいことだなと思いながら
ピオログさんにも感謝してですね
興味ある方は読んでみてください
すげー時代だな
すげー気に入ってやってんな俺たち
そうだね
割に合わないんじゃないけど
45:01
最後まで立ってたいっすね本当に
なんかでも
いやーわかんねーな
なんかどっかで割に合わない
もうやーめたっつって
パンの修行とかしてパン屋開いたりする
ような未来とかあったりするのかな
でもパン屋運営もさ
ソフトウェアから離れらんないから結局
形が変わるだけで立ち向かない
でもなんかパン屋を
ごめん別にパン屋をバカにする人は
一切ないんだけど
自分のパン屋を守るぐらいは頑張るよ
なるほどね
ネットバンクさえ守れれば意外と
個人情報とか持たずに
住みそうだもんな
でも従業員の情報とか
そんぐらいで
従業員は雇わない
AIに働かせて
AIに働かせよう
AIにパン焼いてもらおう
AIに車いじってもらって
AIにパン焼いてもらおう
倒れた暁にはパン屋ということで
パン屋か
絶対ガチガチのパンしかできない気がする
パンじゃないのがいい気がするな
早起きの時点でも無理だわ
でもAIにやってもらうから関係ないんじゃない
パン屋舐めすぎ問題だ
AIなんでもできるから
AIなんでもできる
パンも焼けるんですか
って驚いていこう
クソすぎる
最新のGPTモデルではパンが焼けるらしい
やめよう
次行きますよ
もうね 縮めた終わってあと2つさらっと紹介ですけど
データドックの基地で
Introducing Pathrunner and AWS Pre-Bridge Escalation Framework
っていう基地ですね
これ多分前紹介したんですけど
Pathrunnerっていう
AWSの権限昇格の
経路を
自動で
ある程度自動で権限昇格を試みる
っていう挙動までやる
シーライルを作って
前は
ある種のデータベースとして
こういう経路があるよっていうのを
出してくれてたけど
それの施工までやってくれるようなツールが
出たってことだよね
です
Pathfinding.cloudっていう
今言ったドメインでアクセスできる
多分まだAWSしかないんだけど
このロール持ってるって
この条件だとここのリソースに
行けちゃうよとか権限昇格できちゃうよみたいな
まとめてるやつを
自動で検出実行できます
実行ができるの結構すごいな
と思ったんだけどね
なんでライブ的には
Exploit
モジュールとか
いろんなペイルアウトが入ってたりとか
48:01
ある程度カスタマイズできるようなものも
あったりとか結構高機能になってて
触ったりはちょっと
AWS
環境持ってるけどそんな大したものも
持ってないんで試すとはないんですけど
見る感じかなり
使えそうだなっていう
ものになっていて
これOSSで
出してくれたらめちゃくちゃありがたいなっていう
シンプルに
紹介でした
ちょっとヤバいもの置いて
試してみようぜ
自分
AWSわかんないもん
Google Cloudが出たらもうそこ
試したいんだけどまだ
前も多分紹介したときに出てないから
そうなんだよね
欲しいよね
欲しい
なんか
準備して
そうだねGCP今1個しかない
バスが
だからその
箱は用意したいというか多分
いつか
充実していくかもしくはプロテク
投げろってことかもしれないけど
お前が全部洗い出すんやつって
そうそう
なんて思った
でもCSPMとかやってるしデータドック
内部的にはノウハウあるだろうから
時間の問題かなと思うけどね
はい
こういうの使って
防御していきましょう
次は最後
ショピュア
ショピュアのブログで
Building Overexposed Understanding Application Exposure
っていう記事ですね
何かというと
オーバーエクスポーズドっていう
社内ツールを作りましたよって話して
この社内ツールは何をするのかっていうと
Google Cloud
こっちはGoogle Cloudにおいて
JKのイングレスと
Cloud Runの
リソースで
外に
IPアドレスもしくは
ドメインを持つものを
全部洗い出して
それを全部自動でスキャンして
検証するものを
作りましたっていう話ですね
結構アプローチとか
考え方が面白いし
参考になるし
最後のこっちもめっちゃ良いんで
話していくと
いわゆる
ASMではないのかな
推進点に近いんですかね
そういう考え方だと思うんですけど
分からんけど感覚というか互換でいうと
ASMの一種に近い感じがするけどね
そうだよね
なんで課題感としては
置いとくとして
言うても
自分たちのGoogle Cloud管理なんで
一つ問いがあるとしたら
例えばパブリックインターネット
誰でも意図せず
誰でもアクセス的に設定になってないんだっけ
とか書けるべき認証
かかってないんだっけって
Google Cloudの設定を見れば分かりますよね
っていう問いがあるんだけど
実際の現場においては
皆さんも通過するところだと思いますけど
51:01
そういう設定を
設定を監視し続けるとか
また全部テラを向かして
頑張って運用するとかって結構
理論上はそうなんだけど
じゃあ実際に事故が起きる場面
って言うと
手動で誰かが書いちゃったって場面もあるかもしれないし
誰も把握してないものが
実は動いてましたみたいなのも
どうしても現実に起きるよねっていう
考えがあるんで なんで
考え方としては
一歩目としては
自分たちのGoogle Cloudで
露出しているものを漏れなく全部洗い出す
洗い出したものに対して
外から
何のユーザーも
名乗らずパブリックインターネット経由で
スキャンをかけるっていう
風にして
意図しないものがないかっていうのを検出しよう
っていう考え方 哲学になってますと
一歩目の
自分のGoogle Cloud環境の
ドメインIPアドレスをどうやって
漏れなく洗い出すかで言うと
クラウドアセットっていう
どのクラウドにも似たような
機能ありますけど そのGoogle Cloud上にある
すべてのリソースを
見れる機能があるんで
それ使って
全部のクラウドのGKEイングレスを洗い出して
そこからIPアドレスとか
ドメインも取れるんで それでリストアップして
漏れなく取って そこに対して
スキャンをかけるっていうような形になってますと
あと 細かい部分としては
判定に対して
6種類
固定してますよとか
意図した設定になってますよとか
6種類の判定を下すように
したりとか
また
パブリックになってるけど これは意図通りですみたいな
アローリストを作ったりとか
マゾンに対していろいろこういう改善をしてみたいなのが
細々 かなり詳しく
言及されているというような感じですね
僕 これ読んでるときに
OSSEしてくれたんだって
勝手に思いながら読んでたんですけど
そういうわけではないんだが
ただ一方で
これと似たようなスキャナを作るための
プロンプトを最後に公開してくれていて
GISTに貼ってあって
いいですね そうなんですよ
これめちゃくちゃよくて
作りたいって方はこれをパクって
作るといいと思います
ちなみに僕 これ今日仕事しながら裏で
この記事のやつ作ってって
1分回してめちゃくちゃ動くものできたんで
多分もう時代ですよね
手元でざって作って
やってみると
面白いんじゃないかなと思います
逆に作ったものから
これを作るためのプロンプトを出して
やれるわけだよね
確かにね それはそうだね
作ったときのプロンプトを出さなくても
確かに
何かOSSにするにはちょっとな
みたいなセキュリティツール
個人的にはあるんだけど
こういう風にブログ書くのめっちゃいいな
パクりたいな
逆も
あるよね 使ってみたいけど
54:03
これ安易に回していいんだっけ
みたいなのが分からん時に
作り直しちゃえばいいやんみたいなのが
考え方としては
あるような気がするし
直近だとショップやり
リアクトネイティブやめて
アンドロイドIOSに戻して
AI使えばできるやんとか
クラウドフレアも
ネクストJS再実装とか
パワーある
AIちゃんとゴリゴリ使おうという
意思があるところは
割とそういう考え方で
いろいろやってるのかもね
こういう部分とかを見ると
作ればいいじゃんっていう
ちなみに
クラウダーセットから
引いてくるは
なんか
今の時代ってか別に
それ時代前からあるけれども
Googleクラウドは特有だな
あるようなクラウドサービス
特有だなと思うんだけど
自分たちが管理しているはず
と
認識しているリストから
それを起点にして
なんていうか想定外のもの
ないですかみたいなのをチェックしていく
とかはアプローチとしては
普通に前からあるような
話かなと思っていて
これはどっちかというと
なんか管理している
リストっていうのがまず
かなり精緻に取れるっていう前提があって
故に
それらに全部匿名アクセスをして
いけばいいっていう話かなと思うんで
考え方自体はなんか
アプローチが今時なだけで
考え方自体は前からある感じかな
っていう気はしますね
確かに確かに
クラウド
なんか
知らんクラウドとか管理外のプロジェクトが
ない限りはそこが
ほぼほぼ
完璧に担保できてるっていうのは結構
ありがたい前提だよね
これはぜひおすすめです
マジで
1時間ぐらい
してから見に行ったらできてたんで
サッとできると思います
やってることはシンプルなんだよね
クラウドアセットエクスポートしてきたやつを
読み込んで判定して
ロジック
これに書いてあるからさ
そのディテールがこの記事に
いいっすよ
今日はそんな感じですか
はい
いろいろ大変でしたね
大変な週を過ごせたと思いますが
皆さんお疲れ様でした
本当に
どの週の
どの週のことについて
いつのタイミングで言って
よくわかんなくなったな
タイムラグ的に
難しいあれですけど
PHPソードの
5日後ぐらいか
もうだいぶ経ったな
PHPソード
証明書ソードの5日後ぐらいじゃないですか
お疲れ様でした
57:01
続かないといいっすね
取り上げなかったけど
ブロッドリートゥーシェルとか
いろいろあるけど
あとあれかRubyのやつもあるけど
いっぱい出てくるね
なんか
分散してほしいっすけどね
どういうこと
時間軸の話
対象の話
公開タイミングの
事象発生の話やな
公開は別に多分脅威変わんないから
それは無理じゃない
そのうち
同じ日に出さないようにするみたいな
コーティネーションが発生するのかもね
いやーでもさ
そこでまたなんか揉めそうだよな
うちの方がやべえんだから
うちの方を先に出させろみたいな
足並み揃えない
コンティビューターが出てきてとか
なんか
PHPもPOC個人で公開して
すげえなんか炎上してる人いたな
そうね
もう漏れるんだろうね
もうどうしようもないな
はい
まあそんな感じで
治安の悪い世の中になってますが
体調には気をつけて
倒れずに頑張っていきたいとこっすね
お疲れ様です
はい
じゃあ次回は
おもろ記事もいっぱいあると信じて
来週もお楽しみにしててください
おやすみなさい
おやすみなさい
