放送の始まりと自己紹介
こんばんは、Replay.fm 第65回です。
こんばんは。65回。
記念すべき。 65?
65回。
ちゅーたんぱいな。
13かける5。
13かける5。
そうだね。なんか…
13かける5だね。うん。
マジでなんとも言えん数字だね。
そうだね。75とかだったらなんかまだ分かるけど。
そうそうそうそう。
65っていう、なんかマジでなんとも言えない…
あと10週間頑張らないといい数字にはたどり着けない。
いやー、アドベントカレンダー頑張ってますね、俺らだから。
そうだね、なんかギリギリ滑り込みながらなんか…
やっとるな。
やっとるって感じ。
こんなペースで投稿するの初めてだからさ、その…
気ぃ抜くと夜10時ぐらいに、
あ、今日俺じゃんって気づいて。
あーわかる。
ガーって書くみたいな。
でもなんか意外とやれるもんだなって気持ちでいる。
そうだね、うん。
なんかもうあれだな、翌々日の分をなんか書いとるよ、先に。
えらいねー。
書いてるっていうか、あのー、
うん、ざっざっと書き始めてる。
なんか、その…
なんていうかもう定型、定型文の部分は先に書いといちゃって、
なんか出先とかでポロポロポロって書けるようにして、
なんか割とパッと出せる状態でやっとるわ。
賢い。えらいなー。
うん。
もう普通に、
くちょくに書き溜めたいと思いながら、今んとこ書き溜められてないわ。
いや、まあいいんじゃん。
なんかその…
リアクトサーバーコンポーネンツの脆弱性
やっぱ収録で一回話してるから、結構思い出せるって言うんだよな。
そうだね、うん。
うん。
逆になんか、一人で記事に書き起こそうと思った時に、
その、何か言ったらいいのかようわからん問題はあるな、なんか。
あー、なるほど。
記事は覚えてるんだけどさ、なんか。
一回触れてるしなーと思って。
なんかもう一回なんか文字残すのだるいなーってなっちゃう。
あのー、リッスンで文字起こしたりというかさ、
それ引っ張ってきてさ、
あー、なるほどね。
この記事について話した部分抜き出してきていて、
せせええにブログ書かせればいいんじゃない。
うん。
いいかもしんない。
うん、やる意味。
それ、それだったらもうなんか記事食わせてさ、
なんか紹介記事を書いてくださいって。
いやー、マジで。
ひどすぎる。
本末転倒やん。
最悪やん。
自分の色出してこ。
うん。
AIに出せない人との、人の温かみを出してこ。
人の温かみが出るほどの、なんか文章量書いてないからな、今のところ。
いや、でもそのさ、文量が多すぎないっていうのも、逆に温かみでしょ。
うん。
だから、AIに書かせたらもう多分すごい。
確かにね、確かに。
膨らむじゃん。
めちゃくちゃな量がね。
確かに、そう言われてみりゃそうだな。
そう、なんか、
うん、まあ、プロンプトによるのかもしんないけど、ちょっと、
学校の教科書みたいな文章になりがちというか。
うん。
絵文字入ってきたいね。
確かに。
なんか、やたらフレンドリーな感じでね、なんか。
そうそうそうそう。
最後にまとめてくれる感じでね。
そうそうそうそう。
希少天欠やね。
うん。
完全になんか、想像できる感じやね。
まあ、人の温かみであと、今日9日に収録してるんで、あと16日分ですか。
頑張りましょう。
はい、頑張りましょう。
まあ、別に年内頑張ったから、なんか一休みってわけでもないんだけどね。
なんか別に年明けもずっと続いてくるからさ。
なんかお休みとかないよね。
まあね。
いやいや、でも、気持ちの面にね。
感想、感想した感想を喋れるようにやっていきたい。
はい、やっていきましょう。
よし。
今日も上からやらないといけないね。
よし。
今日も上から言いましょう。
はい。
1個目がDatadogのセキュリティラボのブログで、
CV2025を5518にリアクトシェル、
Remote Code Execution in React Server Components and Next.js
という記事ですね。
まあ、開発者、開発関連の方であれば、どっかでは目にしてるであろう、
結構掘った長台のリアクトシェルって呼ばれてる。
リアクトの脆弱性の話ですね。
で、なんか次の収録文でもっと詳しい深掘りしたやつが出てきそうなんだけど、
まあ触れないわけにもなあっていうところで、
軽く紹介できればなって感じなんですけど。
これは結局、なんか、実はちゃんと追っかけてなくて、
うちは気にせんでいいかなっていうところからもう止まっちゃってて、
教えてほしいです。
ざっくり言うと、
リアクトサーバーコンポーネンツっていう、
リアクトの多分、今19だっけ?
最近ですね。
最近入ってきた機能に含まれて脆弱性があったよって話で、
リアクトサーバーコンポーネンツっていうのは何かっていうのは、
超ざっくり言うと、
従来のリアクトJSって、
クライアントサイドで動くものでしかなかったんで、
サーバーサイドで動かすっていうのはなくて、
サーバーサイドは厳密には動くんだけど、
サーバーサイドレンダリングで、
クライアントのコンポーネントをレンダリングして、
Httpレスポンスとして返すとか、
事前にサーバーサイドジェネレーションって呼ばれてますけど、
事前にコンポーネントをジェネレートして、
Htmlを吐き出してっていうような形では使われてたんだけど、
ランタイムでリアクトのコンポーネントとかリアクトJSが動くっていうのはなかったんですけど、
それが最近リアクトサーバーコンポーネンツって名前で出てきた機能がまずありますと。
需要としては名前のとおりサーバー上で動くし、
サーバー上でしか動かないので、
例えば今までの世界だと、
Webフロントエンドアプリケーションから直接データベースを参照してセレクトして、
それをレンダリングしたいみたいなことを考えると、
それ用のAPIを用意してあげて、
APIにフェッチするロジックをリアクトJSクライアントサイドに書いて、
そこで非同期処理とかもちょっと気にしながら、
リアクトのレンダリングサイクルとかも気にしながら書くっていうのが当たり前の世界だったんだけど、
リアクトサーバーコンポーネンツでそこを使うと、
今言ったデータベースにアクセスするような処理をクライアントの中に書いちゃって、
それを一つのパッケージとして、
実体としてファイルとして実装した後に、
それをクライアントサイドのコンポーネントからインポートするってことができるんですよね。
で、それをリアクトでコンパイルというか、
コンパイルすると、
クライアントサイドに巻かれるJSにはそのDBにアクセスするようなロジックとかコードっていうのは混ざらないんだけど、
サーバー側ではきちんと実装したサーバーコンポーネンツのロジックがあって、
開発者目線はクライアントからそのサーバーを呼び出すっていう、
割と自然な形で書いたコードが裏側では良い。
そうそうそうそう。
吉那に通信していい感じにやってくれるって機能が最近出たよって話で、
なるほどね。書き味的には自分が今どっち書いてるのかよくわかんなくなるやつのあれだよね。
そうそうそうそう。
なんで出た当初とか、今はどうなんだろうって感じなんだけど、
Next.jsがこれをサポートしたときは、
サポートっていうのはリアクトサーバーコンポーネンツって結構複雑な仕組みなんで、
これを生で触ってる人はほとんどいなくて、
自分が使ってるライブラリーがリアクトサーバーコンポーネンツをサポートするのを待つみたいな感じなんですけど、
Next.jsとかサポートしてるし、割とメジャーどころは増長してサポートしてる。
で、Next.jsがこれサポートしたばっかのときは、
今言ったような分かりづらいみたいなので結構ちょっと議論が起きてたりはしたって感じかな。
そうなんですけど、そこに含まれた脆弱性って感じで、
内容としては結構シンプルで、めっちゃ細かくは置いてないんですけど、
今言った吉野にやる、通信をやるっていう部分の中にフライトプロトコルっていうのがあるらしくて、
そこで飛ばした、たぶんシリアライズしたデータをクライアントから飛ばすっぽいんですよね。
飛ばして、それをデシリアライズする部分の処理で、
シンプルにプロトタイププロデューションの脆弱性があって、
で、そこを悪用すると、JSのプロセス呼び出すような組み込み関数があるんですけど、
それとかを叩けちゃうんで、コマンド10コマでいきますよって言うんです。
割とものとしてはシンプル。
で、今週読んだ記事の中ではこの記事が唯一具体的なコードを確か上げてたんですよね。
分かりやすいね。
そうそうそう。
ものとしてはシンプルな。
なるほどね。
影響範囲が結構でかいんですよね。
このサーバーコンポネンツ動いてるサーバーは多分ほぼ刺さってしまうので、
みんな騒いでるのはそういうところだし、
Next.jsのシェアはかなり広い。
Next.jsに限らずリアクトサーバーコンプレッサーをサポートしてるライブラリーはそれなりに多くあるし、
影響範囲と対応策
プロダクションが動いてるんで影響範囲も広いし、
これ発表されてから多分数時間以内に中国のアクターが悪用してるのを確認しました、
みたいなことを確かWisdomブログに書いてあったりとか、また経緯文にも載ってるって感じで。
対象範囲の方は、対象範囲かどうかをちゃんと調べなきゃいけないし、すぐにパッチ当ててくださいっていう。
割とヤバいメッセージをする感じですね。
なるほどね。これはきついね。
プロトタイプポリューションでぶっ刺さる系では一番でかいんじゃないかな、話題になった中で言うと。
プロトタイプポリューションのパッチというか渋いはそんな珍しくないんだけど、
ここまできれいに刺さっちゃうのは結構珍しいというか、
サーバーのプロセスが解釈しちゃうっていうのが多分でかいのかな。
末端のちっちゃいライブラリでプロトタイプポリューションとかだと、
そこにたどり着けるか、外部からそこにまでたどり着ける可能性ってなんだかんだ低いよねというか、
限定的だと思うんだけど、今回はもうリアクトレイヤーでも成立しちゃうから、
なかなかなっていう感じですね。
なるほどね。これはきついね。
ちょっと気になってるけど覚えてないのは、
どういう混ざった根本なのか間接原因なのかわかんないけど、
サーバーサイドで動くNode.jsのライブラリって腐るほどあるんで、
別にノウハウがNode.js界隈にないわけではない気がしているんだけど、
なんで出ちゃったのかみたいな結構個人的に聞いて。
プロトタイプポリューションっていう攻撃自体が結構防ぎにくいというか、
生のJSの根っこの部分じゃん。
そうだね。
確かに。
なんて言ったらいいんだろうな。
リアクトのDangerous 3なんとかかんとかインラインしてみるみたいなやつとか、
ああいう配慮は聞いてないわけじゃん。
もっと言うとプロトタイプ応戦って普通に書いてたら普通に起きちゃうみたいなのが、
書くコードによるけど普通に起こりうるというか、
結構気をつけてくださいだとどうしようもない系ではあるよなとは思うんだよね。
静的解析とかで結構見つけられそうな気はせんでもないけど、
難しいよなあ。あくまで外部入力に対してっていうところで見ないといけないから。
そういうリンターとかは知ってたりするのかな。
だからそれで言うと再発防止どうするのか結構個人的には気になるなあ。
そうだね。いやおもろいね。
でもこのコンストラクターコンストラクターにきれいにぶっ刺さるっていう恒例は面白いなあ。
ずっとクライアントサイドで動くものを開発してきたコミュニティだと思うから、
リアクトサーバーコンポーネンツの問題
それが関係してんのかなとかは普通に素朴な疑問としては。
ただなんかそれは間違いなくあるかなとは思うんだけど、
なんかでも別にプロトタイププロデューションダメだよねっていうのは別にクライアントアローが何だろうが関係なくあるはずで、
あんまそこは言い訳にならんかなとは思って。
なんかXで見てるとそもそもリアクトサーバーコンポーネンツがなんかおかしいよねみたいなこと言ってる人もいたけど、
別にそういう話じゃないねこれはね。
そういう話じゃないと思う。
まあちょっと過激かなっていう。
まあそれはリアクトサーバーコンポーネンツなければ起きないことではあったが、
まあでもそれ言い出したらね。
まあただなんて言ったらいいんだろう。
危ない端ではあるよなと思っていて、
溶け合いっぷりがクライアントとバックエンドのなんか。
まあどうなんだろうなこれ。
まあそうね。
でもなんかリアクトクライアントサイドのやつとは結合してない気はするんだよな。
そうだよねリアクトサーバーのサーバーコンポーネンツのパッケージは分離されてるから、
ごっちゃになってみたいなのはそんなに、
まあわかんねえなちょっとリアクト。
まあでも結構そのなんて言ったらいいんだろう。
アプリケーションの動きとして透過的にやろうと思ったときに、
クライアントサイドからバックエンドへの関与が大きくなるよねっていうのは多分あるんじゃないかなとは思うんだけど、
ちょっとそこは正直もう全然専門外なのでなんとも言えんかな。
ありそうだなとはなんとなく素人目線思うけど。
どうなんだろうね。
ちょっと気になるのは今のエコシステムで実際このシェル取られたから何が起こるのっていうのはちょっと気になったな。
どうなの。だってGCEで直ホストしてますとかあんまなくない?今のエコシステムで。
そうだね。
でも例えばそのサーバーから、だからサーバーコンポーネンツを使ってるってことは多分、
本来今までだったらAPIサーバーとかWebフロントエンドで分かれてたAPIがになってた部分を処理してる可能性は高い気はしてて。
そうだね。データベースへの接続とかは確かに持ってるか。だからそういう意味でいくとやっぱまずいはまずいんだな。
そうだね。なんかシークレットとかへのアクセスもありそうだし。
システムによるけど割と痛い目見るシステムは多そう。
わざわざReactサーバーコンポーネンツを使ってる環境っていうのはまさにこれが刺さったときにまずいっていうのは確かに言えるわ。それはそうだね。
それはそうでございますね。
クライアント、Web側のWebというかNext.jsとかそういうフレーマークの責務が昔より結構大きいからその辺はやんわりとパラダイムシフトをした後なのかもしれない。
考え方を改めないといけないかもな。
そうだね。これはむずいな。どうなんだろう結構ね。
派手に。久々の祭りって感じです。悪い方の祭りというか。
いやーこれでもちょっと話したいと思ったけど、Reactのコミュニティの動向とかもし置いたら続報探しにいこうかな。
今後どう防ぐかな気がするんだよな。結構もう出ちゃった場所が。
いやーでもなんか作りの上では今後も起こり得るんじゃない?だってこのなんていうか、プロトタイプ?
うん。
プロトタイプのモデルがなくならない限りは多分プロトタイプポリューションっていうのはなくならないし、
多分どうしようもないよね。
例えばTSからはもうプロトタイプ触れませんみたいな機構を入れるとかせんかきは無理なんじゃない?
そんなのが実現可能なのかがちょっと分からんけど、なんかだいぶブレイキングチェンジだよね多分。
あとはAIでどうにかしていく。
なんか最近ReactがFacebook参加から正式に離れたんですよ。開発チームがあって。
React Foundationっていうのが出て、そこにAmazonなりバーセルとか。
フェイスブックじゃないか、メタか。
Microsoftとかあるんで、その辺の資本のパワーでいろいろなんかいい感じにしてくんねえかなってぽんやり思ったっていう。
まあ100%防げはしないだろうけど。
ウェルスナビのマルウェア誤検知
これ難しいな。Reactレベルのそのレイヤーでできることってやっぱそんなにない気がするけど、どうだろうな。
なんかちょっと改めてプロトタイプポリューションのその対策をさ、なんかちゃんと自分で全部説明できないなと思って今調べてるけど。
なんかやっぱ難しいよねってイメージはあって、やっぱ実際難しいよなとは思うんだけど。
いかんせんな。なんかきついよね。
まあそんな感じですね。
いやーこれやっぱきついと思うけどな。なんか付き合っていくしかない気がするけど。
付き合っていくしかないし。
まあでもなんかペイロードにさ、今回のケースではペイロードにさ、アンダースコアプロとか入ってくるよね。
うんそうだね。
なんかWAFとかでは引っ掛けやすいのかな。どうなんだろう。なんかバイバスしうるのかなこの辺も。
一応なんかクラウドフレアはもう吉谷にブロックしちゃうよみたいなのにして話題になったりしたけど。
まあペイロードがはっきりしてる分ね、なんか比較的マシではあるよな。
うんうん。
で、ブログになんかこういうの観測したよっていうのが書いてある。
へー。
やっぱまあチャイルドプロセスだった時に。
まあなんか予防的な策としてそのチャイルドプロセス禁止とかできるのかな。
ノードJSちょっとね最近勉強しようと思ってできてないんだけど、なんかノードJSのプロセス実行時にパーミッション絞るみたいな機能がノード24かなんかでエクスペリメントから外れて、
なんかそういうのでもし防げるならそのGAできる策としてはあるかもね。
うん。
いやー、おもろいな。
うん。
はい。
ありがとうございます。
影響してる方はさすがにキャッチしてると思いますが、もし万が一キャッチしなかったら急いでこれを聞いた瞬間に調査してください。
うん。
えー、じゃあ次に行きますか。
当社のスマホアプリがマルウェア投稿検知された原因分析と見解っていうウェルスナビさんのアドベントカレンダーの記事ですね。
えーと、なんかどうしようかな、なんか大雑把にサマリーすると、
ウェルスナビさんのAndroidアプリが一部の環境でマルウェアとして検知されるっていう問題が起きて、
お客さんから複数の問い合わせをもらって調査を進めたよっていう話。
で、結論、誤検知だったんだけれども、なんでこれが起きちゃったんだっけっていうのを割と深掘りして記事にしてくれてるような感じかな。
で、結論なんか、外部依存のライブラリーの中で、その端末がルート化してあるかどうかを検知するのに、
その要はルート化してれば通るコード、ルート化してなければ通らないコードっていうのが含まれていて、
それがセキュリティソフトで検知されて、誤検知されてっていうような話だったらしくって。
で、もう今の時点では、これは結局あれかな、課検知の申請ができるよっていうふうに書いてあったんだけど、
それの結果なのかどうなのかはちょっとよく分からんかったけど、今のところはもう検知されなくなりましたよっていう点末を書いてくれてるような感じかな。
そうだね、厳密にはそのライブラリーが原因だったかどうか多分分かっちゃうよね。
これがそうなんじゃないかっていう仮説を、読んだ限りはかなり角度高い仮説かなとは思うんだけど。
そうだね。いやー、おもろかったな、これ。
おもろかった。おもろかったけど、普通に誤検知でこの作業強いられんの、なんか普通にシンプルに気の毒だなって思った。
そうだね、あんま、あんまというか初めて見たな、こういうの。
初めて見たね。
実は起きてんのかな、結構。
あるかもね。
ライブラリーがさ、何のライブラリーかは書いてないけど、実はちょこちょこ使われてるとかあったら普通に。
結構ありそうだけどね。
うーん、なんか、そのライブラリー側に一周立てたい、いやでもなー、違うんだよなー。
でもなんか別に。
限定的だもんね、これ。
やってることとしてはなんか、まあ、いやどうなんだろうね、なんかそのAndroidの開発を自分でしてないから分からんけど、
そのルート化してあるかどうかのチェックっていうので、やり方としてこれがメジャーなのかどうかがちょっと分かんなくて、何とも言えないけど。
アバスト。
あとこの、特定の端末だからこのマルウェア検知の、これはプリインストールされてるってことなのかな。
うん、アバストはプリインストールされてるのかの話がどっかに書いてあった気がする。
ああ、なるほどね。
うん。
いやー、だから結構HKSというか悩ましいね。
悩ましいね。なんかよく、なんか根気強くやったなっていう。
うん、いや、偉い。
まあその授業は授業だからあんまお茶を濁せないっていうのはあるのかもね。
あるかもね。
うん、証券系のビジネスをやってるとかどうなのか。
まあ実際なんか変なものがね、購入してましたと話にならない、話の人が笑えないからね、全然。
うんうん。
なんか結構、なんか実際にその、自分たちが持ってる手持ちのソースコードじゃなくて、
アプリのストアから落としてきたアプリの実態に対してリバースエンジニアリングしたよみたいな話とかも結構、なるほどなと思って。
うん、面白い。
賢いね。
サプライチェーンどこで可能性で言うとね。
そうそうそうそう。可能性で言うとね、なんかプレイストアと自社管理のソースコードの間でっていうパターンも全然あり得るので、
なるほどなっていう風に思いました。なんか結構、そうだね。
しかも何か依存を見ましょうってなった時に、やっぱフラットに見ようとすると何か多分、
何か実態の方のリバースエンジニアリングの方がいいのかもね。都合もいいのかなとはちょっと思ったな、今。
分からんけどどうなんだろうね。
分からん。
全然、いや、リバースエンジニアリングの解像度が低すぎて全然分からん。
ちょっとしかやったことないわ。なんかAndroidのリバーシングとかも全然。
大変興味深かったです。お疲れ様でした。
この記事、いや本当お疲れ様でした。この記事も個人的にはめっちゃ光ったというか好きだった。
このまま障害法にしてもいいぐらい。
APIの脅威とTRIFOGの提案
多分何か事実上、実際そうなんじゃないかなって思うんだけどね。
お客さん向けの報告書をベースに何かやってるんじゃないかなって思うけどね。
めっちゃ何かクオリティ高くて素晴らしい。
ありがとうございます。
アドベントカレンダーに感謝。
感謝です。
次いきます。
TRIFOGの会社のブログでThe Rise of API Wormっていう記事ですね。
話としては割と結構シンプルなことが書いてあって、
先週紹介したシャイフラットの話がありましたけど、
シャイフラットはなんだろうな。
始まりに過ぎんぞみたいな割とちょっとそういう論調の記事で、
何の始まりに過ぎんかっていう話で言うと、
ローカル内に入ってクレデンシャルスキャンをした上で、
そのクレデンシャルからいろんなサービスの中身とか権限をたどって、
どんどん侵害を広げていくっていうものが、
これからも出てくる恐れがありますよっていうことを話してる記事ですね。
ちょっとメモに書いたんですけど、
TRIFOGってセキュリティクレデンシャルスキャンの製品、
丸々組み込まれるぐらいサポートしてる企業って、
弊社も実は補正になったりするんですけど、
サービスですね。
有料版OSS版なんですけどサービス展開してるんで、
ちょっとポジショントークな部分もあるかなとは思うんですけど、
一方で書いてあることは正しいかなと思うし、
個人的にはシャイフラット出る前から微妙に恐れてたことであったんで、
だから紹介したいなっていう感じで、
シャイフラット2回やって成功しちゃってるんで、
似たようなアプローチで別のものに目をつけて拡散していこうとかは全然、
攻撃者側だったら考えるだろうし、
それで狙われるっていうことは、
AWSのセキュリティの課題
狙われる前提で考えた方がいいんだろうなっていうところと、
これにちゃんと向き合うと思うとなかなか頭痛いなって気はしていて、
イモズルで繋がりがちというか、記事中だとちょっとふわっと忘れたけど、
AWSの強い機1個じゃ漏れちゃいましたってなったら、
S3っていうかあれか、シークレットマネージャー見て回って、
その中のクレデンシャル見て、そこにGitHubのパッドがありましたってなって、
GitHub行ってシークレットダンプしてみたいな、そういうのが例として書かれてて、
だいぶ上手くいきすぎてる例ではあると思うんですけど、
一方で全然否定しきれるシナリオではないというか、
そういうふうに繋がるケースって、
ちゃんと管理してなかったらあるだろうし、
ちゃんと管理してても繋がらざるを得ないみたいな部分を考えると結構悩ましいし、
じゃあそれを1個1個把握して評価するのができるかというと、
あんまり現実的じゃないと思うんで、
じゃあどうすんねんで言うと、結構愚直になんだろうな、
ローテーションしましょうとか、
いらんクレデンシャルなくそうよとか、
今だったら多分時代的にキーレスにできるものが多いかというのをすんで、
キーレス化しましょうとか、
そういうのを1個1個コツコツやっていくしかないのかなという気持ちに改めてなったという感じですね。
なんかきついね。
結構
何がきついって、
キーレスにしましょうって割と使う側は結構簡単だしいいなと思う一方、
サービス提供側はやっぱ重いよね。
そうだね、重い。
重いね、確かに。
実装しろって言われたら確かにちょっとだるいな、
APIキーのほうが楽だね。
そうそうそうそう。
確かに。
そんな簡単にサクッとなくしていけるかというと、
ちょっときついよなって思うから、
なんかそのAPIキー、
いわゆる事実上のベアラートークンっていう言い方をしてもいいのかな、わからんけど。
それをいかに安全にしましょうかねっていう話を、
もう少し真面目に向き合って考えるっていうのも一つありなのかなとは思うし、
特定のフォーマットだったらTriHogとかGitHubとかが見つけられるよっていうのはあるわけだから仕組みとして。
そういうのをもうちょっと頑張ってみてもいいんじゃないかなとは思うけどな、
世界観としてはね。
今の現状としては結構、
クリティカルなサービスからすごくゆっくりKeyless化してるって感じだよね。
クラウドプロバイダーはAzureはちょっと未把握だけど、
さすがにあるとするとサポートしてて、
GitHub、またあれか、NPMも侵害を受けて後追いでサポートみたいな感じだから、
そんな感じでやられたところから順にサポートされていくと思いたいけど。
あとはGitHub上にあるものとかは、
今言ったような仕組みで見つけられるよねっていうのは当然あると思うんだけど、
結局でもローカルに入られたらそこから抜かれるよねって話はあると思うから、
いずれにせよKeylessにしていきましょうっていうのは多分必要なアプローチで、
逃げ場はないかなと思うんだけど、
いやーきついね。
そう言うはやすしなんだよな。
うん、マジで言うはやすしなんだよな。
果たしてKeylessにしたとって、ローカルからの接続までちゃんと保護しきれますかってなると、
結構怪しくない?ってなって、
接続する瞬間はあるわけで、
プロセスレベルでの保護をじゃあ何とかしましょうよローカルでみたいな話になってくると、
それこそブラウザみたいな世界観をあらゆる局面で実現しないといけませんみたいな話になりかねないし。
その辺はどうなんだろうね。
APIキーの管理
めっちゃ楽観的に考えるなら、
今は多分みんなもうローカルにお宝ある状態だから、
それ集めて回るほうが攻撃者目線は楽というかおいしいみたいな部分があって、
それがみんなちょっとちゃんと知らしてKeyless化したり、
.mをワンパスに突っ込むなり、
知らした時に向こう側が手を変えてイタチゴッコが始まるみたいなのは結構ありそうだなっていう気はする。
でも現時点でも知らないだけでありそうはありそうなんだよな。
なんか大規模な攻撃では多分やってないと思うけど、
何て言ったらいいんだろう、狙い撃ちしてくるようなパターンだときっとやってるケースもあるんじゃないかなとは思うね。
そうだね、標的型では全然ありそう。
その会社の開発者のあらゆるアクティビティに張り付いて漏れたらそこを起点に何かするみたいなのは全然あるかなと思うから。
そこまでそこにまで備えるかどうかは結構各社の差し加減というか。
備える備えないで言うとなんかまあ想定はしないといけないけど、
なんかそのそういうのよりも多分圧倒的大多数の会社組織がきっと
その大規模にワーってやってる中に引っかかっちゃうっていう方が多分可能性としては高いよねっていうのは言えるんじゃないかなと思うので。
うんうんうん。
なんかパターンとしては全然想定しておかないと。
確かにね。
しかもなんか極力にやることあんま変わんない気はしていて。
うんうんうん。
突き詰めてくとね、なんかそんなにやること変わんない気がするんだよね。
どっちにも効くというか。
うん、そうだね。
それは確かに。
はい、なかなか向き合っていかなきゃいけないなという気持ちに改めてなったっていう感じですね。
うんうんうん。
いやでもこれ流行るときついね、なんか普通に。
うーん、嫌だ。なんか嫌な予言、普通にね。
もう。
これでもなんかNPMのポストインストールがもうきついよねみたいな話とかもあったじゃん。
なんか。
あーそうだね。
ああいうのがあるのって、なんかね。
うんうんうん。
なんかでもNPMインストールに相当することをしたら何かコードが実行されるってことはないから。
あの、Jminに聞いてみよう。
うん。
ポストインストール相当の機能がある他にも何かコードが実行されるってことはないから。
うん。
なんかね、
NPMインストールに相当することをしたら何かコードが実行されるってことはないから。
うん。
なんかね、
Jminに聞いてみよう。
リインベントの新サービス
うん。
ポストインストール相当の機能がある他言語のパッケージマネージャーがあれば教えてください。
Python、
setup.py、
あーでもちょっと違うな。
Bundler、
うーん。
うーん。
分からんな、まあ語はないらしいぐらいしか分からない。
ラスト。
NPMのように。
その正規の使い方としては何を想定してるの、あれって。
例えばよく見るのは、見たことあるのはそのNode.js、
あれですね、そのNode.jsじゃないネイティブのコードが必要なとき、バイナリーが必要なときとかに。
パペッターとかね。
あーそうそうそう。
手元の環境を見たり、何か場合によっては吉野にビルドするみたいなのを走るとかは見たことあるかな。
なるほどね。
あと何かあるかな、あんま自分がライブラリ作るときに使ったことないけど、
少なくとも安直に次のバージョンから切りますってできないぐらい使われてはいる感じだね。
なるほどね。
いやーむずいね。
ジェミニに聞いてみよう。
いやーダメだ、ジェミニに聞いたことをこんな場所で喋ったらいけない。
調べてこよう。
まあそうだよね。
まあでもコンパイル。
そうそうそう。
依存関係のダウンロード。
そうなんだよね。
ちょっとややこいパッケージで何か使われがちな気がするな。
はい。ありがとうございます。
うっす。
じゃあ次は私かな。
チャゲさんのブログで実践ウェブペネトレーションテストを出版しましたっていう記事ですね。
タイトル通り実践ウェブペネトレーションテストってオライリ本が出版されたんですけど、その紹介という感じですね。
このチャゲさんという方が執筆されたそうなんでという感じです。
とても良さそうなんで読もうと思ってるっていうんで興味ある方はぜひって感じなんですけど、
名前の通りウェブのペネトレーションテストの実践ができる内容になってるんで、
実はこれの違う方なんですけど名前忘れちゃった。
名前忘れちゃったんですけど、ペネトレーションテスト本がもう一個あるんですよ、オライリの最近出たやつ。
そっちは会社の輪読会でやったんですけど、実践ペンテストかな。
その本とかも実際にこのツール手元にインストールしてこういうふうに触って、
じゃあ脆弱などっか立ち上げて攻撃してみましょうみたいな感じでやったりしたんですけど、
なんかそんな感じで手動かせる系っぽいなっていうのが。
フォートスキャナー自作で始めるペネトレーションテスト。
それです。
ありがとうございます。
小竹さんですね。
なんでとても良さそうだなっていう。
僕とかバックグラウンドソフトエンジニアで診断の経験とかなかったりするんで、
実際何してんねみたいな部分でいい学びがありそう。
いやー、輪読会やります?
やりたいっすね、個人的には。
やるかー。
あとなんか、えーって思ったのはブロック暗号に関する攻撃みたいな部分は、
Webアプリケーションでもよく使われてるんだけど、
一見すると暗号化されたデータはランダムな文字列にしか見えないので、
外部からのテストではスルーされてしまうことが多いですが、
原理をひもどいてみると脆弱性が判別することは珍しくありませんって書いてあって、
これはなんていうかプロの視点だなーと思って、へーって感じ。
面白いかも。
でもなんか、もう詳細は正直忘れちゃったけど、
なんか見るよ、ブラックボックステストだと。
あ、そうなんですか。
暗号文っぽいなーっていうものは、なんかゴチャゴチャ触ってみるっていうのはミニマムやるし、
ブロック暗号だったらこうだよねーみたいな推測にも続いていじるみたいなのはやる。
実際に。
なるほどね。
みんながみんなやってるかわからんけど、やる。
うんうん。
なんでしょう、なんか、
ツイッターでアンケート取るか、やってますやってません。
やってませんって言えねえよ。
言えない言葉だね。
なんかでも急拡としてなんかでもやらん、そのわけわからん文字列があったらさ、
なんかちょっといじってみたら壊れんのかな壊れないのかなとかさ、
どこいじったら壊れんのかなとかさ、なんかやらん。
いや、わかんない。
やるでしょ。
ペンテストしたことなのか。
やるでしょ。
やらんことはないか、まあまあその理解はできる。
自分が実際その動きを取れるかはさておき。
これをそのペンテストっていう観点で見た時に、
その悪用までつなげられるかっていうのは結構難しい話で、
そのなんかできそうだねから、
そのなんか悪用につなげるっていうのは結構なんか大きな断絶があるかなと思うので、
ちょっと中身が気になりますね。
うん。
そうですね。
はい。
ぜひ僕と一緒にみんな呼んでみんなで感想せんしましょう。
はい。
じゃあ次かな。
はい。
われわれコミュニケーションのブログでリインベントですね。
リインベントが多分先週か今週かやってたんで、
その紹介記事がバーっと流れてきてるんですけど、
AWSリインベント2025ソフトウェアデベロップメントライフサイクルを支える
AWSセキュリティエージェントがいいっていう記事ですね。
はい。
内容としてはAWSセキュリティエージェントっていうものが発表されたよっていうところで、
その紹介の紹介っていう感じですね。
ちょっと詳細は情報量も多いんでぜひ読んでくださいって感じなんですけど、
めっちゃざっくり言うと3ステップの部分、
AIエージェントのセキュリティレビュー
開発プロセスにおいて3つのポイントで
AIエージェントがセキュリティレビューをしてくれるよっていうのがあって、
1つ目がデザインドックのレビューをまずしてくれるよって、
2つ目が実際のコードレビューをしてくれる。
3つ目が動いてるものに対してペンテストしてくれるよっていうのを
自律的にやってくれますよっていうものだそうです。
今なんか無料期間らしくて、
申し込めば使えるっていうんでおすすめですよみたいなところがあって、
記事では実際にその社内でWASPジュースショップを題材にして
試してみたんですけど、
割と概ね、
使えるものになってそうみたいな所感が書かれてたって感じですね。
デザインドックとかは当然ないので、
逆に書き起こしてみて、
食わせてみてみたいなことを多分してるみたいなんですけど、
そうですね。
デザインドックというか設計書というか。
はい、そんな感じです。
ちょっとぜひ試してみたいなという気持ちで。
ブルーチームとレッドチームの役割
このペネトレーションテストが気になるな。
あ、でもドメインの所有者検証する必要があるんだね。
これはAWSを使ってないともしかしたら面倒とかあるかもね。
あるかもね。
詳細は分かんないんだけど。
AWSだったら省略できるとかもしかしたらあるかもね逆に。
分からんけど。
ありそう。
所有者検証、そうだね。
なんか徐々にこういうサービスが出てきてすごいいいですね。
匠勝てんのか。
どうなんでしょうね。
どうなんすかね。
国内サンダーと匠さんと。
でもなんかこういうやつはまだなかったよな。
そのコードに対してGoogleのまだクローズドのやつとか、
あとチャットGPTもなんか、
まだクローズドベータのやつがあるっぽいけど。
あれの多分コードを見てコードの脆弱性を見つけるみたいな感じだけど、
こっちはドキュメントレビューをするっていうのと、
あとペンテストするっていうのはあんまりないよね。
ないね。
僕は知ってないんだけど。
実際にいろいろ試すと思うんですけど。
PortSweeperとかどうなったんだろうな結局。
どこまで行ったんだろうな。
すごい、もはや半年以上前な気がするけど。
スタンスとしてはあくまで人間の補助というか。
そうだね。
作業の効率化みたいな。
AI自体が何かをするみたいな話はまだ見かけてない気がする。
もしかしたらあれかもね。
そのスタンスの効率化みたいな。
AI自体が何かをするみたいな話はまだ見かけてない気がする。
もしかしたらあれかもね。
そのうちやるのかもしれないですけど。
はい。
みんな試してみんなで感想戦しましょうこれも。
はい。
はい。
じゃあ最後かな。
私からご紹介ですが、
ブルーチメンシュの考え方、
Rack Security コッタにブログですね。
はい。
これはね感想を聞きたかったですね。
そうなんですね。
読みやした?
ざっと眺めた感じ。
なるほどですね。
記事の紹介としてはブルーチメンシュですね。
実際に多分ペンテスター役がいて、
話の文脈的には多分Rackさんが発注された時に攻撃者役としてやって、
発注元の会社、依頼した会社側のブルーチームの能力を測ったり練習したりするみたいな、
多分そういう文脈なんだろうなっていうのを途中で気づきながら読んだんですけど、
そういう文脈においてどういう考え方でどういうアプローチがいいのかみたいな部分に触れてくれてるって感じですね。
細かい部分はいろいろありつつなんですけど、
結構全体的にホワイトハウを組み合わせて話してくれてるのが印象的で、
前提として僕は全然記事中ではスレッドレッドペネトレーションテスティングっていうTLPTっていうものに興味があって、
スレッドペネトレーションテスティングっていうTLPTっていうものについて話すよって言ってるんですけど、
このTLPTについては全然詳しくなかったんですけど、
例えばそのブラックボックスだっけ、ブラックボックステスティング、
表語忘れた、あ、そうですね、ホワイトボックス、ブラックボックス方式のテスターみたいなので、
適切な情報開示量っていうセクションがあって、
これとか何かっていうと攻撃、この日に演習しますってなった時に攻撃するレッドチーム役の人がどういう攻撃をするのかとか、
何をするのかみたいな部分でどこまで開示するかみたいな、すべきかみたいな話があったりして、
こういうのも何も考えずに、例えば開示せずにやっちゃうと場合によっては成果が出ないよっていう話とかがあって、
じゃあここに関してはブルーチームの成熟度に合わせて考えるといいですよみたいな話とか、
また事前ルール提示みたいなのもなるほどなっていうのがあって、
こっちとかは例えばたまに実際に会った声なのか分からないですけど、
あくまで演習でありテストなんで、テストだと思ったんでそこまでやらなくていいと思ったみたいな話とか、
テストなんで例えばアクセス遮断しちゃうとダメだと思ったみたいな、
そういう感想が最後に出ちゃわないように事前にきちんとルールを擦り合わせておくのも大事ですよみたいな話をしてて、
そういういろんな何でしょうね、目的に対してそういう調整をしていかないといい演習にならないしっていう部分が割と丁寧に解説されてるって感じですね。
TLPTの実践と課題
はい。
感想としては基本収支になるほどなというか、今話しながら思ったけどこのTLPTに限らず脆弱性診断とかに近しい話はある気はしてて、
まあそうね。
もうちょっとなんかあれかもしんないけど、全てのものごとが極端そうであるべきだと思うけど、
そもそも何でやりたいのかみたいな目的があって、そこに対してどういうふうにやるかみたいな部分を調整しないと成果は最大化しないよねみたいな、
めちゃくちゃざっくり言うとそういう話だと思ってて、
このTLPTは僕は見たこともないし経験したこともないけど、この記事を読んだ感じはそこの触れ幅みたいなのがめちゃくちゃでかくなっちゃうんだよな、
なってしまうんだろうなっていう部分は。
なんかいわゆるペンテストがTLPTだと私は認識してて、
ペンテストという用語が脆弱性診断プラスアルファぐらいの用語に落ち着いちゃったがゆえに日本ではTLPTっていう用語があえて生み出されたっていうふうに理解してるんだけど、
TLPTとかって英語記事あんまり出てこないと思うんだよな、多分。
わからんけど。
なので、いわゆるペンテストがTLPTだと思ってもらっていいんじゃないかなって思うな。
なるほど。
で、このレッドとブルーのシナジーみたいな話って多分フリーの記事でも出てたんじゃないかな、きっと。
なんかあったね。
あったよね。
確かに、中にいるからこそみたいなやつもあったよね。
そうそうそうそう。
確かにね。
真に試されるのはブルーチームだよねっていうのはその通りだと思うし、
なんて言ったらいいんだろうね。
DevSecOps的な観点で環境とかプロダクト自体の堅牢化みたいなのも当然必要ではあるけれども、
実際のオペレーションやってる側のブルーチームの能力向上みたいなところにはめちゃくちゃ役に立つっていうのはその通りだなと思うし。
そうだね、あとは。
いやーでもこれ結構。
なんかあれだね、カオスエンジニアリングに多分近いんだよな、考え方として。
そう、わかる。
うん。
なんか、セキュリティ以外の開発の概念でも似たようなことある。
そうそう。
インシデントレスポンスの机上訓練やるとかでも多分同じような話が観点はすごいあるというか。
応用できる気がする。
いやー、もしですね、このアラックさんの場合は多分フリーと違って、
ブルーとレッドが同じっていうよりかはブルーチームがある会社から依頼を受けてレッドチームをやるみたいな感じだから、
なおさらこういうのが大事っていうのはあるんだろうね。
今日は診断の、それこそTLPTってあえて造語で生み出してるぐらいだから、
要は脆弱性診断の延長じゃないところまでちゃんと持ってこうとすると、
こういう前段の整理とか理解っていうのが必要だよねっていう話なのかなとは思ったな。
なんか別に個人的にめっちゃ新しい話っていうのはなかったんだけど、
これ読んでどう思うのかなっていうのはめちゃくちゃ気になってたというのはそういう背景。
なるほど。
難しい。
これはみかんですけど、めっちゃ勉強になりました。
いい記事でした。
めっちゃいい記事だった。
ありがとうございます。
こんな感じかな。
今日は以上でございます。
いい分量ですね。
ちょうどいいね。
毎週これぐらいでいけるとなんかいい具合だね。
そうだね。
結構でもなんか面白い記事多かったけどな、この週。
多かった。
なんかあえてその紹介はしてないけど、
ステートマシンの話とかなんかもう入れなかったけど、
結構なんかわからん、このステートマシンっていうのをあんまり自分自身の開発で触れたことがないから、
なんかあれだったかもしれないけど、結構面白いなと思ったし。
面白いですね。
あとDマークを。
聞こえんがある。
そうなんだよね、そうだろうなって思ってそう。
Dマークをなめてましたとかね、結構これ、
これ入れ忘れたかもしれないな、なんかまあいっか。
本当?
ちょっと迷ったんだよな。
入れるか、じゃああえてなんかもうここで追加しちゃうけど、
Dマークをなめてましたっていう弁護士.コムのブログですね。
これはアドベントカレンダーだったっけ?
そうだね、弁護士.コムアドベントカレンダーの3日目の記事ですね。
SREチームの方が書いてる記事で、
なんかDマークのポリシーを何からクアランティーンに変更するまでの流れの話を書いてくれていて、
Dマークのレポートの分析環境の構築をしたりとか、
ポリシー変更による影響の事前調査をしたりとか、
実際にポリシー変更を段階的にやったりとかしたよっていう話で、
結構割とそんな簡単じゃなかったっていう割とうまくいかなかった系の記事で、
めちゃくちゃ学びの多い記事だったんだけど。
一つ目が、クアランティーンポリシーが適用されたメールのDマークの認証失敗率を
計測できるだろうっていう仮説がそもそも正しくなかったみたいな話が書いてあったりとか、
これやばいよな。
転送によってDマーク認証に失敗している正当なメールを特定できるだろう。
要はメールを受け取った側でメールを転送して、結果Dマークの認証に漕げてるみたいなやつ。
正当なメールがどれぐらいあるかみたいなのを特定できるだろう。
どれがそれに該当するかっていうのを特定できるだろうっていう仮説を持ってたんだけど、
結果的には転送の有無を知ることすら困難で、
Dマークのレポートの分析に基づいて顧客のサポートを行うみたいなのが目の見外れたよみたいな話とか、
あとはメールの受信者への影響をなめてたよって話で、
Dマーク認証に失敗しても迷惑メールホルダーに振り分けられるだけで、
最悪迷惑メールホルダー見てくださいっていう風に言えば済むだろうと思ってたんだけど、
実際には受信側サーバーでもうそもそもメールプロバイダーとかセキュリティ製品によって迷惑メールホルダーにすら入れないみたいな振る舞いをするやつがいて、
困ったよっていう話。
結果的にクラウドサインをやってるので、ことと次第によっては結構大きな大事になってしまうっていう可能性もあったんだけれども、
結局軽々じてギリギリ生き残ったみたいな話だったのかな、結論。
なんとかかんとかできたよっていう話ではあるのかなと理解してるんだけど、
あとあれだね、社内への影響とかもそうで、思ったよりもいっぱい問い合わせ受けたよっていう話とか、
結構苦しかった話を書いてくれてるんで、ぜひ読んでみてくださいっていう話かな。
この分析のやつマジかって思ったな。
RSCユーザへの重要な対応
そうだね、これきついよね。
これきついわ。レポート送ってくるメールプロバイダーが使用通りのレポート送ってないってことだよね、おそらく。
たぶん。
どうなんだろうね。
いやでもなんか確かにこれはやんないとわかんないというか、
問い合わせも通常時から30%増えたって書いてあって、結構ね。
きついよね。予想してたならまだしもさ、予想してないなんかそういうのが来ちゃうと結構、
社内からの風当たりみたいなのもきつくなるよなと思うし。
確かにね。
いやー良かった。
いや良いっすね。これなんで紹介するに入れなかったのか全然わかんないな。
シンプルに忘れそう。読んだら見つけられて。
しかもDマークの舐めるなって記事も同じ弁護士.comから出てるっていう。
舐めるなと言ったが舐めてました。
これ舐めるなね多分。なんか紹介したっけな。読んだ記憶あるんだよな。
なんかあれなんだっけ。Dマーク頑張ってやりました。あの記事は。
あれはまた別のとこだったよね確かね。
別かな。
あれどこだったっけ。
どこだっけな。
このノーションに溜めとるおかげですぐに出せるはず。Dマーク。
Dマーク。
前のこれはどこだ。
あーヴェルスナビか。
これがヴェルスナビか。本当だ同じサブキット。
今日読んだ。
なんかすごい良かった気がするな。
なんか結構そのなんていうかこのヴェルスナビの記事の方は割と上手くいったケースだった気がするんだけどなんか。
そうだね。
これを読んでさっきの弁護士.comの記事を見るとなんかきついなっていう。
そうだよね。
なんかどっちもさ公開要請が求められる類のサービスではあるかなって思うんだけどなんかそれにしてもここまで差が出ちゃうの結構興味深いなとは思うな。
まあでもそのヴェルスナビは僕昔使ってたんでわかるんですけど最悪メール来なくても多分死なないんですよね。
あーなるほどね。
例えばなんかの書面発行とかの通知メールとかあるけどまあwebで全部見れるから詰みはしないし。
でもクラウドサインは多分詰むケースあるじゃないですか。
そうだね。
先方にアカウント発行とかしないから。
その辺でその問い合わせの。
まあ温度感は変わるよね。
うん。ハレーションが起きやすいっていうのはあった気がするな。
いやー。
そうだね。
そっか意外と最近だったな。ヴェルスナビのやつは8月に読んでましたね。全然知らなかった。
問い合わせの増加と記事の品質
知らなかったですか。
裸感半年前だったけど。
はい。
あーすみません。おかわり。めっちゃいいおかわり記事を読んだ。
いいっすねー。当分12月はちょっと報告で過ごして。
なんか去年1月すげー記事なかった気がするんだよな。
そうかもしれない。
なんかカンコ鳥鳴いてた気がするんだよな。
まあもう年明けはみんな休んでもらってって感じですけど。
はい。
もう年末ぐらいからそんな感じだった気がするけどな。
年末の記事がないから年始からもう記事がねーっていう感じだったんだな多分。
そうだね。1月。
あ、でも1月。去年の1月6の週とかは意外とあるな記事。
うーん。
1月。いや違うね。1月6の次の週で1月の記事を読み始める。
あ、でもぼちゃぼちゃあるな。いややっぱあるかも。
まあ、はい。
楽しみに。
世の中のアウトプットにご期待ください。僕らがコントロールできない。
俺らはね別に何もしない。ただの折りしてるだけだからね。
いつもの。ただの折りしてます。
フリーライダーです。
フリーライダー。大丈夫。お金稼いでないから。
皆さんがいい記事を書いてくださってるおかげで僕らはこうして面白おかしくポッドキャストをやられてるので。
そうですね。
ありがとうございます。
ありがとうございます。
はい、じゃあそんな感じですか。
はい。
じゃあ引き続きアドベントカレンダーも記事読みも頑張りましょう。
頑張りましょう。
皆さんお楽しみにしててください。来週も。じゃあおやすみなさい。
おやすみなさい。
おやすみなさい。
