2018年9月10日月曜日

WordPressのプラグインDuplicator 1.2.40以前にリモートコード実行の脆弱性

エグゼクティブサマリ

WordPressの人気プラグイン Duplicator(1.2.40以前) にリモートから任意コード実行可能な脆弱性が発見された。Duplicator はWordPressサイトを複製することのできるプラグインであり、Duplicatorにより複製したサイト(複製先)が影響を受ける。このため、プラグインのアップデートだけでは対策にならない。詳細は対策の項を参照されたし。

概要

WordPressのプラグイン Duplicator はWordPressサイトを手軽に複製できるプラグインであり、サイトの移行や複製に広く用いられています。Duplicatorは複製元にプラグインとして導入して、移行用の二種類のファイルを生成します。

Duplicator → installer.php             インストーラー
               2018-xxxxxxxxxxxxxx.zip   アーカイブファイル

これらのファイル移行先サイトにアップロードして、installer.phpを実行することで、サイトの複製を作成します。
このinstaller.phpに脆弱性があり、任意コード実行を許す結果となります。

脆弱性の原因

脆弱性の概要は以下の記事(英文)にて紹介されています。ただし、即実行可能なPoCは含まれていません。

Duplicator Update Patches Remote Code Execution Flaw

※ 2018年9月10日 17:40追記 : この記事本文にはPoCはありませんが、リンク先(PDF)にて即実行可能なPoCが記載されています。ブックマークコメントにてご指摘いただきました。ありがとうございました。

この記事の内容から、当該脆弱性を再現したところ、リモートコード実行が確認できました。PoCが公開されていないこともあり、悪用防止のため、原因と攻撃の概要のみ説明すると、下記の通りです。
  • installer.phpはwp-config.php (WordPressの設定ファイル)を自動生成する
  • この生成部分にPHPコードのエスケープ漏れがあり、外部からの入力がPHPコードとして実行される

攻撃ステップは、以下の通り。
  1. 複製先サイトに installer.php が残っていることを確認する
  2. installer.phpを実行し、パラメータとしてPHPコードをインジェクションする
  3. 生成後の wp-config.php にアクセスし、任意コードを実行する
リモートコード実行例

対策

Duplicator 1.2.42 (現時点の最新バージョン)にて対策されています。即時のバージョンアップ(複製元、複製先の両方)を推奨しますが、対策はこれだけでは不十分です。
既に Duplicator で複製したサイト(複製先)は、installer.phpおよび installer-backup.php を即時削除する必要があります。このファイルに限らず、移行により生成されたファイルのうち、サイト閲覧に必要ないファイルは削除を推奨します。
複製先に脆弱な Duplicator で生成された installer.php が残っている限り、複製元でDuplicatorをバージョンアップしても、installer.phpに対する攻撃は受けるため、上記は重要です。
一般論としても、このようなセットアップ用のスクリプト類は、セットアップ完了後はただちに削除すべきですし、セットアップ中も外部からアクセスできないように、アクセス制御すべきです。

PR

【10月24日(水)・11月7日(水)】徳丸本によるホワイトハッカー入門 ~基礎講座・応用講座~ 開講 申し込み受付中

2018年3月6日火曜日

安全なWebアプリケーションの作り方改訂のお知らせ

徳丸本こと、「体系的に学ぶ 安全なWebアプリケーションの作り方」は、2011年3月の発売以降大変多くの方に読んでいただきました。ありがとうございます。
ただ、発売から既に7年が経過し、内容が古くなってきた感は否めません。たとえば、クリックジャッキングの説明はほとんどないですし、OWASP Top 10 2017で選入された安全でないデシリアライゼーションやXXEの説明もありません。なにより、Web APIやJavaScriptのセキュリティ等がほとんど書かれていないことが課題となっていました。

そこで、版元のSBクリエイティブと相談して、この度改訂することにいたしました。3月末脱稿、6月頃発売の見込みです。

改訂にあたり、以下を考えています。

  • Web APIとJavaScriptに関する説明を4章に追加
  • XHR2対応に向けてCORSの説明を3章に追加
  • 携帯電話の章は丸ごと削除して、別の内容に差し替え(お楽しみに)
  • OWASP Top 10 2017対応(安全でないデシリアライゼーション、XXEを追加)
  • Macに対応。VMwareからVirtualBOX、FiddlerからOWASP ZAPに変更
  • SQLインジェクションの説明はPostgreSQLからMySQLに変更
  • 全体的に細かい変更を予定
  • 100ページを上限としてページ数は増える見込み
  • CD-ROM/DVD-ROMは添付せずダウンロードになる
  • 今回はレビュアーの公募はしません

おそらく、「本を買ったばかりなのに」という方もおられるとは思いますが、タイミングの問題は避けられないことでご容赦いただきたいと思います。できるだけそのような思いをする人を少なくするために、版元の許可を得て早めの告知をさせていただきます。
一方で、版元は第1版の増刷はもうしないと思いますので、(あまりいないとは思いますが)第1版が欲しい方はお早目の入手をお勧めいたします。

2018年1月31日水曜日

[書評]サイバー攻撃 ネット世界の裏側で起きていること

中島明日香氏の近著『サイバー攻撃 ネット世界の裏側で起きていること』を読んだので紹介したい。本書は、一見すると入門者向けの初歩的なセキュリティ解説書の体裁をとっているが、その内部に著者の恐ろしい野望が秘められていると感じた。

重要事項説明

  • 著者と評者には特筆すべき利害関係はない
  • 評者は本書を自費で購入した(献本等ではない)
  • この記事のリンクにはアフィリエイトが含まれる

はじめに

本書は、ブルーバックスの1冊として、サイバーセキュリティの分野の、特に脆弱性について焦点をあて、入門的な解説を試みるものである。本書6ページから、「本書で扱う内容」の一節を引用しよう。
本書の目的は、適切なサイバー攻撃対策を講じる際の一助となることです。そこで、脆弱性そのものとそれを突く攻撃手法について、情報科学の知識を持たない人でも理解できるように、基本的なところから解説します。
この一節だけでも、本書の狙いが意欲的なものであることが分かる。情報科学の基礎知識のない人に対して、脆弱性の成り立ちを説明することがどんなに困難であるか、評者は身にしみて実感している。だが、私が驚いたのはここではなく、本書の目次である。目次を引用しよう。
第1章 サイバー攻撃で悪用される「脆弱性」とは何か
第2章 サイバー攻撃は防げるか:脆弱性の発見・管理・修正
第3章 プログラムの制御はいかにして乗っ取られるか:バッファオーバーフローの脆弱性
第4章 文字列の整形機能はいかにして攻撃に悪用されるか:書式指定文字列の脆弱性
第5章 いかにしてWebサイトに悪意あるコードが埋め込まれるか:クロスサイト・スクリプティングの脆弱性
第6章 機密情報はいかにして盗まれるか:SQLインジェクションの脆弱性
第7章 脆弱性と社会:脆弱性市場からサイバー戦争まで
第4章に注目いただきたい。何と「書式指定文字列の脆弱性」(CWE-134)が紹介されているではないか。よりによってマニアックな…ということもあるが、CWE-134を入門者向けに簡単なイラスト等で比喩的に説明するのは不可能ではないのか。著者はどうやってこれを説明するつもりなのか、評者の第一の興味はここにあった。

本書の構成

ここで本書の構成を概観しよう。
第1章では、脆弱性とは何かということで、「ソフトウェアとは何か」というところから話を起こしている。著者は脆弱性を「欠陥の中でとくに第三者が悪用可能なもの」と定義しており、これは評者の定義「脆弱性は悪用可能なバグ」とよく整合していて評者の満足度が少し高くなったw それはともかく、著者は、ソフトウェアの説明をその分類(ファームウェア、OS、ミドルウェア、アプリケーション)から丁寧かつ簡潔に始め、脆弱性が悪用されると何が怖いのか、なぜ脆弱性は生まれるのかというポイントを説明していく。
第2章は「サイバー攻撃は防げるか」として、脆弱性の歴史や、脆弱性情報共有のためのCVE、CVSS等の仕組み、脆弱性のライフサイクルやゼロデイ攻撃の説明、脆弱性の現状等を概観する。
第3章から第6章は、代表的な脆弱性として、バッファオーバーフロー、書式指定文字列の脆弱性、クロスサイト・スクリプティング、SQLインジェクションを取り上げ、詳しく説明していく。これらの章が本書の中核であろう。
第7章は、脆弱性と社会というテーマで、脆弱性にまつわる光と影のエコシステム(脆弱性報奨金・バグハンターや、脆弱性売買のブラックマーケット)の存在、サイバー戦争への言及と続き、最後は「いかにしてサイバー攻撃から身を守るか」で締められている。

本書の眼目は 3章から6章

前述のように、本書の眼目は、脆弱性というものを基本から解き明かす3章から6章にある。驚くべきことに、著者は、脆弱性を説明するに際して、比喩に逃げずに正面から脆弱性の成り立ちについて説明している。そのために、3章の冒頭は、簡素なC言語入門の様相を呈している。スタックオーバーフローについて理解するには、ソースコードをコンパイルして機械語にすること、関数や引数の概念、オートマチック変数を実現するスタックフレーム等の概念が必要になるが、著者は、プログラミングを知らない読者に向けて、これらを簡潔に説明していく。その上で、スタックベースのバッファオーバーフローの実際について、C言語ソース、アセンブリ言語のソース、機械語、図表等を交えながら丁寧に説明する。
バッファオーバーフローの実例として、著者はPHPの脆弱性 CVE-2011-1938 を取り上げているが、ここでも評者は驚くことになる。評者はかつて、この脆弱性をブログ記事で取り上げたことがあるからだ。

PHPのsocket_connect()関数における *つまらない* 脆弱性の話

当脆弱性を紹介した理由を著者は以下のように説明している。
本節で紹介したCVE-2011-1938の脆弱性は、ほとんど悪用される可能性はありません。なぜならば、攻撃者がsocket_connect関数の引数を指定できるケースはほとんどないためです。脆弱性の構造が単純で、初心者にもその仕組が把握しやすいため、この例を紹介しました。
実は評者も先のブログ記事で似たような説明をしているのだ。
memcpy関数でUNIXドメインソケットのソケット名をコピーしていますが、addr_lenのチェックをしていません。絵に描いたようなバッファオーバーフローですね…そもそもUNIXドメインのソケット名を外部から指定できるというシナリオが「あり得ない」状況です。UNIXドメインのソケット名を外部に公開する必要がなく、任意のソケット名を外部から指定できることによる脆弱性も考えられるからです。
さて、評者が本書を取り上げるきっかけになったのは何と言っても第4章の「書式指定文字列の脆弱性」である。著者はどのようにこの脆弱性を説明しているか。著者はまずprintf等の書式指定について説明を始め、書式指定子を外部から指定できることの問題点を詳細に説明している。書式指定子の指定によるバッファ書き換えの方法として、%n書式による悪用の実際を実に丁寧に、図やソースコードを交えて説明する。おそらく著者が一番書きたかったのはこの第4章なのだろう。
書式指定文字列の脆弱性としては、sudoの脆弱性 CVE-2012-0809 を取り上げ、脆弱なソースの紹介、脆弱性が混入した原因、修正後のソースの説明に至っている。ここの内容は評者も初めて知るもので興味深かった。

ここまで紹介した第3章と第4章はいわゆる「バイナリ」の分野だが、第5章と第6賞はウェブアプリケーションの脆弱性についてである。XSSやSQLインジェクションを説明するためには、脆弱性の説明の前に、HTTPやHTML、JavaScript、セッション、SQL等の要素技術を説明する必要がある。これだけで力尽きてしまいそうだが、著者はこれまで通り基礎事項の丁寧な説明を続ける。XSSとSQLインジェクションの基礎的な説明の後、悪用例として、XSSはセッションハイジャック、SQLインジェクションは認証回避とUNIONを用いた情報漏えいを紹介している。いずれも妥当な解説である。

著者の野望は果たされたか

冒頭で述べたように、著者は本書でプログラミングを知らない層向けに、脆弱性について詳しく説明を試みている。そのためにはプログラミングの知識が必要不可欠であるため、脆弱性の説明のために必要なプログラミングの知識から本書では説明が始まっている。実に野心的な試みと言わざるを得ない。
では、その著者の野心は成功しているのだろうか。これについて、評者は「分からない」と言うしかない。既に評者はプログラミングをある程度知っているので、プログラミングを知らない読者が本書を読んでどんな感想を持つかはわからないし、正直なところ、プログラミングをまったく知らない読者にとって、本書は難しいのではないかと思った。この点については、しかるべき読者の評を待ちたい。
ただし、本書は、プログラミングをある程度知っている読者にとっても極めて有益だ。なので、著者の狙いはともかくとして、本書の「現実の読者層」は、ある程度はプログラミングになじんでいるセキュリティ入門者なのではないかと思った。

ささいな指摘

いくつか軽微なミスを見つけたので報告しておこう。

・CVE-2011-1938が影響を受けるバージョンについて
本書P97にて、CVE-2011-1938は、「PHPのバージョン5.3.3~5.3.6に存在していました」と説明している。これは公式な説明がそうなので無理もないが、正しくは5.2.7~5.3.6である。詳しくは、前述の評者のブログ記事を参照されたし。

・SQLについて
「SQL(Structured Query Language)」はという説明があるが、ISO等の規格では、SQLは何かの略語ではないとされている(P172)。

・SQLインジェクションにおける認証回避の攻撃文字列
SQLインジェクションの攻撃例で、認証回避の文字列を以下のように説明しているが、
'OR'A'='A'
正しくは下記である(P181; 末尾のシングルクォーテーションが余計)
'OR'A'='A

まとめ

中島明日香氏の『サイバー攻撃 ネット世界の裏側で起きていること』を紹介した。プログラミングの知識のない層向けに脆弱性の本質を説明するという著者の試みはまことに野心的であり、評者はその野心と、野心の実現のための努力に敬意を表する。果たしてその野心が額面通りに実現されたかどうか、評者には判断できないが、少なくともプログラミングをある程度知る層に向けては、脆弱性についてのよい手引になると考える。



2017年12月25日月曜日

PHPプログラマのためのXXE入門

この日記はPHP Advent Calendar 2017の25日目です。前回は@watanabejunyaさんの「PHPでニューラルネットワークを実装してみる」でした。

OWASP Top 10 2017が発表され、ウェブのセキュリティ業界がざわついています。というのも、2013年版までは入っていたCSRFが外され、以下の2つの脅威が選入されたからです。
  • A4 XML外部実体参照(XXE)
  • A8 安全でないデシリアライゼーション
これらのうち、「A8 安全でないデシリアライゼーション」については、過去に「安全でないデシリアライゼーション(Insecure Deserialization)入門」という記事を書いていますので、そちらを参照ください。
本稿では、XML外部実体参照(以下、XXEと表記)について説明します。

XXEとは

XXEは、XMLデータを外部から受け取り解析する際に生じる脆弱性です。具体的には、XMLの外部実体参照により起こります。
ここで、XMLの実体(entity)は以下のように宣言するものです。例はWikipediaから拝借しました。

<!DOCTYPE foo [
<!ENTITY greeting "こんにちは">
<!ENTITY external-file SYSTEM "external.xml">
]>
このようにして宣言した実体は、XML文書内で、&greeting; &external-file; という形(実体参照)で参照します。
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE foo [
<!ENTITY greeting "こんにちは">
<!ENTITY external-file SYSTEM "external.xml">
]>
<foo>
 <hello>&greeting;</hello>
 <ext>&external-file;</ext>
</foo>
上記で、external.xmlの中身が、「Hello World」だとすると、上記のXMLの実体参照は以下のように展開されます。
<foo>
 <hello>こんにちは</hello>
 <ext>Hello World</ext>
</foo>
ということは、XMLを受け付けるプログラムに外部実体宣言を含むXMLを食わせれば、ウェブサーバー内の任意のファイルを読み込み表示するという、あたかもディレクトリトラバーサルのような攻撃ができることになります。これがXXEの基本形です。

サンプルプログラム

ここでXXE脆弱なサンプルを紹介します。年賀状の季節ですので、住所録を想定して、XML形式ファイルで個人情報をアップロードして登録するプログラムを用います。PHPではJavaに比べてXXEを発現する条件が厳しいので、一番ありそうなケースの一例として、パッチのまったく当たっていないDebian 7 (wheezy) で実行しています。

まずはXMLファイルをアップロードするHTML。
<form action="xxe.php" method="post" enctype="multipart/form-data">
  <input type="file" name="user" />
  <input type="submit"/>
</form>
XMLを受け取り登録する(実際には登録内容を表示するだけ)のプログラム。
<?php
$doc = new DOMDocument();
$doc->load($_FILES['user']['tmp_name']);
$name = $doc->getElementsByTagName('name')->item(0)->textContent;
$addr = $doc->getElementsByTagName('address')->item(0)->textContent;
?>
<body>
以下の内容で登録しました<br>
氏名: <?php echo htmlspecialchars($name); ?><br>
住所: <?php echo htmlspecialchars($addr); ?><br>
</body>
正常系のデータ例
<?xml version="1.0" encoding="utf-8" ?>
<user>
  <name>徳丸浩</name>
  <address>東京都港区麻布十番</address>
</user>
この場合の表示
<body>
以下の内容で登録しました<br>
氏名: 徳丸浩<br>
住所: 東京都港区麻布十番<br>
</body>
ここで攻撃例として、以下のXMLファイルをアップロードします。
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE foo [
<!ENTITY pass SYSTEM "/etc/passwd">
]>
<user>
  <name>徳丸浩</name>
  <address>&pass;</address>
</user>
表示は以下となります。
<body>
以下の内容で登録しました<br>
氏名: 徳丸浩<br>
住所: root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
【以下略】
/etc/passwdの内容が表示されていることが分かります。

XXEの発現する条件

ところで、なぜこのデモにDebian 7を用いたかというと、Debian 7で提供されているlibxml2のバージョンが2.8.0というXXE対策のされていないバージョンだからです。libxml2の2.9.0以降は、外部実体をデフォルトでは読み込まないようにするという制限が加わり、上記の脆弱性デモは成功しなくなります。Debian7でもlibxml2に最新のパッチが当たっている環境では大丈夫です。
Debianに限らず、CentOS(6以上)、Ubuntu(12.04以降)でも全てのパッチが当たっていれば大丈夫です。つまりPHPでは、XXEは基本的に「プラットフォームの問題」といえます。

新しいlibxml2でもXXE脆弱にする方法

では、libxml2が2.9以降なら絶対安全かというと、アプリケーションレベルで外部実体を読み込む設定にしていれば、当然脆弱になります。上記のスクリプトだと、以下の追加によりそれは可能です。
$doc = new DOMDocument();
$doc->substituteEntities = true;          // この行を追加
$doc->load($_FILES['user']['tmp_name']);

その他の攻撃

先程の攻撃スクリプトでは、ウェブサーバー上のファイルを読み出す攻撃を紹介しました。これ以外にhttp:等のURLを指定して、別サーバーの情報を読み出すという攻撃ができます。この攻撃は一般にSSRF(Server Side Request Forgery)と呼ばれ、外部から直接アクセスできないサーバー・機器への攻撃用の踏み台として用いることが可能です。

攻撃シナリオとして、ある人が自宅のPCを外部にウェブ公開している場合に、そのサイト経由で自宅リモートルータに侵入する実験をしてみます。
この場合、外部実体宣言として以下のようにすればよいわけですが…
<!ENTITY router SYSTEM "http://192.168.0.1">
実際の攻撃では、以下の2点の課題があります。
  • ルーターの認証を突破する必要がある
  • 外部実体が展開された結果が正しいXMLになっている必要がある
この2点を解決する方法ですが、まず認証の突破は、ルーターのパスワードがわかっていれば(あるいは辞書攻撃により)、URLに埋め込む形で以下のように指定することができます。ユーザ名: admin、パスワード: PASSWORDを例として想定しています。
http://admin:PASSWORD@192.168.0.1/
次に、XML形式としての妥当性ですが、PHPでXXE攻撃する場合、以下のようにPHPフィルタを用いてBASE64エンコードするという技が知られています。
<!ENTITY pass SYSTEM 
"php://filter/read=convert.base64-encode/resource=http://admin:PASSWORD@192.168.0.1/">
これを用いて、自宅のAtermを攻撃してみました。詳細は省略しますが、上記手法により、無線LANの事前共有鍵を盗むことができました。ウェブサーバーを踏み台として、外部からは直接アクセスできないルーターの管理画面にアクセスができたことになります。
この種の攻撃を防止するには、XXE脆弱性の排除は当然として、ルーターのパスワードを強固にする事が重要です。これは、DNSリバインディング攻撃にも有効な対策です。

対策

PHPの場合XXE対策は、既に述べたように、libxml2をバージョン2.9以降にするか、対策パッチを適用することです。Linux上にウェブサーバーを設置している場合は、最新のパッチがあたっていることを確認して下さい。
加えて、アプリケーション側で明示的に外部実体の読み込みを許可していない必要があります。

今まで説明していない対策として、以下の関数呼び出しによる方法があります。
libxml_disable_entity_loader(true);
これですと、libxml2のバージョンやアプリケーションの他の設定に関わらず、常に外部実体の読み込みが禁止されます。単独で安全な設定になるので推奨したいところですが、強力過ぎて副作用もあります。この設定にすると、サンプルスクリプトの $doc->load() メソッドの呼び出しもエラーになってしまうのです。つまり正常系が動かなくなるケースがあります。

これに対応するには、loadメソッドを避け、別の方法でXMLファイルを読み込んでから、その文字列をloadXMLメソッドで解析します。下記の例では、file_get_contentsで読み込んだXMLファイルをloadXMLメソッドで解析しています。
libxml_disable_entity_loader(true);
$doc = new DOMDocument();
$xmlstr = file_get_contents($_FILES['user']['tmp_name']);
$r = $doc->loadXML($xmlstr);

まとめ

PHPにおけるXXE脆弱性について説明しました。
PHPの場合、libxml2を最新にするだけで防げるので、XXEがOWASP Top 10に選入されたと知って「なぜ今時?」と思いましたが、Javaの場合はデフォルトでXXEが有効になるので、PHPはたまたま安全なケースが多いということなのでしょう。ただし、仮にXXE脆弱な場合、PHPは攻撃のバリエーションが増え、危険度が増加する可能性があります。
ウェブサイト運営という観点からは、libxml2を最新の状態にするという対策で通常は問題ないかと思います。一般に公開するソフトウェアを開発する場合は、libxml2が古い環境を想定して、以下のいずれかによる対策をお勧めします。
  • libxml_disable_entity_loader(true); を呼んでおく
  • libxml2 2.9以降必須という条件をドキュメントに明記する

2017年12月14日木曜日

2017年に登壇した勉強会を振り返る

この記事は #ssmjp Advent Calendar 2017の14日目です。昨日は、tigerszkさんの「ssmjp2017 ~今年一年の振り返り~」でした。明日は tcsh さんです。
ssmjpにちなみ、2017年に登壇した勉強会についてスライドとともに振り返りたいと思います。

セキュリティとUXの◯◯な関係

アレなタイトルですが、副題も「すれ違い続けた二人の運命の邂逅~セキュリティとUXは本当にトレードオフなのか」となっております。

日時: 2017年6月9日 20時~
場所: ヤフー株式会社 紀尾井タワー コワーキングスペース LODGE
講演タイトル: セキュリティ対策の都市伝説を暴く

登壇者は、BA(当時)の太田良典さんとヤフーの日野隆史さん、私でした。私からは、「セキュリティ対策の都市伝説を暴く」と題して、UIを損なうセキュリティ対策が本当に必要なのかというお話をしました。



聴講された方のブログ記事をいくつか紹介します。

セキュリティ・ミニキャンプ in 近畿 2017(神戸)

神戸のミニキャンプにて併催されたサイバーセキュリティセミナー in 神戸の特別講演を依頼されたものです。Webアプリセキュリティの基礎をというご要望でしたので、そのような内容になっています。

日時: 2017年6月30日 13時~
場所: 三宮研修センター 6階605会議室
講演タイトル: Webアプリセキュリティの常識




YAPC::Fukuoka 2017 HAKATA

YAPC::Fukuokaでゲスト講演を担当しました。この時は何をしゃべるか悩み抜いた末、40分で技術的にまとまった話をするのは無理、ということから、最近のウェブサイト侵入の事件をデモつきでひたすら紹介するというネタに走ったところ、なんとベストスピーカー賞を頂戴してしまいました。

日時: 2017年7月1日 10:00 〜
場所: LINE Fukuoka株式会社
講演タイトル: ウェブセキュリティの最近の話題早分かり




OWASP 名古屋 第1回ローカルチャプターミーティング

OWASP名古屋チャプターの記念すべき第1回チャプターミーティングで講演させていただきました。ウェブセキュリティの基礎というご依頼でしたが、少しネタに走りまして、たにぐちまことさん著の「よくわかるPHPの教科書」に含まれる脆弱性を題材にして、一通りのウェブアプリケーション脆弱性を説明するという趣向でした。具体的には、SQLインジェクション、CSRF、XSS、ファイルアップロードの問題について、この書籍の脆弱性(初期の版のもの)を使って説明しています。

日時: 2017年9月2日
場所: 愛知大学名古屋キャンパス(笹島)  講義棟8階、L802教室
講演タイトル: ウェブアプリケーションセキュリティ超入門





若手エンジニアのためのセキュリティ講座 - サポーターズCoLab

サポーターズさんの依頼により若手エンジニアのためのセキュリティ講座という講演を実施しました。後半では、セキュリティエンジニアのお仕事、徳丸自身のキャリア、いつまでも現役エンジニアでいつづけるために…などのお話をしています。

日時: 2017年9月9日
場所: 渋谷スクエアA
講演タイトル: 若手エンジニアのためのセキュリティ講座




PHPカンファレンス2017

PHPでは例年講演させていただいておりますが、今年はセキュアコーディングのお話をしました。簡単に要約すると、「従来は、外部からの値は信頼できないものとして扱うべきという原則が言われていたが、ソフトウェアは複雑なので、どの値が外部由来かどうかは簡単に判別できないので、内部・外部に関わらず信頼できないものとして扱うことを原則とすべきではないか」というお話です。

日時: 2017年10月8日
場所: 大田区産業プラザ PiO
講演タイトル: 著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則




デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう

弊社(EGセキュアソリューションズ株式会社)で実施した勉強会です。デバッガを用いてWordPress本体やプラグインの脆弱性を追っかけることにより、脆弱性の中身を深く知ろうという趣旨のものです。

日時: 2017年11月15日(好評のため 11月29日に同内容で再演)
場所: EGセキュアソリューションズ株式会社
講演タイトル: WordPress 本体とプラグインの脆弱性をデバッガで解析しよう



ブログ枠で参加された方のブログ記事を一部紹介します。


2017年11月の#ssmjp

以前「秀丸マクロを生成する秀スクリプトという言語処理系を作った」という記事を書きましたが、その内容について講演させていただきました。

日時: 2017年11月30日 19時~
場所: ヒカラボ (レバレジーズ本社( 渋谷ヒカリエ 17F )
講演タイトル: 秀スクリプトの話



秀スクリプトのデモ動画を貼っておきます。


こちらは、秀スクリプトでスクレイピングをするデモです。


ということで、今年も多くの勉強会で登壇させていただきました。来年もよろしくお願い致します。

2017年11月30日木曜日

IEのクッキーモンスターバグはWindows 10で解消されていた

エグゼクティブサマリ

IEのクッキーモンスターバグはWindows 10では解消されているが、Windows 7とWindows 8.1では解消されていない。このため、地域型JPドメイン名と都道府県型JPドメイン名上のサイトは、クッキーが外部から書き換えられるリスクが現実的に存在しするので、セキュリティ対策上もクッキー書き換えのリスクを考慮しておく必要がある。

クッキーが外部から変更された際のリスク

ウェブサイトの利用者が第三者によりクッキーの値を変更されると、以下のような攻撃が可能になります。
  • セッションIDの固定化攻撃(脆弱性がある場合)
  • クッキーを攻撃経路とするクロスサイトスクリプティング攻撃(脆弱性がある場合)
  • 一部のCSRF対策の回避
「一部のCSRF対策」と書いたのは、OWASPの資料ではDouble Submit Cookieと呼ばれるもので、乱数値をクッキーとリクエストパラメータの両方に持たせ、両者が一致していれば正規のリクエストとみなすという方法です。OWASP公認の方法のせいか、脆弱性診断でよく見かけます。私の知っている限り、以下のアプリケーションフレームワークのCSRF対策として採用されています。
  • FuelPHP
  • CodeIgniter
  • Django
いずれもメジャーなものですね。他にもきっとあると思います。
Double Submit Cookieは、サーバー側で状態を保持する必要が無いため、RESTとの相性が良いというのも最近好まれる理由かと思いますが、外部からクッキーを変更されないことを前提しているところが微妙なところです。
筆者の所属企業の脆弱性診断サービスでは、Double Submit CookieによるCSRF対策は指摘対象となっていて、危険度は状況によりInformationからMediumまで変わり得ます。

クッキーを外部から変更する方法

クッキーを第三者が変更する方法ってあるの? と思われた方も多いと思いますが、以下のような方法により可能です。
  • クッキーモンスターバグ(対象ドメインかつ対象ブラウザの場合)
  • HTTPSを使っているサイト(参考
  • クロスサイトスクリプティング脆弱性がある場合
  • HTTPヘッダインジェクション脆弱性がある場合
  • サブドメインに信頼できないサイトがあるか、XSS等の脆弱性がある場合
このうち、脆弱性によるものは当該の脆弱性を修正すればよいとして、「アプリケーションに脆弱性がないのにクッキーが書き換えられる」ものは、クッキーモンスターバグとHTTPSを使っている場合です。後者は以前詳しく説明したので、本稿では、クッキーモンスターバグについて取り上げます。

クッキーモンスターバグとは

東京都のサイトを例として説明します。東京都のサイトは、地域型JPドメイン名を使っていて、ホスト名は www.metro.tokyo.jp です。ここで、example.tokyo.jp という都道府県型JPドメイン名の罠サイトから、domain=tokyo.jp のクッキーが設定できたとすると、この罠サイトを閲覧したユーザーは、東京都のサイトで有効なクッキーを設定・変更されてしまうことになります。 
通常このようなSet-Cookieはできないはずなのですが、Internet Explorer(IE)は伝統的に(?)このようなクッキーを受け入れてしまいます。この種の問題はクッキーモンスターバグ(Cookie Monster Bug)と呼ばれます。

Windows 10 でクッキーモンスターバグを検証してみた

IEのクッキーモンスターバグは最近でも有効なのだろうかと思い、全ての更新プログラムを適用したWindows 8.1 と Windows 10で確認してみました。Windows 10では、Edgeも同様に検証しています。試験用のドメイン名としては、kawaguchi.tokyo.jpとtokumaru.bunkyo.tokyo.jpを用いました。その結果は下記のとおりです。


ドメイン名ドメイン属性Windows 8.1Windows 10
IE11IE11Edge
kawaguchi.tokyo.jp tokyo.jp 設定可設定不可設定不可
tokumaru.bunkyo.tokyo.jp tokyo.jp 設定可設定不可設定不可
bunkyo.tokyo.jp 設定可設定不可設定不可

結論としては、Windows 10では、IE、Edgeともクッキーモンスターバグは解消されています。厳密にどのタイミングで解消されたかは追えてないのですが、Windows 10の初期の版から解消されていることを確認していますので、Windows 10が登場したタイミングで解消されたのではないかと予想しています。

クッキーモンスターバグとどう付き合うべきか?

とは言え、Windows 7とWindows 8.1ではIEのクッキーモンスターバグは解消されておらず、上記の経緯から予想するに、これらでは解消される見込みは薄いと考えます。これらのWindowsがサポート終了となるのは、それぞれ2020年1月14日と2023年1月10日ですから、少なくともWindows 8.1がサポート終了となる2023年1月までは、クッキーモンスターバグのことは想定しておかなければならないことになります。

脆弱性対処との関係

セッションIDの固定については、ログイン時にセッションIDを振り直すという標準的な対策を取っていれば、クッキーモンスターバグの影響は受けません。
問題は、Double Submit CookieによるCSRF対策の回避です。こちらは簡単な対応策がありません。このため、IEのクッキーモンスターバグの影響がある地域型JPドメインおよび都道府県型JPドメイン名のサイトでは、Double Submit CookieによるCSRF対策は避けて、別の方法で対策するべきではないかと考えます。
なお、クッキーモンスターバグの影響がない場合でも、通信経路上に攻撃者が存在する場合は、中間者攻撃によりHTTP側でクッキーを改変できます。筆者の所属企業ではDouble Submit CookieによるCSRF対策を(危険度は様々だが)常に指摘対象としているのは、こちらの攻撃経路を考慮しているためです。

まとめ

クッキーモンスターバグの現状について報告しました。現状の見通しとしては、Windows 8.1のサポートが終了するまでの約5年間は、地域型JPドメイン名と都道府県JPドメイン名においては、クッキーが外部から変更されるリスクを多めに見積もる必要があります。その結果、少なくともこれらのドメイン名上に置かれるウェブサイトにおいては、Double Submit CookieによるCSRF対策は避けるべきだろうと考えます。


PR記事

OWASP Top 10 2017に対する弊社脆弱性診断の対応

2017年10月5日木曜日

PHPカンファレンス2017にてセキュアコーディングの話をします

PHPカンファレンス2017にて講演する機会をいただきました。

日時:10月8日(日)10:00~17:00(徳丸の出番は14:10から)
場所:大田区産業プラザPiO(東京都大田区)
費用:無料(申し込みはこちら
講演タイトル:著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則

想定聴講者としては、SQLインジェクション対策は聞き飽きた、もう少し突っ込んだ話が聞きたいという方を念頭においていますが、小難しくならないように、できるだけ平易にお話したいと考えています。

私はセキュアなプログラミングに関して、とにかく個別の脆弱性を守るための各論が大切で、それを知らないとどうしようもないという立場を取ってきました。その考え自体は変わっていないのですが、そうは言っても個別の各論を束ねる原則論、総論はないかのという思いはもちろんあります。
従来から、そのような「セキュア開発の原則」については各方面から提案のあるところですが、私はどれを見ても納得がいきません。恐らく、それらが根本的におかしいということはないと思うのですが、用語が曖昧だとか、書かれている例が適切でないとかの積み重ねにより、納得感が薄いのです。

このような私の思いに対して、自分自身の考える「セキュア開発の原則」をまとめたいと思い、過去に以下のような講演をしたことがあります(2016年2月27日)。


タイトルが「試み」という遠慮がちなものになっている理由は、世の中の教科書的な原則論に逆らう自信がまだあまりなかったからというのが正直なところですが、この講演は幸いにも概ね好意的に受け止められたと認識しています。

それから1年半がたち、ようやく「こうではないか」というものがまとまりましたので、PHPカンファレンスの場で発表させていただきたいと思います。

話の前半は、信頼境界の話から、脆弱性対処の原則論の話に展開していきます。

  • 値の扱い方
  • 信頼境界とは何か
  • 典型的な脆弱性と信頼境界の関係
  • 防御的プログラミングとセキュアコーディング

話の後半は、演題にあるようにPHPの著名アプリの脆弱性を取り上げ、それらがなぜ混入したか、どうしたら防げたかという話題になります。それは脆弱性を修正する方法という意味ではなく、どのような考え方をすればそもそも脆弱性が混入しなかったかという話です。

ところで、昨年のPHPカンファレンスでは、和田卓人さんの招待講演が素晴らしかったですよね。


和田さんのようにはいきませんが、私も和田さんがされたような話をしたいと大いに刺激を受けました。その成果をいくばくかでも披露できればと考えております。

フォロワー

ブログ アーカイブ