debiruはてなメモ

はてなブログの HTML が Invalid なの、わたし、気になります

VALUE-DOMAIN に存在していたアカウント乗っ取り可能な CSRF 脆弱性について

2015年12月に私が発見した VALUE-DOMAIN での CSRF 脆弱性について、その脆弱性の報告と修正までの経緯を記しておきます。

きっかけ

数年前に VALUE-DOMAIN を利用していましたが最近は使っていないのでアカウントを削除しようとしたところ、アカウント削除操作を行うページの作りが「不自然である」ことに気付きました。更に調べたところ CSRF 攻撃によってアカウント乗っ取りが可能な状況であることが分かりました。

アカウント乗っ取りが可能な CSRF 脆弱性は2015年12月22日にIPAに報告し、2016年2月18日に修正が完了した旨の報告を受けています。以下でその詳細を説明していきます。

アカウント削除ページの作り

VALUE-DOMAIN のコントロールパネルには次のような項目があります。

  • ドメインの管理
  • サーバーの管理
  • 支払い方法の設定
  • マイページ
  • サポート問い合わせ
  • (その他)

マイページには「登録情報・パスワードの設定」と「アカウントを削除」を行うページへのリンクがあります。今回は、このマイページの2つの機能に注目しています。

「アカウントを削除」のページに遷移すると、「アカウントを削除する場合は、ここをクリック」というリンクが置いてあり、そのリンクの URL は次のものでした。

http:‭//www.value-domain.com/modprof.php?action=delete2

このログイン済みユーザがこの URL にアクセスする(HTTP リクエストを送る)だけでアカウント削除処理が完了してしまう作りになっていました。

アカウント削除ページの問題点

VALUE-DOMAIN に限らず、例えば Twitter でもそうですが、Web サービス(Web アプリケーション)というものは「その URL に HTTP リクエストを送る(URL にアクセスする)」ということによってそのページの内容を得たり、ツイートを投稿したり、設定を変更するといった処理が行われます。

このとき、その「とある HTTP リクエスト」の送信が、「ユーザが意図して行ったリクエストであるか」が問題になります。ここでいうユーザとは、パソコンや携帯端末の正規の利用者、ログインを伴うサービスであればそのアカウントの所有者のことです。

  • (a.) ユーザがボタンを誤クリックして、リクエストを行ってしまった場合
  • (b.) 他人がユーザの端末を勝手に操作して、リクエストを行った場合
  • (c.) セッションハイジャックによって、ユーザになりすまして操作が行われた場合
  • (d.) XSS 攻撃によって、ユーザの意思によらずリクエストが行われてしまった場合
  • (e.) CSRF 攻撃によって、ユーザの意思によらずリクエストが行われてしまった場合

上記のような意図しないリクエストが受け付けられてしまうと、「間違えてアカウントを削除してしまった」だとか「なりすまし操作でパスワードを変更されてしまった」だとか「自身のアカウントで意図しないツイートが投稿されてしまった」という問題が生じる可能性があります。

そこで、あるリクエストを送信する際に(正規のユーザしか知らない)パスワードの入力を要求することにすれば、(a.) 〜 (e.) の全ての問題を防止することができそうです。(パスワードが正しくなければ処理を受け付けないようにするということです。)

しかしそのようにしてしまうと、例えば「ツイートをするたび」にパスワードの入力を要求されることになります。これでは不便です。

このため、意図しないリクエストを防止しつつ、できる限り不便にしないような作りになっていることが望まれます。

  • 例えば (a.) を防止したければ確認ダイアログを出すだけで良いかもしれません。
  • (e.) を防ぎたければ、一つの方法として CSRF トークンと呼ばれる秘密の値を用いた仕組みで、(パスワード入力のような)面倒な操作を行うことなく意図しないリクエストの受理を防止することができます。
  • ユーザにとっては面倒になりますが、パスワードの入力を要求することで (a.), (b.), (c.), (d.), (e.) あるいは上記以外の意図しないリクエストまで防止することができます。この方法は、パスワードの変更やクレジットカード番号の参照・編集、アカウントに関連付けられる機密情報の操作、アカウントの削除など「重要な操作」に対しては適した対策であると考えられます。

その点で、VALUE-DOMAIN のアカウント削除ページにはこうした対策が全く施されていなかった(そして実際に問題があった)ため私が「不自然である」と感じたのでした。

VALUE-DOMAIN への報告

2015年12月20日に「アカウント削除」について、(e.) の CSRF 攻撃によって意図せずアカウントが削除されてしまう問題、および (a.) の誤操作でアカウントが削除されてしまう問題について問い合わせました。

VALUE-DOMAIN というサービスはドメインレジストラとして多くの人に利用されているわけで、そんな VALUE-DOMAIN が「アカウント削除」について CSRF 攻撃し放題というのは何ともつらいと思いつつ、指摘(問い合わせ)を機に(技術者であれば)きちんと直してくれるだろうと期待していたのですが、実際には小手先の対応で、回答を読んでも何が問題なのかを全く理解していない印象を受けました。

小手先の対応と書いたのは、「(a.) 誤操作によるリクエスト」についても指摘しているにも関わらず「(e.) CSRF 攻撃によるリクエスト」の対策しかされなかったためです。この対応後も、リンクをクリックするだけでアカウント削除が完了してしまいます。そして実際にはアカウントの復旧を受け付けているにもかかわらず、「アカウント削除後での復旧、ご返金はいたしかねます。」と明記されています。原則対応しないと言うのは構わないのですが、作りがお粗末すぎるだろうという点で残念に思いました。

なんというか、「アカウント削除以外にも CSRF 攻撃が可能な箇所があるかもしれないから併せてきちんと対応してね」という気持ちを込めて指摘をしたわけです。それが全く期待外れの回答だったのでこちらもきちんと伝える必要があるなと思い、より致命的な問題を指摘することにしました。

CSRF 攻撃によるアカウント乗っ取りの問題

前の章で「重要な操作」には「パスワードの入力を要求するべき」といったことを書きました。しかしながら残念なことに、マイページのもう一つのページ「登録情報・パスワードの設定」にそのような施策はありませんでした。

そして前述の流れから分かると思いますが、「アカウント削除」に対する CSRF 対策については対応を行ったにもかかわらず、「登録情報・パスワードの設定」については何の対策もされていませんでした。

「パスワード」と「登録メールアドレス」、「住所等の情報」の変更は次の URL へリクエストするだけです。(GET リクエストでも受け付けられます。)

http‭://value-domain.com/modprof.php?username=&password=NEWPASSWORD&password2=NEWPASSWORD&email=evil%40example.com&email2=evil%40example.com&email2_=&lastnameJP=a&firstnameJP=a&lastname=a&firstname=a&role=I&postalcode=000-0000&stateJP=a&cityJP=a&address1JP=a&housenumJP=1&address2JP=&phonenum=03-1234-5678&faxnum=&jobtitle=&organization=&state=&city=&address1=&housenum=&address2=&country=&returnurl=&action=modprof&how=modprof2&Submit=%CA%D1%B9%B9%A4%B9%A4%EB

「ユーザID」の変更は次の URL へリクエストするだけです。

http:‭//value-domain.com/modprof.php?action=changeusername2&moveto=evilusername

こうしたリンクを VALUE-DOMAIN のアカウント所有者に踏ませるだけで、そのアカウントのパスワードや登録メールアドレスを変更できてしまいます。また、未ログイン時にはログインフォームが表示されますが、そこでログインしてしまうと同様の処理が実行されてしまいます。

なお、この CSRF 攻撃は POST リクエストである必要はありません。登録情報変更フォームは GET リクエストも受理するため、正規の VALUE-DOMAIN サービスのドメイン名の URL を踏むだけでクエリ文字列に応じた登録情報変更が実行されてしまう状況でした。

私から VALUE-DOMAIN に指摘しても改善が期待できないため、IPA に報告することにしました。IPA とは情報処理推進機構(Information-technology Promotion Agency)のことです。

IPA への届出

脆弱性関連情報の届出受付:IPA 独立行政法人 情報処理推進機構」という次の URL のページ https://www.ipa.go.jp/security/vuln/report/index.html で Web アプリケーションの脆弱性の報告を受け付けています。

2015年12月22日のうちに IPA へ届出をしました。

余談:IPA への届出の仕方について

IPA脆弱性を報告されたことのある方はご存知かもしれませんが、「現在、ウェブ届出フォームは停止しております。ご不便をお掛けして申し訳ありませんが、届出については電子メールで届出頂けますよう、よろしくお願い致します。」という記述があります。何年も前からこの通りです。「現在」とは一時的なものではないのでしょうか。

正直、IPA の届出フォームがこの様なので IPA への報告もする気があまり起きませんでした。

電子メールで届出するための様式(報告テンプレート)は http://www.ipa.go.jp/security/vuln/report/form_web.txt ですが、半角70文字で折り返されているプレーンテキスト、「四角(□)」と「黒四角(■)」で表現されるチェックボックスなど、このテンプレートに沿って記述するのは苦痛でした。

IPA には早くこの点を改善してもらいたいものです。いつまで「現在」のままでいるつもりなのでしょうか。

IPA へ届出した後の状況

  • 2015年12月22日:IPAへ、メールで脆弱性情報の届出を行った
  • 2015年12月24日:IPAから、届出受信の自動返信メールが来た
  • 2016年1月12日:IPAから、届出情報受理(取り扱いが決定)のメールが来た
  • 2016年1月14日:IPAから、問題のあるサイトへIPAが報告した、というメールが来た
  • 2016年2月18日:IPAから、修正完了のご連絡、というメールが来た

IPA からの連絡は機械的なもので VALUE-DOMAIN がどのように問題を理解したのか、どこをどのように直したのかについては分かりませんでした。

IPA に説明しろと言うつもりではないですが報告した側からすれば気になるものです。もしかしたらまだ他のフォームで同じ問題が残っているかもしれません。

それと、VALUE-DOMAIN 側からは今回の CSRF 脆弱性があった件について、その事実や修正したことを公表していないようです。公表するしないはどうでもよいのですが、少なくとも報告者に対して何を修正したかを(IPA 経由でも)伝えてくれたりはしないのでしょうかね。他に問題がある可能性があるままでは、このような記事を書くのも躊躇してしまいます。

VALUE-DOMAIN ユーザの方へ

2016年2月18日に修正が完了した今回の CSRF 脆弱性について、考えられる被害は次のとおりです。

  • ある URL へアクセスしただけで、アカウントのパスワードが変更されてしまう
  • ある URL へアクセスしただけで、登録メールアドレスが変更されてしまう
  • ある URL へアクセスしただけで、住所情報などが変更されてしまう
  • ある URL へアクセスしただけで、アカウントが削除されてしまう
  • その他、マイページ以外の操作について、意図しないリクエストが受理されてしまう

アカウントの削除、アカウントの乗っ取りに注目したため、「支払い方法の設定」や「ドメインの管理」に関する操作に対して CSRF 攻撃が可能であったのか、現在可能なのかについては調査していません(入金操作が必要なため、あまり調査できませんでした)。

なお、パスワードやメールアドレス、登録情報が変更された際には、元々設定していた登録メールアドレスへ、登録情報が変更された通知が届きます。この被害に遭っていないか気になる場合は、そのようなメール通知が来ていないかを確認することで調べられそうです。

2-1節で (a.) から (e.) までを列挙しましたが、例えばクリックジャッキング攻撃によって、アカウント削除での CSRF 対策が施された現状でも他人のアカウント削除処理を実行させるようなことが可能に思えます。VALUE-DOMAIN をお使いの方は、そういった攻撃やいたずらによって被害が生じる可能性があることに注意してください。

この記事は VALUE-DOMAIN サービスを貶めるつもりはありませんし、VALUE-DOMAIN を使うべきでないと言うつもりもありません。このようなことがあったという情報を公開したまでです。他のサービスであってもセキュリティ上の問題があるかもしれません。近年はあるサービスから漏洩した ID と パスワードを基に別サービスへの不正ログインを行うパスワードリスト攻撃が目立っていますが、パスワードの付け方も含め、この記事が Web サービスのユーザとして自衛策を意識するきっかけになれば幸いです。

Next debiru's HINT 「WebはWEBじゃない