1. Replay.fm
  2. #5 バーコード防衛意識高めて..
2024-10-12 1:49:36

#5 バーコード防衛意識高めていきまっしょいの回

下記の記事のについてワイワイ話しました。


https://sota1235.notion.site/Replay-fm-5-9f2c3ecd2dd1479bbab5d795ca710b58?pvs=74

サマリー

第5回のエピソードでは、AppleのVoiceOver機能におけるパスワードの脆弱性とその影響が議論されています。ウェブセキュリティやアクセシビリティの重要性が強調され、関連する具体的な事例が紹介されています。また、リソースアイソレーションポリシーや最近のランサムウェアアキラについての情報が共有され、セキュリティ対策の重要性が再確認されています。さらに、AWS WAFのカウントモードとブロックモードの具体的な使い方についてアドバイスが提供されています。 このエピソードでは、バーコードやセキュリティに関する意識の重要性について語られています。特に、文字列を隠す行為がバーコード情報と矛盾する可能性や、Microsoft Defenderの新機能とその利点についても触れられています。 6000台以上のiPhone詐取事件に関する内容が取り上げられ、中国人2名が偽のiPhoneを利用して交換ポリシーを悪用し、利益を得ていた手法が注目されています。また、システム上のアイデンティティ管理の難しさについても言及されています。 GitGuardianを活用したセキュリティ管理の重要性やクラウドサービスの権限管理に関する課題が取り上げられています。Dropboxやマイクロソフトの事例を通じて、APIキーや個人情報漏洩のリスクについて考察されています。 バーコードの防衛意識を高めることが強調されるこのエピソードでは、OSS環境におけるセキュリティリスクとその対策について深く掘り下げられ、引き続き進化するサイバー攻撃手法についても言及されています。 フィッシングサイトの作成やランサムウェアの問題が取り上げられ、インターネットの便利さとその裏に潜む危険が議論されています。また、マイクロソフトのエッジエクステンションのセキュリティ更新や、Facebookがパスワードを誤って保存していた件も紹介されています。 GDPRの影響について語られ、特にメタの音声データ開示の問題やGoogle Pixelのセキュリティ対策について掘り下げられています。EUの法律が企業やサービス展開に与える影響についても考察されています。 アンドロイドや物理カードの製造技術、クラウドフレアのパスワード漏洩検知機能について議論が行われ、特に物理カードの発行や和風アプローチにおける利便性が強調されています。 クラウドフレアやオリジンに関するセキュリティやリクエストの仕組みが語られ、開発における複雑さや新たな課題が浮き彫りにされています。また、ポッドキャストやRSSのホスティングについても興味深い議論が展開されています。

AppleのVoiceOver機能の脆弱性
こんばんは、Replay.fm 第5回です。
5回です。こんばんは。
こんばんは。5回もやれてる。えらい。
いやー、素晴らしい。
毎週毎週ね。お疲れ様です。
お疲れ様です。
今、後ろで娘が泣いてる声が入ってる。
ちょっと聞こえたわ。
聞こえた?
隠してなかったか。
残念。
大丈夫です。いや、大丈夫なんですけど、
強い意志でね、
収録を続けてますよっていう。
なんか今日キレ悪いな。
頑張っていこう。
お疲れということで。
もう火曜だからじゃない?いつも火曜じゃん。
あー、確かになー。
まだ元気なんだよ、きっと。
いや、否めない。
確かに。
じゃあ、はきはきやっていこう。
やっていきましょう。
はい。じゃあ、
あれ?お前もこれは間違えたんだよな。
あれ?下から言ってんだっけ?
いや、上からで。
じゃあ、上からいきましょう。
たまにでも下からやってもいいかもね。
まあ、今日はいいけど。
いつも上からやってって、
半分ぐらいで若干力尽き
あるから。
確かに。
じゃあ、強い通り。
じゃあ、1個目は
読んだ人が
僕になってるんで、
タイトル読むと、
Apple VoiceOverのパスワード脆弱性を修正する
重要なiOSおよび
iPadOSアップデートをリリース
っていう、これ何の記事だろう?
多分ね、たまたま流れてきた
ニュースだと思うんですけど、
あ、そんなことないわ。
ハッカーニュースでした。え、ハッカーニュース?
あ、俺日本語訳したタイトル入れちゃった。
後で直してきますけど、
えーっと、
まあ、タイトル通りで
iOSで
VoiceOverっていう機能があって、
読み上げですよね。読み上げの機能で
パスワードを
読み上げちゃう可能性がある
脆弱性っていうのと、あともう一つ
えーっと、音声アプリ
とかが
まあ多分録音した音源をなんか
チャットで送るとか、まあLINEとかもそういうのあると思うんですけど
あれをするときに、その録音ボタンを
押したときの
押す前の数秒間の音声が
取得できちゃう可能性がある
っていう脆弱性があったみたいで
で、どっちもリリース
まあパチャリリースされてるんで、まあまあ
って感じなんですけど
報告されてたって感じですね
興味深いな
ユーザーアクションを伴う前の音声が
取れちゃうってこと?
うーん
そっちは結構原理
謎というか、なんなんだろうね
なんかその、スイッチのさ
録画機能とかってさ
押した瞬間から30秒前の
音声を取るとか、わかんないけど
なんかその、なんかの理由で
直近何秒間かを
持ってんのかもね
メモリー上から、知らんが
面白いな
うん
なんか個人的に結構
むず、むず、むずそう
Apple目線むずそうだなと思ったのは
結構このボイスオーバー
っていう機能自体はアクセシビティ
を考えて
万人が使えるものをきちんと作っていく
っていうところでとても重要な機能
だと思うんだが
それがなんというか
脆弱性と呼ばれるところ
までなんかリスクを生んでしまう
っていうケースは結構
うーん
僕がこれをボイスオーバー作るから
だったらなんか漏れちゃいそうだなと思って
結構なんか
なんというか、アクセシビティに
限らずなんですけど
あんま関係ないと思わずにちゃんと
感度を持っていかないといけないなって思った
っていうところですね
アクセシビリティとウェブ開発
で直近は
直近、はい
近仕事でも、僕じゃないけど
スクリーンリーダー対応とかをやったりしてたんで
うーん
再レビューしとこうみたいな、まあたぶん大丈夫なんですけど
うーん
何をいつどこで読み上げるかみたいなところに
たぶんある程度想定して
読み切れていいものダメなもの
ダメなのやつはどうするのかみたいな
なんかたぶんちゃんと仕様として
考えないといけないんだろうなっていうのを
思った感じですね
これなんかHTMLの仕様とかでさ
そのこの要素は読み上げちゃダメ
みたいなのってあったりしないのかな
あー
ありそう
ちょっとWebに、ボイスオーバーだからWebに限った話ではないと思うんだけど
うーんそうだね
確かになHTMLとか
あるかもね、どうなんだろう
いや気になったのがさ
なんていうか
パスワード入力
インプットタイプパスワードで
その入力したパスワードを
見えるようにするボタンを
つけてるケースがあるじゃん
うんうんうん
いわゆるインプットタイプパスワード
インプットタイプテキストに変えてみせるように
するようなつくりのやつ
うんうん
あれってその
ボイスオーバーとかする側が
元々のその要素が元々
パスワードであったことを
認知できてないとたぶん読み上げちゃうよね
そうだね
判別方法がないね完全に
うん
Webブラウザとかはある程度
その辺たぶん気を使っていて
うんうんうん
ボイスオーバーとかはどうなのかなとはちょっと
なるほどね
それもそうだしなんかその
Webはその
ある程度標準化されたセマンティックスが
あるから
それでなんか対応できそうだけど
アプリとか
ちょっと大変そうだよね
どうなのかな
なんか
弊社の話になっちゃうけど
それこそウチはフラッターを使ってて
フラッターだとその描画エンジンがさ
独自で乗っかってて
そのiOSがこうして
欲しいみたいなところのレールから
ある意味外れてるわけだからさ
たぶんなんか
こういう属性だったら
読み上げないようにするよみたいな
のをなんかあんまり
ちゃんとできる気がしないなっていう
うん
フラッターで頑張って作ったりしてんのかな
でもなんか
でもフラッターを通じて
ネイティブの機能をなんか参照する
使うみたいな形になってないと
うんうん
そうだね
確かにな
普通に調べてみよう
さすがにありそうだよね
だからこのボイスオーバーが
そういうラベルがついてんのに読み上げちゃったのか
そういうラベルをつけようがない
領域で読んじゃってたのかとか
なんかその辺は
実は結構その辺次第で話は変わるのかもしんないね
CV番号振られてるから
詳細はググれば
わかんのかな
確かに
いや
ちょっと頭の片隅に
心にとどめておきたい系ですね
一応ね
aria-hiddenとかを使うと
読み上げないようにするとか
CSSで
speak
を何にして
してあげると読み上げスキップとか
やってくれるらしいけど
これがその
WATWAGとかW3Cとかで
標準化されてる仕様なのか
ちょっとわからない
ariaは違うよね
なのかな
全然わからん
ariaって何なの
ごめんそもそもすごい
完全に素人丸出しの質問なんだけど
僕も素人なんですよ
ariaって何なんですかね
でも一応
MDNにページが
そうだね
WAI-ariaの基本
ページはあるから
書いてあったわ
W3Cによって定められた仕様で
要素に適用できる追加の意味論を提供する
一連のHTML属性を定義しており
それが欠けている
どのような場所でもアクセシビリティを
向上させます
ウェブセキュリティの実践
なるほどね
一応標準化をされてるんだね
なるほどね
いやこれ
いやこれ知らずに
いやまあウェブ開発
プロエンジニアたちは
ちゃんと把握してやってるのかもな
わかんねえな
いやまじこういうの
山あるさんとかになんか話聞きたいな
聞きたいね確かに
せっかくなんか
全然かかりなかったけどせっかく近くにいたのに
なんか
ちょっともったいなかったなっていうのを
知って思う
これなんか
いやでもこれ現実問題
いやまあ難しいね
多分弱小
中小には無理だけど
それなりに成熟した企業で
そもそもアクセシビリティに
どのタイミングでちゃんと投資できるのかみたいな
問題が現実問題ある気がするんだけど
ちゃんと投資できる体力がついた時に
例えばデザインシステム
とかがあるんだったら
じゃあその機密情報を
表示するとかそういうコンポーネントは
これ使ってねみたいな
それ使うと吉永に必要な属性がこの仕様に
乗っ取って
使われてるみたいな世界にならないと
結構なんか普通に漏れちゃいそうだなって気がするな
うーん
いやなんかさあまあそれもあるんだけど
なんか
やっぱ配慮が足りてない面はあるよな
と思っててその
なんか本当に普通に
自社サービスの話だけど
なんて言ったらいいんだろう
全格のスラッシュみたいなのがあるじゃん
あれを使ってその
なんかプッシュの通知の中に
あれを使ってこう
なんか文字の装飾を
してるみたいなのを見るとさ
いやーそれボイスオーバーで読み上げたらどうなるんだろうな
なるほどね
偉いことになりそうだけどなんか
そのーね
テキストに対する
メタテキストをどうするんだろうみたいな
うーん
いやー
自分もさやっちゃうことはあるからさ
その気にせず無邪気に
なんかXとかでやっちゃうことも
あるけどさなんかでも
企業がやってるのとまたちょっと意味合いが
違うじゃん
そうだね
インフラに近いようなサービスとかは
理想論で言えば
気を使ってあげられるといいよね
うーん
いやー難しいんだよなー
いやー山田さん呼びたいね
毎回一人呼びたい人ができるっていう
そうなんだよね
呼びたい人リストを
多分作っとくべきなんだろうなー
なるほどね確かに
いやー
はいそんな感じですか
はい
ちょっと超
有力ポッドキャストになったら山田さん呼ぼう
そうだね
来てください
お願いします
大手なんでうち
大手
大手とは
はい
ありがとうございます
じゃあ次は
はい
ウェブセキュリティの歩き方ですね
ヤップシーでいいんだよねこれね
通称は
ヤップシーの箱立ての
今年の箱立て10月5日かな
に秋山さんっていう
セキュリティ界隈のすごい人
秋CTFっていうの
今も残ってるのかな
昔運営してて
残ってないやめちゃったよね多分ね
その秋山さんが
発表してたスライドですね
タイトルがウェブセキュリティの歩き方
ってなってるんですが
長いんですよ
全部
全部紹介するとか
そういう感じのものではなくて
ただただこれがあるをかけて
ウェブセキュリティ周りの
脆弱性の説明とかを
一通り
なんて言ってるんだろうな
これ読んどいてって送っとけば
大体終わるっていういいスライドが
最新のセキュリティ動向
世の中に出てきたなっていう感じ
ちょっとずつ古くなっていくっていうのは
もちろんあると思うんだけど
それにしても
なんか今年
なんか分かんないけど
ウェブ分からんとか
新卒分からんとかセキュリティちゃんとやりたいですって
人にまず渡せる資料って感じがするよね
素晴らしい
隙がないっていうか
これ紹介するんだったらこれもみたいなのが
もうないんだよね
気持ちで
恥ずかしながら僕も
なんか完全には
分かってないものっていうか
そんな世界だっていうものがあるから
勉強し直そうと思いました
それでいくと
僕があんまり理解してないな
って思ったのは
リソースアイソレーションポリシーの話
リソースアイソレーションポリシーの話
あーこれか
あーそうこれ俺も
あんまり分かってなかったな
うーん
ちょっと学習を怠ってしまってるね
いやーでもさ
進化が早いよ
分かるよ
しかもなんか散ってるじゃん
あれが強くなりましたみたいな感じじゃなくて
そのいろんなものが増えてるからさ
なんか難しいな
って思うんだけどね
あとはなんだっけ
X4ADD4が正式になんか
採用されたよみたいなのが
どっかにあった気がするんだけど
4ADDヘッダーっていうのが
出たよみたいなのが
AzBetaの中か
AzBetaの
あーそうそうこれ
Excel Options Strict
Preloadね
あーこれか
それ今次かな
こっちか4ADD
あーほんとだ
いつの間に
これはちょっと知らなかった
XPrefixは
やっぱ滅ばしていかないと
うーん
こういうところからも
自分が置いてかれてるなっていうのは
よく分かるので
うーん
いやー
この場を通じて
キャッチアップしていきたいな
いい機会ですね
いやー皆さん読んでくださいぜひ
読んでくださーい
うちの社内でも結構なんか
ちょっと話題になってた
あーいいっすね
丁寧に頑張って読むぞみたいな
勉強会したいよね普通にこれを読むだけの
勉強会するだけでも全然価値がある気がする
うーんあれなにこれなにって
こういう時どうなのみたいなのをね
なんかやるだけでも
間違いない
確かにありがとうございます
じゃあ次いきますか
これ
えー
えー
サマに書いたの僕だっけ
僕かな
そうです
じゃあ僕は読みますけど
えー何の記事だっけ
クォーリスコミュニティ
読み方あってるかな
クォーリスのセキュリティブログ
クォーリス失礼しました
ストレートブリーファンダスタンディング
という記事なんですけど
記事の内容は正直
タイトル通りであきらっていうランサメアが
最近猛威を振るっていて
2023年3月から活動している
ランサメアなんですけど
えー特徴としては
欧米とオーストラリアの複数業界を
ターゲットとしているよとか
ランサメアアンサーサービスとして機能して
二重強拡なんで
データも盗むし暗号化もするっていうところ
で挙動すると
でこれ
これ日本語間違ってますね
196以上の組織に
感染した
実際に感染してるっていうのが
確認されてるので
割とそこそこいろんな企業をやらてる
っていうところで
個人的に
このあきらの詳細がかなり詳しく書いてある
記事でどういう技術で
どういうステップで感染させて
どういう挙動をするのかみたいなところが
かなり詳しく書いてあるんで詳細読んでください
って感じなんですけど
ランサメア専門家目線で
このあきらがどう見えてるか正直分かんないんで
言及しないんですけど
僕の個人一
ソフトエンジニア目線としては
人取り座と
斜め読みした感じは
イニシャルアクセス
獲得するところから
侵入して横展開して
最後実行まで行くっていうところの
過程でそんなに
分かんないけど
何も知らない人が
ブラックハッカーに想像するような
めちゃくちゃすごい
迂回経路とか
すごいハッキング的なことをしてる
ようにあまり見えなくて
基本的に存在する
ポートが開いてますとか
特権アカウントが放置されてますとか
そういうものを一つ一つ辿っていって
順当に
やってるように見えていて
なのでやっぱ
改めて分かってることだけど
基本的なセキュリティ対策をいろんなレイヤーで
コツコツとコツコツとやっていくっていうところは
大事だなと思うし
そういう
ふうな使い方するかちょっと
分かんないけど自分たちの活動
地味だなって思っても
こういう記事読むと実はこのステップのここで
ふさげるところじゃんみたいな
答え合わせにはなんないのかな
答え合わせとはしないほうがいいけど
なんというか励みになる
気はしたな
ってちょっと思った
AWS WAFの運用
攻撃の特性としてまず
数じゃ当たるっていうやり方を
してるわけなので
なのでより簡単に
その刺さるところに
当たれば
それだけで十分稼げますよっていう
やり方をしてるから
よりそういう
やり方を取ってるように見える
取ってるっていうのも
あると思っていてこれがなんか
特定の組織を標的にってなるとまた
話が変わってくるから
必ずしも基本的な
対策で
いつも通用するっていう話じゃないと思うんだけど
でもこれに関しては間違いなく
そうだと思っていて
なんかステップバイステップで
なんていうか
ここまで入られたら
次これをするはずだから
これを対策しないといけないみたいなのを
ステップバイステップで見ていけば
おおむねどこかで止められるでしょう
っていうのは絶対あるはずで
確かにな
なるほどね
それこそ多分
強硬な
セキュリティを築いてるが
分かんない
リターンがでかいような企業は
ちゃんと独自の攻撃をしてくるというか
その辺の
世界はちょっと
なんか
飛び込みたくねえなっていう気持ち
今ちょっと
絶対僕は立ち打ちできないなと思ったけど
自分のサービスがそういう
育ち活動するかもしんないから
頑張らなきゃいけないんですけどね
そうですね
でもなんか結構
ソフトエンジニアに
コースを読んで欲しいかもなって
ふわっと
思ったなあ
よくまとまってるんだよな結構
なんか
この何でしょうね
具体的なファイルの挙動とか
この辺はちょっとコードとかも
かなり詳しく書いてあるから
読み込みすぎるとあんまりよくわからんってなっちゃうけど
ステップのところはすごい
いいなって思いました
はい
ありがとうございます
じゃあ
次行きますか
はい次は
AWS WAFをカウントモードで動かしたはいいが
その後どうすればいいんだっけ
っていう神なしエンジニア
ブログさんの記事で
ございます
基本的にタイトル通り
AWS WAFを
カウントモードっていうのがあるらしくて
このカウントモードっていうのが
一般的なタームなのかどうか
ちょっと僕わかんないんですけど
多分いずれにしてでもWAFとか
あるいは
IPSとかもそうなんですけど
基本的には検知だけするモードと
ブロックまでするモードっていうのが
分かれていて
このAWS WAFにおいては
前者をカウントモード後者をブロックモード
っていうふうに呼ぶらしいです
とりあえず動かしてみて
どんぐらい検知されるのかね
っていうのを確認するためにまずカウントモードで
動かすっていうのが定石なんですけど
それを動かし始めたら
いいけれども
何をもってブロックモードに
すればいいんだっけっていう
悩みに対する
なんて言ったらいいんだろうな
一つの実例みたいなのを
紹介してくれてる記事ですね
はい
これは結構
なんていうか
セキララというか
等身大というか
いいなと思ったのは
実のところをやればできるぐらいに
思っていたのですが
私自身すぐに原稿化して説明できなかったので
エンジニアの誰もが
同じように判断できるようになってもらうため
文章化しましたみたいな
これいいなと思いました
大事だね
あとは
通常利用で記録されていないということは
記録されるタイミングは
攻撃を受けたタイミングであると
考えられるため
全く記録されていない
ルールは
有効化しちゃってもいいよ
みたいな話とか
かなり具体的に書いてくれていて
これに関しては
通常時のログ
難しいな
ここからここまでで取ったものを
通常時で見出します
通常時のログをどれくらいの期間に渡って
取るかに依存するので
必ずしもそうではないけど
だいたいそうだよねっていう話とかもあるし
具体的に
こういうケースで
ブロックモードにしちゃっても
いいんじゃないみたいな考え方とかを
一通り紹介してくれていて
いいなと思いました
確かにな
この1個目の
文書化みたいなのは
尊いね
自分も
これと
同じゲームをやったわけじゃないけど
やればできる系
かつやった時に
ひと回しした時に
なんとなくかんどころをつかむ系の
改善活動とか
運用とか保守みたいな
セキュリティ以外でもあるかもしれないですけど
往々にしてあると思うんですけど
これを
セキュリティの共有
なんとなくかんどころをつかんだ
みたいな状態を
人に得てもらうためには
言語化しないといけないっていうのは必ずあって
セキュリティ周りとかは
亀梨さんも僕が知ってる状態と
一緒だったら
セキュリティチームがめっちゃ
でかいっていうよりかは
ソフトエンジニア何人かと
セキュリティ担当1人か2人とかだと思うんですよね
っていう状態で
エンジニアもある程度やってもらいたいっていう前提に
立つんだったら
セキュリティ詳しくないであろう
っていう前提に立ってこういう活動をするっていうのは
ひたすら
いい
ええやんけって感じですね
何メディアさんさまだよって感じだけど
めちゃくちゃ
尊い
僕のねコメントがね
ええやんけなんですよね
ええやんけと
あとなんかちょっと個人的にちょっと思ってるけど
こういう愚直な記事さ
わかんないもう
領域の性質上しょうがないかもしれないけど
なんか
なんか僕も
会社ブログ書くときには実は意識してて
もう聞かざらずに
いやもう努力作やってます
セキュリティ意識の重要性
もう一つ一つ新たを潰してるだけです
みたいな
ただまあここではこういうポイントがあるみたいな
のが結構なんだかんだ見乗りが
見乗りっていうか
欲しい人は欲しい
欲しい人は欲しい情報なのかなって思ったり
をしてるから
なんかあんまキラキラしてないからさ
発信するのもちょっとためらいがちなのは
わかるんだよね
そんな大したことやってないよ
っていう
でもさっきのさウェブセキュリティの
歩き方とかもそうだけどさ
あれはわかってる人が全部まとめました
っていうだけじゃん
でもそれだけでも価値があるわけでさ
そうだね
現場の
実業が一番いいよ
聞きたいよ
本当に
あと難しいのはやっぱなんか
セキュリティ周りに難しいのは
まだやれてないけどやってます
っていう記事を出すのはちょっと
やっぱ微妙だなって気がしてて
それはセキュリティ観点でというか
それはこれができてません攻撃してください
ときになりかねないから
そこだけちょっと
面倒いなと思ったりするけど
そうね
だから基本的には
できてることから
アウトプットをするっていう
アウトプットしてないかといってできてないわけじゃないんだけど
難しいよね
難しい
あとは
ふと思ったのはこの
なんて言ったらいいんだろうな
要は
誤検知を見つけて
誤検知があるやつに対象します
誤検知がないやつは有効にします
みたいな作業の繰り返し
なんですよ
なんかセントリーみたいな仕組みとかで
ポチポチできたら楽なのにな
ってふと思った
逆セントリーなんだけど
逆セントリーってなんやねんって感じだけど
逆セントリーってなんだ
逆セントリーとは
セントリーはさ
エラーをさ
ロギングして
これ新しいやつだよみたいなの出してくれるじゃん
なんか
いや難しいな逆
逆って何が
何が逆なのか
分かんなくなっちゃったけど
ああいう感じでさ
このルールでこれが引っかかって
新しいやつだよみたいなのが
お知らせしてくれたらさ
画面上でポチポチやって
確かにね
いい感じにできないかなと思ったんだけど
AWS WAFとかは
コンソールでそういうのあったりすんのかな
分かんないけどね
クラウドアーマーとかは
そういう感じじゃないと思うんだよね
引っかかったときに
ポチポチじゃなくてフィルターをおじまえでどうにか
変えるってことになるから
そういう意味では確かに
セントリーみたいな
世界観のほうが楽かも
一週間無視するとかさ
欲しくない?
欲しいかも
確かにな
ないのかな
でもどうなんだろう
実装する目線に立ったときに
なかったら作れば売れるよ
いいよ
セキュリティ製品で一儲けするか
一儲けしよう
一発当てて
遊んで暮らそう
なかったら地味に売れると思うんだよな
でもないってことは
売れないんだろうな
Microsoft Defenderの機能
分かんないけど
よくも悪くもさ
想像で喋ってるか違ったら
違うって言ってほしいんだけど
大規模
悪くなっていくと文業が進んでいく
領域じゃんセキュリティ自体が
そうなっていくと
この和風を
堅持して対応する人
なんか僕の
今時点の知識だと
SOCの人とかがポチポチやるとか
そういう世界なのかなって気がすると
あるあるのフォーマットが
自ずと売れてしまうというか
なんだろうな
似たようなやつないかな
分かんないけど
使いづらいのは
分かってんだけど
でももう
どの製品に行ってもだいたいこういう使い心地で
使えるよねっていうのに
オーノストロップインされてしまってるみたいなのとか
あと
大きくなっちゃうとオーリーマンのサービスの方が
売れるから単体で勝負できないとか
なんかいろいろありそうだなって
確かにね
しかも別にそれ単体で
全部解決しようっていう性質のものでもないから
ちょっと緩めにしたいとも多分
おおむね問題ないんだよね
あーそうね確かに
あくまでね
一枚の防御だから
ただその
領域を絞れば売れるかもね
そのうちみたいな中小の
まずやり始めたいんだけど
コスパよくやり始めたいみたいな
大きくなったら
うちのサービス卒業して
でかいの使えばみたいな
限らずでやればいいんじゃない
まあそれはそうね
GitHubとかのセキュリティルールとかさ
なんか
ありとあらゆるものをそこに突っ込んで
あーなるほどね
いい感じにできますよみたいな
ログ全部つなげんしゃいみたいな
なんかありそうだな
データドックとかが作ってそうだな
なんならセントリーでできるんじゃない
それ
セントリーってさ
セキュリティのレポートを食わせられるんだよ
確か
へーそうなんだ
それは知らなかった
セキュリティポリシーレポート
なんならセルフホスティングすれば
なんかいろいろ
カスタマイザーできるんじゃないか
なるほどね
一応ねOSSになってたと思うんだよね
地味に
いやー
でもなー難しいな
なんか何使っても同じ問題になる気がすんだよな
結局
そのちょっと楽になるだけで
筋肉ないとすぐ荒れるから
まあでもそのちょっとがね
楽になるだけでも違うかもね
ちょっとクララーマー
今期がっつり触ろうと思ってるんで
修行した後にまた
いや実は違うんすよセントリーは
って言えるようになってくるわ
楽しみですね
ありがとうございます
ありがとうございます
じゃあ次は
まあ
俺かこれも
お願いします
マイクロソフトディフェンダーが
アンセキュア
Wi-Fiネットワークスの
ディテクションを追加しましたよ
という記事でございます
はい
タイトル通りなんですけど
一応なんか
歌い文句としては複数の
ネットワークの特性を見てヒューリスティックに
判断するよっていう風に
言っていて記事では言っていて
ブリーピングコンピューターの記事ですね
Evil Twin
っていう手法
要は
全く同じ
ESSIDで
立ってるアクセスポイントに繋がせて
そっちで
元々
そのESSIDに繋ぐようになってるので
全く同じ
ESSIDでアクセスポイント立てると勝手に
繋ぎにくるみたいなやつにも
なんか対応してるよっていう風に
歌っていて
ちょっとなんかタイトル見て
暗号化なしのアクセスポイントを警告するだけ
とかなんかそんな感じでちょっとチープなのを
想像したんだけど
意外となんかやってそうな感じ
はして
でもなんか
それってチェーンオブトラスト
というか要は
TLSとかで防げる範囲よりも
外をこう積極的に
そういうもので守る必要が
本当にあるのかなっていうのは
ちょっと思わんでもない部分が
ある
でもMicrosoft Defenderがやってくれるんだったら
別にいいかって気もするし
得が
得はなくても損もない
って感じではあるよね
あとなんか
でもすごいちょっと
チープな想像だけど
日本より海外の方がこの辺の問題
切実な気がしてて
たしかにね
その温度間の差みたいなのもしかしてあるかもね
一応なんか
通知を出して
Defender VPNっていうのがあるらしくって
ごめんなさい僕Windows全然
使わないので知らないんだけど
Defender VPNっていうのが
あるらしくって
iCloudの
プライベートリレーとかと似たような
動きをしてくれるんじゃないかと
思うんだけど
ドイツとカナダで
使える
日本使えないんだ
なんでドイツとカナダなんだ
わかんない
需要があるのかな
なんでだろうね
そんな感じでMicrosoftが提供している
VPNを通してインターネットに
アクセスするようになるので
どんだけ
よろしくないネットワークを
経由していたとしても
通信内容は安全だよっていう
のが実現するらしい
なるほど
素晴らしい
こういうとこで
守ってくれた方が
総合的には
いいよね
僕らは別に自分たち気を付けられるけど
一般の
大半の人が
マイクロソフトに
入れてないかもな
入れてないけど
勝手に入ってるとかもあるし
もう何もわかんないから
これ入れとけば安心って思ってる人も
いるだろうから
MS Defenderって今最初から
入ってて最初から有効でしょ
そうなんだ
いつからだったか忘れたけど
それはいい話だな
プラットフォームに
丸投げみたいで申し訳ないけど
そこで押さえられると一番いいよね
デフォで入ってると思うけどな
こういうときは
Wikipediaを見ると早いんですよ
Googleでよくだ
有料のイメージが勝手にあったけど
別に本当だ
ここで有効になってるね
わざわざ別の
アンチウイルスとかを入れて
無効化してない限りは
動いてるはず
いい話だ
ありがとうございます
30分ぐらい
バーコードの隠蔽問題
いいペースなんじゃないですか
いいペースですね
薄めの記事が多いということで
次が
文字隠してバーコード隠さず
ラックさんの
セキュリティコッタニブログの記事ですね
バーコードとセットで表示されてる
文字列は隠すんだけど
横についてるバーコードは隠さない
っていうのがあるあるだよね
っていう記事です
要は文字隠してるけど
同じ文字列がそのバーコードに
含まれてるから
っていうかバーコードが文字列そのもの
だったりするから
よくあるけど意味がなくて
気をつけないとダメだよねっていう
いやーこれ
なるほどねーって思ったな
あんまバーコードを
自分はあげた機会が
なかったからだけど
忘れるよな絶対
いややりがちなんですよ
僕もやったことあって
富士スピードAの
ライセンス新しいの来たわーって
Twitterにあげるときに
ライセンスの番号を隠して
写真撮ったんだけどQRコードが
そのライセンスの件面に
印刷されてて
もろもろ
そのライセンスナンバーがそのQRコードに
含まれてた
長谷川洋介さんに
QRの方が読めるのは
いいのって
工房もなんとやら
あーって
幸い別に
大丈夫なんですけど
iPhone詐取事件の概要
別に大した悪さはできない
大丈夫なんですけど
やりがち
気をつけたいですね
いろんなところにさ
印刷されてるじゃん
ありとあらゆるものに最近印刷されてるのよ
車検証とかもそうだしさ
あーなるほどね
確かに
めんどくさいよね
写真撮ってあげるなって話なんだろうけど
何がプリントされてるかも
わかんないものも多いから
安全側に倒すならやっぱ
撮らないのが
いやーでもリテラシース大人いときついな
相当意識しないとやっちゃうだろうな
やっちゃう人絶対いるよね
なんか俺自覚ないだけで
Twitter
かっこ逆のったら普通にありそうだもん
記憶ではないと思いたいけど
多分あるだろうな
後で探しとくわ
でも直近あげたやつが
映画チケットの
QRコードなんでこれはセーフなんで
映画チケットでも
使われちゃうかもしんないでしょ
これね見た後にあげてるから大丈夫
じゃあ大丈夫だね
探しといてもらおう
これは
知識としてね
まぁあるあるなんで
面白いなって
お話でした
ありがとうございます
じゃあ次いきましょう
これは僕が
引っ張ってきた記事で
えーっと
ブリビンコンピューターの記事で
タイトルがフロードスターズ
インプライズ
知らん単語や
for scamming apple out of
6000 iPhones
っていう記事で
何の記事かっていうと
apple相手にiphoneを6000台以上
騙し取りましたっていう
2名の中国人が逮捕されました
っていう記事なんですけど
やり口が結構面白いなと思ったんで
ここに追加してて
どういうやり口かっていうと
やり方が謎なんですけど
まず偽のiphoneデバイスを用意して
それを
appleのデバイス交換ポリシーっていう
多分何か一定期間だったら
そういう理由で故障だったら
交換しますみたいなものがあって
それを郵送とかも対応してるらしいので
その郵送とかで
これ故障したんで交換してって
送りつけて
交換ポリシーで認められると
新品のiphoneが来る
ので新品のものを手に入れて
それを多分現金化して
稼ぐっていうのをやってた
6000台以上やってて
250万円ドル以上の利益なんで
2億
2億3億ぐらい日本円で言うと
えっとね今ね見たんだけど
3億7千万ぐらい
いやえぐいな
すごい爆益
すいません
レートがねその直感と違いすぎてね
まずびっくりするね
確かに円安
22びっくり
そうで
その手法とかは多分詳しく書いてなくて
っていうのも多分この
詐取手法の詳細
記事のソースが
多分裁判所の判決
のところから引っ張ってるんで
技術的なところはあんま書いてないっぽいんですけど
書いてあることとしては
IMEI
知らなくてググったんですけど多分
個体識別番号みたいなもの
とシリアル番号
っていうのを偽造して
やってる
多分わかんないけど交換ポリシーを
適用できる
シリアル番号なんかしらの方法で
大量に手に入れて
手元には多分
ジャンク品のiPhoneとかをいっぱい用意して
偽造して送る
みたいな感じなのかなっていう
で取り上げたのは
賢いなって思って結構
おもろいなって思っちゃったのと
あと6000台アプライティに騙すの結構すごいな
と思って
これどうやったんだろう
っていう
わかんないけど意外とストアの
対面の
やり取りはが倍とかなんじゃないの
そういうわけでもないのかな
でもオンラインって書いてあったんだけど
なんか記事の感じは結構
まあでも郵送だけじゃないけど
いやでもどうだろうなやり
郵送も対応してるみたいな
言い方だったのかな
IMEIとシリアル番号は
多分フィッシング的なやり方で
集めたんじゃないかなと思うんだけどね
なるほどね
でも違うな多分郵送でやってるわ
だからそもそも香港から
アメリカに対して
やってるから
アメリカの
多分ポストどっかに
確保してそこ経由でやる
みたいなやり口でやってるね
対面とかはついたものでは
なさそう
すごいね
てか6000台やられるまで気づかない
アプリすごいな
そうだね
こういうのを見たときにさ
何て言ったらいいんだろう
6000台
騙し取った側からすると6000台って
すげえなって思うんだけど
こう
Appleから見たときに全体の何%
だったのかとかがすごく
気になるというか
同じやり口で別に見えないって
とか
0.1%にも
満たないですみたいな話だったらさ
それは見落とすこともあるよねみたいな
この交換の
運用がってことか
なるほどね
確かにどうなんだろう
いやでも
それを異常値として検出できるかって
結構さ
難しくない
難しいし
だからそれこそこの
6000台つかまえて
自白っていうか操作で
6000台って分かったのかな
その6000台
相模づける1位なアイデンティティが
多分ないじゃんなんかIPアドレスとかも
ないわけだし送り元も
その輸送の元も多分
まあいい感じにバラしてるだろうし
シリアル番号も本人たちのもの
じゃないんだったら多分その本人から
交換しに来たっていう風に見えちゃう
だろうから
結構異常値判定
というかApple目線で検知するのは
結構きついよね
全体の台数にもよると思うんだけどさ
普段の
ペースで行くとこの6000台は
おかしいよねみたいなのがさ
要はその
ハードウェアだからさ故障率とかって多分
持ってない
確かにね
これ期間とかあんのかな
すごい短期間に
中来
2017年から
2019年の
2年で
3000台で
12ヶ月で終わって
1ヶ月500台ぐらい
でもAppleの
規模でさ年間3000台でしょ
分かんないよ
しかもアメリカだしな
逆によく見つけてきたなって
気がしてきたわ
たまたまなんか偽造に気づいたか
怪しいけど掴みきれずに
調査してやっと捕まったのか
いろいろありそうだね
へぇ
おもろいなぁ あとは特定の人物に
結びついてるっていうのを見つけにくいな
確かにその通り
あると思うんだよその
1台2台さ
出てるってこと多分あると思うんだけど
うーん
すごいねこれは
CDR番号とかも
偽札対策みたいに進化してくるかもしれない
こういうのきっかけに
ちょっとハードウェアも大変だな
って思いますけど
アイデンティティ管理の課題
おもろお記事でした個人的に
ありがとうございます
ここからしばらく
僕の記事が続きます
僕の記事が続きます
まぁまぁ
軽めのジャブをたくさん打っていきたいな
と思うんですけど
次が
これブリーピング
ハッカーニュースかな
The Secret Weakness Execs Are Overlooking Non-Human Identities
っていう
GitGuardianのプロモーション記事
ですね
プロモ記事なんだけど結構面白いというか
再認識にいい記事だったんで
GitGuardianというのは
何の会社なんですか
GitGuardianは多分いろんなサービスやってるんですけど
一番有名なのは
僕が勝手に有名だと思ってるのは
無料で使えるやつで
Secretのコミット検知
Secretがコミットされたときに検知する
っていう
タブアップがあってそれとかは無料で使える
から割と
あるあるだし
多分有料で
主に多分
オリジナル周りのいろんなサービスを
展開してるんじゃないかな
そうだねSecret Detectionとか
ハニートークンとかもやってるんだ
パブリックコミュニタリング
いろいろ
なんで
それ系でアイデンティティ管理の
話が書いてあって
理解しました
なんかその記事タイトルにも書いてあるんですけど
切り口としては
Non-Human Identity
って呼ばれてる
概念の話をしてて
Non-Human Identityってのは何かというと
文字通り人間に
紐づかないアイデンティティ
アイデンティティっていうのは
システム上のソフトウェア上における
アイデンティティで例えば
GitHubとデータドックを連携したときに
連携元を
何かしらの
アイデンティティとして認定して
連携先は認証なりをして
連携するとか
あとAPIキーとかも一つのアイデンティティだよね
とかそういうものがあるよね
って話してこれが管理するのが
むずいよねっていうのがざっくり言うと
この記事で言ってることで
で難しいポイント
いくつかピックして
ざっくり話すとまず量が多い
量が多いので大変ですと
で量が多いし大変
なのとまたその人間と同じ
ベストプラクティスを適用できない
例えばその人間だったら
2FA認証
全員設定してねみたいな
プラグポリシーで強制するとか
っていうのが会社だったらできるけど
APIキーは人間じゃないんで
そこのAPIキーの使用にもよっちゃうし
それはできないよね
って話とか
あとこれは確かになって思ったけど
その企業内で
物によるけど誰でもいつでも
作れちゃうしそれ作られたっていうのは
作られたっていうこととか
作られた後にどう使われてるか
っていうのはほとんど監査されないので
結構管理が大変
でこれAPIキーとかだったら
ちゃんとやれよって思うかもしんないんだけど
その基礎中で触れられてるのは例えば
インテグレーションとかってポチポチとしたら
誰でもできるよねとかそういうものにも
触れてて
多分業務でみんなが向き合う
やつとかだと
NotionとGitHub連携とかって別に
セキュリティ管理の重要性
誰の許可も得ずに
ポチポチとしたら
オース連携誰でもできるとか
あれとか多分分かりやすいやつ
一応GitHubから制限できるんですけど
個別に権限とかで
がっちり制限できないんで
実質管理できないとかも
かなと個人的に思ってるとか
またそういうものがやっぱ自由で
カオスになりがちなんで
強すぎる権限が与えられて
古くなって放置されてるとか
がありがちで
やっぱHuman Identityと比べると長く
残ってしまいがちっていうところが
難しいよねと
で言うまでもなくなんだけど
これは
管理が大変なもそうだし
それで実際に大企業もやられてるよ
っていうのでDropboxとかマイクロソフトの
企業挙げて
具体的に支援とは挙げてないですけど
調べれば世の中
無限に出てくるというか
AWSキー漏洩で
個人情報漏洩しましたみたいなのを
正直に1ヶ月に1回ぐらい見るし
よくあるよねみたいな感じ
あとは
結局全部話しちゃってない
面白かったね話しちゃうんですけど
直近とかだと
クラウドフェラーが
オクタ経由で侵害された
有名なやつありましたけど
これとか
ざっくり言うと初期対応
めちゃくちゃ早くて
きちんと侵入されずに
防ぎましたよみたいなところを
クラウドフェラー側から出して
やってるんですけど
その後に本番環境の認証情報の漏洩
っていうのが実は漏れちゃってたみたいな
第2法が
出たっていうのがあって
クラウドフェラーぐらいちゃんと
検事とかいろんな体操を
整えてるとこでもやりきるのが
難しいんだよっていう話も
引き合いというか
アーティフォーマーとして出されてるって感じですね
どうすればいいんだいってところは結構
ふわっとしてて
結論GitGuardian使えっていう風に持っていきたいから
だったと思うんですけど
何使ってるのかちゃんと可視化しようとか
Unknownsは守れないから
知りましょうっていう
それはそうっていう話と
漏洩とかローテーションしたいってなった時に
どういう風に修復するのか
プロセスをきちんと組みましょうみたいなところ
1回頑張って修復して終わりじゃなくて
持続可能で運用可能なものを
ちゃんとどう組みましょうかっていうところと
あと3つ目があんまりよく分かんなかった
書いてあったけど
よく分かんなかったですけど
アイデンティティとアクセス管理を統合しましょう
みたいなことが書いてあって
IAMパムシフトマネージャー等を
全部一括管理しようみたいな
これをGitGuardianできるよってことが
言いたいんだと思うんですけど
まあまあまあ
っていうような記事でした
なんで結構面白い
というかこの辺
ふわっとしか分かんないなって人は
読んでみるといいかなと思ってて
クラウドサービスの権限管理
感想としては本当にそうですね
としか言えないというか
本当に難しいよねって
仕事で取り組んでそう思うんですけど
全部アグリで
GitGuardian使ったことないんですけど
1個ビジネスになっちゃうのは全然
納得できる
領域だなって思うし
あとなんかこれやりきりという会社
本当に少ないんじゃないかって
思ってて
全部追ってなるとね結構
そうだよね
どっか多分
妥協してるはずで
じゃあどこで妥協してんのかとかどういう優先度
つけてんのかとか
何は自動化で守って何はドロークサークでやってますか
とかそういうのってあんま
表に出せないよね
と思うけど
なんかそこが知りたいんだよな
みたいな気持ちで結構
なることが多いなとか
あとその最近
ここ半年ぐらいちょっと思ってるのは
これって結構対象両方
なんじゃないかなと思ってて
その
例えば物によってはですけど
APIキーちゃんと管理したい
ときにそのAPIキーが
設定できる権限が
そもそもなんかAdminはメンバー
しかないとか期限が切れない
とか最後に利用
した履歴が使用上取れない
みたいなのってすごいあるあるで
じゃあこれを漏洩したら
困るからなんかGitGuardian
突っ込んで管理しましょうとかRotation
頑張りましょうとかっていうやるのもいいんですけど
そもそも
APIキーとかは
Non-Human Identityを生み出す
側がちゃんとその必要最低限の
セキュアに運用するための仕組みを
整えてくれよっていう
のが結構
個人的に強く思ってるが
まあ
それをやるのも大変なのも
分かるんですごい
辛いなって気持ちで
しみじみ
思ってしますね
だからね実業務で
あるあるはなんかその
Google Cloud
ワークラウドアイデンティティ連携に
移行できるものは全部
順次こう着々と進めてるんですけど
もう原理上どうしても
無理みたいなパターンとかやっぱりあって
それ無理な理由はやっぱり
向こうが対応してないからなんですよ
僕らの気持ちとしては対応してくれよって
もうキー作りたくないし
Rotationも大変だし
自動化もやろうと思えば
できるけど
どうすとかかんのっていうのをやってよって
思うけど
そういういろんな気持ちが
湧き出る記事でした
サービス提供側としてはさ
なんで提供しないんだろうね
ニーズがないからじゃないかな
ニーズはあるんだけど
優先度が低いんじゃないかな
世の中みんな意外と気にしてない
そうだと思います
とりあえず僕もやっぱこの職種
職種というかポジションになるまでは
多分こんなに気にしてたかって言ったら
多分気にしてないし
ぼちぼちコンソール押してAPIキーばんばん
吐き出すとかやっちゃってたから
うーん
不条理っていうか
うーんみたいな
なんか
パスキーとかと感覚に似てるのかもしれない
僕ら目線は
パスキーにしたら全部
実は暗黙的に生まれてた
一般のコストが
全部とは言わないけど
90%くらい解決されるかもしれないけど
一般の人目線では
そこの莫大なコストっていうのは
見えてこないし
そのあった時に
分かりやすいやつでやってくれよみたいな
別にログインできれば何でもいいわみたいな
そういうギャップはある気がする
APIキーとかもワークロードアイデンティティ連携になった
できますって言った時に
ワークロードアイデンティティ連携ってなんじゃいみたいな
とかなるとか
そういう状態
とは言わないが
それよりもっと
サービス便利に使わせてよとか
UI良くしてよとか
そういうとこに積力が働いちゃうのはすごい
最新のセキュリティ動向
そうだよねとも思う
いろいろ思うところありますけど
そこは競争力になってほしい
競争力になると
今度はもう金が
当たり前の世界であってほしい
そうなんですよね
ベースラインであってほしいんだよな
僕は結構
カンサルグとかをめっちゃ課金しないと
使えないサービスとか結構
お祝いって気持ちで見たり
でもお金がかかる気持ちも
サービスを運営する側だから
分かるんで
難しいですねって感じです
オースゼロは素晴らしいよね
あーそうですね
間違いない
パスアドレスになることが
いいことだと本気で
思っているからこそ
フリープランでも
パスキー使えるよみたいな
話とかさ
みんなあってほしいな
そういう先駆者に
みんながついていくしかないんだろうな
難しいな
だいぶ本筋から離れる気は
するけど
セキュリティの領域で働いている人間って
誰しもが
大成り章なり
自分がいらない世界を
作るために
仕事をしていると思っていて
そうだね
そうだね
それは間違いない
難しいね
明日から現実へ向き合って
頑張っていくしかないですよ
セキュリティ製品じゃないものに
それを求めるのも
茶をかど違いなのかな
実際グラデーションあっても
いいかなと思っていて
そこに渡す情報の
機密性の高さとか
権限の強さ次第で
自ずと
そのサービスに求められる
セキュリティレベルが変わってくるっていうのは
自然の話だと思うから
それはしょうがないかなと思いつつも
一つは
最低限ここは守るでしょっていう
ラインがあるんじゃないかっていうのと
もう一つは
こんなに大事な情報を預けるのに
そんな機能しかないのっていうのが
正直
見かけることが少なくない
僕の感覚だと
そこはなんかちょっと
風潮変わって
風潮なのか
何なのかわからないですけど
世の中の流れというかね
なんか
まあそうね
今って当たり前が変わってほしいなって
気持ちがあるのかな
深い話
深い
みんなで解決してこうぜ
知らんけどみんなって誰だって感じだけど
はい
いっぱい撃っちゃったな軽めの
いっぱい撃っちゃうぞ
ちょっとサクサク
綺麗じゃないです
綺麗よくサクサクいこうかな
まあでも
読んでみてくださいGitGuardianは
じゃあ次も
僕なんですけど
これもHacker Newsで
タイトルはPyPy Repository Found Hosting
of a Crypt Wallet Recovery
Tools That Steal User
Dateっていう
記事です
記事のタイトル通りです
ほんとあるあるの
パッケージホスティングレジストリに
悪意のある
いわばマルウェアですよね
マルウェアが配信されてて
削除ちゃんとされてるけど
ダウンロードした人いたよみたいな
気をつけなきゃいけないよねみたいな
記事なんですけど
個人的になぜ追加したかというと
やり口自体はずっとあるやつだと思うんですけど
若干進化してるなというところで
記事に記載があったのは
まず正規のパッケージを装うために
結構作り込みがされてますと
セキュリティの重要性
リードミーにいい感じに書いて
なんならちょっと皮肉っぽく
記事に書いてあったんだ
安全なサンドボックス環境での実行方法
みたいなのがリードミーにちゃんと書いてある
みたいな感じで
悪い子じゃないですよアピールを
すごいきちんとやったりとか
あとOSSあるあるだと思うんですけど
結構メジャーなやつってリードミーに
スポンサーの名前がバーって並んでて
とか
こんだけシェアが広いんだよとか
いろんな
いわばアピールすると思うんですけど
そういうようなものをきちんと書いたり
偽のダウンロード統計みたいなのを
表示して
メジャーで正しいパッケージっていうのを
全力で騙しにきてるっていうところ
が一つあるのと
それはそうだよね
っていうのと
あともう一つは結構
実際に害がある振る舞い
我々として振る舞いをするタイミングが
僕が知ってないのだと
NPMとかはインストールした瞬間にもうだめ
みたいなパターンがあったりするんですが
今回紹介されてたやつとかは
インストールした瞬間とか
リクエストした瞬間とかじゃなくて
特定の関数に
それが仕込まれてる
みたいなのが結構特徴としてあるらしい
とか
また
それが発火した後の挙動としても
C2サーバーの
アドレスとかを例えばハードコードするみたいな
手法とかはもう今時だとバレて
しまうから外部ソースから取りに
行くみたいなところで検知を回避する
みたいなところ
僕はちょっと知らなかったんですけど
Dead Drop Resolverっていう手法らしくて
調べてみると
例えばドロップボックスに
C2サーバーのアドレスみたいなのが
多分書いたテキストファイル
とかがあってそれを読みに行って
それで通信を始めるとか
なんかその迂回
検知を回避するための拘束な
いろんな手法っていうのが
埋め込まれてるよとかでなんか書いてあって
GitHubに埋め込むとかは
わかるけどYouTubeに埋め込まれるパターン
とかもあるらしくてなんか要やるな
みたいな確かにYouTube
への通信を
ブロックしづらいというか
だから分かりづらくしてるんだろうな
って思った
気になったのはこれもう
なんていうか
こういう特徴みたいなのはちょっと
面白いなと思いつつ
でもこれ
もう何十回も見てきてる話なんで
やっぱそのパッケージ
ホスティングなんかPyPyとか
ノードだったらNPMとかRubyだったら
なんなんだろうRuby Bundler
ちょっとホスティングのほうはわかんないですけど
RubyGemsかとかに
頑張ってもらわないとちょっと
頑張ってもらうというか仕組みそのもの
の進化をいい加減しないと
いつまで経っても解決しないんじゃないかな
って気がしてて
そういう意味ではなんか
ノードJSでめちゃくちゃちゃんと
キャッチアップはできたんですけどJSRっていう
NPM互換のある
新しいやつで
いろんな面でセキュアだよっていうものが
出たりしてたんですけど
結構
セキュリティ面というよりは
ホスティング側
自体へのフィードバックが結構
辛辣なものを見かけることが多くて
いやー
むずいなーと思ったり
っていうか
気持ちいいですね
既存のやつに結構変化を求めるのは難しい
って話もある気がしててこのJSRは
1から作り直したから
1から作り直したからこそ
入れられた仕組みって多分すごいたくさんあって
それをじゃあNPMに今から入れてくれ
っていうのは
規模のでかさとかいろんなことを考えると
難しいっていうのがどうしてもある
気がするから
うーん
進化を求めたいが
まあでも別に何も考えてないわけじゃないんだろうな
っていう気持ちで
まあサプライチェーン
嫌ですねっていう感じですね
サイバー攻撃手法の進化
改めて思いました
いやー
これはこの特定の関数が
呼び出された場合にのみ
悪になる機能がトリガーされるっていうのは
うん
そっちのためなのかな
それともそっちのほうが
なんていうか
これボレットの鍵とかの話だよね
そうだね
ボレットの鍵を復元するよっていうライブラリーを
予想ってる
だからそっちのほうが
効率よくたくさん集められるから
とかではないのかな
どうなんだろうね
理由言及されてたかな
マリシアスファクションにトリガーと
オンリーウェンスサルティングファクション
アーコードメイキング
インターフローム
典型的なパターンとは違うよ
っていうところしか
そうだね
確かにな理由はどうなんだろうね
うん
感覚的にもそっちのほうが
たくさん
集められそうだけどね
インストールして
取りたい情報が
インストールした環境にないんじゃないの
これって
そうかもね
なるほどね
ケースバイケースだと思うんだけど
それは確かに
ローカルでは検知を回避しつつ
実際に発火させたい場所はデプロイ先みたいな
パターン
それはあるかもね
確かに
ありそう
その辺の言及はないですね
うん
これは
でも難しいよね
難しいですね
うーん
まあ
難しいということを
改めて分かったという
ジャブ記事です
うん
うーん
あと進化を求めたり
JSRいいぞみたいなこと
コメントで書いてるが
結構でもある気はしてて
まあな
うーん
難しいですよね
だから先々先週ぐらいに
読んだ
マルウェアの悪になるコードの
遺伝子みたいな話とか
あれぐらい
本当に根本解決しようとするなら
発想変えなきゃいけないのかもな
うーん
リリースノートに対して
コードのバージョン間の
差分がそのリリースノートに対して
不自然だよっていうのは
なんかAIで
なんとかできたりしないのかな
LLMとかでなんとかできたりしないもんかね
ああ
それできたら結構違うかもね
うーん
精度低すぎたら困るけど
60%ぐらいの
セーニング
いやー一定の精度があれば
ワークしそうワーニングを出すみたいな感じ
うーん
原理上はできそうだけどね
まあでもそれは先々週の
先週か先々週の
うーん
とかなんかそういう記事どっかで読みたいな
なんか分かってこないかな
そのあれじゃん脆弱性を修正するって記事
はなんか先週か先々週ぐらい読んだけど
そうだね
怪しいのを検知するみたいなところは
確かにどれぐらい技術が進んでるのか気になるところですね
確かにそれで原理上
それができればそのアップデート差分を
確かにできそう
できればなんかGitのリポジトリ丸ごと
食わせてさ
そうだね
このプリリクエストにこのコミットがひも付いてるのはおかしいと思います
とかさ
だからこれ怪しいですとかさ
なんかやってくれてもいいよなんて思うし
確かに明日GitHubコパイロットで試してみようかな
なんかコパイロット
そのうちGitHubがそういうの出したりすんじゃないかな
確かにね
今コパイロットが
GitHub上で動かせるようになってて
うんそうね
リポジトリの内容を全部スキャンして
インデックスするっていうのができるから
その状態でこのリポジトリの
脆弱性とか怪しいこと見つけてっていう
言えばなんか
ちょっと今時点分かんねえな
うん
確かに
そんな感じでございます
はい
大丈夫ですか疲れてるんじゃないですか
大丈夫ですもう読んでないから今
ほぼほぼ喋ってない今
ありがたいことに
ガツガツいきますよ
えーっとじゃあ
次の記事は
ハッカーニュースです
ハッカーニュース 私もハッカーニュースで
Free Sniffer DZ Fishing Tools Fuel
14万以上の
Cyberattacks Targeting User Credentials
っていうところで
記事の内容としては
スニファーDZ
スナイパー
フィッシングアザーサービス
の話で
これの被害が結構出てますよ
って話なんですけど
過去1年で見ると14万件以上
これ制のフィッシングサイトが
見つかっていて結構シェアが
大きいっていうところと
あとこれ無料で使えるフィッシングアザーサービス
っていうのが
今ならフィッシングが無料
たまったもんじゃねえや
マジで
なんで無料かっていうと
利用者目線でこのサービスを
使うときにまず大きく
二択あって
多分
ぽちぽち画面を
押していくと
フィッシングサイトが出来上がります
っていうような使い方
SaaSみたいな使い方をするか
もしくは自前のインフラにそこから引っ張ってきた
テンプレートをホスティングするか
っていう二択がまず選べる
らしいと
無料で提供して
できてる理由は
この二択のうち全社の
Sniper's DG上でホスティングする
パターンの場合は
攻撃が成功したときに
利用者ももちろん
成功した情報を
もらえるんだけど
Sniper's DG上にホスティングされて
Sniper's DG上のDBに
その盗んだ情報が入ってくるので
利用者も得するし
同時にSniper's DGさんも
情報をもらえるので
おそらくそれで無料で成り立ってるんじゃないか
っていうところですね
なので騙す相手を選んできて
メール送って引っ掛けるとこまでは
無料で利用してる人がやってきて
その成果は
山分けじゃないけど
等しく成功をもらえるっていうスキームになってる
TelegramとかにこのSniper's DGの
コミュニティ
Telegramは使ってないんでよくわからないですけど
そういうものがあって
ツールの使い方
なんかもう
すごい世界だなと思ったんですけど
そのツールの使い方が
がっつり解説する
チュートリアル動画がYouTubeにあったりもする
みたいな感じで
なんというか
詰まるところ
僕らの知らない世界で
ブラックハッカーになりたいって
志した知識のない人が
いた時に
すごくいい入り口になってしまってる
まずはここでフィッシングサイトを作って
メールで送って騙さない
なんかして
そうっていうところの足掛かりになってしまってる
っていうのが記事で触れられてたところですね
まあ
個人的に思ったのは
ランサムエアーザーサービスと
しっかり
組織化厳しいなっていうのは
引き続き思いつつ
守る視点だと
法的にできるのかわかんないですけど
このフィッシングサービスに
登録して
見に行った時にたぶん
画面とか見てないんでわかんないですけど
たぶん
テンプレがある
わけじゃないですか
このカード会社のフィッシングサイトを作るみたいな
テンプレがバーってあってポチッとしたら作れるみたいな
仕様になった時に
そのテンプレに自社のサービスが
登録されてることを
検知できれば狙われ始めてる
ってことがわかるんじゃないかっていうのを
ふと思ったが
そういう意味で観察してみたいなと思ったけど
なんていうか
その理由でアカウント作って
フィッシングサイト作んなかったとしても
日本だと捕まりそうとか
よくわからんな
あんま近寄らん方が
いいとは思うけども
そうだよね
登録するだけでどうかはさすがにないとは思うけども
実際そういう仕事をしてるわけだしね
大丈夫だとは思うけど
なんか
普通にテイクダウンできないのかな
このサービス
確かにね
インターネットの
便利さが裏面に出てるよね
この辺の捕まえられなさというか
その辺が完全に
どこでホスティングしてんだろうね
この大本の
サービスを
上手いこと隠しちゃってるんだろうし
よほどその
なんていうか外からテイクダウンできない国で
ホスティングしてるとかじゃない限り
こういうことって多分起こらないはずだからさすがに
なるほどね
守ってるそういうのを守ってる
ところで
ホスティングをしているはずで恐らくね
なんかそういうあるあるの国とか
あるんだろうな知らんけど
それこそフィーズとかで引いたら
わかるかもしれないけど
まあいいや
そうですね
なんかこれテンプレを
プラガフルとかにして
お好きなテンプレを追加できますよ
とかしたらもっと流行ったりするんじゃないかな
とか思ったけど
流行らせる目線で言うと
そうかもね
それはそうかも
なんか皮肉だな
拡張の余地は結構ありそうだよね
流量テンプレートとかさ
いや広い世界だな
スナイパーDZで使える
テンプレートをいくらで売りますとか
それだけでも成立しそうだな
と思ったけど
この経済圏は面白いね
成り立っちゃってるのが
一生自分がその中に入ることはないだろうけど
面白いね
成り立っちゃってるのが結構
なんか
わかんないけど
最近キャッチアップした
いろんな人の
コメントの温度感を聞くと
こんな組織化というか
分業が進んでるのここを多分
最近の話みたいな
聞かぬこともないんだけど
なんでこんな
IT業界が成熟したように
こっちも成熟してるって話なのかな
なんだろうね
うん
ランサムもフィッシングも
なんていうか結構
あれだもんな
いやわかんねえな
いいやそういう記事でした
じゃあ次いきますね
マイクロソフトのエッジエクステンションの更新
えー
これも
これはヤギ足が追加したやつを
僕が読むっていう
マイクロソフトオーバーホール
セキュリティフォープラブリッシュ
エッジエクステンションという記事ですね
マイクロソフトが
エッジのエクステンションを
公開するときの
セキュリティ周りの
エクステンションを使用しましたよ
という記事でございます
紹介お願いしてもいいですか
ざっくり言うと
APIを
多分
拡張機能を公開するAPIみたいなのがあって
リリースを自動化するときとかに
使うようなAPIだと思うんですけど
それのバージョンを更新しましたよ
ってところで
ざっくりしようとしては
まず初めて拡張機能を公開するときには
パートナーセンターっていう
コンソールみたいな画面を通して
アップロードする必要がありますと
なんでAPIとは違いない
API経由ではアップロードできませんと
初めてアップロードしたときに
そのまま
多分公開されるんじゃなくて
内部的に何か
審査がされてるっぽいのかな
その審査みたいなのがあって
それが承認されると
公開されると同時に
次以降そのAPI経由で
公開するための
APIキーが発行されるようになる
このAPIキーが
72時間で自動で切れる
みたいなものになっていて
なんでそのAPI経由で
拡張機能を公開するっていうときに
このAPIキー
発行した瞬間に受け取ったAPIキーがないと
API経由での公開ができないようになる
っていうのが
使用変更としてある
何が変わるかというと
使用知らないと多分ちゃんと
差分勝てないんですけど
この仕様になって担保されるのは
APIにアクセスするための
クレデンシャルみたいなのが
手に入れる経路が
コンソール操作できる権限がないと
多分無理なのかな
一番最初に公開して受け取った人が
これを拡張機能の公開API経由で
受け取った状態になるんで
既存のメジャーな拡張機能を
乗っ取って悪になるやつを
上げるみたいなことの難易度が
ちょっと上がったのかなっていう感じですかね
キー自体も
有効期限がそこそこ
長いか短いかは
判断難しいですけど
72日間で終わるんで万が一漏えいしても
漏えいしたらダメだろうな
でも永続的にやられるもんではない
っていう状態にはなるのかな
このキー自体の再発行とかは
多分無くしちゃっても
パートナーセンターに入れば
再発行はできそうな感じになって
これ自体はおそらく
マイクロソフトのアカウントで
ログインしないとダメなんで
そこ経路に乗っ取りはしづらいかも
っていうような感じですね
既存
感想はそんなにないんですけど
拡張機能はやっぱ
危ないよねってのはずっと
みんな分かってたことで
この辺の対策進むのはすごいいいよねとか
またChrome今どうなってんのかとかは
ちょっと分かんないなと思ったんで
Chromeと比べてどうなのとかは
ちょっと気になったな確かに
ちょっとそれは
今日はリサーチ間に合わなかったですけど
調べていこうみたいなっていう
ところっすね
Chromeの方が進んでそうだけど
知らんが
Facebookのパスワードの管理問題
どうなんだろう
どうなんだろうね
まあいいやそんな感じです
ありがとうございます
じゃあ残り
4つぐらいですか
駆け抜けていきましょうか
これもな
おもろ記事というか
ブリーティングコンピューターの
記事で
ファインメタ
91ミリオン
ユーロ
ホルスターリングパスワード
インプレインテキスト
っていうところで
記事のタイトル通りなんですけど
Facebookが誤って
パスワードを平文で保存してましたと
希望感としてはすごくにん
希望らしくて
やっちゃってましたっていうのは
アイルランドに自主じゃないですけど
自ら申請しましたと
それに対してアイルランドの裁判所
なんですかね
法令に基づき罰金が課されました
というような記事ですね
罰金自体1億ドルなんで
何桁何桁だろうか
という規模の記事なんですけど
開示自体
できてませんでしたって
開示自体は2019年に行われたので
多分5年ぐらいかかって
この判決が出たって感じで
具体的に何に違反したかっていう
ところが
いわゆる複数の情報に違反してるので
罰則ですっていう
状態になったらしくて
その辺具体的なやつは記事に書いてあるので
気になる方は読んでほしいんですけど
記事中で4つほど触れられてて
パーソナルデータの扱いみたいなところが
多分商店になりそうかな
っていうところですね
なんとなく当時のこと
思い出してきたんだけど
元のニュースリリース読むと書いてあるんだけど
インスタグラムの
ログの話なんだよね
あーなるほど
インスタの方か
インスタ
メタがインスタ回収したのっていつだっけ
えー
わかんなすぎるな
いつだろう
買ってきたらそんな感じでしたで
罰金払わされたら
きつそうだなって思って
あーでも2012年の
記事 あーだいぶ前か
相当前だね
まあじゃあ7年あったらどうにか
せいだったのかもしんないね
そうだね
いやでもとはいえだよね
とはいえきついな
まあでも結構なんか
きついなって思うのはログ
うんうん
割とその機微情報がログに出ちゃってるって
その
どこでもあり得る話だと思うし
そうだね
どうしても後回しになっちゃってる
そういうのが多いんじゃないかなと思っていて
それがたまたまパスワード
でしたよっていう話
だと思うんですよね
そうだね
それだからGDPRの罰則で
なんかめちゃくちゃ
罰金取られるって
うーん
なんかこれが果たしてその
なんて言ったらいいんだろうな
これが果たしていい方向にいくのか
僕ちょっと疑問で
そうだね
いかないかなと思っちゃうんだよね
いやー
言いたくないけど隠し
既になんならそういう記号があっても
あんま驚かないかもな
うーん
いやー
今回要は自分で申告したなと思うけど
なんていうか
いやヨーロッパで
サービスを展開してる国内外
含めたサービスが
徹底してこれできてますかって言われると
なんかそもそも
GDPRの影響とメタの問題
正確にできてないパターンもあるだろうし
じゃあできてないってなった時に
じゃあこれメタと同じように
裁判所行って開示しましょうか
みたいになった時に
あのアホみたいに高い罰則を受ける
覚悟
いやー
あるべき姿としてはそうなんだけど
でもそうだね
確かに
隠してる会社があっても驚かないです
僕は
うーん
これね
これきついよな
GDPR対応し
いやーあとなんか
そうだね
ヨーロッパでサービス展開したくないなと
思っちゃうよな正直
思っちゃうよね
結構しんどいなと思う
やりたくない
うちはさえやってないんで大丈夫なんですけど
うーん
一応ねその
はい確かに
きついね
これは
あーちょっとなんか
いやー
わかんないなー
うーん
これがあるからちゃんとしようでちゃんとなる
ものかというと
なんか厳しい部分が絶対あるはずで
そうだねそうだね
もちろんねこれがあるからちゃんとしようっていう
その方向に働く部分も
まあ間違いなくあるとは思うんだけどさ
うーん
なんか
そうねー
どういうその腹の底はどういう
スタンスなんだろうねそのGDPRを
運営する側その
牽制として
なんかもうどうせ自己申告しないでしょ
っていう前提で牽制としてやってるのか
いやもう徹底的にやるぞなのか
なんか
前者だとしたらなんかメタはちょっと
気の毒というかまあでも
いやー
まあやった方がいいんだろうな
こかつとかで変なことになるよりは
なんかでバレたらね
もっとひどいことになるのは間違いない
と思うし
その
まあちょっと経緯がわかんないけどね
何らかのあれでバレたから
そのちゃんとニュースリリースを出しました
みたいな経緯かも
もしかしたらそういう経緯かもしれないから
まあまあ確かに
ちょっとわかんないけれども
ただまあ
何せよその
まあしょうがないね
会社としてはやることやってますっていう
話だとは思うし
うーん
これもパスキーで解決しよう
パスワード安定
あーでも
いや冗談だよ冗談だよ
パスワードが別に
あの鍵に変わるだけでしょ
国会鍵に違う
国会鍵は別に
そうだね漏れても問題ないから
まあもちろん漏らしてもいいわけではないんだけど
うーんそうだね
確かに
守るものを減らしたいな
って気持ちが
まあできたらやってるわ
って感じなんですけど
でも逆張りでさ
なんかEUとかだとさ
そのなんていうか
こうパスキーでしか
ログインできないサービスを提供してはいけません
とかやってきそうじゃない
ある種のさそのロックインが
あるわけじゃん
あープラトンウェザンとかってことね
まあそのロジックだったら
ワンチャンねじ込まれそうな
気がした
やりそうだよね
いやーなんか
マッチポンプもいいとこだよな
頑張って
いやーなんか
そうだね
絶望しかないけど
この前
話したか忘れたけど
EUからの
AppleとGoogleに対する占めつけも結構なんか
個人的には
ちょっと
誰の
なんの幸せなのってすごい思っちゃうんだよな
そのアプリプラットフォームのさ
ブラウザ独占
別にあれも
あとあれか手数料の話とか
直近だから来週の記事かな
プレイストアが
はいそして
プレイストア以外からも配信できるとか
やつが確かあったんだけど
サイドローディングの話
あれもなんか
いや
視点が
難しいけどな
独占してるって
確かに分かるんだけど
Google以外がGoogleと同じ
安全レベルでそのプラットフォーム運用できるんですか
っていう
現実問題
誰が解くのって解いてくれないじゃん
裁判所は絶対
その
その歪みというか
なんかな
GDPRもそうだよな
言ってる方は正しいと思うけど
運用するのは
中小
企業も企業の規模がかかる
お前らがやれよって言われて
なんか
そうなんだけど
みたいな
感じだよね
それでもGoogleは
ヨーロッパでのサービス展開をやめないし
Appleも
ヨーロッパでiPhone売り続けてるし
だから
バランス取れちゃってるんだろうね
確かにね
逆に大きなところしか進出できなくなりそう
だけどね
Google Pixelのセキュリティ
なんか
悪意を持って解釈するのは
そういう法令だとも
思えるしね
そもそも自分の経済権を守る
じゃないけどさ
そうだよね
相当しか取れない部分は
どうしてもあるよね
そうですね
はい
ヨーロッパに
思いを発していきましょう
コメントができてるようになってきてる
残り3記事くらいだとね
こういうテンションになっていっちゃうんで
どうしてもね
テンション上げていこう
次の記事面白いからテンション上げていこう
次の記事面白いよ
面白いですね
これも僕が
追加したやつですけれども
Googleセキュリティブログか
Googleセキュリティブログか
Pixels Proactive Approach to Security
Pixels Proactive Approach to Security
Addressing Vulnerabilities in Cellular Models
っていう記事で
これ僕もちょっと文外観なので
ふわっと
頑張って読んで
ふわっと求めたものを話すと
携帯の
物理携帯ですね
物理スマートフォンの
1コンポーネント 多分ハードもソフトも両面だと思うんですけど
1コンポーネントとして
セルラーモデムスっていうのが
ありますと
セルラーモデムスって何かっていうと
ざっくり文脈的には
電波を受け取る部分の
ハードウェアおよびソフトウェアっていう風に
解釈していいかなと思っていて
ここの部分に
脆弱性が
ソフトウェアが動くんで
ありますと
あることがありますっていうところに対して
じゃあピクセルがどう対応してるかっていうのを
詳しく書いてくれてる記事
です
で その前提のもと
記事の内容をもう少し話すと
このセルラーモデムスっていうのは
これ読んで確かにって思ったんですけど
性質上 信頼できない
任意の値っていうのを
受け付けるインターフェース
なので
悪意のあるものが入ってくるっていうのを
想定しなきゃいけないですと
なんのこっちゃいって言うと
例えばニセの基地局建てて
そこから脆弱性をつくような
悪意のある電波を流すみたいなことが
実際の攻撃としても多分ある
らしいし
それに対してちゃんと備えなきゃいけないよ
っていうのがありますと
その辺に対してピクセルは
頑張ってますっていう話
この辺投資するのってすごい大変なんだよ
的な言い合わせが書いてあって
結構パフォーマンス制約が厳しいプロセッサーを使ってるので
他のスマホはできてないんだが
ピクセルは頑張ってるぜみたいなことが書いてあって
そうなんだぐらいの
感覚なんですけど
具体的に何が頑張ってるかで言うと
結構
これちょっと詳しくは読んでほしいなと思ってて
すごいたくさん書いてあるんで
あれなんですけど
教科書に出てくるようなメモリ系の
脆弱性の対策がすごい書いてあります
何ていうか
パフォーマンフローとか
あれかな
丸目誤差で起因する云々とか
それも結構基本的なものが書いてあるなって気はしていて
ただ基本なんだが
その基本守るのがどんだけ難しいかって話で
そこに対してかなり力を入れて投資をしてますっていう
具体的にはバババンってやるとか
ラスト2コースとか
他のGoogleの記事でも触れられてるようなところを
すごいやってるんだよっていう話が書いてあるって感じです
結構なんか
こういう世界なるほどなって思ったっていう
あんまりそんなめちゃくちゃ
なんかこれを受けて
話したいことってそんなにあるわけじゃないんですけど
結構面白いなと思ったっていうところですね
面白いですね
なんかこれは
本当にどうにもなんないのかな
要はその通信方式としてこれを守るとかって
要は偽の基地局が立ってて
偽の基地局が発した電波を処理してしまうみたいな問題って
通信方式そのものの改善とかで
なんとかなったりしないのかなと思うんだけど
そんなにそんなところにリソースは割けないっていうレイヤーなのかな
ここまでいくと
わかんないけどその受け取る
それが正当なものかどうかを判断するために
一旦インプットしなきゃいけないっていうのは
多分どんなスキームでも変わんなくて
そうなった時に
インプットしてたらアウトみたいな脆弱性が
あるって話なんじゃないかなと思った
なんか
で本当はそんな脆弱性つくんだよって話なんだろうけど
実際もう
いっぱい出ちゃった実績中からどうしても
潰し切れてない部分があるから
だからこそめちゃくちゃ投資してるよみたいな
多分論調だったかな
EUの法律と企業の挑戦
なるほどね
これ見て思ったのが
車の世界もちょっと近いのかもなって
ちょっと思って
今その
通信方式そのものの改善とかで
なんとかならないのって言ったのは
車のことを思い浮かべながら今
話したんだけど
車の要はキャンって呼ばれてる
コントローラーエリアネットワークとかは
新しいやつは
そこに接続できる機器
参加できる機器
そのネットワークに参加できる機器っていうのを
なんていうか
暗号技術とかを
使って一定制限してる
みたいなのがあったりとかして
そもそも繋いでも
なんもできんみたいな状態にしてたりするんだけれども
でもそれでも多分
その
一発目何か受け取って
処理をするっていうところは絶対あるはずだから
だから多分そっちもこういう
ここで上がってるような
やり方にもしかしたらシフトしていくのかもな
アンドロイドと物理カード
とかはちょっと思った
たしかにね
なんか車の場合は
まだもしかしたらやりようあるのかもね
結構端末側の
いやでもどうなんだろうそんなことねえか
まあでもその
ハードルみたいなのは
スマホのほうが低いんだろうな
アンドロイド
物理的に接続する必要がないので
いくらか楽
っていうのはあるかもしれない
車はもう配線につなぎに行かないといけないからさ
そのソフトウェア
自体もアンドロイドはもう
OSSだろうか
一部
読みに行けちゃうというか
見に行けちゃう部分もあるだろうし
たしかにね
車とか原理上そういうのが
あるっていうのは結構知っといてもいい
さすがにアンドロイドのレイヤーの話じゃないでしょ
これ
ドライバーとかそういうレベルの話でしょ
まあそうなのかな
確かに
関数
セルラーバイス
まあ確かにそうかも
いやでもどうなんだろう
ドライバーとかもっと下のレイヤーじゃないの
この
セルラーモデムが何を指すのかな
物理的にどんな姿なのか
想像がね
そうなんだよ
ピクセルモデルみたいな書き方をしてるな
まあでも多分ハードではあるんだろうな
そのプロセッサーみたいな
言及があるってことは
チップ
物理レイヤープラスそこに
搭載するソフトウェアの話
だから確かにアンドロイドが
さらに下に叩きにいく
レイヤーなのかもね
うんうん
確かに
そうだね
いや
まあ
頭が上がんないっすな
はい
そんな感じです
じゃあ次も物理ですかこれは
物理物理
まあ物理の話もありますね
次はクレジットカードを製造する技術
というタイトルでございます
久々に私の出番ですね
皆さまお久しぶりです
これもさっきの
ウェブセキュリティの歩き方と一緒で
ヤプシーの函館
10月5日の
ヤプシーの函館で
なんだっけ
スマートバンクの
オリーさんが発表してたスライドらしくて
公演は見てないんだけど
スライドだけ流れてきたのを
拾ってきたっていう感じですね
はい
これもなんていうか
サマリーを書いて紹介するには
ちょっと
あまりこの場が
適切じゃないっていうのがあるので
パスワード漏洩検知機能
皆さん読んでみてください
っていう感じなんですが
一つ思ったのは
これを体験する機会っていうのはなかなかないな
っていう風にちょっと思って
うーん
ないね
本当にガチで
自分のところで物理カードを発行しましょう
っていうのをやろうと思った時に
何が起こりますか
っていう話
うん
いやー詳しいな
そうなんですよ
いやー
メールカードとかもこれやってたりしたのかな
実は知らないだけで
やってるんじゃない
物理カードがある以上はさ
多分やるよね
こういうの表に出してるところがまず珍しいよな
あー確かにね
書いてあるから
社内の資料を読み合わせるより
こっちの方がなんか僕は
読むことができるんだけど
あるのかないのか知らんけど社内の資料が
いやーでもこれまとめるのも大変だよな
結構さ
eludeでまとめてくれてるよね
絶対その細々したさ
わからない書類仕事とかさ
そういうなんかすごい
詳しく書こうと思えばいくらでもなんか
事務的なプロセスとかもあるだろうけど
結構要点要点を抑えて
技術的なところとかね
抑えてくれてるから
うーん面白いねー
いやー
やっぱ
RSAに刺されてきてるなー
RSAとは限んないか
RSAとは限んないけど
いやー
面白いですね
面白かったです
ぜひ読んでみてください
よし
はい
じゃあ本日は
最後ですか
えーっと
これも私ですね
クラウドフレア和風のパスワード
漏洩検知機能についてっていう
全デブの
カメオンクラウドさん
クラウドフレアジャパンのエヴァンジリスト
がそうです
なるほどね
真っ当な人の真っ当な記事を
僕は引っ張ってきたわけですね
ありがとうございます
タイトルの通りでクラウドフレア和風の
パスワード漏洩検知機能について
紹介してくれてる記事で
はい
えーっと
どこから
話していけばいいかな
デフォルトオンになってるらしくて
チェックかけてくれてるらしいです
設定変更すると
ブロックを
したりとか
MFAの要求をしたりとかが
できるよっていうのを紹介してる
記事ですね
デフォルトオンで
チェックかけてくれて
オンに出てるよみたいな話を書いて
くれてたんじゃないかな
これはこの記事に書いてあったんだっけな
もしかしたらクラウドフレア
側のドキュメントを
僕見たかもしんない
そんなこともないかもしれない
合わせて読んでみてくださいって感じなんですが
えーっと
フリーとか
安いプランと
フリーのプランなのかなちょっと分かんないけど
デフォルト
難しいなデフォルトだと
特定のその
製品群の
特定のリクエスト
のパスワードだけを
披露っていう形になっていて
例えばDrupalとかJoomla
とかWordpressとか
そういうものの
パスとパラメータ名が基地のもの
よく知られてるものだけしか
見てくれないんだけれども
エンタープライズプランだとフィールド名とかいじれるので
任意の
パス任意のパラメータで送ってる
っていうのをチェックかけられるようになるよ
っていう
感じらしい
でHave I Been Pwnedの
データベースと
クラウドフレア独自のリストでチェックをかけて
くれるよっていうものらしくて
概要としては
そんな感じなんですが
和風でやるの
結構頭いいよなと思っていて
これは
ユーザーコミュニケーションの課題
アプリケーション側でやろうとすると
結構だるいんですよね
作り込みとかも
多いし
和風でやってくれるんだったら
楽ちんだなと
あと追加認証を求める場合の
動きがどうなるのかが
記事の中だけだと
よくわかんなくて
これはクラウドフレアの和風触ってみないと
何とも言えないんだけど
ドキュメントを見た感じ
たぶんリクエストの
リライトをしてどっかに飛ばすとかを
やってくださいね
っていう話なんじゃないかなと解釈したんだけど
ちょっとわかんない
確かにそうだよね
クラウドフレア側が
そのMFAの再設定
そのサービスのMFAの再設定がどこか
わかんないもん別に
なるほどね
確かに和風でやるの頭いいっていうのは
確かにそうかも
あとはこれ
使いたいなちょっと触ってみよう
どこまで細かくカスタマイズできるかが
本番導入できるかっていう部分は
大事かなって気はしてて
実際のサービスでやったときに
じゃあうちのサービスに途中から
導入するってなったときに
導入する前のユーザーが脆弱なパスワード
使ったらブロックされちゃいました
とかだと困るじゃん普通に
なったときに
どういう仕様にするんだっけとか
その分岐をこの機能の
中に作り込めないと
結構今から作るサービスとかが
ある人とかはいいかもね
っていう感じだけど
でもアクションの
いろんなアクションがあって
使えるから
なんとでもなるんじゃないかな
それこそパスワード変更ページに案内するとかも
できると思うし
いやーでも
ログ残すだけでも
そうですね
ログ残してエクスポートして
元に
パスワード変更メール来るとか
結構難しいよそのコミュニケーション
あーなるほど
いや分かんないけど
なんも訳分からん人たち
もいるわけですよ
まぁまぁそうね
怖って思う人も多分いるわけですよ
何をされてるのか分からないっていう人たちはいるわけで
そういう人たちに対して
なんていうか
あなたのパスワードまずいんで
その帰ってくださいってコミュニケーション
取るのって結構難しい部分があると思っていて
やり方間違えたら
燃えそうだね
できるだけその
自然にいい方向に持っていくか
あるいは別にパスワード変えなくても
大丈夫な形に
誘導するかどっちかだと思っていて
なるほど
別にやってもいいけどね頑張ってもいいと思うよそのコミュニケーション
結構大変だよね
確かに
いやー
それでいうと
その機能の届けたい価値とは
違うのかもしんないけど
単純に
危ないアカウントリストアップとしても使えちゃうのかな
ブロックとか
リライトせずにログだけ残す
そうそうそうそう
それはありだな
別にそのリスト作れば
自動でアクション取ったほうがいいと思うけどね
そのタイミングでさ
まあね
でもその
危ない
ログ絵積みのパスワードを
使ってる人数を把握したいっていう
ことだけを
考えた時に自前実装をしようと思うと
結構めんどくさいわけじゃないですか
それがこれポンって
入れてできるのはいいかもなっていう
もちろんアクションまで生かしきったほうがいいのは
間違いないんだけど
まあでもログインアクションした人
しかできないから
全ユーザーはあぶり出せるわけではないんだよな
あとはパスワード変更で
これかませるとさ
脆弱なパスワードを登録させないってできるよね
多分
そうだね確かに
パスワード変更のパスで
そういうパスワードが入力されたらブロックする
できるわけじゃん
うまくやんないとちょっと
エンジニアの
実装ちょっとだるそうだよね
どっちで何が動いてこうなってんだ
分かる分かる
結構工夫は必要かもね
パスワード変更まで
持っていくこと考えるとやっぱアプリケーション側に
持たざるを得ない気もするな
でも結局
クラウドフレア独自の
アクションで
多分いろんなことできると思っていて
要は
リクエストにフラグ立てをして
クラウドフレアとオリジンのセキュリティ
オリジンに渡すとかもできると思うんだよねきっと
なるほどね
要はだからこれはパスワード変更のリクエストだけど
なんていうか
ロエパスワードチェック引っかかったよっていうのを
クラウドフレアからオリジンに渡すときに
リクエスト立てしてあげれば全部アプリケーション側で
できるわけじゃん
だからアプリケーション側はこのフラグが来たら
クラウドフレアがそういう判定をしたことだから
エラーで出すみたいな
っていうことだよね
まあね
まあ
確かにそのぐらいだったら
なんか時代感じるなすごい
複雑ではあるよね
でもそういうの結構あるんじゃない
なんていうか
オリジンで使ってさどこの国からのアクセスから
アクセスからを判定するとかもさ
多分
何らかリクエストにそういうパラメーターを
くっつけてオリジンに送って
オリジンで判定するとか普通にユースケースとして
はあると思うし
確かにその辺の経験積みたいな
なんかその
あんまそういうところをがっつり本番用
自分が直接やったことないからさ
そのオリジン側に
こういうヘッダーとか
こういうフラグをつけたらこういう
使用を入れるわけじゃん
そこでまた多分
そこはそこで考えなきゃいけないことが
出てくる気がしてて
その辺のセキュリティとかあんま
変えそうとないから
面白そうだし面倒そう
面倒そうと
ただヘッダーにしちゃうと
パラメーターのスキーマとか使えなくて
だるいみたいな話とかもあるから
あーなるほどね
クエリにして
本当はね
変なことできない
クエリにするとさ
クラウドフレア通さなかったときに
つかないパラメーターがあって困るとか
また出てくると思うしさ
本当に面倒くさい
いやーでもまあ
弊害を感じるよね
そうだねというかなんか
令和の開発って感じがする
フルセット揃えないとなんか
機能しないみたいなのすごい面倒くさいな
と思うんだけど
できるけど
まあまあ
ちょっと
難易度上がってきちゃうよね
いやー
まあでもクラウドフレアすごいな
よくやってるわ
いやーちょっとさ
いやー頑張って触ろう
クラウドフレアね触れてないんですよね
リプレイフェームの
わかんない
なんかめっちゃイケてるLPとかホスティングするか
いやーやりたいやりたい
今度なんかちょっと書きたいし
勉強したいわ
LP何書くんだよ
めっちゃいい感じのアニメーションで
読んだ記事をバーってなんか
動かすか
まあでもそれこそ
RSSのホスティングとかも
全部そこでやればいいじゃん
あー確かにRSSホスティングするの
面白いね
ポッドキャストのあれもさ
ベースはRSSだから
音声ファイルとか
音声ファイルとかをクラウドフレアに置くと
高くつきそうな気がするから
ちょっと悩ましい気がするけど
いやーいいよその
音声周りのホスティングはもう一等分
Spotifyポッドキャスターで
でもこの読んだ記事を
ここで読まれた記事を読みたい
っていう需要があった時に
これのRSSがあると結構いいかもしんない
いやー
違うんですよ僕がその似たような
ことを思ってる
その某まとめがあるんで
あーそうそうそう
でその手で読みに毎週
毎週のトゥードに積んでるわけですよ
月曜ぐらいに更新されるっぽいから
月曜に開いて
あ更新されてなかったってなって
なんか支枠するとすごい差分がガッとくるみたいな
そういうの別にRSSにしたいなとか
まあパーサー
書いてもいいのかもしれないですけど
とか
まあそうですね確かに
いやーやっていきたいですね
いやー
ゲスト
ゲスト呼びたくなるし
悩ましい問題も多いし
いやー
EUさん
まあでもしくしくと頑張ろう
学びが多かったですね今週も
なんか
良かったね
バランスがいいっていうか
めちゃくちゃ
この記事とこの記事で超お時間
使いましたみたいなのが
今週はなかったから
こんぐらいの感じでいけるといいのかもしれないけど
まあまあでもいいよ話したいように
話せばいいよ
今週はね僕が
先週サボったんで
いや先週サボったわけじゃないですけど
今週はちょっと時間あったんで頑張って
骨粒を集めた感があるから
うん
いやー
いやー
いや来週もやりますとかそういうわけじゃないですけど
持続が一番なんで
今んとこで
でもね来週分結構
薄味な雰囲気があるんだよね
本当
なんかわからない俺が追加した記事はそんなにない
今のところもう木曜日だけどそんなにないから
ちょっと薄味なんじゃないかな
まだちょっとあれだな
まあ来週は来週で
じゃあちょっと楽しみにしましょう
僕がまだ全然
追加してないんだよな
うん
はい
いやーありがとうございます
いやーありがとうございました
木曜は疲れているということが
よくわかる回でしたね
年だな
夜遅いからなんかその
なんか
ちょっとあれなんだよな別に
近所迷惑になってるわけじゃないけどすごい
なんかねだんだんね夜のテンションになってくっていうのも
あると思います
あー
一回さ朝とかに
あー朝か
子供いるからきついか
昼とか
昼はありだね
昼は全然あるかな
1時間1本勝負
昼にやったらなんか全然テンション違ったりしてね
確かに
やってもいいかも
まあちょっと模索していきましょう
はい
ポッドキャストとRSSホスティングの可能性
そんな感じで第5回お送りいたしました
また来週も
お楽しみください
おやすみなさい
01:49:36

コメント

スクロール