不意になにかを残すブログ

SSLサーバー設定のテスト目的で使っている人も多いと思う Qualus Security Labsの記事
https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat
で、SSL CheckerからBEAST脆弱性の判定(TLS1.0以下でCBCモードを使っている)を外す、というのが有ったのでメモ。

BEASTは成功すると数分から数十秒程度でクライアントのセッションが解読されるため、非常に危険なものと考えられている（orた）。
TLSv1.0以前ののCBCモードでは、セッションを再利用してリクエストを送る際、最後に送信された暗号ブロックが、次のHTTPリクエストの最初のブロックのIVとして使われている。攻撃者が送信済みの最後の暗号ブロックを傍受した後で、リクエストの先頭ブロックにあたる平文、例えばクエリ文字列を変更できるなら、BEAST攻撃が成立する。

最初に考案された対策は、HTTPSリクエストの直前に0バイトのTLSレコードを送る方法。
TLSでは可変長データストリームを扱うために、任意のデータ長を一つのレコードとして暗号化し、レコード毎に署名して送信できる様になっている。少なくとも1つ暗号ブロックが送信されるので、次のリクエストのIVは予測できなくなる。
https://www.ipa.go.jp/security/rfc/RFC2246-06JA.html#621
だが、TLSv1.0では空のレコードを想定しておらず、解釈してくれないTLS実装があった。
（自分の知識はここまでで止まっていた……）

その後、全てのサーバーが対応できる方法として、リクエストの最初の1バイトでTLSレコードを分割してしまう、という方法が考えらた。
https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c59
攻撃者が操作したかもしれない新しいリクエストをTLSで送る際に、最初の1バイトでTLSレコードを分割してしまえば、最初の暗号ブロックで攻撃者が変更できる情報はせいぜい1バイトになる（正確にはレコード長などもいじれそうだが）。そのうえにTLSフラグメントの構造上CBCブロックの残りはMACで埋まる。BEASTが成立するには攻撃者は最初の平文ブロック全体を（ある程度の確率で
制御する必要があるので、攻撃を無効化出来る。代償は、HTTPSリクエスト毎のMACの生成・検証コストが二倍になること。


この1/n-1 splitting手法は、多くのブラウザのTLSクライアント実装に2011年末〜2012年にかけて導入されているようだ。（iOS/Safari除く）
Qualys Security LabsのSSL Checkでは現在、BEASTはクライアント側で対応可能として、RC4や鍵交換をより重要視して評価するように変更されている。

ただ不安な点は、いまだ一定数いるだろう、1/n-1 splitting非対応のクライアントをサーバー側でチェックできていない点だ。（ハンドシェイク中に推測することはできるかもしれないが、opensslにそういったオプションが今のところない）
メーカーサポートが切れたスマートフォンのように、ブラウザがアップデートされなくなった環境では、クライアント側対策が行き渡っていない可能性が高い。日本のように2年毎の契約期間で端末のリプレースが抑えられていると、もうしばらくは2011年製の端末、Android2.3あたりが生き残りそうだ。

個人的には、今すぐセッションIDが解読されたら困るが、将来解読されても困ることが無いウェブアプリなら、まだRC4-SHAでいいように思う。RC4が解読される可能性よりも、XSS脆弱性が残っている可能性の方がずっと高いだろう。
逆にOAuthのように長期間変化しない認証用トークンを利用するなら、TLSv1.2（openssl-1.0.1以降）でサポートされる強い鍵交換と暗号モードを使うようにしたほうがよさそうだ。

ロリポップレンタルサーバーを運営するpaperboy&co.から被害に関するニュースリリースがでていた
http://www.paperboy.co.jp/news/201309091900

あたかも影響範囲は改竄被害をうけた人だけのように読めてしまい、改竄だけで済ませてくれた愉快犯より前に、他の誰かが悪用目的でアクセスしていた可能性を考慮していない。
少なくとも、同社のサーバーにアカウントを持つユーザーは全て、DBパスワードや、スクリプトの管理ページヘのログインパスワードを変更しておくべきだ。


今回の脆弱性を悪用すると、特段の前提条件なしに犯人以外のだれでも、少なくとも同一サーバーの他のユーザーのファイル・データベース内容を閲覧できた。
ということは、今回の犯人が最初に脆弱性に気づいたのだと確認できない限り、ロリポップレンタルサーバーの（どのサーバーが被害を受けたか明示されていないので）全てのサーバーで、

・被害を受けなかったアカウント含め、DBパスワードやCGI/PHPスクリプトの内容

・DBに入っている、ブログや掲示板のユーザーの通知メールアドレス、ECサイトの顧客個人情報

・アクセスログなどから、サイト閲覧ユーザーのIPアドレスやアクセス時刻

などが漏れていた可能性がある。これらの「可能性が無い」ことを確認しようとすると、少なくとも脆弱性発生時点から修正完了までの、HTTP・DBアクセスログ、アップロードされたファイルなどを精査しなければならない。

件の脆弱性は相当長期間にわたって（おそらくはサービス提供開始当初から）存在していたはずなので、全てのログとアップロードされたファイルのバックアップを完全に保存しているとは考えにくい。どうやって、
『個人情報へのアクセスは無く、個人情報の漏えい、流出の心配はございません。』
などと言い切ることが出来るのだろうか？ （現時点で確認されていません、ではない）
念の為、リンクトラバーサルという攻撃手法は今回の件の犯人が発明したものではないし、不法にアクセスした人間が得られた情報を公開するとは限らない。

漏れたことが確認できなくても、漏れた可能性のあるパスワードを使い続けるのは避けるべきだ。
ニュースリリースには脆弱性が発生した時期が記載されていないので、幸運にも被害を免れた（WordPress以外の）ユーザーは全て、最低限DBとCGI/PHPスクリプトの管理パスワードを変更しておく事をお勧めする。

もっとも、過去にデータベースに個人情報を保存していたことがあるのなら、誰かが閲覧していない事を祈るしか無いのだが。

先日ロリポップレンタルサーバーでの改竄事件についてのエントリを書いた
http://causeless.seesaa.net/article/373409482.html

この事件の後、
・パーミッションはエンドユーザーが"必ず" xxxに制限しないといけない
・シンボリックリンク脆弱性はFollowSymlinksを無効にすればいい
というような事がまことしやかに？言われている様に思われたので書いておく。

エンドユーザーによるファイルのパーミッション制限は、

1. 複数ユーザーが共用するサーバーにおいて、
2. サーバーの非特権プロセスにトラバーサルやそれに類する脆弱性にあったとき、
3. 自分の管理下のスクリプトやパスワード管理手法には全く脆弱性がない

場合には意味がある。 実際、ロリポップレンタルサーバーの件ではroot権限が奪われたわけではなさそうなので、パーミッションを厳しくしてさえいれば難を逃れた人は結構いるのではないかと思う。逆に言えば、2の段階で未然に防ぐことで、ユーザーがパーミッションを全く気にしなくても安全に運用できるレンタルサーバー業者もある。

つまりは、その業者の技術をどれだけ信用できるか、による。


まずトラバーサルについて説明したい。
トラバーサルとはアプリケーションのアクセス制御ポリシーの漏れを突く攻撃手法の一つだ。

今回指摘されたApacheのFollowSymlinksは、管理者の意図したアクセス制御、例えば
「各ユーザーの公開ドキュメント用フォルダ配下のファイルにだけ、Apacheがアクセス出来るようにする」
というアクセス制御ポリシーを、エンドユーザーがシンボリックリンクで迂回する方法を提供してしまう。
具体的な方法は徳丸氏の解説が詳しい
http://blog.tokumaru.org/2013/09/symlink-attack.html

この場合Apache（とその開発者）にしてみればソースコードに書かれた通り正しく実行しているだけなのだが、サーバー管理者の意図したポリシーとのミスマッチが起こっている。
トラバーサル脆弱性は、本来意図したファイルアクセス制御ポリシーと、実際に設定されたポリシーのズレを突く手法、ということができる。

トラバーサル可能性を塞ぐ対策は、ファイルへアクセスするアプリケーションが非常に多いためにとても面倒だ。FollowSymlinksを悪用する方法はその一つでしか無い。
サーバーで動作するApacheのコア機能や、mod_rewriteなどモジュール、FTPなど各種デーモンなど、サーバーで動く全てのソフトウェアのすべてのファイルアクセス用コードが、全く同じアクセス制御ポリシーを守るようにしないと、それは何らかのトラバーサル脆弱性に繋がる。

各ユーザーのCGI/PHPスクリプトにトラバーサル可能な脆弱性があっても、普通はそのユーザーが被害を受けるだけですむ。しかし、サーバーの基本的なサービスにトラバーサル可能性があると、攻撃者は僅かな権限を得るだけで、あるいはスクリプトすら用いずに、非常に多くのファイルにアクセス出来るようになってしまう。
パーミッションでの制限は、他のユーザーのトラバーサル脆弱性全てに対する、より低レベルながら一つの防御手段になる。

パーミッションはPOSIX互換OSの基本的な機能で、ファイル所有者(User/Owner)・同一グループ(Group)、それ以外(Others)という3分類のアクセス制限しか提供してくれない。
単純なだけあって、これを破ることは一般に難しい。パーミッション制限を迂回できるような脆弱性や、SuExecのようなユーザーIDを自由に変更できる特権をもつコードに脆弱性があれば、管理者用のコードを書き換えて、サーバー全体を乗っ取る事ができてしまい、同一OSを使っている全世界のユーザーが等しく危険になる。これは特権昇格可能な重大な脆弱性と見なされ、発見されると緊急のセキュリティパッチとして、比較的短期間で修正される（と期待できる。普通は。） 携帯端末のいわゆるJailbreak/root化には、販売後修正されなくなった脆弱性が使われることもある。


もちろん、ユーザーによるパーミッション制限は、ユーザー側ができる最後の自衛手段であって、これに頼る運用はとても不安だ。
サーバーの運用ポリシーにとしては、ユーザーがファイルのパーミッションを全く管理しなくても安全な方法がある。
最新のApacheの厳格なアクセス制限ポリシーや、ユーザー別プロセスのchroot/jail、LXCのようなコンテナ化などを利用して、各ユーザー間を可能な限り安全に切り離して管理していることも多いだろう。

実際に、トップが即座に自社のサービスに同様の脆弱性がないことを説明できるさくらインターネットのような場合もある。（またパーミッションに頼った運用もしていない）
一方で、ロリポップレンタルサーバーのように、トップが即座に自社のサービスに脆弱性がないと言いつつも、指摘されるまで修正できない業者もある。彼らは、事件発覚1週間後の緊急メンテナンス http://lolipop.jp/info/news/4149/
まで、Apacheにトラバーサル可能な脆弱性を残したままだった。（このとき修正された脆弱性も、また別のシンボリックリンクトラバーサルと呼べるもの（ToCToUとも別）だったが、ほとんどの業者には関係ないはず）

ユーザーは何もしなくてもデフォルトで安全、というポリシーが好ましいし、当然そうあるべきだ。だが、完全には技術を信頼できない共用サーバーを、コストの都合上利用せざるをえないなら、他のユーザの脆弱性からの二次被害に対するユーザー側の最後の自衛手段の一つとしてパーミッションを設定しておくことは、幾らかの意味があると思う。

データを暗号化して保存している、と謳うオンラインストレージサービスは多い。 ウェブサイトでは直接ファイルを閲覧できず、ユーザーのPCやスマートフォンの内部で暗号化してからサーバーに送るので安全性が高い、と主張している場合もある。

しかし、オンラインストレージの多くはウェブサイトのログインにパスワードを要求したり、ログインするだけでファイルにアクセスできたり、パスワードを忘れた時のためのリセット機能があったりする。こういったサービスでは、サービスを提供する側が、ユーザーの保存したファイルを秘密裏に閲覧することができ、ユーザーにプライバシーはない。強制力を持つ政府機関が命令すれば、サービス提供者はデータを復号して提供せざるをえないだろう。

だれかに見られても困らないデータを置くには便利なサービスだが、多数の個人情報や企業秘密のように、第三者への漏洩その自体が重大なデータを保存する場所としては不適切だ。


多くのオンラインストレージサービスが提供するストレージの”暗号化”では、ユーザーだけでなく、サービス側も暗号鍵を持っている。

オンラインストレージサービスのクライアントソフトに入力するのは、基本的にユーザーID（あるいはメールアドレス等）とパスワードだけなので、ファイルの暗号化に利用できる暗号鍵（正確にはファイル暗号化用の暗号鍵をさらに暗号化するための鍵）はこれらを組み合わせたものしか使えない。それ以外の情報は全てサーバー側に置かれている。
なお、DropboxやSkydribeなどではワンタイムパスワードを利用できるが、これは第三者の攻撃を制限するためのものであって、データの暗号化には全く貢献しない。

ユーザーIDやメールアドレスはユーザーへの通知のために平文のまま保存しておく必要があるだろうし、秘密にすることがあまり強く求められているわけではない。従って、暗号鍵となりうる秘密は基本的にパスワードしかない。

多くのサービスでは、クライアントソフトはパスワードを直接サーバーに送って、暗号化されたデータと暗号鍵を一緒にダウンロードしている。パスワード付きZIPファイルをパスワードと一緒にメールするようなものだ。

ならば、パスワードをサーバーに全く漏らさないクライアントアプリを使い、かつパスワードに暗号鍵として十分に長くランダムな文字列を入力すれば安全だろうか？

もし、サービス提供者が、「パスワードを忘れたなら、二度とファイル内容を復元することはできません」と明示しているなら、それは例外的に安全かもしれない。暗号鍵を失ったら二度と復元できないのは、脆弱でない暗号の性質としては当たり前だからだ。

実際に、パスワードをサーバー側に全く送信せず、クライアント側で暗号化を完結させている（とされている）ものとしては
SpiderOak https://spideroak.com/engineering_matters
がある。ただしこれも、モバイル向けクライアントアプリは暗号化機能を載せておらず、サーバーにパスワードを渡して復号してもらっているようだ。


パスワードを忘れても、リセットする方法があるならば、パスワードはただの合言葉で、ファイルの暗号鍵ではないことが分かる。ただし、反論としては次のような”安全な”パスワードリセット手法が考えられる。
「パスワード（あるいはファイル保存用の暗号鍵）を、パスワードリセットのために必要なメールアドレスや予備の質問などから生成した鍵で暗号化し、別に保存しておく」
こうすることで、パスワード（か必要な暗号鍵）を復元できる。
公開鍵暗号を使っている人なら、同じ秘密鍵を複数のPINコードで別の場所に保存しておけば、ひとつ忘れても他のPINコードを覚えていればそれが使える、といえば分かるだろう。

だが現実のサービスで、パスワードリセットのための秘密の質問とその答えは、どこで入力しただろうか？ オンラインストレージサービスのウェブサイトで入力したのでは、それがログに残るのでやはりサービス側が暗号鍵を得てしまう。（SpiderOakではPWのヒントを表示できるるだけで、秘密の質問とその答えのような仕組み自体が存在しない）


結論として、
・ダウンロードしたクライアントが認証のためにパスワードをサーバーに送るサービス
・パスワードをウェブサイトに入力することがあるサービス
・サービスのウェブサイトでパスワード変更やリセットが可能なサービス
は、サービス提供側と司法当局などによってファイルの内容が盗み見られることがありえる。

著名なところと思われる、Dropbox、SugarSync、Google Drive、SkyDrive、Bitcasa、Copy.comは上記のいずれかに該当する。

ユーザーのデータをサービス側が見ることの出来ないシステムを作るのは面倒だしコストがかかる。
なぜなら安全に暗号化されたデータは原理的に圧縮・重複除去することができない（＝乱数列と見分けが付かない）ため、安全でない手法のようにストレージやネットワーク帯域を節約することが出来ない。
また、ファイル内容をサービス事業者側が全く管理できないので、違法なファイルをアップロードしたユーザーがいることが発覚して、FBIにサーバーを全て差し押さえられるような法的リスクも上がる。

使い切れないほどのスペースと根拠なく「暗号化されているので安全」という謳い文句のオンラインストレージサービスを聞いたなら、本当に秘密にすべきデータをアップロードする前に、その仕組を疑ってかかるべきだ。
いまのところ、オンラインストレージ側の暗号化に頼らずに、TrueCryptのようなクライアント側だけで暗号化が完結することを検証可能な暗号化ソフトで正しく暗号化した上でオンラインストレージにおくのが、秘密にしたい大きなデータ同期への現実解になるだろう。 実際、Dropboxのクライアントソフトは、大きな暗号化ファイルの変更部分だけをアップロードしてくれる。（複数人で編集したりすると大変だけれど）


なお、サービス側が暗号鍵を持っていても、ストレージの暗号化は別の面でユーザーのセキュリティに寄与する。
大きなサービスになればなるほど、管理するハードウェアの数も、データに直接触れることが出来る人間も増える。数が増えれば、そのどれか一つを紛失したり悪人が紛れたりする確率は増えていく。暗号化プロセスや、暗号鍵の管理を限られたサーバーとオペレータだけで行うことで、セキュリティ上のリスクは大幅に低減できる。
ただし、これはサービスを第三者から守るセキュリティであって、秘密のデータをサービス自身や政府機関などの覗き見から守るセキュリティではないことに注意する。

ロリポップでの大規模なWordPressサイトの改竄について
http://lolipop.jp/info/news/4149/

ロリポップからのリリースでは、管理パスワードとログインへのアクセス制限の強化を推奨して、パーミッションの変更と全体のウイルスチェックを行うとしている。WordPressそのもののアップデートはマニュアルに方法が記載されているものの、リリースでは触れられていない。
このことから、被害が大きくなったのは、ロリポップの提供していたWordPressのインストール手順に問題があり、wp-config.phpなどのファイルのパーミッションが不適切だったためではないかと推察出来る。


いくつかのアカウントだけWordPressの管理パスワードが突破される、というのであれば、世界中でほぼいつでも起こっている。
もし、あるユーザーの管理パスワードが脆弱で推測することが出来てしまうと、そのWordPress管理画面から自由にプラグインを導入できる。古い脆弱なWordPressやプラグインを使っている場合も同様で、この場合、そのユーザーアカウントで攻撃者は任意のスクリプトを実行でき、ファイルやDB上のデータ全てを自由に改竄可能になる。
ここまでは、ロリポップに限らずどこのホスティングサービスでも起こりうる、脆弱なパスワードあるいは古いバージョンを使っているユーザーの自己責任と言える。

安価な共用サーバーでのウェブホスティングでは、数多くのユーザーが一つのサーバーを利用している。一つのアカウントに侵入されても、同一サーバーの他のユーザーのデータを読まれたり、変更されたりしないように、CGIは各ユーザーの権限で動作させ、ファイル・ディレクトリの所有者がパーミッションでアクセスを制限することで、他のユーザーの秘密のデータを保護している。そのため、（脆弱な）あるユーザーの権限でCGIが実行できても、影響範囲はそのユーザー１人にとどまる。
（ユーザー毎のchroot/jail/LXCなどを利用ことで、パーミッションに依存せず、各ユーザのデータを保護しているところも有るだろうが、少なくともロリポップはそうでは無かったことになる）

しかし、wp-config.phpに不適切なパーミッション（たとえば444、サーバー上の全てのユーザーが読み込み可能）が設定されていて、そのファイルの場所が分かっていれば、他のユーザーがスクリプトの内容を読めてしまう。wp-configにはデータベースに接続するためのパスワードが記載されているので、DBに接続して管理パスワードを変更してしまえば、管理者としてログインしてウェブサイトを改ざんできる。

つまり、WordPressをインストールしたユーザーのうち、たった１人が脆弱なパスワードを利用していたり脆弱な古いバージョンを使っていて、ファイルのパーミッションが不適切であれば、同じサーバーのユーザーが芋づる式に二次被害を受けることになる。
対策として、真っ先にアナウンスされた内容はWordPressのアップデートを推奨するもの（WordPress自体の脆弱性対策）ではなく、強い管理パスワードとパーミッションの再設定を求めるものだったことから、この推測が補強される。

ロリポップにWordPressをインストールしたユーザーの多くが、誤ったパーミッションを設定していた理由は幾つか想像できる。単にユーザーの不注意かも知れないし、ロリポップへのWordPressインストール方法を紹介したサイトが、間違ったパーミッション設定を多数のユーザーに伝授してしまったのかもしれない。

しかし最もありえそうなのは、ロリポップの「WordPress簡単インストール」機能に問題があり、ユーザーのwp-config.phpに不適切なパーミッション（たとえば644）を設定してしまった場合。
ロリポップのWordPressインストール手順にはインストール後のパーミッションの変更が記載されていなかったので、ユーザーはそうと気付かずに、インストーラが設定した不適切なパーミッションのまま運用していた、と考えられる。

WordPressの簡単インストール機能がどのように動作するのか、現在その機能が無効化されていて確かめることが出来ないが、ほぼ同様の動作をするだろうMovableTypeの簡単インストール機能は有効で、自動的にDBアカウントとパスワードが記入される mt-config.cgi のパーミッションは644のままだった。ユーザー権限でCGIを動作させている共用サーバでは通常、400（所有者のみ読み出し可能）に変更するはずだ。
wp-config.php のパーミッションを400にする必要があるのに、同じ方法でDBに接続するMovableTypeは変更する必要が無いというのが不思議なところだ。二次被害を引き起こした可能性がある以上、WordPressにかぎらず全てのインストール機能は無効化して、全てのファイルのパーミッションの再確認をするべきだ。


上記の推測があたっているとすると、ユーザーが強固なパスワードを使っていて、手順通りに最新バージョンで運用していても、脆弱なユーザーの二次被害を受けることになる。
（追記）
各サーバーで最初に侵入されたアカウントへが侵入経路がWordPressの脆弱性であろうと、それ以外であろうとも関係は無い。
（/追記 thx:名無しさん）

ユーザー側でとれる対応は、
・wp-config.phpやmt-config.cgiなど、同一サーバーの他のユーザーに見られては困るファイル（管理パスワードやDBパスワードを記述したファイル）のパーミッションを400に制限する（脆弱なユーザーからの二次被害対策）
・手元のバックアップと現状のファイル・DB内データを比較し、改竄があればバックアップから復元する（バックドアや不正なリンク設置への対策）
・DB接続用パスワードも強固なものに変更する（対応するwp-config.phpの記述も変更する）


現状のロリポップの記載内容では、改ざんされたウェブサイトの所有者全員が脆弱なWordPressプラグイン・テーマを使っていたかのように書かれている。WordPress以外のCGIスクリプトにも同じ問題が起きていないかのチェックがなされていない、というのは問題だと思うのだが。