攻撃者はどのようにしてハッシュされたパスワードにアクセスしますか？
パスワードをハッシュする方法とパスワードの強度は重要です。ハッシュされたパスワードに誰かがアクセスした場合、驚くほど短い時間で何度も何度もパスワードを試し、脆弱なものをクラックする可能性があるためです。
私が持っている問題は、攻撃者がそもそもハッシュされたパスワードにアクセスする方法を教えてください。たとえば、/ etc/shadowファイルにアクセスできる場合、すでにゲームオーバーではありませんか？それは単に悪いアクセス許可設定ですか？バックアップ？その他の間違い？ 1つのシステムが危険にさらされると、そこからのパスワードが他のシステムへの侵入を試みるために使用されるのですか？
最終的に私のクエリは、攻撃者がハッシュにアクセスすることは避けられないという、この件について読んだことから得られる含意に要約されると思います。実際にはどうなりますか？
いくつかの方法があります。
- SQLインジェクション
- 漏洩したバックアップ
- 不満を漏らしている従業員
- コードの実行を許可するサーバーのあらゆる種類の違反。
phihag コメントで言及されているように、 OWASPトップ1 の半分以上がリークされたハッシュにつながる可能性があるため、これが発生する可能性のある方法はたくさんあります。投稿で簡単に集計することはできません。
これは、ハッカーがハッシュを取得することが避けられないという意味ではありませんが、万一に備えて 優れたハッシュアルゴリズム を使用して自分とユーザーを保護する必要があります。バックアップが失われたり、気付かれずにサーバーがハッキングされたりする可能性があるため、適切にハッシュ化されたパスワードを使用することで、夜に眠ることができます。この戦略は "defence in depth" 、または単に "最悪の計画"として知られています。
多くの方法があります。頭のてっぺんから思いつくものがいくつかあります。今はテストする必要がないので、構文に少し問題があるかもしれませんが、一般に、これらはそのデータを取得するために行うことです。
以下のエクスプロイトでは、notハッシュを盗む例を提供していることに注意してください（SQLiを除く）が、エクスプロイトがどのようにできるかの例作業。攻撃者は以下のエクスプロイトを使用して、システムをさらに侵害します。
SQLインジェクション
例：
a OR 1=1'; exec sp_msforeachtable "SELECT * FROM ?";--次のように、
sp_msforeachdbを使用することもできます。a'; exec sp_msforeachdb 'USE ?;exec sp_msforeachTable "SELECT * FROM !","!"';----は、注入を妨げる可能性があるSQLステートメントの一部をコメント化するためにあります。これらは非常に基本的な例にすぎません。クエリの形式によって異なります。- OSインジェクション。
; cat /etc/passwd; rm -rf /* - LDAPインジェクション。
*、(cn = *)(|(password =*)) ローカル/リモートファイルインクルードの脆弱性につながる安全でない直接オブジェクト参照。
/etc/passwd%00（注：もちろんパスワードはここに保存されません。ユーザーがパスワードを再利用するときに有効なユーザー名を見つけることが重要です。または、ユーザー名を使用して特権の昇格を支援します）%00は、その後に続くものを回避するために使用される「nullターミネータ」であるため、存在しないものを含めようとしないでください（例：/etc/passwd.txt）。これは、使用している言語に応じて、\000、\x00、\z、\u0000、\0、または\00になることもあります。- データベースへのアクセス権を持つ開発者/ユーザーをハッキングします。
- データベースサーバー、または他の手段によるWebサーバーの悪用
マークバッファローへの追加：
7。中間者攻撃。暗号化されていないトラフィックを監視すると、パスワードハッシュが明らかになることがよくあります。 pass-the-hashシナリオでは、システムはハッシュとパスワードを信頼し、攻撃者がクラックせずにハッシュを単純にコピーできるようにします。
本当に安全な唯一のコンピューターは、インターネットから隔離され、電源がオフで、プラグが差し込まれておらず、地下100フィートのバンカーに埋め込まれていて、唯一の入り口に武装警備員がいるコンピューターです。それでも、たまにチェックインします。
パスワードのハッシュは、「セキュリティの詳細」と呼ばれるものの一部です。理想的には、攻撃者にそのデータへのアクセス権を与えるような理想的な世界では間違いを犯さないので、理論的にはプレーンテキストのパスワードまたはハッシュであるかどうかは問題になりません。現実の世界では、侵入は実際に発生しており、侵入の方法と場所を予測することは非常に困難です。セキュリティの詳細の背後にある考え方は、理論的には、攻撃者が何らかの方法でシステムを危険にさらしたとしても、被害を軽減するための努力を払うようにすることです。
現実の世界では、定期的にハッシュにアクセスする必要があります。ユーザーがログインするたびに、それらにアクセスできる必要があります。したがって、ほとんどの場合、認証を行うアプリケーションがアクセスできます。誰かがあなたのアプリケーションを危険にさらすならば、彼らは彼らが読むことができるはずではなかったデータを読むことができるかもしれません。
これらの攻撃が発生する方法は無限です。入力のサニタイズに失敗した場合、SQLインジェクション攻撃を受ける可能性があります。バッファオーバーランが発生し、攻撃者が独自のコードを実行する可能性があります。アクセス許可エラーが発生し、必要のないときに誤ってファイルを読み取り可能にしてしまう可能性があります。攻撃者は、バックアップサービスの取り扱いを誤ると、バックアップテープの1つを手に入れる可能性があります。
これらの攻撃はすべて、攻撃者にあなたのコンピュータの足掛かりを与えますが、必ずしも完全な侵入をもたらすわけではありません。 SQLサーバーをchrootした可能性があるため、SQLサーバープロセスは残りのコンピューター全体を文字どおり認識できません。ただし、このような状況では、ユーザーが必要とするログイン情報はSQLサーバーの範囲内にあるか、SQLサーバーの価値がない必要があります。したがって、ログイン情報は通常、他のより悪質な侵害が発生する前に侵害されます。
パスワードをハッシュすることにより、それらの値を減らします。ハッシュは、ログインの目的には役立ちません。彼らはその値にハッシュするパスワードを持っている必要があります。彼らはハッシュを壊すコストを負担できるかもしれないし、できないかもしれない。すべての世界の中で、最初からこれについて心配する必要はありませんが、セキュリティの詳細なアプローチに加入している場合は、侵入が成功してもすべてのデータが危険にさらされることはありません。
一部の旧式のネットワーク化されたun * x/linuxインストールは、集中管理された認証にNIS/YPサービスを引き続き使用します。 NISは、すべてのワークステーションがユーザーを認証するために、ハッシュされたパスワードをネットワーク上で効果的に公開します。