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

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

インフラセキュリティ, セキュリティ, 脆弱性, Tomcat

この記事を読むのに必要な時間：およそ 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のバージョンアップを行うことをお勧めします。

インフラセキュリティ, セキュリティ, 脆弱性, Tomcat

著者プロフィール

宮本久仁男（みやもとくにお）

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

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

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

博士（情報学），技術士（情報工学）。

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

監訳書の1つ：実践Metasploit