4月 23

Apache Struts 2のClassLoader を外部から操作される脆弱性（CVE-2014-0094）（S2-020）を利用した攻撃検証レポート

【概要】
前回は検証では攻撃者が制御を誘導することが可能であることを確認しました。今回は実際の攻撃を想定し「webshell」が設置できることを確認します。webshellはブラウザからコマンドを入力し、その結果を表示するようなウェブアプリケーションです。

【影響を受ける可能性があるシステム】

– Apache Struts 2.0.0 – 2.3.16

【対策案】
Apache Software Foundationから本脆弱性を修正されたバージョン「Apache Struts 2.3.16.1」がリリースされております。当該脆弱性が修正された修正プログラムを適用していただくことを推奨いたします。

なお、上記の「Apache Struts 2.3.16.1」では、回避策（Workaround）として記述のあるとおりに初期設定が変更になっております。そのため、緊急のバージョンアップが難しい場合は回避策を実施いただくことを推奨いたします。

【参考サイト】
CVE-2014-0094

Apache Struts 2 Documentation S2-020

Apache Struts2 の脆弱性対策について(CVE-2014-0094)(S2-020)

【検証イメージ】

【検証ターゲットシステム】

Debian 6.0.7 上のApache Tomcat 8.0.3、Apache Struts 2.3.14を利用したWebアプリケーション

【検証概要】
脆弱性の存在するターゲットシステムへ、細工したHTTPリクエストを送信し、webshellプログラムをダウンロードさせ、ダウンロードさせたwebshellから任意のコマンドを実行し情報を取得するというものです。

これにより、リモートからターゲットシステムの操作が可能となります。

【検証結果】
はじめに、攻撃者がwebshellを置いたサーバにアクセスしてみます。設置するwebshellが置いてあります。

また、ターゲットシステム上にwebshellが存在しないことを確認します。

続いて、ターゲットシステムにwebshellをダウンロードさせるリクエストを送ります。すると、ターゲットシステム上にwebshellがダウンロードされます。

さらにターゲットシステムで任意のコマンドを実行してみます。「id」「pwd」「cat /etc/passwd」を実行しています。

このように、前回と異なり、webshellを一度設置するといつでも操作が可能となります。

【考察】
脆弱性への根本的な対策としては、バージョンアップを行うこととなります。
しかし、バージョンアップを行う前に攻撃されてしまうことも考えられるため、今回の例において攻撃された際に被害を最小化するためにはどのようなことを行っておけばよいかを考えてみました。

項目としては以下の4つです。

アプリケーションサーバの実行ユーザの権限を最小化する
不要なソフトウェアをインストールしない
アプリケーションサーバからの外部への通信を制限する
サーバ上のファイルの改ざんや追加を検知する

1. アプリケーションサーバの実行ユーザの権限を最小化するについて。

今回の検証ターゲットはアプリケーションサーバ（Tomcat）の実行権限をtomcatユーザとしています。
言い換えると、管理者（root）のみが実行できるコマンドや、操作できるファイルについては攻撃者が実行、読み取りをすることができません。つまり、攻撃に成功した場合でもこの脆弱性単体では全権を奪取されることはないとないと言えます。（Tomcatを動作させている権限が管理者ユーザである場合は、この限りではありません。）
この実行ユーザの権限に関して、脆弱性の利用方法の特徴を捉え、それに応じた厳密な権限の制御を行うことで有効な対策を行えると考えれます。
今回の脆弱性を利用した攻撃は、公開ディレクトリにファイルを生成する必要があります。つまり、攻撃に利用するためのファイルを生成させないよう、Webの公開ディレクトリにはtomcatユーザで書き込みを行わせないということが運用上可能であれば、これは有効な対策の１つだと考えられます。

2. 不要なソフトウェアをインストールしないについて。

今回の検証では、webshellをダウンロードする際、wgetコマンドを呼び出しています。wgetは外部からファイルをダウンロードする際に便利で、よく利用されるコマンドの1つです。しかし、これは同時に、攻撃者にとっても便利なツールであることを意味しています。まずは、これらのツールがサーバ上で利用する必要があるのか否かという点から考える必要があります。
必要な場合は、最低限のユーザにのみ利用を許可するという運用が望ましいと考えられます。
今回の場合に当てはめると、管理者ユーザにはwgetの利用を許可するが、tomcatユーザには利用を許可しないといったことが有効な対策の1つであると考えられます。

3. アプリケーションサーバからの外部への通信を制限するについて。

今回の検証では同一セグメントからファイルをダウンロードさせていますが、実際の攻撃ではインターネット上からwebshellをダウンロードさせることになります。その際、アプリケーションサーバから直接外部に接続するアクセス先を制限していればwebshellのダウンロードは実施できないと考えられます。たとえば、パッケージや修正プログラムのダウンロード先や、サービス提供に必要なアクセス先のみにアウトバウンド通信を制限しておくといったことが有効な対策の1つであると考えられます。

4. サーバ上のファイルの改ざんや追加を検知するについて

今回の検証では、いったんターゲットシステム上に任意のコードを実行するためにファイルを保存する必要があります。「アプリケーションサーバの実行ユーザの権限を最小化する」でふれたように、公開ディレクトリの書き込みを行わない設定にしていれば任意のコードを実行させることはできません。しかし、アプリケーションサーバのログファイルは書き込み権限があるため、ログの改ざん余計なファイルを作成されることは考えられます。
このような場合に有効だと考えられるのが、ファイルの改ざんが追加を検知することです。コストが高い大がかりなものから、cron機能を利用した簡単な仕組みまでいろいろな方法が考えられます。

以上は、ほんの一例であり、他にも対策はあると考えられます。また、これさえ実施しておけば完璧！というわけではありません。しかしながら、今回のような攻撃が成功しにくくなったり被害が抑えられる効果はあると考えます。

また、今回あげたような対策は「やって当たり前」と考える方もいるかもしれません。一方で、まったく実施されていないシステムもまだまだあると考えられます。一つの脆弱性をきっかけに現在運用しているシステムについて、最新のバージョンへのアップデート以外にもどのような対策が可能か今一度検討されてみるのはいかがでしょうか。

reported by oda, ntsuji

Posted 2014年4月23日 by oda in category "exploit