正しく構成されていないデータベースで、25,000のホストを持つクラウド全体をキャプチャできた方法

こんにちは、Habr！



私はそれほど昔はITに携わっていませんでしたが、最近、サイバーセキュリティのトピックに夢中になりました。ペンテスターの職業は特に興味深いものです。サーフィンをしていると、SecurityShenanigansによる「DBの構成が不適切なために25,000を超えるホストのクラウド全体を所有できるようになった」というクールな記事を目にしました。両方の部分の翻訳とあなたの注意を喚起します。

前書き

この記事では、大規模なクライアントを危険にさらすためにBMC / IPMIを使用してデータベースへの直接sqlmap接続を実行する方法を学習します。

バックグラウンド

数年前、私たちのチームは、Openstackネットワークでインフラストラクチャ侵入テストを実施するというタスクを受け取りました。これは、25,000を超える仮想マシンをホストする約2,000の物理サーバーで構成されていました。発信トラフィックの量に制限のある小さなサブネットで作業を開始しました。クイックスキャンの後、Nmapは悪用される可能性のある明らかな脆弱性を見つけることができませんでした。そのため、私たちは利用可能なサービスの調査を開始しました。その中に、開発サーバーでホストされている無防備なPostgreSQLサーバーが見つかりました。会社名のいくつかの派生物を使用してカスタムワードリストを作成した後、アカウントからの比較的単純なデータを使用してシステムに忍び込むことができました。ユーザー名はPostgres、パスワードは「admin」でした。



次に、使用することにしましたsqlmap。このツールはSQLインジェクションを使用するように構築されていますが、直接データベース接続を確立するときに（資格情報がある場合）、いくつかのオプションを提供することもできます。これらのオプションの1つは、本番環境のデータベースに対してコマンドシェルを起動することです。







シェルをテストした後、逆接続を取得するためにカスタムペイロード（ペイロード）を構築することにしました。これにより、より快適に作業できるようになります。



msfvenomを使用してペイロードを作成しました。この場合のペイロードは、Linuxx64マシンのリバースTCPシェルでした。前の画像では、データベースアーキテクチャを選択する必要があることがわかります。





msfvenomを使用してペイロードを収集する



このペイロードの利点は、単純なNetcatを使用して接続し直すために使用できることです。他のほとんどのペイロードは、同じタスクに対してMetasploit（エクスプロイト/マルチ/ハンドラーを選択）のようなものを必要とします。



sqlmapラッパーを使用してペイロードを実行した後、サーバーへの接続を取得しました。





ペイロードの起動接続の回復





とアクセスのテスト

BMCデバイスの使用

インフラストラクチャ侵入テストを実行し、新しいネットワークセグメント上のマシンを危険にさらすときはいつでも、新しいものが出現していないかどうかを確認するために再スキャンする必要があります。このデータベースにより、ほとんどの仮想マシンとホストを含​​む会社のクラウドネットワークに接続することができました。いくつかのBMCデバイスが見つかったため、新しいスキャンの結果に非常に満足しました。





3つのBMCデバイスの1つ



BMC（Baseboard Management Controller、サービスプロセッサ）は、メインサーバーに接続された優先的な組み込みデバイスであり、帯域外の監視と制御を提供します。CPU、BIOS、オペレーティングシステムとは独立して動作します。これらの要素のいずれかで発生するエラーは、その動作に影響を与えることはできません。マイクロプロセッサには独自のプロセッサ、メモリ、ネットワークインターフェイスがあるため、サーバー自体の電源がオフの場合でも使用できます。すべての主要な機器サプライヤーは、自社製品に特定のBMCを持っています。

• Dell DRAC
• IBM IMM
• HP iLO
• スーパーマイクロIPMI

あなたがに精通する必要があることを別の用語は、IPMI（インテリジェントプラットフォーム管理インタフェース）は、基本的にあなたがこれらのデバイスとの通信に使用するプロトコルです。その目的は、サーバーの電源がオフになっているが電源に接続されている場合でも、オペレーティングシステムに関係なく、サーバーハードウェアを監視および管理することです。



IPMIは、見つけることができる最も安全でないプロトコルの1つであるとだけ言っておきましょう。 IPMI 2.0は、認証ステップ中にサーバーからカスタムハッシュを直接要求できるように設計されています。 「暗号0」モードで認証を要求すると、別の脆弱性が存在します。これにより、任意のパスワードでログインできるようになります。





IPMIブロックアーキテクチャ



BMCデバイスは、データセンターの組み立て段階で一度構成され、サーバーが従来の方法で利用できない場合にのみ使用されるタイプのデバイスであるため、通常は保護が不十分です。暗号0が



有効になっている一部のデバイスで簡単に認証できました。





ここでは、ランダムなパスワードでログインする方法を確認できます。 「-C0」の部分に注意してください。





ランダムなパスワードでデバイスに正常にログインしたデバイスの





ネットワーク情報



一部のデバイスで暗号0が有効になっていない場合でも、他の方法でログインできます。最も有名な2つは、デフォルトの資格情報を使用するか（sysadminは通常変更を試みません）、ハッシュ開示の脆弱性を悪用する（そしてハッシュを壊す）ことです。後者はほとんどのデバイスで実行する必要がありました。





ほとんどのユーザーのBanalのデフォルトのユーザー名とパスワードのペア





サーバーに要求するユーザーのハッシュを含む単語のリスト





metasploitを使用したカスタムハッシュの拡張





すぐに、典型的なハッシュに関するデータを取得します。



すべてのハッシュを通過した後、それらをクラックし始めました。





最初のハッシュをクラック



する数分で、約600個のBMCにアクセスできました。





609個のハッシュが正常にクラックさ



れましたクラックできなかったHPILOデバイスがいくつかありました。幸いなことに、HP iLO 41.00から2.50にも認証バイパスがあります。これにより、Webサーバーによって処理されるHTTP接続ヘッダーのバッファーオーバーフローを介して管理者アカウントを作成できます。 このエクスプロイトはこれを使用して、APIの残りの部分への特権アクセスを取得します。これにより、アカウントを作成する権限が与えられます。





CVEの使用-2017-12542



これらの手順の後、会社のBMCデバイスの90％を完全に制御できるようになりました。BMCデバイスについて読んだことがあれば、次のことができることがわかります。

• モニター
• リブート
• 再インストール
• KVM（仮想化）

接続されたデバイス。これは素晴らしいことですが、サーバーへの物理的なアクセスをシミュレートするだけなので、内部に入る必要があります。はい、デバイスの電源を切ることでだまされますが、それだけでは不十分だと思ったので、掘り下げました。



物理アドレスを持つハードウェアをハッキングする最も一般的な方法の1つは、ハードウェアを再起動して、ルートシェルの自動実行を制御することです。これは、Unix、Mac、およびWindowsで実行できます。



このアプローチの難しさは、各サーバーが通常約2000の仮想ホストをホストすることです。そのため、未使用のサーバーを見つける必要がありました。計画は、それをオフにし（または、すでにオフになっている場合は開始する）、自動実行を編集してルートアクセスを許可することでした。その後、構成を調べて、他のサーバーも危険にさらす可能性のあるバグ/ペイロードを見つけたいと思いました。



Openstackを使用すると、ローカルインフラストラクチャを照会し、特定のパラメーターを照会できます。それらの1つは、仮想マシンの状態です。このローカル企業の場合、VMの可用性（トラフィックを受信するためのホワイト/ブラックリスト）+動作状態（開始/無効）として定義されました。



ブラックリストに登録されたサーバーを見つける必要があり（動作状態は関係ありません）、ディスクの問題が原因で動作していないサーバーが見つかりました。幸い、起動はできましたが、ファイルシステムの一部が読み取り専用モードになってしまいました。





適切なハッキングサーバーのOpenstackリクエスト



それが見つかったら、以前に見つけた資格情報を使用してログインしました。





以前に取得したアクセスを使用し





ます。KVMインターフェイスへのアクセスKVMインターフェイス



は、BMCを介したサーバーへの直接接続をシミュレートします。起動時に、Grub自動ロードを編集ro init = / bin / bashし、適切な行に追加してルートシェルで起動する必要があります..。通常、読み取り/書き込みフラグ（rw）が使用されますが、障害が発生したディスクの問題を防ぐために、読み取り専用フラグ（ro）を使用する必要がありました。





grubメニューの編集



ログイン後、ネットワークインターフェイスを調べて、サーバーへの接続をテストしました。ご覧のとおり、ifconfigには10を超えるアクティブなインターフェイスが表示されます。







ネットワークの構造を分析し、私たちがどこにいるかを理解するために少し時間を取った後、私たちはサーバーの研究を始めました。



数分で、bash_history（Linuxマシンで見つけることができる貴重な情報の最良のソースの1つ）





novadb資格情報の中間点がbash_historyに見つかりました。



Openstackアーキテクチャに慣れていない人のために、Novaは、証明書、クォータ、インスタンス名、メタデータ、その他の重要な情報など、クラウド全体の管理情報を格納する管理データベースです。





資格情報の確認ログイン



後、grants_MySQLを使用して管理者アクセスを確認しました。







これを行うと、NovaDBの内部構造を確認できます。





Novadbデータベースのテーブル



VMに関する情報を見ると、約34,000台のデバイスが見つかりました。ただし、それらの約3分の1は利用できない/機能していません。正確な金額は、行エントリfloat_ipsで確認できます。







データベースからのこのデータが非常に重要である理由を説明しましょう。



会社全体をシャットダウンする場合は、BMCインターフェイスを介して各仮想サーバーをシャットダウンできます。 sysadminsが電源をオンに戻すまで機能しません。



独自のマルウェアを作成してすべてのサーバーに感染させることはできますが、BMCチャネルを介した大量展開は簡単ではありません（アクセスする前に未使用のサーバーを起動してGrubの自動実行を編集する必要があったことを思い出してください）。



ただし、NovaDBにアクセスすると、データベースを破損するだけで、クラウド環境全体が機能しなくなります。 sysadminがデータベースをすばやく確認できるほど賢いとしても、破損したデータベースのトラブルシューティングは、欠落しているデータベースよりもはるかに困難です。



また、システム管理者は何かが間違っていることを理解し、最新のバックアップですべてを上書きするだけですよね？私たちもそれについて考えました。これが、先に進んでバックアップを危険にさらした理由です。



最初は、のようなものでメインデータベースにクエリを実行しようとしました

SELECT * FROM information_schema.PROCESSLIST AS p WHERE p.COMMAND = 'Binlog Dump'; が、会社は不規則に実行され、マスター/スレーブスキームを使用しない独自のバックアップソリューションを使用しました。そのため、メインのポートと同じポートで実行されているバックアップデータベースを見つけるために、隣接するサブネットのスキャンを続けました。





バックアップ



を見つける方法既存の資格情報を使用する可能性を確認したところ、もちろん、それらが見つかりました。





バックアップへのアクセスの確認



独自のバックアップを使用して、仮想化インフラストラクチャの完全な侵害と、数分で操作を完了する方法を証明することができました。



私は常にレビュー/レポートを終了し、見つかった問題を修正できるようにします。さらに、それらの多くがありました、例えば：

• 資格情報の再利用
• ネットワークセグメンテーションはありません
• 禁止パスワード
• 安全でないバックアップ構造
• 古いファームウェア

修正が容易ではなかった重大な問題の1つは、IPMIプロトコルの欠陥でした。 



最も成功する解決策は、BMC対応サーバーを、IPアドレスのリストが制限され、制御された別のネットワークセグメントに配置することです。これがこの会社が最終的に行ったことです。



私たちの話を楽しんでいただけたでしょうか。私たちがこのトピックを学ぶのを楽しんだのと同じくらい。