00:00
こんばんは。Replay.fm 第19回です。
こんばんは。
こんばんは。
こんばんは。
こんばんは。
こんばんは。
いやー、記念すべき第19回ですね。
めでたいね、19。
めでたい。次20回だよ。早いね。
早いね。10回だから5ヶ月か。
5ヶ月って思うと中途半端やな。
まあね、5ヶ月、5ヶ月か。
まだ5ヶ月しか経ってないんだな、でも。
確かにね、なんかだいぶ生活に馴染んだ感はある。
なんかあんまり、いやー素晴らしいっすよ。
結構息を吸うように、なんか何でしょうね。
育児生活を送ってると、そのまとまった時間がやっぱ以前と比べると取れないんで、
いかに何を処理するかなんですけど、
もう気づいたらずっとフィードリを開いて、
うち機械式駐車場なんですけど、
機械式駐車場でうちの区画がブイーンって来るのを待ってる間とかに、
5個ぐらいペペーって読む。
偉すぎる。偉すぎる。
あの日憧れてた効率の良い社会人になれてるのかもしんない。
ちょっと脊髄で喋ってるとは思ってないことを言ったけど、
まあまあまあまあ馴染んできましたねっていう。
まあもういい時間ですしね。
なんか脊髄で喋りたくなる時間だよね。
そうだね。ちょっと今日開始がいつもより30分ぐらい遅い。
いやー脊髄で、脊髄から脳みそに戻して順々にやっていきますか今日も。
はい、やっていきましょう。
はい。じゃあ1個目はお願いしようかしら。
OSVスキャナーの紹介
OSV、ちょっと読み方が分かんないんだけど、
多分Scaliperとかなのかな。
ちょっと分かんない読み方が分かんないんだけど、
A Library for Software Composition AnalysisっていうGoogleの記事ですね。
Googleセキュリティブログの記事ですね。
新しいって言っちゃっていいのかな。
OSVスキャナーっていうのが以前リリースされて、
それの関連ツールとして今回のSCAのツールが出ましたよっていうアナウンスの記事です。
SCA、Software Composition Analysisのツールを出してきたんですが、
結構多彩な感じで、インストールパッケージ、スタンダードアローンバイナリー、
あとソースコードといろいろ何でもチェックできるよっていうことを歌っていて、
ちょっと他のSCAのツールがどうなるかっていうのが調べた感じちょっと分からなくて、
Snykとかが割と有名どころだと思うんだけど、
Snykとかはここまで多彩な感じではないし、
結構特色がこの辺にあるのかなと思って読んでました。
SBOMの生成ができて、
割と最近こういうのよくあるなと思うんだけど、
Goで作られててGoのライブラリーとしても使用できるっていうものらしいです。
最初に話したOSVスキャナーっていうデジアクセススキャナーと最終的には統合するっぽくて、
ReadMeとか見るとその辺のことが触れられてたりしましたね。
ただ結論を触ってみないと分かんないっていうのがちょっとあって、
そのうちというかちょっとどっかで時間取って触りたいなと思ってるんだけど、まだできてない。
空のスクラップを作ったところで終わってしまってる。
なんかOSSで強そうなのがパッと思いつかなくて。
なんかパッと思いついたのはTrivyとかかなと思ったけど。
Trivyはでもコンテナのスキャンツールだからソースコードとかは見てくれないと思うし、
ソースコードは見ないね。
でもなんか多分結構思ったよりいろいろやってくれるかなって何かを読んで思ってしまう。
ディペンデンシーとかのSVMとかを作るとか。
やってくれそうだね。
結構なんかそのコンテナスキャンのイメージが強いんですけど、
プラスアルファもね、何て言うんですか、機能もあるんだな、ふわっと思ったって感じ。
まああれか、そのテラフォームのミスコンフィギュレーションとかを見るとかもできるよとか、
シークレットのスキャンもできるよとか。
今回紹介してるやつはちょっとまたベクトルが違うけど。
そうね、違う方向に進化してる感じだね。
いろいろあるっていう。ソフトウェアライセンスのチェックとかもしてくれるとか。
使ったことないけど。
いやー触りたいですね。触んないと何ともって感じだな。
なのでこれはそのうち触ってみたスクラップを作って持ち込みたいなと思うけど、
まあいつになるかなって感じですね。
こんな、いやーSボムの、Sボムという言葉が飛び交うようになってから結局あんまり僕は触れてなくて、ちょっと危機感で。
まあまあでもなんかその自分自身がSボムを触るってなんかちょっともう違うような気がしていて、
そのなんかSボムの存在は知っているべきだけど自分がそれをどうこうするってなんかあんまないような気がするんだよな。
その理想的な世界において。
なんか生成まではまあこういうツール使ってやって、それをどこに加わせるかみたいな感じなのかもね。
確かに。
それで言うとなんかそのダンプしたSボムをいい感じに管理できるようにするよみたいな。
OSSとかあんまなんか聞いたことないな。多分あるんだろうけど。
結構そのSボムを生成するところまでがなんかいろんなツールやサービス出てるイメージがあるな。
それで言うとなんか、何だっけ、前回紹介したFutureverseかなんかの記事。
Futureverseだったら両方取り込めるよみたいなこと言ってなかったっけ。逆だっけ。両方出せるよって話だっけ。どっちだっけ。
入出力子って書いてあるから、だから両方できるわ。
うんうん。あ、そうだね、なんかいいなみたいな。
そう、このMilesも結構いろいろできるんじゃないかと。
だからなんか脆弱性管理ツールみたいなコンテキストにおいては結構Sボムのサポートっていうのは多いんじゃないかなと思うんだけど。
うんうん。
共通フォーマットだもんな。
じゃあ、第20回はSボム記念会ってことで。
いやいや。
やっせきずりで喋っちゃったな。
速攻終わりそう。
どうせ忘れてるんだよな、来週までに。
まあね。
ちょっとこのデータベースに後で触るチェックリストつけとこう。
うん。確かにずっと後でやりたい企画リストの方が欲しい気がするけど。
あー企画。まあね、両方じゃあ作ろう。
後で。
ありがとうございます。
この統合されたらますますオールインワンで便利になるのか、
まあ使ってみてやな、手触り次第ですね。
はい、じゃあ次行きますか。
行きましょう。
クッキーセキュリティの重要性
クッキーセフト対策とデバイスバウンドセッションクレデンシャルズ。
Jackさんのブログですね。
どう説明しよう。
DBSC、デバイスバウンドセッションクレデンシャルズについての
解説記事というか紹介記事で
全部を紹介すると若干長くなっちゃう気がするんだけど、
割とクッキーを盗む方向に攻撃者のアクティビティーが
シフトしてきてるよねっていう前提がある中で
クッキーをどう守るかみたいな部分。
クッキーそのものを守るっていうのもそうなんだけど
盗まれたクッキーが全然違うところで使われるのを防ごう
みたいなアプローチもあるよっていうので
このDBSCっていうのを紹介してくれてるっていう感じでございますね。
で、直近のChrome拡張のインシデントっていうか
めっちゃ盗られたみたいなやつとかも踏まえた
アンサー記事になってるのかなと思っていて
割とこの辺が効いてくるんだろうなという。
ていうか当然こういうのがないと
クッキーそのものはもう守りきれないものではあるから
早く来てほしいなっていう感じではありますね。
なんかあと気になったとこで言うと
例えばChromeは様々なデータをローカルの
エスキューライトに保存することが多いが
クッキーに関してはMacのキーチェーン、LinuxのKボレットなど
アプリからしかアクセスできない安全な領域に保存しているって
さらっと書いてくれてるんだけど
この辺どうやって調べてというかどう知識として
自分の中にストックしてるのかなみたいなのがちょっと気になった。
確かにね。
Chromeは自分でもコントリビュートしたみたいなことを
いつかの記事で紹介してたから
そういうところから仕入れてるのかもしれないんだけど
多分Jackさん自体5年10年単位とかで
Webのアップデートをひたすら追い続けてるから
それで知ってるっていうのは普通にありそうな気がする。
なんならこの前の
Windowsでこれができた、今マスに書いてあげたものができてないって話は
俺はJackさんのポッドキャストから聞いたから
一時操作できた人なのかなって気がする。
すごい。あとは
OSでも結構似たような仕組みがあって
あるよなーって思って読み進めてたんだけど
まさに触れていてDepopとかMTLSみたいな仕組みで
Proof of Possessionを実現してるよっていう話で
これも類似のパターンとしては同じような
仕様だよっていうアプローチだよっていうような
話ですね。
結構いろいろ他のアイディアとかも交えて紹介してくれてるので
かなり興味深くてぜひ読んでみてほしいなっていう
感じですね。
あとはWindows11からTPMを持つことが必須になるってさらっと書いてあって
これも知らなかった。読み進めていく中で
AppleのデバイスはShare Enclaveがあるけど他はどうするんだろうなみたいな
ちょっと思ってたらその辺も書いてくれてて
至れり尽くせに先回りされてる感じが
心地よい記事でした。
主題の話の主の部分はもちろんだけど
これが必要な背景とかもめちゃくちゃ必要十分な
情報があるなと思って
みんな読んでほしいなって思いました。
全体的にこの仕様自体は
良さそうだなと思うんだけどセキュリティ管理者として見たときに
どれだけ普及するかが次の課題のはずで
結局これがどこでも使われてませんってなると
全然その恩恵を受けられないというか
有名どころはやっていくんだろうけど有名どころとかそういうところに
敏感なところ例えば
IDプロバイダーのサービスを提供しているようなところとか
そういうところはやるんだろうなって思うんだけどね。
その辺は多分他のいろんなWebの仕様と同じで
フィールドバックループを回して確定するのかしないのかっていう
そういうと各ブラウザのリアクションが
どうなるかはちょっとポジに
状況としてはChromeが先行して実装してって感じになるのかな
どうなんでしょうスタンドポジション
そうなりそうな気はするけどね
出どころがどこなのかというと
Chromeチームより提案って書いてあるからそうだね
もうFlag付きで試すことができるって書いてあるし
でも欲しいっすよね
欲しいし何かの交互感性を壊すような仕組みではないとは思うから
あまりに疲れてなかったら意味ないようになると思うけど
どうなんでしょう世の事業者はどれくらい
ここの領域に関心を払えてるんだろうな
いやー
これはさあでもなあそうね
払ってほしいけどね
っていうかその構図としては
パスキーと一緒でさ
ユーザーサイドでできることがないわけだから
サービス提供側がやらなきゃダメなやつだよね
これもね
現実的にはリスクの高い事業から順々に提供されてって
それがどこまで広がりきるのかって感じなのかな
バカすかフィッシングやられたり
インフォそうだな
インフォスティアって何を抜かれてるかとかまあでも等しく全部抜いてるんだろうな
なんかその辺の話は個人のアカウント云々関連みたいな
今日別の記事であったよね確かね
そうなんです実は
そんな感じの記事でしたこれは普通に良かったので
普通に良くなかったら紹介しないんだけど
結構僕も
ここ最近かなり面白いというか勉強になった
ありがとうございます
じゃあ次いきますか
お願いします
Googleソースフローの登場
Googleソースフローっていう
僕の大好きトリュフフォグのブログですね
結構物議を醸すというか
なんかマウントじゃないですか僕は話題になる前に読んでて
これ読みたいなって思ってたら話題になってて
トリュフフォーがファンとして
まあそれと同じですけど
YDC認証の脆弱性
どういう記事かというとですね
タイトルはちょっと過激なんですけど特定の条件下において
それでログインみたいな
YDC認証をサポートしてるサービスのアカウントを
特定の条件下で乗っ取れますよっていうその条件に当てはまる
アカウントっていうのがめちゃくちゃたくさんあるよっていう話で
じゃあその条件とは何かっていうと
まず例えばどっかの事業者がGoogleワークスペース契約して
自社のドメインで
何かのSaaSに契約してそうなるとそこの従業員は
弊社とかだったら.x.co.jpっていうドメインがあるんですけど
そのドメインでアカウントを一緒に登録してっていう風に
利用すると思うんですけど
会社が例えばなんか事業うまくいかなくて会社畳みましたとか
社名を変更してドメインを変えて
古い名を手放しちゃいましたっていうケースの時に
Google側のアカウントは当然向こうには
なるんですけど じゃあその手放された
Googleアカウントのドメインに対して別の人が
ドメイン取り直してそれでもう一回Googleワークスペース契約して
アカウントを作った時にそのオース認証が
Eメールアドレスが同名であれば通っちゃうよっていうのが
この記事が言ってることですと
実際に何個か検証してみたよって言って これが有効であること分かってるよって話と
何で有効になってしまうのかみたいな部分で言うと
本来はそのYDストークンで
そのアカウントの
IDというかその1位の値を
比較してリッチしなければ弾くっていう処理をやるべきで
基本的にはそのJotにあるサブの値を
使って比較するのがやるべきことなんだけども
このサブの値が
さっき言ったそのアカウントがあって
解約して別の人が同じアカウントを作るってパターンの時に
サブが変わんないっていう仕様があるっていう
あるらしいっていうのがこの記事で触れられていて
リリースしちゃうよねって話と
あとはちょっと覚えてないけど
多分
現役実際にあったかな そもそもサブを見ずに実装しちゃってるパターンがあったら
ダメだよねって話もある気がしてて これは正直どうしようもないというか
サービスプロバイダーがちゃんとやるかやらないかみたいな感じに
なっちゃうと思うんですけど
これ自体はGoogleに報告してて
脆弱性として報告したんだけど
最初はこれは使用ですってなったんだけど
しばらくしてやっぱ脆弱性だから直そうって感じなのと
データ漏洩事件の分析
その報償金みたいなのを多分トリフォームの報告者に支払って
修正してるっていう話があるので
何かしらの対応がされるだろうっていうような
サブは変わらないっていう話なの?
変わるって話じゃなかったっけ?
変わらないって話じゃないかな
サブが変わらないからアカウントの
1回消えて復活したアカウントなのにその区別が付けられないって話
だと理解してたけど
サブが
変わらないっていう話なのかな
ちょっとどっちとも読めたりそうな気がするよくわからん
それでも1回
違うか 変わるって話か
そうだよね たまに変わるから使えないって話じゃないかなと思ってたんだけど
大変失礼しました そうでした そうかそうか
別に普通に使い続けてるのに変わっちゃうから
それを比較してサービスプロバイダーが実装できないから
サブ以外のお手に頼らざるを得なくて
それが制作性というか
今回の事象に繋がっちゃうよって話か
でも0.04%だったとしてみんなそんな気にしてんのかな
気づいてあえてサブを使わないっていう選択をしてる人たちがどれだけいるのかちょっと気になるな
それで言うと
トリフォグの記事だと多分結構かなり断片的というか
某テックカンパニーによると0.04%ぐらい変わっちゃうけど
その顧客の割合は数字にするとちっちゃくないから
使えないんだよって言ってますみたいなこと言ってるけど
一企業の一意見だしトリフォグのフィルターを通してるんで
ここはなんかちょっと本当に0.04%なのかとかは全然わからない
全然わかんないよね
合わせて4体に書いてくれてて
役者が記事を貼ってくれてて
リトーさんのねGoogleのID特有のサブの値が変わるって本当?
っていう記事を書いてくれてて
Googleの見解じゃないからわかんないねっていう結びをする
あり得ないでしょっていう
まあわかんないよな
Googleの回答待ちにしかない
自分で検証するぐらいしかやれることない気がするけど
0.04%でしょ
バグとかなんだとしたら結構
ちょっと当たりやすい宝くじぐらいの感じで頑張って試さないと
わかんなそうではない
どういう実装したら変わるの?
そうだね
内部的に1ユーザーに紐づくレコードが複数あるとか
そういうレベルじゃない?
それすらさすがにないでしょって思うんだけど
あとなんかわかんないけどエイリアスが悪さしてるとか
プラスつけて
いやわかんねえな
わかんないね
2024年の12月19日にやっぱ問題だからやるねって
Googleから言ってるんで
今ちょうど1ヶ月ぐらいだから
もう治ってるかもしれない
あと1ヶ月2ヶ月とかでもしかしたら
トリフォームの方から出たりするかもね
Googleでサブクレームが変わるみたいなところは
Googleでなんとかできるけど
Eメールアドレスの方参照してるのは別にGoogle関係ないわけだから
残り続けるわけでしょ
どうすんだろうね
しかもGoogle側からはわかんないじゃん
中身を変えるとかをすれば根本的にGoogle側で解決できる可能性はあるけれども
要は
オーガニゼーションの持ち主が変わった時に
メールアドレス出して入ってくるものが変わるみたいなことをやればね
Google側でなんとかできる余地はあるけど
もしくはもう1回廃止されたドメインの
いやでもな
あるというか可能性としてはなくはないよね
いやーきつくね
僕らから見えないじゃんサービスプロバイダーがちゃんと実装してるの
ちょっと気になったのは
実際どういう問題につながるのかはあんまり思いをはせられてなくて
言うても会社を畳んでるパターンとかの場合は
畳んだ会社のアカウントに入って何ができるかみたいな
何が残ってるか次第じゃない
いやーわかんねえな
無料のサービスとかを黙って使ってましたみたいなのは普通にあり得ると思うし
例えばなんか
スラックのワークスペースとかだったら会社畳んでたらさすがに解約してると思うから
データは丸ごと消えてるよねっていうのはなんとなく言えそうな気がする
オフィシャルに使っててお金払ってるものは
割とそういうケースが多いんじゃないかなと思う一方で
そうじゃないものは多分いっぱいあるし
いっぱいあるしっていうか普通にあり得るよねと思うし
スラックもワンチャン冷静スタートアップで
課金せずに使って終わってとか
その場合でも日数のあれがあるから今スラックの場合は
でもあれ課金したら取り戻せるでしょ
全履歴を抜いてお宝はないかなって
探すとかはできるかもしれない
やられたら嫌すぎるけどなんか畳んだ会社の
に対して攻撃成立されちゃいました
誰も何も
できないよね
何なら気づけないまであるよね
何が起きるか次第なのかな
何が起きるか次第かな
誰が何をすんのって本当にその通りで
嫌すぎるな
ワンパスとかで残ってて個人アカウント突っ込んじゃって侵害されるとか
まだ解約してないクレカ
まあでも結構どうだろうな
具体的にどこまで何ができるか本当に分かんないな
意外となんか難しい気もする
入られるサービスによるかな正直
またそのドメイン変更して捨てちゃったパターンとかは普通に怖いかなって
ありそう
収穫問題の一つとして捉えてもいいのかもなもしかしたら
こんなんもうずっと持ってるしかないじゃん
消しに行くほうが絶対早いはずで
ドメインっていうよりは
あれかなGoogleの場合はGoogleバックスペースで
各々が多数認識が一覧で
リボークもできるから
それ全部リボークしちゃえば
リボークしてもデータは残ってるんじゃないの
そうそうそう
いやだな
結構しんどいよこれ
セキュリティ管理をする側っていうよりは
一ユーザーとして嫌だなって感じする
こんなさ会社畳むなんて
最悪の気分の時にこんなこと考えなきゃいけないって言われたもん
普通考えないだろうなそれどころじゃないだろうし
自分のデータがどこに渡ってどう
どういうハンドリングを経てどこに置かれてるのかって
本当に切実に知りたいよね
それが把握できてないと自衛の手段もないわけでこれに関しては
ないですね
治うな話題だな
インテグレーション
サブ使わずにっていう実装に関してはGoogleに限らないわけでもありますしね
Google以外が後からアカウントを取り得るシナリオがあるのかちょっとよくわかんないけど
Googleじゃなくてもっていうのはあるし
だからそれで言うと
サブクレームが変わるよっていうのが事実だとして
一定Googleの責任でそれが起きてるっていうのはあるんだろうけど
まあまあその
サブクレームじゃないところを使っちゃうみたいなのは確かに他でも起こりうるというか
いやーなかなか
確かにないやー悩ましいな楽しいけどまあまあ
会社畳むことを想定して起きたくはないけど
まあでもなんかそうだねちゃんと把握しといた方がいいだろうね
そもそも危ないものに関しては少なくとも
はい
そんな感じでございます
じゃあ次いきますかお願いします
次は私で
なんて読むのかなちょっとわかんないですけど
ホテリアデータブリーチエキスポーシーインフォホテルリゾベーションズオブミリオンズっていう
ブリビンコンピューターの記事ですね
これはそんなに特別ではなくてですね
ホテイラーっていうこれは多分ホテル予約サイトとかなのかな
海外のサービスかなんかだと思うんですけど
そこがサイバー攻撃を受けて数百万人の宿泊客の
個人情報やら予約情報が漏えいしちゃいましたっていう話ですね
でなんでまあまあ言っちゃえばあるある事件ではあるんですけど
取り上げた理由が
このやられた経路が
なるほどって感じで取り入れたんですけど
実際に事故で何が起きたかっていうと
データ自体はAmazon S3に置いてたんですけど
そこから8TBのデータが盗まれちゃいました
って話で
じゃあこれなんでそのS3へのアクセス権が取られたかっていうと
最初はフィッシングだったかな
フィッシングにまず従業員が引っかかっちゃって
何かしらのアカウントが取られました
取られた後に横展開なりもしかして一発でそこにたどり着いたかもしれないんですけど
アトラシアンかな
アトラシアンのアカウントを取られちゃいましたと
アトラシアンのアカウントを取られた後にアトランシアのどっちかはちょっと名言がなかったんですけど
おそらくジラかコンフレンスか
ナレッジを貯めておくようなサービスから
サービスに対してそのアカウントを使ってひたすらクローリングでデータを引っこ抜かれていて
その中にS3へのアクセス情報が入ってたので
そこから侵害されちゃいましたようなのが
この記事では書かれているという感じです
取り上げた理由としては
これなんかありそうって思ったっていう
ただそれだけなんですけど
セキュリティのプラクティスとしては
それこそ個人情報が入っているS3へのアクセスキーなんて
ちゃんと管理した方がいいよねとかローテした方がいいよねとか
シークレットマネージャー以外に入れちゃダメですよとか
そういうのを徹底すべきだしやるべきなんだけど
それが生き届かなかったことで
攻撃者目線ではかなりおいしいというか
セキュリティ管理の重要性
楽っていう言い方があるんですけど
技術書を読む意義
ジラ死ぬようにできたら8テラの個人情報にたどり着けちゃいました
という状況に陥っているというのは普通に怖いなというか
対策としては基本的なことを
やり直したいというか
対策としては基本的なことをひたすら一個一個やりましょうなんですけど
一方でちゃんとこういう攻撃もない
現実世界に起きるよねっていうのは
胸に刻みたいなと思って取り上げた次第でございます
きついね
これこそ
モーラ的に自動化というか
人用でカバー以上のことをしましょうってなると
多分トリュフホグとかを契約して
ギッタブも全部スキャンするしスラックも全部スキャンするよとか
そういうツールっていうサービスって結構あるんですけど
めちゃくちゃ高いんで
ジラとかどうなんだろうな
今しゃべりながら思ったけどジラ側の権限制御がガバガバで
そもそも何もかんでも抜けるのがダメだったよねって話ももしかしたら内部的にあったのかもしれないし
でもなんかジラはオープンだと惜しいけどな
社内においては
どっちかっていうと
アクセスの方を検知するべきだったんじゃないかなと思うんだけどな
S3でそれができるかどうかちょっと分かんないんだけど
S3に対する8ちゃんを抜かれる前にってこと
それなりに時間かかるでしょだって8ジラって
そうだね
AWS自体にはそういうソリューションがあるはずだから多分できるはずではあるよね
確かにねその辺はできたのにやってたのに
運用が軽快化してたのかやってなかったのかみたいなところは
気になるかもね
どこで気づけたかというと気づけたであろうポイントは確かにいっぱいあるけど
入ってるデータの重要度的には少なくともS3のレイヤーでは
何かあったらとりあえずアラートが上がる
みたいな仕組みはあるべきだったんだろうな
なんか容力というか体力があるんだったらジラ側も
Cancelog CMに加わせてとかやったらもしかしたらスクレーピングのやり方によっては
スクレーピングは確かに見つけられたかもね
これもなんか分かんないけど
攻撃自体があれかデータ侵害は
2024年7月に発生して10月まで続いたって書いてあるから
それを思うともっと早く気づけたんじゃないのっていうふうに
理由があり得るかもね
ごめんなさいフィッシングじゃなかったですインフォスティーラーだ
いやーこれは
うーん
やだよねー
脊髄反射感があるけどまあいやですね
でも言ってる通りで
普通に基本的な対策でっていう話あるんだけど
なんて言ったらいいんだろうな
これがじゃあどこでもできますかって聞かれたときに
できないってことあるだろうなとは思う
さっきのジラはオープンであって車内にはオープンであってほしいなみたいな話とかさ
できることできないことがきっと会社によって
変わってくるわけで
多重防御みたいなのをすごく組みにくいなっていう気はした
密着屋で守らざるを得ないような感触
確かにね
難しいな
ロボテめっちゃ頑張ればいいんじゃないかとか色々考えたけど結局
タイミングが噛み合えば成立するだろうし
最新の技術に対する興味
3ヶ月続いたのがやっぱあれかもな
少なくとも
S3
でもS3でしょ
いやー
ジラなりコンフルなり見れば
ジラなりコンフルなりを見れば誰でも
少なくとも車内にいる人あるいは車内に侵入できた人が
落とせてしまうっていうのは個人情報管理みたいな観点でいくと
多分NGでやっぱりそもそも論
そこがちょっと一段
なんていうかきっちり締めとくだけでも締められているだけでも
確かにね
少し難易度上がったんじゃないかなとは思うんだけど
元のインシデントレポートだったらちゃんと読もう
載せてたのもあれだもんね
ミスって載せたのか意図的に載せたのかで結構話変わってくるよね
意図的に載せたパターンだったら上手いってくれた
というかポリシーなり
ある程度締めるというか個人情報管理の文脈で
締めるっていうのができる気もするし
もう一個元ソースを追いに
でもそれで言うとなんか
S3の権限制御がどうなっているのか
わかんないな
それでもアクセスできるっていうのがそもそもNGだよねみたいな話は多分あるはずで
何かが揃ってしまえば
確かにね
必要なときにテンポラリーでアクセス権限が降ってきてみたいな仕組みとかがあるだけで
そこは変わるはずだから
GCSとかだったらできるはずじゃん
だからAWSもできるんだろうなと思ったけど
他人事とは思えないなっていう記事でした
ありがとうございます
じゃあ次お願いします
え 私 いいけど
まあいいや
オンとシェア書いてるの俺だけなのか 本当だ
iOSでGoogleパスワードマネージャーのパスキーを利用できるようになりました
AWSのブログの記事ですね
それ以上正直何もなくて
良かったですねっていう話でしかないんですけど
これ結構出遅れると他のプラットフォームの
パスワードマネージャーが派遣を握れなくなるから
Google順調だなって思いながら見てる
確かにね
エンドユーザーはどんぐらい気にしてるんだろうね
エンドユーザーはどんだけ気にしてるか問題もそうだけど
Appleの人たちはほぼAppleのデバイスしか使ってないとかそういうのもあったりするのかなっていう気もするし
めっちゃめでたいっていう気持ちと
確かにね
あとGoogleパスワードマネージャーのPINはいいですね
PINのリカバリーの話が
分かんないねってサマリーで書いてくれてるんだけど
そうだねそういえばって思ってそれもちょっと
知らんってGoogleパスワードマネージャーのPIN紛失してみた
いやすぎる
結構スクラップ向きの記事な気がするな
何が起きてるか
絶対めんどくさいからやめたほうがいいよ
絶対めんどくさい
捨て垢作ってやるか
アカウント自体のバックアップみたいな概念あるじゃん
Googleアカウントそのデュアバウンドとかサブアドレスとか
もしかしてあの辺とか分かんない複数の要素である程度の強度で
壁を突破できればとか
あるのかな
もう点というかなんか実際そこまで普段の生活で
やる気にならんのよねちょっとどうなってんのかなって確認するのはなかなか難しい
ところだよね
まあまあまあそんな感じの記事でございました
順調にそのパスキーの障壁みたいなところが
低くなってきてるのかなとは思うから
そうだね
このここに書いてあるプラットフォームWindows Mac OS
iOS Android Linux Chrome OS
なんか全部手元に並べて使ってみたいな
いや分かんないけどさ絶対さサポートしてるけど
実務に役立つ内容
なんかシームレスに何もつまずくことなく
使えるかどうかまた別な気はしていて
なんかそれはなんかChromeのChrome違うChromeかGoogle Password Manager
の作りの面もあるっちゃあるけどそのOS
それぞれの制約によるところとかは安定してて
ワンパスとか僕はワンパス使ってるんですけどAndroidとiOS
全然なんというか設定が違うというか
Chrome OSはまあなんか普通に
かなり統合されてそうだからあれだけど
LinuxとWindowsとかそんな変わらんやろって思うしな
iOS Androidの差は結構大きいと思うんだよね
多分だけどね
結構違う気がするなんか根本の仕組みが違いそうだなと思いながら
触ってるわ
そんな感じのめでたい記事でございました
出てくれないと気がめいちゃうんでお願いします
次がBring your own container
Turn the key to EDR bypassっていう
AbyTokyo2024の発表のスライドですねちょっと遅れて公開したよって
発表した人が
どこかに書いてて
割とサイレントにすって公開してる感じで
ここで紹介しちゃっていいのか分からないけど誰も聞いてないだろうの
精神で紹介しちゃうけど良かったんで
紹介したいなと思いました
EDR Bypassのテクニックについて紹介していて
メインカテゴリが4つあるよっていう話そもそもEDRに
トラフィックを見せないだとか正規署名で動くアプリケーションを使うだとか
EDRのプロセス自体を発掘して
検知を避けるとか
4つ目が見えないところで動かすっていうのがあるんですが
見えないところで動かすっていうカテゴリのテクニックとして
ちょっと新しいトレンドなのかが何とも言えないんですけど
どっかコンテナを用いるものでBIOC Bring Your Own Container
っていうのを紹介している発表です
基本的にEDRはコンテナの中のアクティビティを見ることができないので
その前提においてコンテナにどう
データを持ち込むかコンテナからどう持ち出すかみたいなところを
紹介してくれているスライドというか発表でした
コンテナの制約としてそもそも
コンテナ側からホスト側を完全に自由に動向できるわけではないので
あくまでファイルシステム経由で
コンテナ側に持ってきたファイルを動向できるっていうただそれだけ
だったりとか あとはそもそもDockerが必要だけど
Dockerを使ってない環境でDockerを入れて動かすっていうところまでのハードルが
結構高いよねみたいな話とかが
不都合な点として挙げられていて
Mac OSだとDockerを持ち込めても
特定フォルダへのアクセスをOS側の機能でブロックされたりする
例えばダウンロードとかでこのアプリケーションに
このフォルダにアクセスさせていいですかっていう
モダルダイアログが出てくると思うんですけど
ああいうのでブロックされたりするので
そこがバイパスできないっていうかそこがそもそもパーミッションついてない状態なら
アクセスできるところのファイルを持ってくる必要がある
要はアクセスできるところに欲しいファイルを置かないといけないし
みたいな話とかが不都合な点として紹介されてました
ちょっとトレンドがこれがめちゃくちゃ最近
トレンドですよっていう話の中はちょっとよくわかんないんだけど
なるほどなっていうので要をまとまってるというか
結構綺麗にまとめきってる発表のスライドで
すごくよかったなと思って持ってきました
ありがとうございます なるほどって感じ この4つの手法
なるほどね 逆に言うとこの4つで整理しきれるんですね
まあでもそうか 見せない
見せないっていうのが面白い 多分その中でかなり細分化されると思うんだけど
やり方とか 今までインプットした
多くない知識のものを思い出す
確かにこの4つに大体頭があるなっていう気がするんで結構面白い
他はね どこまでできるんだろうな
でもファイルさえマウントしちゃえば外部通信で抜き出すとかぐらいはできるだろうし
潜伏もできるのかな
っていうか何してるかわからんのと
特定のディレクトリとかをどっかコンテナ側にマウントするみたいなことをやること自体は
そんなに不審じゃない
そうだね 一方でその不審じゃないアクティビティの後に
コンテナの中で何をしてるかわからないっていう
EDRでどこを引っ掛けるか次第だと思うんですけど
どっかのコンテナを動かしてディレクトリをマウントしましたみたいなところで引っ掛けるんだったら
確かに検知はできるだろうけど
それだけでちゃんと反応できるかっていうと結構難しい側面があると思うし
十分機能するんだろうなとは思う
どっかコンテナの中のアクティビティ
見れてないのか見ることができないのかっていうとどっち?
できないんじゃないかな
どっかAPIとかで
やろうと思えばできなくない気がするけどね
ちょっと思い出せないな
技術的には可能って感じだと思うけど
確かにその類も
コンテナセキュリティ本でその辺の言及があったっけなっていうのは
マルウェアの脅威
すごい今ちょっと思い出してるんですけど
結局その中で動いてるのが何なのかとかも多分分かんないと思うし
OSレイヤーでね
でもその実態はプロセスのはずだから
OSによるんだろうな
Linuxとかだと
サンドボックス切られちゃってるんだ
分かんねー
WindowsとMacOSはマジで分かんないんですよね
どうなってんだ
知りたいな
読んでおきます
WindowsとMacは内部的には
Macの方はVMでしょ
なるほど
分かんないけど
全然分かんない
どっかMac
そうそう
Macは裏で
Linuxの仮想マシンが動いていて
じゃあ確かに見えなそうね
いやー面白いな
面白いな
なんかこういう
時代が進むについて出てきた便利なものに
きちんと乗っかって悪用される感じがすごい個人的に
面白いなって思います
なんていうか
いやでも
その
不正義タイガーからするとたまったもんじゃないんだけど
まあね
それは本当にそう
なんかその
でもなんか
いやーこれの繰り返しなんだろうな
僕が開発者目線だとやっぱ
パラダイムシフトだし
便利じゃんってなって
前の目でやっぱキャッチアップして
まあこういう側面もある
うん
この1年ぐらいでだんだん分かってきたんで
まあいろいろな話とかもそうだと思うんですけど
おもろい
はい
まあおもろいねという話でした
ありがとうございます
じゃあ次はお願いします
はい
Pythonベースのマルウェア
ノードスティーラーが
Facebook広告マネージャーから情報接種
トレンドマイクロのブログ
記事の内容自体は
このタイトルにある
ノードスティーラーってマルウェアに関して
結構細かく
どっから巻いてどういう挙動をして
どんな動きをするのかっていうのを
かなり詳しく書いてあるんですけど
まあその辺はなんか今回は
ちょっと省略というか気になる方は
読んでいただいてって感じで
触れたかったのが
今日の序盤で話した
インフォスティーラーの話とも繋がるし
前回の以前
Chrome Extensionの大規模な侵害キャンペーンが
ありましたっていうところで
Facebookの広告アカウントを
狙ってきたっていうのが
サイバーヘイブンのレポートから出てた
と思うんですけどそれがこの記事と
ちょうど繋がったんで障害したいなと思っていて
結論から言うと
これFacebook
広告マネージャーを狙ってる
マネージャーなんだけどなぜこれを狙うか
っていうと
Facebook
読んじゃうとFacebookやInstagram
メッセンジャー オーディエンスネットワークなどの
各種プラットフォーム間で
広告キャンペーンを
作成 管理する
管理 分析するツールであり
個人または企業の間で
広く利用されていて
なんで ゆえに
結構個人情報とかビジネス情報を
盗む格好の標的と
見なされていて標的に狙われ続けてます
っていうことが書いてあって
なんというか確かに
大量に個人情報を
仕入れたいってなった時に
1000人仕入れたいってなった時に
1000アカウント盗むより
Facebookの広告マネージャーのアカウント
1個盗めば
ログインしたことないで
返そうと低いんで
実際と違ったらごめんなさいなんですけど
ターゲティングする相手とか
引っかかった人たちとか
なんか結構
1アカウントから大量の情報を抜けるんだろうな
っていうことを
思っていて なんで
それでゆえに狙われてるのかっていうのが
ちょっと繋がったんで紹介
させてもらいました
なるほどね こっからなんか
フィッシング広告打ったりとかするのかな
あーなんか
それも別の記事に
書いてあった そうなんだ
やるよね
フリーライトして
乗っかってっていうのもあったね
なんかいろんな面で
美味しいんだろうね
多めの情報も抜けるし
ただで広告も打てるし
そっからまたイモズルで
引っ張れるしみたいな感じ
なるほどなっていう
結構その
いやーそういう意味では
どの会社も多分
広告じゃなくても
弊社もある通過
広告運用するじゃないですか
事業会社だったら
ってことは広告は管理アカウントだって
それは狙われてるよっていう認識が結構
強めに持ってもいいな
と思いましたね
明日チームの朝会で話そうって
話そうって思った
そうですね
あれってなんかこの広告マネージャーって
個人のアカウントにひもついてるのか
そっち側の仕組みは
自分で触ってないから
全然想像がつかないな
企業アカウントがあって
企業の管理者アカウントみたいなのは
個人のアカウントになってるのかな
多分なんかロールみたいなのが
振れるんじゃないかな
多分ですけど
分かんねえな
これはむずいね
なんか
取られる前に
1%結構
結構なんか
最近仕事で
ワンパスワードの棚下ろしっていう
すごい弊社用語で言うと
ゴリラワークというかただただ
やるっていう仕事を
筋肉
筋肉で解決っていう
やってるんですけど
結構思うのが
いろんなコンテキストで
あらゆるサービスを会社全体で
見ると本当に利用していて
それを全部把握しきるのって
多分
管理はできても多分
把握は無理というか1人が全部理解するのは
まずほぼ不可能だし
変化し得るじゃないですか
なので不可能なのと
その前提に立つと
何でしょうね
全部を結構十分な時間をかけて
リスク評価していくっていうのも
難しいよなっていうのは
思っていて
やるべきなのかもしれないですけど
何でしょうね
例えば
今回の例だったら
Facebook広告アカウントみたいなのが
うち契約してますねってなった時に
ここには
でもやるべきなのかな
もともと言おうとした
ことに対して
自分で自己解決してしまった感があるかも
言いたかったのは
こういうトレンドを掴んどくと
優先順位とかをつける時に
すごくいい材料になるっていう意味では
トレンドインプットするのって
大事だよねっていう風に
思ったんですけど
自社の資産の一つである
このFacebook広告マネージャーに
じゃあ個人情報ってどのくらいあるんですか
みたいな観点にきちんと立てれば
自らちゃんと管理もするか
っていう風に今
自己解決した感じです
Facebook広告マネージャーのリスク
資産管理の文脈に
どう絡めて
ちゃんと管理できるかみたいな
いやーできるか
インスタのアカウント
まあでもCRMツールとかは当然
入るよねっていう話だから
当然そこも入るよねっていうのを
まあ
なんていうか
ふわっとした言葉で言うならばちゃんとしなきゃいけないんだろうね
そうだね
別に把握はしなくてもいいけど
抑えるべきポイントは抑えるべきだろうな
個人情報あるんですか
あるんですかとか
つながったと思ったので
紹介させてもらいました
やったね
5ヶ月の成果です
じゃあ次は
Windows 10
KB5049981
Windowsの脆弱性対策
Update list with new
BeWellVD
ブロックリストっていう
ブリングコンピューターの記事です
これは何かって言うと
ブリング用シリーズって感じなんですけど
Bring your own
バラネロ
ドライバー
BYOVD攻撃を
防ぐために
Windowsからパッチが出たよっていう
記事です
そのパッチの内容自体は
なんていうか
攻撃を防ぐための内容って感じなんですけど
これを僕は結構
知らなかったんで
紹介させてもらったって感じで
そもそもこの
Bring your own
バラネロドライバー攻撃が
何かって言うと
頑張って
正しく説明することを
ここにあるんですけど
Windowsの仕組みとして
ドライ
いや ちょっとちゃんと読み直すか
ドライバー
っていうのがあるのかな
ドライバーっていうのがあるね
そうですね
ドライバーっていうものが
ちなみに耳寄り情報なんだけど
さっきの
BYOCの資料でも
実は紹介していて
18ページなんだけど
それ読めば実は
パッと
読む文章量としては
少なくなる気がする
なるほどね
そうですね
ドライバーっていうのが
ドライバーっていうソフトウェアがあって
これ自体は
OSに対してかなり
強い権限を持ってるもので
Windowsで組み込みで入ってる
なんでその正規のソフトウェア
で
これを
使った攻撃っていうのは
このドライバーに脆弱性が
あることがありますと
普通にCVが裁判されるようなことがあって
そうなると
攻撃者がそこにアクセスできたときに
Windowsはその攻撃を
検知
しづらいっていう話があってなぜなら
Windowsに組み込まれた正規の
きちんと証明がされたソフトウェアなので
それを介した操作
っていうのを
異常じゃないですけど
それすなわち攻撃されたって検知できない
もしくはされづらいっていうので
活用するっていう攻撃
確かにこのスライドが素晴らしい
かつこのドライバー自体は
Ring0っていう
これはもう多分Windows用語なんだろうな
と思いながらちょっとざっと理解して
読み下したんですけど
権限
最高権限で
いろんなセキュリティ機構をバイパスできる
っていうところで
攻撃者的にはおいしいっていうことです
なんで
今回のこの記事のアップデート
っていうのは
基地の動いてるドライバー
のうち脆弱性が
見つかったものがあってそれを
実行禁止リストみたいなものが
おそらくWindowsの中にあるんで
それに加えてアップデートしたよ
っていうのがやったこと
です
なんで結構
なんかシンプルに
攻撃も知らなかったしWindowsでそういう概念が
あるのも知らなかったし
なんていうかちょっと面白いのは
じゃないですけど
自社っていうか自分たちで組み込んだものを
自分たちでブラックリストに入れて
動かなくするっていう
そんな仕組みがあって
紹介したって感じです
これ自体の脆弱性はなんで修正できないんだろうね
今ふと思ったけど
どういうこと?修正はしたんでしょう
古いやつを持ってきてるから
いや
古いやつを
ブロックして新しいのを
入れてるって感じ
その
その記事の内容的には
その
Kernelドライバーの
ドライバーのブラックリストみたいなのがあるんですよ
そのブラックリストに
脆弱性があるよってなった
ドライバーを入れましたっていう
アップデートになってて
脆弱性のあるドライバーの
脆弱性を
脆弱性が発見されたドライバーに
パッチを当ててリリースしてよって
内容ではないんです
脆弱性とその対策
それはだからとっくに終わっててっていう話だと
理解したけどね
あーなるほど
そうそう
その上で過去に出ていた
脆弱なドライバー
あーそっかそっか
それがだからそこでロードされないように
そうだねそうだね
失礼しました
完全に思い出しました
そうですね
ブラックリストは意味がありますね
うん
勉強になりましたって感じでした
さっきのセラもちゃんと読もう
なんかもうちょい上手い方法ないのかな
と思うんだけど
なんかでも普通に動かなくなっちゃう
関係あるんだろうな
もうちょい上手い方法みたいなのを考えたとき
うーんそうですね
この記事でもなんか
OpenSSHが動かなくなったよみたいな
うん
報告されてたりするらしくて
要はアップデートしてない環境みたいなのがあったときに
アップデートに追従してない環境みたいなのがあったときに
もうちょっと上手い方法っていうのは
このWindowsアップデートに入れなきゃいけないって
結構重いなって思って
うーん
なんかもうちょっとリアルタイムに
ある種のCRL的な
サーティフィケットリボケーションリストみたいな
なんかあるんだけど
証明書がもうこいつ死んでるよ
っていうリストがあったりするんだけど
あとはなんだっけ
えっと
えっと
OCSPか
みたいな
オンラインサーティフィケットステータスプロトコルってやつで
公開下議員の証明書の執行状態を取得する
プロトコルなんだけど
なんかその要は
えっと
そのステータス自体が
証明書のステータス自体が
そのCRLとか
OCSPで
なんていうかある程度リアルタイムに
あの
伝播していくというか
それぞれその要は
こういったCRL入ってるから
バリッドなものを見なきゃダメだみたいな判断を
それぞれの環境でしてくれるんだけど
なんか
Windowsアップデートに入れずとも
それができたらいいんじゃないって一瞬思ったんだけど
なんか
うーんって思って
どうなのかなって
ただその
なんて言ったらいいんだろう
その脆弱なドライバーにパッチを当てたバージョンと
今回出したものの間に
どれくらいの開きがあるかにもよるから
そうだね
要は
これがパッチを当てると同時に
ブロックリストにも追加しているよって話だったら
えっと
そのOCSPなり
CRL的な仕組み
全然多分それは
それをそのまま使うと色々問題が起こるので
なんか多分ダメなんだけど
そういう仕組みで
Windowsアップデートなしにリアルタイムドライバーがブロックされる
みたいな状況になったとて
どっちにしろ
それが有効な環境には
そもそもパッチが当たってないから
別に持ってくるまでもなく
動いている脆弱なものが動いているみたいな
状況になっちゃって
あんまり意味がないよねみたいな
話もあると思うし
そもそもそれがブロックリストに入ることによって
勝手にブロックリストに
入ることによって
その関係でそのドライバーが使えなくなって困る
みたいなのも普通に起こりうるし
意外となんか
Windowsアップデートに入れざるを得ないんだろうな
っていう感じがして
それはちょっともどかしい感じがする
あとなんかそのWindowsの
シェアが広すぎるが
ゆえにとかもあるのかな
たぶん
そのバージョンとか
パッチを当てている状況とかの
差というか
楽さが広いがゆえに
どれだけのユーザーを落とさずに
でも安全に
なるべく倒してみたいな
こういう仕組みに落ち着いたりしたのかなっていう
ちょっとしたすけどね
そんな感じです
ランサムウェアの仕組み
はい
じゃあ次
今日はあと2個どっちも僕
はいお願いします
ランサムウェアアピューズ
Amazon
AWS Feature to Encrypt
S3 Buckets
というリビンコンピューターの記事ですね
これは
ランサムウェアキャンペーンの
に関する記事で
どういうキャンペーンかっていうと
AWSの
S3で
普通に使うと
デフォルトではそのAWSのマネージドの
キーが裏側であって
そのマネージドのキーによって
データが暗号化されて
保存されるっていうような
仕組みになってるんですけど
このキーを独自の自分たちが
発行したキーに差し替えることができる
っていう機能があって
これを悪用して
動作するランサムウェアがあります
っていう話ですね
やってることはシンプルで
なんとかしてそのS3の
独自キーを登録する権限を
保存した上で
攻撃者が作ったキーを登録して
暗号化をしてしまって
っていうことを
しますと
もしやられてしまうと
データを保持して
S3の持ち主は
データを複合するために使う
キーが手元にない状態
なのでだし
AWS側もそれを複合できるわけがないので
積んでしまうっていう感じですね
対策自体は
S3の登録権限っていうのが
AWSで個別に
定義されてるんで
これを一律落としてしまうのが
いいんじゃないっていうことが書いてあるって感じで
ですね
なんか
責任業界的には
ユーザーが管理すべき領域
かなって気がする
のと
ここの
仕組み自体は結構シンプルというか
なんでめっちゃ驚きっていうわけではないんですけど
まぁなんでしょうね
S3を使ってるからとか
Googleクラウドストレージを
使ってるからとか
だから
Nansamには引っかかりづらいとか
そういう認識は
もともと動かすべきではないとは
思ってたけど
なんかすべきじゃないよねっていう話の
実例としては
心に止めておこうかなっていう
ところと
キーの登録を権限レベルで
広めに落としておくっていうのは
なんか自分は
発想というか
トゥードゥリストの中に持っててなかったんで
やるべきかもなっていうのはちょっと
思ってて
ただなんかプラバディによって結構構造が
違ってて例えばGoogleクラウドは
ちょっとパッと調べた感じなんですけど
クラウドストレージのセキュリティ
AWSとはちょっと違って
そうね
プリングやオンキー自体が
KMSに対してのものの
理解なので
なんか
KMS側の世界の権限を
落とすか落とさないかみたいな
またそのプロジェクト
またげるのかどうかとか
そういうのも多分
Googleクラウド側はあるので
なるほどね
シンプルながら強力な
攻撃かなと思って
取り入れましたって感じですね
なるほどね
これでもあれだね鍵取りめんどくさくないのかな
AWSこれで
S3にひも付く鍵
みたいな概念があるわけでしょ
そうかね
Googleクラウドでいう
KMSみたいな集中管理するような仕組みがない
あるけど
それに依存しない形で
S3に直で
鍵を
適用
なんていうか
使えるっていうわけでしょ
そうだね
どうなってんだろうね
僕が言った権限の分かれ
僕が言った
AWSはS3側で
完結されてて
GoogleクラウドはKMS側
って話は
権限設計の話ではあるから
AWS側も裏側は
KMS的なものに繋がってるけど
っていう話とかもしかしたら
あるのかもっていう気はする
AWSは全く触ってないんで
適当に喋ってるんですけど
AWS自体も
KMS相当のやつはあるはずだから
裏側はそっちに繋がってるんだけど
S3に設定したかったら
S3側の権限が
必要だよって感じたりする
でもどうなんだろう
わかんないな
そうね
クラウドストレージのドキュメンテーション見てるんだけど今
クラウドストレージ
要はAWSのほうは
S3に
このSSECっていう話の解説
S3のドキュメントの中に
この話が載っていて
じゃあGoogleクラウドはどうなのかなと思って
見てるんだけど
クラウドストレージの場合はやっぱり
KMSにっていう話は
ここら辺の理解は
なんていうか合ってるんだけど
なるほどね
嫌だね
嫌だねって話が
多いんだけど
なんか結構
これ読んで
自社の
構成を
元に
チームで話したりしたんですけど
なんか考えること増えるなっていうのは
シンプルに思ったというか
ちょっと面倒だけど
でもやんないとちょっと
ダメだよねっていう感じで
あるんで
なんかケース次第
まぁそうね
S3の場合はあれかな
まぁどうだろう
いろんなパターンはある気はしてて
キーを設定する権限と一緒に
S3の権限も
フルで取られてるんだったら
まぁ
どうなんだろうな
わかんねえな
例えばなんですけどGoogleクラウドの
いや
クラウドストレージわかんねえな
例えばバックアップ機能みたいなのがあったときに
古い世代は
キーを差し替えても大丈夫なのかとか
どこまでどういう権限を取られちゃったら
積むのかみたいなところを
考えるのは結構大変だけどやんなきゃな
っていう感じです
何が言いたいのかわからなかったけど
その何だろう
ケースによっては別にこのキーの権限を
落としてても
S3を守られてなきゃ意味ないよねって話も
あるだろうし
はい
シンプルながら結構
おもろいなって思う
おもろくないんだけど
データ量がでかかったりすると
攻撃者目線は嬉しかったりするのかな
ダウンロード
してる間にバレないっていうか
キーだけ差し替えて
適応されるのをゆっくり待って
終わったら完了みたいな
これデータの持ち出しも
してたっていう話なんだっけ
えっと具体的な
インシデントには言及してなくて
インシデント次第かもしれない
S3から
持ち出すこと自体は
何だっけ
さっき別の
記事でやってたから
旅行ゲーム
だから普通によくある話
持ち出そうと思えば持ち出せるんだろうな
使ってる
ランサムウェア
ザサービスとかにもよるのかもね
二重脅迫するようなランサムウェアだったら
持ち出しまでやるだろう
持ち出せるのは
持ち出せる気がするけどな
そこはちょっと
分かんない
あえて持ち出さないってパターンあるのかな
いやー
とりあえず暗号化しちゃえ
っていうので
人質にするっていう
それでも成立はするかもしれないけど
マネタイズが
難しいというか
マネタイズってのは
攻撃者側ってこと
それはもう
複合キー欲しければ金払いでいいんじゃない
うーん
それを全部諦めますって言われちゃったら終わりじゃん
その
金払わないと漏らすよ
っていうのができなくなるし
そこはじゃあ
そこは二重脅迫するかどうか
な気もする
その辺どうなんだろうね
なんか
二重脅迫自体がめっちゃ主流になってる
認識はあるけど
偶然に見かけるっていう
でも基本的には
できるのはやるって感じな
あるいはデータそのものを売るっていうパターンも
あるしね
売れるデータなら確かに
そんな感じですね
じゃあ最後いきますか
パスキーの新刊紹介
めでたい記事
パスキーのすべてという本を書きました
素晴らしい
Googleのエイジさんの記事ですね
もう素晴らしい
本当に
素晴らしいです
それだけではあります
その記事には
この本にこういうこと書きましたよ
ってことが書いてあるんですけど
この記事の時点で結構
まず
著者が素晴らしいですね
最前線の方々なんで
まず間違いないでしょうっていうところと
その記事の内容で
こういう人向けに
こういうこと書いてるっていうのがあるんですけど
見出しそのまま読むと
もう素晴らしいなって感じなんですけど
PMとかデザイナーが知っておくべき
基本的な情報もまとめてるし
エンジニアが知っておくべき
パスキーの実装に必要な要素っていうのも
まとめてるし
上級者向けの情報っていうのも
たくさん盛り込んでるよってことが書いてあって
なんでかなり
なんでしょうね
今時点でのパスキーのすべてを
タイトル通りパスキーのすべてを知るっていうのは
とてもいい本だな
っていう雰囲気があるんで
皆さん予約しましょうっていう
技術の重要性とその変化
僕は予約しました
の記事です
これ系は特にパスキーは
めっちゃガラっと書くことはないと思うけど
1年2年経ったら
一論集はどんどん変わってくる
ありそうな気がするんで
今のうちに
読もうぜっていう気持ちもありつつ
って感じですね
ちょっとなんか
いくらでもあったんだろうけど
いいコンテンツは
一箇所にわっとまとまってて
これ読めば終わりっていうのは
ちょっとパッと思いつかないというか
W3Cの韓国とか
結構
上からわーって読んだりしたけど
全部は読んでないんだけど結局
読めば分かるけど
じゃあ結局どこが
集まりポイントなのみたいなところとかは
あれだけだと正直分かんないし
そうだね確かに
知っておくべきところが
どこなのっていうのを
全部分かってる人がまとめてこうやって出してくれるのは
めちゃくちゃありがたいから楽しみ
してます
めっちゃ楽しみです
発売いつだっけ1月28なんでもう5日後じゃないですか
あらー
いやーそういうせいだよ
めでたい
いやー
はい今日はこれで
全てでございます
いやー
でもなんかちょっと個人的には楽しかったな
良かったです
良かった
Bring Your Own Containerはちょっと
読んでます
素振りな素振りはまあまあ
無理のない愛でやればって感じです
はい
R-Syncとかもなんかちょっと
ざわざわしてたけどまあ
パッチやっててねってかな
R-Syncまあ使ってるところ
あるなのな
うん
はい
R-Syncはでもこれどう
なんか開くような難易度で言うと
どうだったんだろうね
なんかいくつか
あるよね
要はさその
インターネットからアクセシブルな
ところには使ってないだろう
と思うんだよねまず
あーでもそれで言うと
そのR-Syncのあそうこれだ
あのこの記事があってですね
66万の
R-Syncサンバーが
繋がってんだ
コード実行できる脆弱性
見つけてるよって記事があって
だからまあ
これ系さ毎回思うんだけどさ
何だっけ直近だと
あのLinuxのプリンターのやつ
ちょっと忘れちゃったけど
IPPかな
そんなん
こんな条件満たさんやろみたいなのあるけど
なんかその後にブリーピングコンピューターとか
インターネットベースで
うん10万のデバイスが
そこをチニコマみたいになくてちょっと面白いんだけど
だからなんか
意外とあるというか
だからこれ笑っちゃいけなくて
自分たちでその
ワンチャンあり得るものがあるんだったら
ちゃんとね調べたほうがいいんだろうな
と思うんですけど
まあそのコンテナベースのアーキテクチャとかだと
あんまりないのかもしれない
あーまあ
わざわざ開けない限りはね
そうだね
だからなんか
まあ予防的なところじゃないですけど
そのファイアウォールの
設定をちゃんと維持しときましょう
とかである程度こういうのは
初手は防げたりはするだろう
うん
そうですねそこをチニコマ
なんか一緒に取り上げて
まあでもそうっすねまあまあでもなんかあるあるではあるんだよな
なんか内容自体は
はい
そんな感じですか
さあ来週
来28
28だから
再来週の放送で
パスキーの全てを読んでみた
劇場
爆速で読んで
タイミング的には
届いてその日にワッて読んだら
ワンチャン間に合うよ
そうだねちょっと頑張るか
無理やろ厳しい
さすがにさすがにそんなそんな
上手くいかないよ
内容骨太だしね
うん
まあまあちょっと叶え楽しみにしておりますが
はい
はいじゃあ
心の国はないですか
ないです大丈夫です
じゃあまた来週も
よろしくお願いします
おやすみなさーい
