2019年5月のセキュリティインシデントの詳細：ブログ投稿のフィードバック
2019年5月に発生したセキュリティインシデントの更新を、何が起こったのか、どのように起こったのか、およびそのようなインシデントが再発しないように適用した修正の技術的な詳細とともに投稿しました。投稿からの抜粋をいくつか示します。最初は紹介からです。
2019年5月12日00：00UTC頃、コミュニティの複数のメンバーから、新しいユーザーアカウントの予期しない権限昇格が通知されました。誰も認識しなかったユーザーは、Stack ExchangeNetworkのすべてのサイトでモデレーターおよび開発者レベルのアクセス権を取得していました。私たちの即時の対応は、特権を取り消し、このアカウントを一時停止してから、イベントにつながったアクションを特定して監査するプロセスを開始することでした。
最初の発見後、特権の昇格は氷山の一角に過ぎず、攻撃によって実際にソースコードが漏洩し、184人のユーザーのPII（メール、本名、IPアドレス）が誤って公開されたことがわかりました。 Stack Exchange Networkの（全員に通知されました）。ありがたいことに、パブリック（Stack Exchangeコンテンツを読む）でもプライベート（Teams、Talent、またはEnterprise）でもないデータベースはどれも盗み出されませんでした。さらに、内部ネットワークインフラストラクチャに直接アクセスしたという証拠はなく、攻撃者がTeams、Talent、またはEnterprise製品のデータにアクセスしたことはありませんでした。
そして最後の段落から：
この事件は、誰もが従うべきいくつかの基本的なセキュリティ慣行について私たちに思い出させました：
- すべてのインバウンドトラフィックをログに記録します。すべてのインバウンド接続のログを保持します。これにより、すべての調査が可能になりました。ログに記録していないものを調査することはできません。
- 2FAを使用します。レガシー認証をまだ使用している残りのシステムは、最大の脆弱性になる可能性があります。
- 秘密をよりよく守る。TeamCityには秘密を保護する方法がありますが、一貫して使用していないことがわかりました。「シークレットは単なるパスワードではない」ことをエンジニアに教育します。SSHキーとデータベース接続文字列も保護します。疑わしい場合は保護します。シークレットをGitリポジトリに保存する必要がある場合は、git-cryptまたはBlackboxで保護します。
- 顧客の要求を検証します。顧客からの要求が珍しいほど、その要求が正当であるかどうかを確認することが重要になります。
- セキュリティレポートを真剣に受け止めてください。私たちのコミュニティが疑わしい活動を非常に迅速に報告してくれたことに感謝しています。ありがとうございました！
ブログの投稿には他にもたくさんあります。以下の投稿に関連する質問やコメントがあれば、遠慮なく質問してください。できる限り回答します。調査が進行中であるため、ブログ投稿に含まれている以外の攻撃に関連するその他の詳細についてコメントすることはできません。
回答
攻撃者の意図についてコメントできますか？
特定の目標/特定の（ユーザー）データの後であるように見えますか？
それとも、棒で突っついている「好奇心旺盛なティーンエイジャー」がどこまで到達できるかを見ていたのでしょうか。
PSこの件に関してオープンに感謝します、本当に感謝しています！
この行：
Stack Exchange Network全体で物事を検索する（質問にアクセスする）というこの行為は頻繁に発生し、今後数日間の攻撃者の方法論を予測して理解することができます。（私の強調）
リアルタイムのように聞こえます。攻撃が発生しているときに、攻撃者が（攻撃後に）見たものを法的に見るのではなく、StackOverflowでアクセスしたものに基づいて攻撃者が何をするかを正確に特定できます。どちらの意味ですか？
主に攻撃者に関連するいくつかの質問：
- 攻撃者はどうなりましたか？
- アカウントを一時停止しましたか？
- SEはいつでも攻撃者に連絡しましたか？
- 攻撃者の身元を公開してみませんか？
- 他の誰かが後でこれと同じ攻撃方法を使おうとしましたか？
イベントのもう一方の端に検出可能な睡眠サイクルがありましたか？
明確にするために編集：
攻撃者に気付いた後、そして彼らが展開するときに彼らの行動のいくつかをたどったので、あなたは日々そして遡及的に生物学的サイクルに似ている何かに気づきましたか？例：食事（1〜2時間の休憩）、睡眠（8時間の非活動パターン）、「パワーナップ」（90分）など...？
これは実際にはインシデントの一部ではありませんが、従業員のアカウントに関するセキュリティ対策に関するより一般的な懸念事項です。この事件には多くのステップがありましたが、最後のステップはSEアカウントの特権を昇格させることでした。devインスタンスを介してCIサーバーへの管理者アクセスを取得して本番環境でSQLを実行するよりもはるかに簡単な方法を想像できます。また、SEが実装した、より単純な取得の試みから防御するための緩和策とセキュリティプラクティスに興味があります。従業員アカウントへのアクセス。
メインのSEサイトをファイアウォールの背後に配置することは明らかにできないため、常に公開されます。また、SEの内部ログイン方式では、2FA方式は提供されていません。
- 従業員アカウント2FAは他の手段（または他のログインプロバイダー）を介して保護されていますか？
- 安全性が低く、アカウントにアクセスするための回復メールの受信に使用される可能性のあるプライベート電子メールアドレスまたはログインプロバイダーが従業員アカウントに添付されないようにするための対策はありますか？
- 従業員アカウントの新しいソースからのログイン試行の監視はありますか？
- 誰かが従業員アカウントの実行中のセッションにアクセスした場合に備えて、危険な従業員ツールに対する追加の保護がありますか（たとえば、セキュリティが重要なツールにアクセスするときにパスワードや2FAトークンが再度必要になります）
スピアフィッシングのようなものは、おそらく、誰かが従業員のアカウントにアクセスしようとする可能性が高い方法の1つです。
このセキュリティインシデントが発生したのとほぼ同時に、数日後、一部のユーザーは、チャットでのTwitterのワンボックス化が機能しなくなったことに気づき始めました。その後、従業員は来年の2月に、このセキュリティインシデントの結果として「いくつかのギャップを埋める」必要があったために意図的に無効にされたことを確認しました。
このセキュリティインシデントの結果として、チャットでのTwitterワンボックス化を無効にする必要があった理由について完全な説明を得ることができますか？一度に公表されたブログ記事「他の潜在的なベクターは、」閉じていたと述べた、と私はリンク2020年2月のスタッフのメッセージは、上記のTwitter oneboxing機能は、「私たちは閉じたギャップの1つの使用をした」と述べました。それは何でしたか、そしてそれはどのようなセキュリティリスクを生み出しましたか？
最後に、この機能を安全な方法で再度実装できる方法はありますか？上記のスタッフメッセージの数か月後の2020年8月に、その時点で提出されたバグレポートは、別の従業員によって設計によりステータスとしてマークされました。（安全な方法で）設計を元に戻す機能要求が考慮されますか、それとも攻撃ベクトルを開かずにそうすることは不可能ですか？
TeamCityの「パスワード」パラメータータイプはそれほど安全であるとは見なされないことにフラグを立てます。
パスワード値は、TeamCityデータディレクトリの下の構成ファイルに保存されます。サーバーの暗号化設定に応じて、値はスクランブルされるか、カスタムキーで暗号化されます。
ビルドログの値は、単純な検索と置換のアルゴリズムで非表示になっているため、「123」という簡単なパスワードを使用すると、「123」が出現するたびに置換され、パスワードが公開される可能性があります。パラメータをパスワードタイプに設定しても、生の値を取得できないとは限りません。プロジェクト管理者なら誰でもそれを取得でき、ビルドスクリプトを変更できる開発者なら誰でも、悪意のあるコードを記述してパスワードを取得する可能性があります。
なぜ開発者の魔法のリンクがCM（おそらく開発者だけ）に表示されたのですか？
これは本当に素晴らしい事件報告です！私が読んだ中で最高のものの1つ。
Stackを公開してくれてありがとう、Deanは素晴らしい書き込みをしてくれてありがとう！
私はいくつかのことを知りたいだけです：
- インシデント対応チームの規模はどのくらいですか？
- 調査中に従った特定のプロトコルはありましたか？
- 外部のセキュリティベンダーを関与させるために関与した重要な要素は何ですか？その特定のベンダーを選択する際に考慮されたポイントは何でしたか？
- 外部のセキュリティベンダーからどのような教訓が得られましたか？彼らの監査プロセスは、チームがすでに使用しているものとは異なっていましたか（効果的/非効果的）？
この記事では、Stackのアーキテクチャ全体と開発プロセスを垣間見ることができます。それについての記事がすでにある場合は、より詳細な記事を読んだり、リンクしたりするとよいでしょう。
「他の人へのアドバイス」の下：
すべてのインバウンドトラフィックをログに記録します。すべてのインバウンド接続のログを保持します。これにより、すべての調査が可能になりました。ログに記録していないものを調査することはできません。
Stack Exchangeと同じくらい忙しいネットワークは、どのようにしてインバウンドトラフィック全体をログに記録できますか？これらのログはWebサーバーエントリ、IPフロー、または完全なTCPセッションですか？
小さなネットワークでほとんどのエントリと接続の試行を記録できましたが、このような大規模なネットワークでどのように記録されるのかわかりません。
以下の引用で、「公的にアクセス可能なプロパティ」の意味をより明確に説明できますか？
公的にアクセス可能なプロパティへのすべてのトラフィックのログを含むデータベースがあります