TwitterとGitHubは、ハッキングされていないことをどのように確認できますか？
昨日、Twitter 発表済み 彼らは最近、内部ログにマスクされていないパスワードを保存するバグを特定しました。最近、Githubにも 同様のバグ がありました。どちらの場合も、誰もこれらのファイルにアクセスできなかったと主張しています。
ツイッター：
バグを修正しました。調査の結果、違反や不正使用の兆候は見られません。
繰り返しになりますが、パスワード情報がTwitterのシステムを離れたり、誰かに悪用されたりしたことを信じる理由はありませんが、アカウントを安全に保つためにいくつかの手順があります。
GitHub：
同社によると、プレーンテキストのパスワードは、これらのログにアクセスできる少数のGitHub従業員にのみ公開されています。同社によると、他のGitHubユーザーはユーザーのプレーンテキストのパスワードを見たことはないという。
GitHubは、定期監査中にエラーを発見し、サーバーがハッキングされていないことを明らかにしたと語った。
注目すべきは、GitHubがハッキングされたり、侵害されたりしていないことです。
TwitterとGitHubは、ハッキングまたは侵害されていないことを確認するにはどうすればよいですか？サーバーを危険にさらしてファイルを読み取り/コピーしている誰かが常に痕跡を残すでしょうか？
彼らは確信が持てない。実際、ハッキングされていないことを確認することはできません。しかし、徹底的な調査によって、それが多かれ少なかれ可能性があると結論付けることができます。
Twitterの声明は、ハッキングの兆候はないと言っているだけです。これは、ハッキングされた可能性を排除するものではなく、ユーザーにパスワードの変更を促す際に暗黙のうちに認めています。
GitHubに関しては、表現はもう少しカテゴリー的です。しかし、パスワードのリセットを強制することは、関係するリスクを理解していることを示していると思います。
もう1つ注意すべき点は、どちらの場合も、リークは純粋に内部のログシステムにあったということです。サードパーティのユーザーがこのシステムにアクセスしたことがあるという兆候はありません。内部ロギングシステムが外部に公開されることはめったになく、システムがトラブルシューティングを必要とする場合にのみ内部的に参照されます。それがおそらくこのバグが何ヶ月も気付かれない理由でもあります：おそらく他の膨大な量のどこかにある単一のログエントリは、それらが必要なステートメントのすぐ隣または真ん中にない限り、通常は気付かれません。他のエントリをデバッグします。
また、Twitterがバグ自体を発見したのはごく最近のことです。つまり、Twitterが登場する前に、社外の人がこのバグに気付いていた可能性は低いです。
ネガを証明するのは難しい。
では、どのようにしてポジティブを証明しますか？この場合、外部からの攻撃をどのように証明しますか？通常、さまざまな形式の攻撃、違反、またはアクセスを監視するためのシステムがいくつか設置されています。これらは、ファイアウォール、侵入検知システム、 SIEM 、およびさまざまな監視およびロギングシステムです。今日のネットワークでは、各コンポーネントに何らかの監視機能があるか、Check_MKなどのサードパーティツールによる監視が可能です。
したがって、企業ネットワークの境界から貴重な情報自体を保持するマシンまでの各ステップは、何らかの形で監視されます。これらのログは、ネットワークと企業のポリシーに応じて、定期的に分析されます。分析システムは、予期されるトラフィックと予期しないトラフィックまたは動作を区別できます。 Un/Expectedの動作は、インスタンスファイルアクセス用です。
内部ログファイルは通常機密データと見なされるため、ファイルアクセスもおそらく監視されます。特定のユーザーグループに属していない誰かが内部ログファイルをコピーまたはアクセスしようとすると、おそらく予期しない動作または禁止された動作としてログに記録されているはずです。可能性のある攻撃者がこのファイルにアクセスする権限を持つユーザーになりすますことができた場合、それもログに記録されますが、予想どおりの動作です。
理論的には、攻撃者がすべてのセキュリティ制御を克服し、0day脆弱性を悪用し、すべてのコンポーネント、IDS、SIEMなどのすべてのログに痕跡を残さず、内部ログファイルをコピーして外部に密輸する可能性があります。それは非常にまれです。
私の推測は、ログファイルが発見された後、これらのすべてのログが徹底的に分析され、外部からの攻撃があったかどうかを証明しようと試みました。アナリストは疑わしいデータを見つけなかったため、ほぼ確実に外部からの攻撃はないと結論付けました。そして、これは実際にTwitterのプレスリリースに表示されるものです（Florin Coadaのコメントを参照）。繰り返しますが、私の推測：GitHubのプレスリリースには、投機を停止するためのより厳密な言葉がありましたifハックがあった場合。 （実際にはうまくいきませんでした。;）
もちろん、TwitterやGitHubにそのようなセキュリティ管理機能がないことも考えられますが、私は本当にそう望んでいません。
私は彼らがサーバーで起こっているほとんどすべてのアクセスログを持っていると思います、彼らは誰かがファイルにアクセスしたかどうか、それがいつだったか、彼らがログインしたエイリアス、彼らのソースIPアドレスなどをチェックすることができます。アクセスは合法的な従業員によるものであり、ハッキングされていないと自信を持って言うことができます。これは実際にハッキングされていないことを保証するものではなく、すべての証拠がその方向を指し示していることに注意してください。
答えはとても簡単です。彼らが確信していると彼らが言っているところはどこにもない。実際、彼らは実際に2つの方法で違反があった可能性があることを暗黙に伝えています。
- 彼らは、違反が「あったと信じる理由はない」または「の証拠はない」と言います。証拠の欠如は、侵入者が彼らの進路を覆ったことを単に意味するかもしれません。
- 安全のため、パスワードを変更するよう要求されます。これは、違反が発生していないことを保証できないことを意味します。
特により大胆なGitHubステートメントについての私の解釈は、パスワードがログファイルに入れられたという事実はハッキング攻撃の結果ではなく、開発者が偶然にデバッグコードを導入した結果であると言いたいということです。製造。攻撃者が後で取得するためにパスワードを収集するためにこの機能を導入した可能性があるため、これは重要です。
彼らがハッキングされたことがないこと、そしてハッキングされないことは保証されていませんが、この事件はハッキングの試みとは無関係です。
このような大企業は多数のサーバーを備えている必要があるため、すべての外部アクセスは 要塞ホスト を介してルーティングされます（外部の意味は、実際のサーバーケージ/ルーム内からではありません）。要塞では、すべてのコマンドが外部ネットワークから運用サーバーに中継されるため、ロギングがなんらかの方法で設定されている可能性があります。ログに記録されたコマンドは、たとえば誰かがvimでファイルを開いたかどうかを簡単に確認でき、ユーザーがハッキングされたかどうかの問題を解決します。 SSHアクセスもログに記録されるので、既知の「良好な」IP/sをユーザーから除外でき、不審なエントリや奇妙なエントリをIT部門が調査できます。エントリを説明できない場合、違反と見なされます。それ以外の場合、サーバーは「安全」であり、この問題に関してそれほど心配する必要はありません。
彼らが実際に言っていることは、彼らが実際にセキュリティ侵害があったことを100％確信しているということです。誤って。多分。そして自分自身で。残りは光沢です。
彼らは個人を従業員として異なって見るかもしれませんが、私はそうではありません。優れたハッカーは内部から働き、信頼を得ます。 NSA？ FSB？
彼らは私たちのパスワードにプレーンテキストでアクセスするべきではありません。これは、パスワードアクセスが機能する方法ではありません。その意味は、今までに使用したすべての場所でそのパスワードを変更することはあなた次第であることです。現在、パスワードは誰にでも知られているものとします。