IPMI stuff from DARPA work
IPMIを調査するためのソフトウェアをいくつか書きました。以下はその結果の一部です。いつものように、検出、データ取得、監査という一連の流れをやろうと考えました。それぞれが、少なくとも私にとっては、それなりに興味深い問題であることがわかりました。
http://fish2.com/ipmi にある論文や資料
これは、リモートBMC上のアカウントを推測し、そのハッシュを抽出し、(HMACでハッシュ化された)パスワードのクラッキングを試みる小さなPerlプログラムです。興味のある方のために、これについて少し書きました。コメントが多用されており、何かの役に立つかもしれません。
IPMI仕様によれば、リモートシステムの暗号スイートを認証なしで取得できるとされていますが、実際にこれを行うツールを私は知りません(すべて認証が必要です。もちろん、生の16進バイトを入力すれば別ですが!)。そこで、これを行う小さなツールを書きました。これは主にipmitoolの出力に従おうとしています。その過程で、そのユーティリティのバグを発見したと思います(最終行で、時々システムが誤って解釈されるように見えるゴミを出力することがあります)。しかし、誰にもわかりません。テストするのに十分なシステムを持っていないのです。とにかく... ipmi-get-ciphers.py。
少なくとも、Cipher0システムを見つけるのに役立ちます(注:これは単にサポートされている暗号スイートを示しているだけで、実際に有効になっているという意味ではありません)。しかし、世の中には興味深いものがあります。
ここには2つのプログラムがあります。1つはシンプルなPython製リモートプローバーです(言っておきますが、Perlが嫌いになり始めています)。もう1つは、FreeIPMIのユーティリティを使用して、認証情報付きの構成データを取得するものです。
単一のパケットをBMCに送信し、応答をじっくり調べる小さなPythonプログラムです(インラインコメントが50%以上、gzip圧縮で2.5k)。たった1つのパケットで何ができるのかと疑問に思うかもしれませんか? まず、IPMIのための10以上の異なるセキュリティテストができます。まあ、最初から最後まで、それは単なるパケットです :) 動作には、Python、BMC、およびUDPポート623への開放された経路が必要です。使い方は単に「ipmi-get-auth.py target」です。
これを極限まで進めると... まあ、上記のメガバージョンのようなもので、すべてのチャネル、すべての権限、すべての... まあ、どのようなものかおわかりでしょう。偏執的な人のために(なぜこのような動作をするのかは、コメントまたは私が書いた投稿を読んでください!)
mega_chan.py /
メガ・メガ・メガ ... チャン・チャン・チャン...
ここでは、システムにGet Device IDパケット(IPMI v2仕様のp250を参照)を送信するシンプルなプログラムを紹介します。これは理論上、認証なしで動作するはずです。私が行った小さな調査では、約90%のシステムがこれに応答しました(すべてが有効な情報を返したわけではありませんが!)。ベンダーやモデル番号などの情報を取得できることもありますが、より興味深いのは、従来ネットワーク経由での取得が難しいとされてきた一意のIDを実際に取得できることです。
Supermicroは、そのBMCからのパスワードファイル漏えいに関していくつか問題を起こしてきました。たとえば、これや他の記事を参照してください:
a-penetration-testers-guide-to-ipmi
このスクリプトを使用するには、単に次のようにします:
dump_SM.py password_file
私の環境では動作します。保証はありませんので、あしからず。
まあ、UDPポート623と通信できれば、リモートシステムがIPMIを実行しているかどうかを調べるのは非常に簡単です。しかし、データセンター内にいない限り、ほとんどの人はUDPをブロックします。たとえブロックしていなくても... UDPスキャンは想像できる限り最も遅いものです。そこで、現在は2つの基本的な方法を使用しています。老舗のNmapとipmiping(FreeIPMI GNUツール由来)を活用しています。最も簡単な方法は次のとおりです。
</p> <p>
Nmapは大規模ネットワークのスキャンにおいてipmipingよりもはるかに効率的であるため、この方法はNmapがホストのUDP 623がオープンであると報告した場合にのみ使用されます。
</p> <p>
良くも悪くも、このポートはしばしばブロックされるため、多くの場合、他の方法でIPMIが実行されているかどうかを間接的に突き止める可能性が高くなります。
</p> <p>
ポートは、その指標となる能力と、Nmapがそれらをオープン、フィルタード、または他の状態として検出するかどうかによって重み付けされます。
</p> <p>
Nmapは接続先サービスのバナーも表示できます。私はターゲットを探すために正規表現を使用しています。たとえば、"iLO"や"DRAC"という文字列は、システムがHPのIntegrated Lights Outサービス(またはiLO)を実行している可能性があることを示す良い指標です。
</p> <p>
<strong>注記:</strong> 現在、ブロードキャストpingメソッド(自分がいるサブネットをすばやく通過する非常に高速な方法)は使用していません。この有効性に関するデータを単に持っていないためです。機能するときは非常に高速ですが、任意のスキャンの制御と信頼性を可能にするとは感じられませんでした。私の3つのシステムのうち2つ(DellとHP)はRMCP pingに応答しました。idiscover(ipmiutil discover)によるブロードキャストpingに応答したものはありませんでした。ただし、すべてが以下の私のPython監査ツールには応答しました。
</p> <p>
残念ながら(もちろん!)、通信とネットワークの亡霊が登場します。nmapは、ポートがオープンかどうかについてさまざまな理由(open、closed、filteredなど)を返します。さらに別のテーブルには、Nmapが言うところの「open|filtered」ヒットよりもオープンポートに多くのポイントを与える重みのセットがあります。nmapの解釈と重み付けは少々もどかしいですが、それが人生です(c'est la vie)。
</p> <p>
すべての重みを取得し、すべてのポイントを合計すると、IPMI確信度レベルが得られます。アドホックテストでは、15ポイント以上がシステムがIPMIを実行している強力な指標であることがわかりました。
</p> <p>
現在、私はさまざまなしきい値(no、possibly、probably、yes)を持っています。テストでは、自分のサーバー以外への既知のアクセスなしで、それなりにうまく機能しているようです。つまり、私が疑わしいと思うものと上記の基本的な思考モデルは、確かに特定のサーバーを上位に浮上させ、ランダムなホストはそのままにしておきます。ただし、誤検知にはいくつかの実際の問題があります。多くのファイアウォールは、nmapに対して任意のポートに何かがあるように見せかけているようです(まれなポートを1つか2つ追加することも考えました(たとえば、ポート1や31313のようなものに耳を傾けている場合、おそらく*実際に*リッスンしているわけではありません!))
</p> <p>
しかし、これはこのテーマに関する最終的な結論を意図したものではありません。IPMIバナーのまともなデータを取得するのはかなり簡単なはずで、多数のシステムを迅速にスキャンするには、これが断然最良の方法だと思います。
上記を実装するPerlスクリプトが4つあります。1つはスキャン用、1つは解釈用、残りの2つは重み付け用です。研究ツールまたは概念実証であり、本番用スキャナーではありませんが、それなりの妥当な出力を生成します。
必須: Nmapバージョン6。
使い方はかなり簡単ですが、少し癖があります。rootとして実行する必要があります。詳細な出力には詳細フラグ(-v)を使用します。
スキャンは、ターゲット名に対応する一対の結果ファイルを作成します(スラッシュはアンダースコアに変換されます)。それらに対して後処理スクリプトを実行するだけです。数値の逆順ソートに通すと、より興味深い順序になります。10を超えるものは疑わしいと見なし、20を超えるとIPMIが実行されている可能性がかなり高いと言えます。# standard run: ./ipmi_scan.pl -A -v -O yes 192.168.0.0/24 # fast ./ipmi_scan.pl -tcp -v 192.168.0.0/24 # kitchen sink ./ipmi_scan.pl -A -v -O high 192.168.0.0/24
この場合は、簡潔フラグ(-t)を使用して、出力を最小限に削減しました。
./post_ipmi_scan.pl -t 192.168.0.0_24|sort -rn 96.3 192.168.0.69 16.25 192.168.0.46 10.8 192.168.0.23 7.33 192.168.0.202 5.4 192.168.0.189 5.4 192.168.0.179 1.7 192.168.0.9 1.23 192.168.0.1 1.1 192.168.0.8 0.9 192.168.0.251 0.63 192.168.0.55 0.43 silent/192.168.0.250 0.2 pi.fish2.com/192.168.0.14 0.2 fierce.fish2.com/192.168.0.6 0.2 192.168.0.88 0.01 192.168.0.16
上記の結果では、上位3つのシステムが実際にIPMIを実行していますが、NmapにUDPポート623がオープンであると報告したのはHPだけでした。私のDellとSupermicroは、より曖昧な「open|filtered」応答を返しました。これはかなり一般的な誤報です。うんざりします。おそらく、我慢してスキャナーと並行してIPMI pingを実行する方が良いでしょう(または、Nmapで正しく実行するNSEを書くか)。
ここでは、FreeIPMIツールを使用して、(a)サーバーの基本的なIPMI/BMC構成を吸い出し、(b)結果に対してちょっとしたセキュリティチェックを行う、いくつかの小さなPythonプログラムを紹介します。
なぜなら... まあ、実際には特別な理由はありません。1つはpython3で、もう1つはpython2です。あなたの準備度を試しているのだと思います。プログラムはかなりコメントが多用されています。特にipmifreely.pyには詳細なコメントがあるので、何が行われているかの詳細はそちらを確認してください。simplejsonとConfigParserが必要です。もしかすると他にもいくつか。
必須として、FreeIPMIがインストールされている必要があります。これを書いている時点では、MacとWindowsではサーバーからクールなJSONファイルを吸い出す機会が失われます。そして、本当に、本当に新しいバージョンが必要です。警告しなかったとは言わないでください。しかし、人生は続きます。
データ取得は、有効な認証情報を必要とするPythonプログラム(I-check.py)を介して行われます。結果をJSONに変換し、それを監査ツール(ipmifreely.py)でチェックできます。「IPMI-policy.ini」にサンプルポリシーがあり、テスト用の値をいくつか入れています。
| I-check.py - IPMI構成データを取得 |
| ipmifreely.py - 上記の出力を解析し、いくつかの結果を出力 |
使用例:
# this grabs the configuration stuff; here I'm using it on an HP iLO 3 server # the output is redirected to a file $ ./ipmifreely.py -v -u admin -p admin 192.168.0.46 > hp.json # This takes the JSON file and looks for issues $ ./I-check.py drac.json ./I-check.py hp.json Host: 192.168.0.46 [bmc-config] Serial_Channel Non_Volatile_Enable_Pef_Alerting = No [bmc-config] Serial_Channel Volatile_Enable_Pef_Alerting = No [bmc-config] Serial_Channel Volatile_Enable_Per_Message_Auth = No [bmc-config] Serial_Channel Non_Volatile_Enable_Per_Message_Auth = No [bmc-config] Lan_Conf_Security_Keys K_G = 0x0000000000000000000000000000000000000000 [bmc-config] SOL_Conf Force_SOL_Payload_Authentication = No [bmc-config] SOL_Conf Force_SOL_Payload_Encryption = No [bmc-config] Lan_Conf_Auth Callback_Enable_Auth_Type_None = Yes [bmc-config] Lan_Conf_Auth Operator_Enable_Auth_Type_None = Yes [bmc-config] Lan_Conf_Auth OEM_Enable_Auth_Type_None = Yes [bmc-config] Lan_Conf_Auth Admin_Enable_Auth_Type_None = Yes [bmc-config] Lan_Conf_Auth User_Enable_Auth_Type_None = Yes [bmc-config] Rmcpplus_Conf_Privilege Maximum_Privilege_Cipher_Suite_Id_1 = OEM_Proprietary [bmc-config] Rmcpplus_Conf_Privilege Maximum_Privilege_Cipher_Suite_Id_0 = OEM_Proprietary [bmc-config] Rmcpplus_Conf_Privilege Maximum_Privilege_Cipher_Suite_Id_2 = OEM_Proprietary [pef-config] Community_String Community_String = public [pef-config] PEF_Conf Enable_PEF_Event_Messages = No
セキュリティ上、何をチェックすべきか、私が良いと考えることの詳細は、IPMIセキュリティのベストプラクティスを参照してください。
| ipmi_scan.pl - 基本的なIPMIスキャナー。Nmapを使用し、利用可能ならipmitoolも使用 |
| ipmi_scan man page - 上記のmanページ |
| post_ipmi_scan.pl - 上記の出力を解析し、重み付けされた結果を出力する |
| j_vendor.pl - 基本的なベンダーデータ... どのベンダーがどのポートを使うか? |
| j_weights.pl - 上記の基本的なベンダー重み |
| IPMI-policy.ini - IPMIポリシーファイル |