

お世話になります。

サーバーが外部より侵入・攻撃を受ける可能性についてお伺いしたいのですが、

以下コマンドを実行し、SSL証明をOFFにしたままにした場合、  
どういったリスクがあるか、ご教授いただけないでしょうか。  
よろしくお願い致します。

`git config --global http.sslVerify false`


CC BY-SA 4.0
2022-07-15T00:05:37.780
89987
2022-07-16T02:02:56.203
50785
question
linux git ubuntu security ssl
攻撃を受ける可能性について


設定しているオプションはあくまで **クライアント** としての設定であり、サーバのセキュリティには直接関係がありません。


CC BY-SA 4.0
2022-07-15T01:23:21.090
89990
2022-07-15T01:23:21.090
3060
89987
answer


サーバー上でgitをクライアントとしてどのように使用しているかどうかです。状況が詳しくわからないとなんとも言えません。

* * *

これから全くの仮定の話をします。たとえば、対象のサーバーおよびその環境が次のような状況だとします。

  * 対象サーバーでは、nginx等を用いてWebサイトを外部公開している。
  * Webコンテンツは別途存在する独自に構築したGitLabサーバーで管理している。
  * 対象サーバーでは、gitコマンドを使用して、cron等を用いて定期的にWebコンテンツをGitLabサーバーから取得している。
  * GitLabサーバーにインストールされている証明書は自己署名証明書であるため、通常アクセスでは証明書検証に失敗する。
  * 対象サーバーはインターネットに直接接続されており、特に通信の制限はしていない。

このような状況の場合、対象サーバーの管理者が、証明書エラーを回避するために、gitでの`http.sslVerify`設定を`false`にしてしまったとしましょう。

さて、もし、攻撃者がこれらの仕組みの概要を知ってい(例えば、サーバーの詳細設計書が漏洩したとかで)、DNSキャッシュポイズニング攻撃等で名前を別のIPに向けることができれば、次のよう攻撃が成功する可能性があります。

  1. 偽のGitLabサーバーをインターネット上に構築する。
  2. 偽のGitLabサーバーで、本来と同じ内容のレポジトリを用意する。(公開サーバーのミスで.gitディレクトリも公開していたため、レポジトリの完全なクローンが可能だとする)
  3. 偽のGitLabサーバーで、レポジトリを偽の悪意あるコンテンツ(フィッシングサイトへリダイレクトするような内容や警告・サポート詐欺を起こす内容とか)に更新する。
  4. DNSキャッシュポイズニング攻撃等で対象サーバーからGitLabサーバーへのアクセスが偽のGitLabサーバーに向けるようにする。
  5. 次の定期処理で偽のGitLabサーバーから偽のコンテンツを取得して、公開内容を悪意あるコンテンツに更新してしまう。
  6. 対象サーバーのサイトにアクセスした顧客がフィッシングサイトに誘導されたり、サポート詐欺にあったりして、会社の信頼が落ちてしまう。

DNSキャッシュポイズニング攻撃等が成功しなければならないというハードルはありますが、とりあえず、なんとか偽のGitLabサーバーに向かわせることができれば、多大な損害を与えることができます。もし、GitLabサーバーに正式な証明書を入れているなど、証明書検証を無効にしなくても通信できるようにしていれば、このような攻撃も防ぐことができたでしょう。

* * *

このように、クライアントとして使用するアプリケーションであるからと言っても、サーバー上で動作させるアプリケーションである限りは、運用上の利用目的などを鑑みて注意深く検証する必要があります。セキュリティの設定を緩める場合は、それによって成立する可能性があるあらゆる攻撃を想定して検証し、設定の可否の判断すべきです。


CC BY-SA 4.0
2022-07-16T02:02:56.203
90012
2022-07-16T02:02:56.203
7347
89987
answer