インフラセキュリティの処方箋

第38回 2017年9月~今月は脆弱性祭り~どうしてこんなに出てくるのか~

この記事を読むのに必要な時間:およそ 2 分

2017年9月は,かなり深刻な脆弱性が相次いで発見された月でした。中でもApache Tomcatの脆弱性は,相当深刻なレベルのものと理解しています。

今月は,Apache Tomcatの脆弱性について解説を行います。

CVE-2017-12615~Windows版Tomcat 7でリモートコード実行できる脆弱性のはずが……

2017年8月16日にリリースされたTomcat 7.0.81ですが,これはWindows版Tomcatが稼働している環境で,任意のコードを実行させられる脆弱性とされて「いました」⁠

Tomcat脆弱性修正

Tomcat脆弱性修正

When running on Windows with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server.

具体的な実行手順は割愛しますが,リモートコード実行のためには,おおまかには以下の手順を踏みます。

  1. 実行させたい内容を記述したJSPファイルをアップロードする
  2. 当該JSPにアクセスし,記述された内容を実行する

CVE-2017-12615は,Tomcat 7.0.81で修正されましたが,その後の第三者検証により,以下のことが明らかになりました。

  • CVE-2017-12615は修正されたものの,さらに悪質な脆弱性がTomcat 7.0.81で確認された
  • 影響するバージョンは,9月25日時点のTomcat7~9の最新版
  • 脆弱性の影響を受ける動作プラットフォームは,Windows以外にもLinux,Unixも入る

もともと,CVE-2017-12615については,2017年9月20日にJPCERT/CCから注意喚起が出されていましたが,上記のような状況を受けて,2017年9月25日に注意喚起の内容が更新されています。

Apache Tomcat における脆弱性に関する注意喚起(最終更新: 2017-09-25)
http://www.jpcert.or.jp/at/2017/at170038.html

CVE-2017-12617~広範なプラットフォームに影響するTomcat 7~9のリモートコード実行脆弱性に対し,新たに採番されたCVE番号

上記のように,広い範囲に影響するTomcatの脆弱性ということで,新たにCVE番号 CVE-2017-12617が採番されました。

本校執筆時点(2017年9月25日)では,まだ脆弱性修正が行われたTomcatはリリースされていないため,Tomcatそのものの設定もしくはTomcatと連携するWebサーバなどで影響するリクエストを止める必要があります。

現状の対策は,設定中のreadonlyパラメータをtrueにすること~PUTを制限するだけでは不十分

本脆弱性は,PUTをはじめとする「書き込みを行えるリクエスト」を,リクエスト内容を細工することで通してしまうものです。詳細は後述しますが,バージョンアップ以外で行える対処は,readonlyパラメータをtrueにするか,readonlyパラメータの設定を削除してしまうことです(readonlyパラメータを指定しないときは,true扱いになります)⁠

下記は,Tomcat 7のweb.xmlを編集し,readonlyパラメータをfalseにしたもので取得したOPTIONSリクエストに対するレスポンスの内容です。readonlyパラメータをtrueにした状態でも,OPTIONSリクエストに対するレスポンスからは,PUTとDELETEが発行可能なように見えますが,実際にPUTやDELETEを発行しても受け付けられないことは検証済みです。

telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OPTIONS / HTTP/1.0

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS
Content-Length: 0
Date: Mon, 25 Sep 2017 18:14:59 GMT
Connection: close

readonlyパラメータは,以下のように<servlet>~</servlet>で囲まれた部分に,<init-param>~</init-param>で囲まれたところでパラメータを設定するだけです。

以下に,readonlyパラメータをfalseにした記述を含む設定を示します。

<servlet>
    <servlet-name>default</servlet-name>
    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
    <init-param>
        <param-name>debug</param-name>
        <param-value>0</param-value>
    </init-param>
    <init-param>
        <param-name>listings</param-name>
        <param-value>false</param-value>
    </init-param>
    <init-param>
        <param-name>readonly</param-name>
        <param-value>false</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

書き込みを行うことを想起させるのは,PUTとDELETEですが,本脆弱性は,細工されたDELETEリクエストも処理するように仕向けることが可能です。これは,Webアプリケーションサーバ上に配置されたJSPファイルを削除することが可能ということを意味します。PUTを制限することで,アップロードされた任意コードの実行は防げますが,DELETEを制限しないとサーバ上のJSPファイルを削除可能になり,これはこれでDoS攻撃を誘発することになります。

大変残念なことに,本記事を校正している段階でまだ脆弱性が修正されたTomcatがリリースされていません。修正版がリリースされるまではPUTやDELETEなどのリクエストを受け付けないような設定にしておき,修正版がリリースされたらすみやかにTomcatのバージョンアップを行うことをお勧めします。

著者プロフィール

宮本久仁男(みやもとくにお)

某SIerに勤務する,どこにでもいる技術者。

OSやネットワーク技術に興味を持ち,その延長でセキュリティ技術にも興味を持って,いろんな調査や研究を手がけてます。

自分で思考を巡らしたり検証したり,というのももちろん好きで,あれこれやってます。もちろん他の人に迷惑はかけない範囲で……ですが。

博士(情報学),技術士(情報工学)。

URL:http://d.hatena.ne.jp/wakatono/

監訳書の1つ:実践Metasploit

コメント

コメントの記入