S3 Ep95: Slack リーク、Github の猛攻撃、ポスト量子暗号 [オーディオ + テキスト]

下の音波をクリックしてドラッグし、任意のポイントにスキップします。 あなたもすることができます 直接聞く Soundcloudで。

ダグ。  Slack リーク、いたずらな GitHub コード、ポスト量子暗号。

Naked Security ポッドキャストで、これらすべてをご覧ください。

【ミュージックモデム】

皆さん、ポッドキャストへようこそ。

私はダグ・アモスです。

いつものように、私と一緒にいるのはポール・ダックリンです。

ポール、今日はどう？

---

アヒル。  いつものように、スーパーデューパー、ダグ！

---

ダグ。  私は今週に到達することに非常に興奮しています 技術史 セグメント、なぜなら…

…あなたはそこにいました、男！

今週、11月XNUMX日に…

---

アヒル。  大野！

ペニーがちょうど落ちたと思う…

---

ダグ。  年も言わなくていい！

11 年 2003 月 2000 日 – Windows XNUMX および Windows XP システムに影響を与える Blaster ワームに世界が注目しました。

Lovesan および MsBlast としても知られる Blaster は、バッファ オーバーフローを悪用し、おそらく次のメッセージで最もよく知られています。 「ビリー・ゲイツ、なぜこれを可能にするのですか？ お金を稼ぐのをやめて、ソフトウェアを修正してください。」

どうしたの、ポール？

---

アヒル。  まあ、それはおそらく、私たちがセキュリティをそれほど真剣に考える前の時代でした.

そして幸いなことに、この種のバグを悪用することは、最近でははるかに困難になっています。それは、スタックベースのバッファ オーバーフローでした。

私の記憶が正しければ、サーバー バージョンの Windows は、 スタック保護.

つまり、関数内でスタックをオーバーフローさせた場合、関数が戻って破損したスタックにダメージを与える前に、何か問題が発生したことが検出されます。

したがって、問題のあるプログラムをシャットダウンする必要がありますが、マルウェアは実行されません。

しかし、その保護は当時のクライアント バージョンの Windows にはありませんでした。

そして、私が覚えているように、それはユーザーが使用しているオペレーティング システムのバージョンを推測しなければならなかった初期のマルウェアの XNUMX つでした。

2000年ですか？ NTですか？ XPですか？

そして、それが間違っていれば、システムの重要な部分がクラッシュし、「システムがシャットダウンしようとしています」という警告が表示されます。

---

ダグ。  はー、懐かしい！

---

アヒル。  つまり、多くの人にとって、感染症に襲われている兆候である巻き添え被害がありました…

…これは外部からの可能性があります。たとえば、あなたが単なるホーム ユーザーであり、自宅にルーターやファイアウォールがない場合などです。

しかし、あなたが社内にいた場合、最も可能性の高い攻撃は社内の別の誰かから来て、ネットワーク上にパケットを吐き出すことでした.

その数年前に話題になった CodeRed 攻撃と同じように、最近のポッドキャストで問題になったのは、この攻撃の規模、量、速度です。

---

ダグ。  そうですね、20年くらい前の話です。

時計をXNUMX年前に戻せば その時です たるみが漏れ始めた ハッシュされたパスワード。 [笑い]

---

アヒル。  はい、人気のコラボレーション ツールである Slack は…

…他の人に招待リンクを送信してワークスペースに参加できる機能があります。

そして、想像してみてください。「リンクを生成する」というボタンをクリックすると、何らかの JSON を含む何らかのネットワーク パケットが作成されます。

Zoom ミーティングの招待状を受け取ったことがある場合は、日付、時間、招待者、ミーティングに使用できる URL、パスコードなどが記載されていることをご存知でしょう。もの - そこにはかなりの量のデータがあります。

通常、生データを掘り下げてそこに何があるかを確認することはありません。クライアントは、「ねえ、ここで会議です。ここに詳細があります。 承諾しますか / たぶん / 辞退しますか?」

Slack でこれを XNUMX 年以上行ったとき、その招待状にパッケージ化されていたのは、招待状自体に厳密には関係のない無関係なデータであることが判明しました。

つまり、URLでも、名前でも、日付でも、時間でもありません…

…しかし、*招待ユーザーのパスワード ハッシュ* [笑]

---

ダグ。  うーん。

---

アヒル。  子供じゃない

---

ダグ。  それは悪いですね…

---

アヒル。  はい、本当にそうですよね？

悪いニュースは、一体どうやってそこに入ったのですか？

そして、一度そこに入ったのに、一体どうやってXNUMX年XNUMXヶ月も気付かれずに逃れたのだろう?

実際、Naked Security の記事にアクセスして、 完全なURL 記事の最後に、 blahblahblah-for-three-months.

なぜなら、レポートを最初に読んだとき、私の心は2017年とは見たくなかったからです! [笑い]

17 月 17 日から 17 月 XNUMX 日までだったので、「XNUMX」がたくさんありました。

そして、2017 年を最初の年として頭に浮かび、「今年の 2022 月から XNUMX 月」[XNUMX 年] と読み違えてしまいました。

「うわー、*XNUMX か月*なのに、彼らは気付かなかった」と思いました。

そして、記事への最初のコメントは、 「ええと[咳]。 実は17年2017月XNUMX日でした。」

うわー！

しかし、誰かが [17 年] 2022 月 XNUMX 日に問題を解決し、Slack が同じ日に修正しました。

「なんてこった、私たちは何を考えていたの?!」のように。

それは悪いニュースです。

良いニュースは、少なくともそれは *ハッシュ化された* パスワードだったということです。

そして、ハッシュ化されただけでなく、*ソルト化*されました。これは、一意に選択されたユーザーごとのランダムデータをパスワードと混合する場所です.

これには XNUMX つの考え方があります。

XNUMX つは、XNUMX 人が同じパスワードを選択した場合、同じハッシュが得られないため、ハッシュ データベースを調べても推測できないことです。

XNUMX つ目は、既知の入力に対する既知のハッシュの辞書を事前に計算することはできません。パスワードごとに *各ソルト* ごとに個別の辞書を作成する必要があるためです。

したがって、ハッシュ化されたパスワードを解読するのは簡単なことではありません。

そうは言っても、全体的な考えは、それらは公の記録の問題であるはずがないということです.

それらは、*漏れる可能性があるためではなく*漏れた場合に備えて*ハッシュされ、ソルト化されます。

だから、Slackの顔に卵を！

Slack によると、200 人に 0.5 人、つまり XNUMX% のユーザーが影響を受けたとのことです。

しかし、あなたが Slack ユーザーなら、ハッシュ化されたパスワードを XNUMX 年間漏えいしていたことに気付かなかったとしたら、影響を受けた人々のリストを完全に列挙していなかったのかもしれません。

とにかく、行ってパスワードを変更してください。

---

ダグ。  また、パスワード マネージャーを使用していない場合は、入手を検討してください。 可能であれば 2FA をオンにします。

---

アヒル。  私はあなたがそれを好むと思った、ダグ。

---

ダグ。  はい、そうです！

Slack または Slack が好きな会社の場合は、 評判の良いソルト ハッシュ アンド ストレッチ アルゴリズム パスワードを自分で処理する場合。

---

アヒル。  はい。

Slack の応答で重要なこと、そして私が欠けていると思ったのは、彼らが「心配しないでください。パスワードをハッシュしただけでなく、ソルトも行いました」と言ったことです。

私のアドバイスは、このような侵害に巻き込まれた場合は、ソルティングとハッシュに使用したアルゴリズムまたはプロセスを宣言することをいとわないことです。 ストレッチングこれは、ソルト化されたパスワードを 100,000 回だけハッシュするのではなく、おそらく XNUMX 回ハッシュして、あらゆる種類の辞書攻撃やブルート フォース攻撃を遅らせる場所です。

また、使用しているアルゴリズムとパラメーターを指定すると、たとえば、 PBKDF2, bcrypt, scrypt, Argon2 – これらは、最もよく知られているパスワード「salt-hash-stretch」アルゴリズムです。

使用しているアルゴリズムを実際に述べた場合、[A] よりオープンになり、[B] 問題の潜在的な被害者に、これがどれほど危険であったかを自分で評価する機会を与えていることになります。 .

そして、そのような開放性は実際に多くのことを助けることができます.

Slackはそれをしませんでした。

彼らはただ、「ああ、塩漬けにしてハッシュした」と言っただけです。

しかし、私たちが知らないのは、彼らが 1 バイトのソルトを入れて、SHA-XNUMX で XNUMX 回ハッシュしたのかということです…

…または、もう少し割れにくいものを持っていたのでしょうか?

---

ダグ。  悪いことの話題にこだわると、人々が GitHub に悪いものを注入する、何が起こるかを確認するためだけに、リスクを公開します…

…別の話があります。

---

アヒル。  はい、現在 Twitter に出てきたとされる誰かが、「心配しないで、害はありません。 あくまでも研究用でした。 レポートを書くつもりです、ブルーアラートから目立ちます。」

彼らは文字通り何千もの偽の GitHub プロジェクトを作成しました。これは、既存の正当なコードをコピーし、そこに「コール ホームで詳細な指示を求める」、「応答の本文をバックドア コードとして解釈して実行する」などのマルウェア コマンドを意図的に挿入したものです。すぐ。

したがって、これらのパッケージのいずれかをインストールした場合に実際に害を及ぼす可能性があるもの.

正当に見える名前を付けて…

…明らかに、本物のプロジェクトのコミット履歴を借りて、「ねえ、このファイルをダウンロードしてください。 自分がしたいって分かってるんでしょ！"

本当？！ リサーチ？？ 私たちはまだこれを知りませんでしたか？

さて、「GitHub を所有している Microsoft は、人々がこの種のものを簡単にアップロードできるようにするために何をしているのですか?」と主張することができます。

そして、それにはいくつかの真実があります。

そもそも、マルウェアを締め出すというより良い仕事ができるかもしれません。

しかし、「ああ、それはすべて Microsoft のせいだ」と言うのは少し行き過ぎです。

私の意見では、次のように言うのはさらに悪いことです。 これは本当に重要です。 これが起こる可能性があることを人々に思い出させる必要があります。」

[A] 多くの人が以前にこれを行ったことがあるので、私たちはすでにそれを知っています。 私たちはメッセージを大声で明確に受け取りました。

そして [B] これは研究ではありません。

これは意図的に人々をだましてコードをダウンロードさせ、潜在的な攻撃者にレポートを書く能力と引き換えにリモート コントロールを与えようとしています。

それは、研究の正当な動機というよりも、私にとっては「太った言い訳」のように聞こえます。

したがって、私のお勧めは、これが*研究*であると考えている場合、およびこのようなことをもう一度やり直すことを決意している場合は、見つかった場合に*多くの同情を期待しないでください*.

---

ダグ。  よし、ショーの最後にこれと読者のコメントに戻るので、このままにしておこう。

しかし、最初に、について話しましょう 信号機、およびサイバーセキュリティとの関係について説明します。

---

アヒル。  ああ、はい！ [笑う]

さて、TLP と呼ばれるものがあります。 トラフィック ライト プロトコル.

そして、TLP は、あなたが他の人に送信するドキュメントにラベルを付けて、他の人が何を望んでいるのか (さらに重要なことに、彼らが何を望んでいるのか) のヒントを与えるのに役立つ「人間のサイバーセキュリティ研究プロトコル」と呼ばれるものです *ない*) データを処理します。

特に、彼らはそれをどのくらい広く再配布することになっていますか?

これは世界に宣言できるほど重要なことですか？

それとも、これは潜在的に危険なのですか、それともまだ公開したくないものが含まれている可能性がありますか?

そして、それは次のように始まりました： TLP:RED、それは「それを自分で保管してください」という意味でした。 TLP:AMBER、つまり「これをあなたの会社内で、または緊急にこれを知る必要があると思われるあなたの会社の顧客に回覧することができます」という意味です。 TLP:GREEN、つまり、「OK、これをサイバーセキュリティコミュニティ内で広く流布させることができます.」

TLP:WHITE、それは「あなたは誰にでも言うことができる」という意味でした。

非常に便利で、非常にシンプルです: 赤、琥珀、緑… 「秘密」と「機密」の違いや、「機密」と「機密」の違いなど、すべての複雑な事柄を気にすることなく、グローバルに機能する比喩です。その周りにはたくさんの法律が必要です。

ええと、TLP にいくつかの変更が加えられました。

したがって、サイバーセキュリティの研究に興味がある場合は、それらを認識していることを確認してください.

TLP:WHITE は、実際にはもっと適切な用語に変更されました。 白 現代ではなくてもいいこれらの不必要な文化的倍音をすべて持っています。

そう、 TLP:WHITE になりました TLP:CLEARというのは、「このデータを使用することは明らかです」と述べており、その意図が非常に明確に述べられているためです。 （すみません、しゃれに抵抗できませんでした。）

そして、追加のレイヤーがあります (そのため、比喩が少し損なわれています。これは、*XNUMX* 色のカラー トラフィック ライトです!)。

と呼ばれる特別なレベルがあります。 TLP:AMBER+STRICT、つまり「社内で共有できる」ということです。

ミーティングに招待されたり、サイバーセキュリティ会社で働いていたりすると、これをプログラマーや IT チーム、品質保証担当者に見せる必要があることは明らかです。問題またはそれを修正することに対処します。

だけど TLP:AMBER+STRICT 組織内で回覧することはできますが、*クライアントや顧客*、または知る必要があると思われる社外の人にさえ教えないでください.

最初は、より緊密なコミュニティ内に保管してください。

TLP:AMBER、前と同じように、「OK、顧客に伝える必要があると感じたら、できます」という意味です。

これは重要な場合があります。なぜなら、顧客に次のように伝えたい場合があるからです。 修正プログラムが到着する前に、いくつかの予防措置を講じる必要があります。 でもちょっとセンシティブなので、まだ世界に言わないようお願いしてもいいですか？」

時には、世界に早すぎることを伝えると、実際には、防御側の手に渡るよりも、詐欺師の手にかかることがあります。

したがって、あなたがサイバーセキュリティ対応者である場合は、次のことをお勧めします。 https://www.first.org/tlp

---

ダグ。  そして、次のことができます それについてもっと読む 私たちのサイトでは、 ネイキッドセキュリティ.sophos.com.

そして、他の簡単な読み物を探しているなら、量子暗号を忘れてください…私たちは次に進みます 量子後暗号、ポール！

---

アヒル。  はい、これについてはポッドキャストで数回話しましたね。

量子コンピューターのアイデアは、十分に強力で信頼性の高いものを構築できると仮定すると、特定のタイプのアルゴリズムが、今日の最先端技術よりも高速化される可能性があるということです。今日の問題の規模の*対数*。

つまり、2を取る代わりに²⁵⁶ 特定のハッシュを持つファイルを見つけようとしますが、たったの (「ただ」!) 2 でそれを行うことができるかもしれません¹²⁸ これは平方根です。

明らかにはるかに高速です。

しかし、大雑把に言えば、今日かかる時間の「対数」で解読できるという理論によると、素数の積を因数分解することを含むさまざまな問題があります。

したがって、取る代わりに、たとえば、2¹²⁸ [宇宙の現在の年齢よりもはるかに長い] 解読するのに 128 日しかかからないかもしれません。

または、「日」を「分」などに置き換えることもできます。

そして残念なことに、その対数時間アルゴリズム (と呼ばれる) Shor の量子因数分解アルゴリズム)…理論的には、これは今日の暗号化技術の一部、特に公開鍵暗号化に使用される技術に適用できる可能性があります。

そして、これらの量子コンピューティング デバイスが今後数年で実現可能になる場合に備えて、これら XNUMX つの特定のクラスの攻撃に対して脆弱ではない暗号化アルゴリズムの準備を今すぐ始めるべきでしょうか?

特に対数の XNUMX つは、潜在的な攻撃を非常に高速化するため、現在「誰もそれを理解することはできない」と考えている暗号化キーが、後の段階で明らかになる可能性があるためです。

とにかく、NIST、 米国標準技術局 米国では数年前から、これらの魔法の量子コンピューターが現れたとしても耐性のある、公開された特許のない十分に精査されたアルゴリズムを標準化するための競争を行ってきました.

そして最近、彼らは現在標準化する準備ができている XNUMX つのアルゴリズムを選択しました。

Doug さん、かっこいい名前を持っているので、読み上げる必要があります。 CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCON, SPHINCS+. [笑い]

そのため、他に何もないとしても、彼らにはクールな名前が付いています。

しかし同時に、NIST は次のように考えました。 私たちがすることは、潜在的な二次候補としてさらにXNUMX人を選び、それらのいずれかが同様に通過するかどうかを確認することです.

したがって、現在 XNUMX つの標準化されたアルゴリズムと、将来標準化される可能性のある XNUMX つのアルゴリズムがあります。

または、5 年 2022 月 XNUMX 日に XNUMX つあり、そのうちの XNUMX つが SIKE、の略 超特異アイソジェニ鍵カプセル化.

(超特異点を説明するには、いくつかのポッドキャストが必要になるので、気にしません。[笑い])

しかし、残念なことに、標準化される可能性を秘めてそこにぶら下がっていたこのものは、すでに少なくともXNUMX年間公開されているにもかかわらず、取り返しのつかないほど壊れているように見えます.

幸いなことに、標準化される直前、または標準化される直前に、ベルギーの XNUMX 人の暗号学者が次のことに気付きました。 XNUMX つのコアだけを使用して、かなり平均的な CPU で約 XNUMX 時間かかる計算を使用して、これを回避する方法があると考えています。」

---

ダグ。  それを標準化して世に出すよりも、今見つけた方がいいのではないでしょうか?

---

アヒル。  確かに！

それがすでに標準化されているアルゴリズムの XNUMX つだったとしたら、彼らは標準を廃止して新しいものを考え出さなければならなかったと思いますか?

これがXNUMX年間気づかれなかったのは奇妙に思えます。

しかし、それが公の精査の全体的な考え方だと思います。誰かが必要なクラック、または侵入してアルゴリズムが当初考えられていたほど強力ではないことを証明するために使用できる小さなくさびをいつヒットするかはわかりません.

独自の暗号を編むことを*考えたことがあるなら…

---

ダグ。  [笑い] 私はしていません！

---

アヒル。  ..Naked Security ポッドキャストで N 回「そんなことはしないでください!」と言ったにもかかわらず、

これは、真の専門家が XNUMX 年間のグローバルな競争で公の精査を受けるアルゴリズムを発表したとしても、非常に悪いことが判明した欠陥を明らかにするのに十分な時間が必ずしも提供されないことを最終的に思い出させるものです.

したがって、これは確かに見栄えがよくありません SIKE アルゴリズム。

そして、誰が知っていますか、多分それは撤回されるでしょうか？

---

ダグ。  私たちはそれを監視します。

そして、今週のショーに日がゆっくりと沈むにつれて、以前に説明した GitHub ストーリーについて読者の XNUMX 人から話を聞く時が来ました。

ロブ 書き込み:

「コメントにはチョークとチーズがあり、それを言うのは嫌いですが、議論の両面を見ることができます. 危険で、面倒で、時間とリソースを浪費していませんか? はい、もちろんです。 それは犯罪志向のタイプがすることですか？ はい、そうです。 GitHub やその他のコード リポジトリ システムを使用している人にとって、インターネットを安全に移動するには、健全な程度の皮肉とパラノイアが必要であることを思い出させるものでしょうか? はい。 システム管理者として、目の前のリスクが明らかになったことに拍手を送りたいと思っています。 多くの開発者のシステム管理者として、私は今、誰もが疑わしいエントリのプルを最近調べたことを確認する必要があります。」

---

アヒル。  はい、RobB さん、そのコメントに感謝します。なぜなら、議論の両側を見ることが重要だと思うからです。

「一体何が問題なの？ これは素晴らしい！"

ある人はこう言いました。 「いいえ、実際、この侵入テストは優れていて便利です。 実際の攻撃者から醜い頭をもたげるのではなく、これらが今公開されていることを嬉しく思います。」

それに対する私の反応は、「まあ、これは実際には攻撃です」です。

後で誰かが出てきて、「ああ、いや、いや」と言っただけです。 大丈夫です！ 正直なところ、私はいたずらをしていませんでした。」

私はあなたがその言い訳を買う義務があるとは思わない!

とにかく、これは侵入テストではありません。

私の答えは、非常に簡単に言うことでした： 「責任あるペネトレーション テスターは、[A] 明示的な許可を得た後にのみ行動し、[B] 事前に明示的に合意された行動制限内でのみ行動します。」

独自のルールを作成するだけではありません。これについては以前に説明しました。

それで、別のコメンターが言ったように、これは私のお気に入りのコメントだと思います… エカーブ 彼は言った, 「誰かが家々を歩き回って窓を壊し、ドアロックがいかに効果的でないかを示すべきだと思います。 これは期限切れです。 誰かこれに飛び乗ってください。」

そして、それが風刺だと気付かなかった場合に備えて、皆さん、彼は言います、 「違います！」

---

アヒル。  これは良い思い出になると思います。プロデューサーとコンシューマーの両方として GitHub ユーザーであれば、できることがあると思います。

コメントと記事にそれらをリストします。

たとえば、すべてのコミットにデジタル署名を付けて、変更があなたからのものであることを明らかにし、ある種のトレーサビリティを確保します。

また、検索を行って、それが適切なプロジェクトである可能性があるように見えたからといって、やみくもに物を消費しないでください。

はい、私たちは皆、これから学ぶことができますが、これは実際に私たちを教えていると見なされますか、それともとにかく学ぶべきことなのでしょうか?

これは教えることではないと思います。

研究としてカウントするには*十分に高い基準ではありません*。

---

ダグ。  この記事に関する素晴らしい議論、そしてそれを送ってくれてありがとう、ロブ。

投稿したい興味深いストーリー、コメント、質問がある場合は、ポッドキャストで読んでください。

メールできます tips@sophos.com; あなたは私たちの記事のいずれかにコメントすることができます。 または、ソーシャルで私たちを襲うことができます： @NakedSecurity.

それが今日の私たちのショーです–聞いてくれてありがとう。

ポール・ダックリンの場合、私はダグ・アーモスです。次回まで、次のことを思い出させてくれます…

---

どちらも。  安全を確保してください！

【ミュージックモデム】