VMware vCenterを突破

現在、仮想システムのセキュリティは流行の傾向にあるため、この質問は無視できません。 今日、VMwareインフラストラクチャの中心であるvCenterサーバーを破壊します。 同時に、0日間の脆弱性を使用して、人生が蜂蜜のように見えないようにします。 仮想テクノロジーとはまったく関係のない旧式の方法でこれを打ち破ります。もちろん、流行は流行しますが、バグはすべて平凡です。



PS：責任あるホワイトハットではいつものように、ここで説明されているすべてのバグは既に閉じられているはずです。ハッキングの時点、つまり2011年には0日でした。 このテキストは、Hacker Magazine No. 7/12（162）に掲載され、CONFidence 2012、PHD 2012、およびDefcon 20でのレポートの基礎にもなりました。

VMware vCenter

多くのエンタープライズシステムは仮想環境に住んでいます。 安いです。 より便利で、よりクールです！ これらの同じ環境を提供するリーダーは、悪名高いVMware社です。 これらの人たちは、クールなハイパーバイザーと、重要なことであるが、導入、管理、制御を容易にするためのあらゆる種類のソフトウェアを持っています。 これにより、VMwareソリューションは柔軟でスケーラブルになり、最終的に効率的になります。 このクールな小さな男をすべて便利に管理するために、彼らはインフラストラクチャの管理部分であるVMware vCenterを統合するサーバーソフトウェアを開発しました。 つまり、たとえば、VMware ESX（i）を搭載した10台の鉄のマシンがあります。 合計で50台の仮想マシンがそれらで実行されています。 このvCenterがない場合、この仮想動物園の管理は非常に不便です。 さらに、vCenterのおかげで、ESXの1つが機能しなくなった場合の仮想イメージの透過的な移行など、さまざまなトリックが可能です。要するに、非常に便利で重要なことです。 これで広告の終わりです。 主なポイントは、悪意のあるハッカーがvCenterを破壊した場合、ネットワーク全体が手に負えなくなるということです。

防衛を突破します

有名な研究者Claudio Crisconeは、この「センター」に何度も出会ったため、その破壊方法を知っています。 そのため、ペンテストの1つで、このソフトウェアに出会い、そこにあるすべてのものを忘れるためにClaudioの知恵を使うことにしました。 実際、Claudioのアイデアはシンプルでした。友人がvCenterアップデートマネージャーに脆弱性を発見しました。 この脆弱性はVMwareプログラマのせいでもありませんでした。 実際、このマネージャーのWebインターフェース（TCPポート9084でハング）は、JettyをWebサーバーとして使用しています。 したがって、Claudioはそこで脆弱性を発見しました。 脆弱性-ジャンルの古典：カタログの境界を越えて：



target:9084/vci/download/health.xml/%3f/../../../../../../FILE.EXT









BlackHatカンファレンスのClaudioスライド;-)



簡単です。vCenterを実行しているアカウントに十分な権限があるすべてのファイルを読み取ります。 しかし、ここにクラウディオが尋ねた質問があります-どうすればファイルを読むことができますか？ 一般的に、彼はファイルシステムを調べ、セッションコードが保存されたすばらしいアクセスログファイルを見つけました（スライドのスクリーンショットを参照）。





不運なファイルの内容;-)



このコードは何ですか？ 実際には、vSphereクライアントはSOAPを介してvCenterと連携します。つまり、通常のHTTPSトラフィックであり、その本体はデータ、コマンドなどのXML構造です。この場合、管理者認証後、SOAPセッションコードが書き込まれます。 、そしてこのコードは、アナログ8などのPHPSESSIONIDを持つCookieとしてチェックされます。明らかに、このコードを盗んだので、SOAPリクエストにそれを入れることができ、vCenterはすでに管理者として認証されていると考えます） つまり、Claudioは、Jetty Webサーバーの脆弱性を通じて、これらのSOAPコードでログを読み取ることを提案しています。



target:9084/vci/download/health.xml/%3f/../../../../../../ProgramData\VMware\VMware VirtualCenter\Logs\vpxd-profiler-6.log







次に、これらのコードをvSphereからのリクエストに置き換えます。 これを行うために、彼はプロキシサーバーを開発しました。このサーバーは、vSphereのパッケージ内のセッションコードをその場で置き換え、MetasploitアドオンVASTOにこのプロキシを含めました。 さらに、このアドオンには他にも多くのチップがありますが、これについては今から説明しません。



このように、Googleのイタリア人の友人はvCenterを罰することを提案しています。 しかし問題は、これらのすべてのバグが私のペンテスト（2011年春夏）の時点で時代遅れになっていたことです。最新バージョンのソフトウェアに対処する必要がありました。つまり、Jettyにパッチが適用されました。



シェルが同じ漏斗に2回当たらないのですか？



失望（景品が機能しなかった）を感じて、私は何をすべきか考え始めました。 一般に、この状況のペンテスターは、このリソースに脆弱性がないことを単に報告書に記載します。 しかし、いつものように、フォースにinりを感じて、私はあなたのパッチを信用しませんでした。 悪用オプションを組み合わせてディレクトリ外に移動することで、Jettyのモックを作り続けました。 そして、15分後に結果が得られました。 同じアップデートマネージャの別の場所にすでに脆弱性がありました：



target:9084/vci/download/.\..\..\..\..\..\..\..\..\FILE.EXT







SOAPコードでファイルを読むことができるので、これはすでに何かです！





あなたの幸せを見つけようとしています...



しかし、再び失望しました-セッションコードは、このすばらしいファイルには含まれていません。 ログを一掃し、私たちを白濁させたVMwareのプログラマーのすばらしい仕事にしか注目できません。 それでは、ファイルシステム上で他に何ができるのか、何が役に立つのかを自分で探してみましょう。最初に思い浮かぶのは、SSLの秘密鍵を盗むことです。 次に、このキーを使用して、SSLトラフィックをインターセプトして復号化できます（wiresharkを使用すると、問題なくこれを行うことができます）。 キー自体は次のように見つけることができます。



target:9084/vci/downloads/.\..\..\..\..\..\..\..\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\rui.key







したがって、ARP SPOOFINGを使用して中間者攻撃を編成する場合、サーバーと管理ワークステーション間のトラフィックを傍受できます。 ところで、管理者のIPアドレスとそのログインは、プロファイラーファイルで引き続き見つけることができます。 もちろん、SSL証明書を置き換え（問題なくこれを行うことができます）、キーを盗むことなくトラフィックを復号化できますが、管理者には無効なSSL証明書に関する警告が表示されます。 キーを盗んだ場合、管理者には何も表示されません。証明書が正しいためです。 つまり、そのような攻撃はよりcで秘密主義的です...





偽の証明書の警告！



VMware vCenter Orchestrator



しかし、vCenterを備えたサーバーには、無料のアドオンが付属しており、自由にインストールできるもう1つの素晴らしいものがあります。これが「オーケストラ」です。 別の管理インターフェイス、今回はセンター自体。 これは何のためですか？ そして、これはクールなことです。 データセンターのライフサイクルを管理するために使用されます。 これは、仮想インフラストラクチャのさまざまなプロセスを開発および自動化するためのフレームワーク全体です。 要するに、それはクールであり、それだけです。 ファイルシステムを調べてみると、次のファイルに出会いました。



target:9084/vci/download/.\..\..\..\..\..\..\..\..\Program files\VMware\Infrastructure\Orchestrator\configuration\jetty\etc\passwd.properties









すでに何か！



それがまさにMD5ハッシュを取得する方法です。 明らかに、この同じ「オーケストラ」の管理アカウントにはパスワードが隠されています。 何が言えますか？ 無塩MD5の使用は秘密ではありません。 そのため、このコンテキストでは、非常に迅速にパスワードを取得しました（スクリーンショットでは、デフォルトのパスワードがパスワードをハッシュ化したため、管理者も問題を引き起こす可能性があります）。 受け取ったパスワードを使用して、Webインターフェースからログインしました。 快適で、キュートで、素敵なデザインですが、もっと必要です。 Webインターフェースをざっと見てみると、同じvCenter Serverが仮想インフラストラクチャの管理に使用されていることがわかりました。つまり、オーケストレーターはそこで認証できる必要があります。 また、設定のどこかにアクセスパスワードが設定されているため、彼はその方法を知っています。





vCenterの設定にアクセスします。



HTMLコードを開いて、私は嬉しかったです。パスワードはそのままで、ブラウザでは視覚的には「星」の後ろに隠れてそのまま表示されます。





vCenterの管理者アカウントは私たちのものです！



さらに、メールアカウント、ドメインアカウント、およびオーケストレーターが使用できるその他のものからのパスワードがあります。 ハッカー向けのストレートパスワードマネージャー！ 仮想だけでなく、ドメインコントローラーも含めて、システム全体が正常にハッキングされたことは明らかです。

うん！

それはすべてのように思えますが、もう1つの詳細があります。 お気づきのように、Orchestratorはパスワードをどこかに保存します。 そして、それらを純粋な形で入手して使用できるようにします。 これは、MD5ハッシュを破るのではなく、これらのパスワードがどこにあるのかを探すことが可能であったことを示しています。 少し掘り下げたところ、それらが見つかりました。たとえば、vCenterアクセス​​のパスワードが保存されています。



target:9084/vci/download/.\..\..\..\..\..\..\..\..\Program Files\VMware\Infrastructure\Orchestrator\app-server\server\vmo\conf\plugins\VC.xml







さらに、エンコードされた文字列の形式によって判断すると、この暗号化は可逆的です。 同様のパスワードでも非常に暗号化されています。

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <virtual-infrastructure-hosts> <virtual-infrastructure-host xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="VirtualCenterHost"> <enabled>true</enabled> <url>https://new-virtual-center-host:443/sdk</url> <administrator-username>vmware</administrator-username> <administrator-password>000a506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef </administrator-password> <pattern>%u</pattern> </virtual-infrastructure-host> </virtual-infrastructure-hosts>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もう1つの興味深いファイルはC：\ Program Files \ VMware \ Infrastructure \ Orchestrator \ app-server \ server \ vmo \ conf \ vmo.propirtiesです。 ここで、DBMSパスワードは同じ方法でエンコードされます。



エンコード方法の本質を理解し、推測が真実かどうかを理解することは残っています。 これが私の友人と同僚の出番であり、パートタイムでLeetMore CTFチームプレーヤーのAlexander jug Minozhenkoも参加しています。 彼にとって、そのようなタスクは2本の指のようなものです...一見すると、彼は最初の2バイトがパスワード全体の長さを表し、その後エンコードされた表現が来ると判断しました。 Sashaは、パスワードの保存を担当する「Orchestrator」のJavaクラスを単に逆コンパイルし、エンコードアルゴリズムを解析しました。 一番下の行は簡単です。パスワードの長さを取得し、パスワードの各バイトを16進数にエンコードし、バイト位置番号を追加します（ゼロから開始）。 したがって、「Password01」のエンコードされた値は次のようになります。



000a506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef







Sashaはデコーダーを（Rubyで）書きました：

 #  pass = "010506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef" #  len = (pass[0..2]).to_i #  3    enc_pass = pass[3..-1].scan(/.{2}/) #  hex-   dec_pass = (0...len).collect do |i| byte = enc_pass[i].to_i(16) #  hex    byte -= i #        byte.chr end # –  : “Password01.” puts "Password: #{dec_pass.join()}"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、攻撃は、ファイルを読み取るために0デイを使用し、読み取ったファイルからパスワードをデコードするために2番目を使用することになります。 また、vCenterにフルアクセスできます。 数秒で...（Metasploitに対応するモジュールの準備ができました）

ファイナル

ご覧のとおり、0日は単純で危険です。 さらに言えますか？..管理者がファイアウォールを使用してアクセスをフィルタリングし、管理ポートへのアクセスを制限すると、攻撃はさらに難しくなります。 仮想インフラストラクチャの保護は1分だけでなく、1台のサーバーでもないため、多くのことが舞台裏に残っています。 VMware Hardening Guide（http://www.vmware.com/files/pdf/techpaper/VMW-TWP-vSPHR-SECRTY-HRDNG-USLET-101-WEB-1.pdf）ですべての人にアドバイスできます。 このPDFには、注目に値する多くの場所がリストされています。 それだけです、病気にならないでください！