Cisco UCS Managerの脆弱性の悪用：悪魔はひどいですか？

Cisco UCS Managerのエクスプロイトがオンラインで公開され ています。 バージョン2.1（1b）およびおそらく他のバージョンが脆弱であることが示されています。

Cisco Webサイトの「 GNU Bash環境変数コマンドインジェクションの脆弱性」セクションには、バグ修正製品の更新バージョンが利用可能であることが示されています。

• 3.0（1d）（利用可能）
• 2.2（3b）（利用可能）
• 2.2（2e）（利用可能）
• 2.2（1f）（利用可能）
• 2.1（3f）（利用可能）
• 2.0（5g）（利用可能）

ネイティブテストでは、脆弱なバージョンは次のとおりであることが示されています。

• 2.2（1d）
• 2.2（1c）
• 2.1（2a）

脆弱ではない：

• 2.2（6c）
• 2.2（3e）

この脆弱性と脆弱なデバイスの数の分析を実施しました。 Shodan検索エンジンと独自の検索アナログ（長期のライブインポート置換）を使用します。 そしてそれが起こったのです。



エクスプロイトコードから判断すると、HTTPSプロトコルを使用して特別に生成されたURLで作業する場合、コマンドはUser-Agentフィールドに挿入されます。 エクスプロイト作業を2つの段階に分けることができます。 最初の段階で、エクスプロイトはシステムが脆弱かどうかを判断しようとします。 これを行うには、ユーザーファイル「/ etc / passwd」が読み取られ、ユーザー「root」が検索されます。 第2段階では、擬似デバイス/ dev / tcpの機能を使用して、攻撃者の制御対象ノードへの逆接続が行われます。



脆弱な機器を発見したため、この脆弱性を少し試すことができました。



コマンドを実行します。

$ who daemon
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイル/ etc / passwdの内容を読み取ります

 $ cat /etc/passwd root:*:0:0:root:/root:/isanboot/bin/nobash bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/usr/sbin: sys:*:3:3:sys:/dev: ftp:*:15:14:ftp:/var/ftp:/isanboot/bin/nobash ftpuser:*:99:14:ftpuser:/var/ftp:/isanboot/bin/nobash nobody:*:65534:65534:nobody:/home:/bin/sh admin:x:2002:503::/var/home/admin:/isan/bin/vsh_perm svc-isan:*:499:501::/var/home/svc-isan:/isan/bin/vsh_perm samdme:x:2003:504::/var/home/samdme:/bin/bash
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり ルートユーザーは存在し、脆弱なソフトウェアはデーモンユーザーから実行されます。

多くのポートも開いています。



uname -a

Linux UCS078A-AA 2.6.27.10 #1 SMP Fri Nov 15 03:08:09 PST 2013 i686 i686 i386 GNU/Linux



cat /etc/*release



Wind River Linux









User-Agent文字列にコードを挿入するのは一般的な方法です。 たとえば、nmapネットワークスキャナー用のshellshock検索スクリプトも、デフォルト設定でこのアプローチを採用しています。 私は個人的にこのスクリプトを構成できなかったため、Cisco UCS Managerのテスト済みの機器の脆弱性を実際に判断しました。



「Cisco UCS Manager」のShodan検索エンジンは何も返しません。 そして、「Cisco UCS」のリクエストで-多くのことから、デバイスに関連する7つのアドレスを見つけることができます。 問題はいくつかの単語の部分文字列を検索できないことであると思われます。最終的には、任意の式が検索されます。 とはいえ、たぶん私はShodanの経験の浅いユーザーなのかもしれません。

PHDays 2015カンファレンスで、同僚とShodan に似た検索エンジンについて話しました 。



マスク16を使用した2つのネットワークでの一般的な要求による検索：





基本的に、検索エンジンの仕組みについて説明しました。 しかし、彼らは特定の機器を見つける問題にも触れました。要求に応じてデバイスの最大数を見つける必要があります。 同時に、クエリ結果には最小限のゴミが含まれている必要があります。 特に、彼らは特定のデジタル指紋についての考えを表明しました。 要するに、機器は異なるように構成できます（デフォルト設定、またはカスタム設定、ファイアウォールの背後またはNATの背後の機器操作）。 試行錯誤によって各事例を研究し、蓄積された経験を考慮に入れて、完全に重要な要求が作成されています。 その結果は、通常の初期検索とは大きく異なる場合があります。 それで、この状況で起こりました。 たとえば、上記のスクリーンショットからわかるように、デバイスを検索すると、「OpenSSL / FIPS」という文字列が表示されます。 Shodanでこの行を再度検索すると失望します。結果には再び明確な検索文字列がありません。 検索エンジンでの検索では、以前の検索と比較して、見つかったアドレスの数が増加しました。 率直に言って、このような検索では依然としてガベージレコードが生成されます。 つまり Cisco UCS Managerとは関係のない検証中のレコード。

一般に、デジタル指紋の作成の問題（特定のデバイスを含む）は、別の記事のトピックです。 固有のIPアドレスを持つ約50 台のデバイスが見つかりました（各デバイスは異なるアドレスを持つ複数のネットワークインターフェースを持つことができるため、見つかったデバイスの数について話すのは完全に正しくありません）。 主にアメリカで。



現在、幅広い視聴者に検索エンジンへのアクセスを提供する問題が解決されています。 コミュニティからの関心がある場合。