文責: mala

前置き

• note.com (以下note) に2020年に報告した脆弱性(現在は修正済み)を解説する
• 個人の活動として行っており所属組織とは関係がない
• 自分がnote社に対して、問題があると指摘していたのは主に広報対応についてですが、この記事は技術的な知見を共有することを目的とするため、技術的な解説を中心にします。
• 公開にあたってはnote社に対して確認の上で行っています。note社による修正対応は2021年までに実施されていますが、その修正内容が適切であるかどうかについて保証するものではありません。(網羅的な確認や追加の検証をしていません)
• note社のサービスに他の脆弱性が無いことを保証するものではありません。

• 2020年9月30日に公開されたnote社の記事で https://twitter.com/note_pr/status/1311184697204985856 https://note.jp/n/n2115642a4e45 "すべてのサービスは適正かつセキュリティ上、問題ない" と書かれた
• これを見て、noteをバカにするためだけに脆弱性を探すことを決意。
• 調査開始後すぐに問題を発見し、2点問題を報告した。

• 問題1: 独自ドメインを利用している法人ユーザーに悪意があった場合、訪問ユーザーの非公開の個人情報(銀行口座番号等)を取得することが出来た
• 問題2: 中間者攻撃により、セッションハイジャックが可能だった。問題1と組み合わせて銀行口座番号等が漏えいしうる状態だった

問題1は、2020年9月30日 18:02 に報告した。問題2は、2020年10月1日 12:32 に報告した。 問題2の部分は当日中に修正されたが、問題1については、大幅な設計の見直しが必要となるため、修正されるまで開示を控えていた。

なお、問題1については、一定の対策は行われたものの、noteが他社ドメイン上でのログイン機能を提供している以上 (本来的にはnote社の管理外のドメイン上で、ログイン状態での応答を返却している以上) 中間者攻撃やDNSレコード変更も含めると、ドメイン所有者から、noteのユーザー名、独自ドメイン上での訪問ページ等については、把握されうるということには注意が必要である。

前提となるnote仕様の解説

• noteには有料記事を販売するクリエイター向けに銀行口座番号を登録する機能がある
• 法人向けプランのnote proには独自ドメインでnoteを公開する機能がある https://www.help-note.com/hc/ja/articles/900001011666
• 例えば、note社自身が運用しているnoteの独自ドメインは note.jp である。
• 通常のユーザーのコンテンツは note.com/ユーザー名/ の形式で、各ユーザーのコンテンツが公開されている。

noteのセッションは、note.com に対して note IDまたは外部IDでログインすることで確立される。 note proを利用して独自ドメインで公開されているサイト(以後、例示として note.example.com を用いる) に訪問した場合には note.example.com → note.com → note.example.com と自動リダイレクトによる往復を行い、独自ドメインに対しても認証cookieが自動でセットされる。

• 悪意のある note pro利用者(攻撃者)が独自ドメインの設定を行って note.example.com でコンテンツを公開する
• 被害者に note.example.com を訪問させる。note.com および note.example.com に有効なセッションcookieがセットされる
• 攻撃者は note.example.com のDNSレコードを、note社のものから、自身の管理するサーバーに変更する
• 攻撃者は note.example.com 上で、任意のHTMLを設置したり、発行済みのセッションcookieを取得可能になる

これによって、以下の攻撃が可能になる

1. note.com に対するセッションハイジャック

• 報告時点では独自ドメイン向けのセッション分離が行われていなかったため、note.example.com で取得したcookieを note.com にコピーしてログインすることが出来た。

2. note.example.com 上から呼び出せる任意のAPIの応答結果の取得

• 攻撃用HTMLを設置してDNSリバインディング、または、独自ドメイン向けのセッションcookieを使ったセッションハイジャックにより可能
• 報告時点(2020-09-30)では、少なくとも銀行口座番号を返すAPIを呼び出すことが出来た

有料プラン契約していないので、デモは用意できないのですが、カスタムドメインでアクセスした際にも銀行口座情報を返すAPIが使えます カスタムドメインの利用者が、DNSレコードを短期間で切り替えると、サーバー上に任意のHTMLをホスティングできるので、APIが返した銀行口座情報をJavaScriptから読み取ることが出来るはずです。DNSリバインディングといった用語で通じるはずです カスタムドメインでnoteを利用→ドメインを自社サーバーに切り替え→ポップアップwindowなどで表示させておいた銀行口座情報をJSから読み取り 直し方は、アカウント設定などで使うAPIは note.com からのみ有効にすれば良いと思います。

カスタムドメイン上でセッション作るのは設計上、そういうふうにしていてプロフィールが最悪Proユーザーに伝わるのは想定内だと思うのですが、口座情報などは想定外かと。 DNSいじらなくても、例えば独自でプロキシしてcookie保存しておくとかでもいけるはずですね(自前でAPI叩けばいいので罠ページも別に必須ではない)。 とにかくカスタムドメイン向けに発行されたsessionではアカウント系のAPIを叩けるべきではない。

もうちょっと詳しく見てたんですが、そもそもカスタムドメイン向けと note.com のセッションcookieって同じもの使い回せますね。。。内部的にはどこで発行したcookieか保存してたりするかも知れないですが、APIの制限加えるなら 本家sessionと独自ドメイン向けsessionをきちんと分離しないといけない。 今どき銀行口座番号が漏れるとドコモ口座なんかので問題になっているので、何桁かマスクしてしまうというのも良いかも知れません。実用上、どの銀行使ってるのか程度が自身で確認できれば十分だと思うので。

• 2020年10月22日に、銀行口座情報の確認や決済関連の設定に関するAPIを呼び出す際には、パスワード再確認が必要となった。
• この時点で、直近でパスワードの再確認を行っていないセッションではAPI呼び出しに失敗するようになった。
• 独自ドメイン向けに発行されたセッションと note.com のセッションの分離、独自ドメイン側から呼び出せる機能の制限は時間をかけて修正が行われた(タイムライン参照)

前提となるnote仕様の解説

• note proの利用サイトを初回訪問する際に、note.com へのリダイレクトして、note pro利用サイトに gs というパラメータを付与して戻ってくる
• 初回訪問時にセットされたセッションcookieがある状態で、gsパラメータが付与された独自ドメインURLに訪問すると、独自ドメイン上でログイン状態となる

当時報告した内容の転載(少し編集している)

noteの独自ドメインセッションですが、中間者攻撃(MITM attack)に対して脆弱だと考えられます。 攻撃者が用意したWiFiアクセスポイントを利用している場合、全自動でセッションの乗っ取りが可能。(報告済み問題と合わせてアカウント情報取得系のAPIも呼び出し可能) 対策は リダイレクト先に http を許容せず、https のみ利用すること。(Pro利用ドメインのチェックは行われているが、条件がゆるいのが原因)

1. 被害者の回線で以下のURLに強制アクセスさせる

• リダイレクト先をnote proを利用している独自ドメイン、httpsをhttpに置き換える
• https://note.com/login/proxy?redirect_to=http://note.example.com

2. gsの値を中間者攻撃で盗聴して取り出す

• 被害者のブラウザは http://note.example.com/?gs=xxxx にリダイレクトする。
• この際、悪意のある中間者は、被害者のブラウザでの通信をブロックして、gs=xxxx の値のみ取り出すことが可能

3. 攻撃者のセッションで取得した gs の値を利用する

• 攻撃者のブラウザで note.example.com の新規セッションを開始する。
• https://note.com/login/proxy?redirect_to=http://note.example.com からの locationヘッダの応答を2で取得したURLに差し替える。

当時保全しておいたスクリーンキャプチャ

• https://twitter.com/bulkneets/status/1606135437482790912

• 2020年10月1日に報告を行い、malaが確認している範囲で当日中に修正された。
• リダイレクト時のバリデーション強化が行われ、note pro利用ドメインであっても http へのリダイレクトは許容されなくなった。

自分がnoteに報告したこれら脆弱性は、根本的にはドメイン設計に対する考慮漏れである。 ブログサービスの中には、独自ドメインでの公開をサポートしているものも多くあるが、独自ドメイン上で認証cookieを作成しているのは、自分の知る限りだとかなり独特のもので、noteに固有のものである。

例えば、livedoor Blogやはてなブログでは、JavaScriptも含めて自由にコンテンツをホスティングすることが出来るが、ブログの表示ドメインと、記事の作成を行うCMS用ドメインは分かれており、認証cookieがセットされるのは、あくまでCMS用ドメインとなっている。このため、ブログ表示ドメインでブログオーナーが設置した任意のJavaScriptが実行されても、訪問者のブログサービスにおけるアカウント情報が取得されるといったことは起こり得ないようになっている。この手のサービスでのブログ表示ドメインは「任意のJavaScriptが実行されても構わない」ものとして取り扱われる。こういったドメインはsandboxドメインと呼ばれることがある。任意のHTMLやJavaScriptをホスティング出来るようなコンテンツ作成の自由度が高いブログサービスを運営する際には、このような表示ドメインとCMSドメインの隔離は必須の要件と言える。(ログイン済みのユーザー情報が保護されるだけで、ログイン情報と無関係にユーザーに危害を加えるファイルがホスティングされるということは起こりうる。例えばsandboxドメイン上にブラクラが設置されたりマルウェア配布に使われるようなことは起こる)

noteは独自ドメインをサポートするものの、コンテンツ作成の自由度は低く、任意のJavaScriptをホスティングすることは出来ない。もしnoteが、ユーザー情報を管理する note.com 上で記事を表示をしつつ、自由にJavaScriptも書けるのであれば、それはただのXSS脆弱性ということになる。noteのサービスの特徴として、フォローやいいねといったSNSの機能や、記事の購入や購読といった決済の統合されており、記事表示ドメイン上でシームレスに、ログイン状態での操作を行えることは UI/UX上の要件として重要なことであったのだろう。

問題は独自ドメイン機能である。noteのサービス上で任意のJavaScriptの記述が許可されていなくとも、独自ドメインでホスティングされるコンテンツは、本質的にはドメイン所有者の管理するものである。だから独自ドメインのオーナーは、任意のタイミングでDNSレコードを切り替えてしまえば、noteの有効なセッションを自分の管理するサーバーに送信させることが出来た。note社が考えた修正方法の一つにDNSレコードの変化を監視すると言ったものもあったのだが、そういったものも根本的な対策にはならない。広範なユーザーを対象に攻撃しようとした場合には検知しうるかもしれないが、元より「ドメイン所有者である」note proユーザーを攻撃者として想定しているのだから、DNSサーバーも攻撃者の管轄下であり、特定の環境から接続された場合にのみ別のレコードを返すことは可能だからだ。特定ユーザーがターゲットならオフィス訪問時に中間者攻撃でも良い。

発見当初、設計上の重大なミスではあるが、前提条件としてnote proの契約が必要であるため、実際に悪用されるリスクは低いだろうと考えた。そこで、note pro利用企業でなくとも攻撃できる経路がないかを探していたところ、ログイン時にhttpでもリダイレクトする箇所を見つけた。組み合わせれば自動でセッション乗っ取りから、ログイン状態で取得できる各種情報の取得が可能となっていた。リダイレクト時にhttpでも受け付けてしまっていたのは、単純なミスであり、副作用なく修正できるため当日中に修正された。独自ドメイン向けのセッションの分離とAPIの制限については、修正に時間がかかるとのことで、最初の報告からは1年以上かけての修正となった。

また、自分が気にかけていたのは、デフォルトで独自ドメインに対しても自動ログインする挙動である(閲覧履歴機能もあるので自動ログインさせたいのだろう)。note.com はnote社が運営していることが分かるし、noteを信用してアカウント登録してログインしていても、note.example.com がnote pro利用ドメインであることは事前に分からない。単にnote記事を閲覧する側としては、note pro利用企業が信用できるかどうかなどは知ったことではない。仮にもし、note社がnote pro利用企業を審査していたり、あるいは契約上で不正な行為を行われないように担保していたとしても、ユーザーからは分からない。訪問サイトでnote proが利用されている場合に、自動ログインされ接続されるのはnote社のサーバーではあるが、ドメイン自体はnote proを利用する各企業が管理するものであり、ユーザー名程度の情報(独自ドメインのnoteコンテンツをログイン状態で表示した際に含まれる情報)は、原理的にはnote pro利用企業からも把握されうるということだ。自分はこれを脆弱性とは表現しないし、単にnoteの仕様として受け入れ可能な範囲であろうとは考えるが、ユーザーに対しては周知されているべきだと考える。note pro利用企業を信用できない場合は、note.com からログアウトしておくことで自衛することが出来る。

• 2020-09-30 18:02 独自ドメインセッションから銀行口座番号のAPIを叩ける問題の報告
• 2020-10-01 12:32 独自ドメインセッション作成時に中間者攻撃が可能である問題の報告
• 2020-10 いくつか緩和策が取られる
• 2020-10-22 銀行口座API（および売上管理やクレカ管理など）について追加の認証が必須となる(note社による情報)
• 2021-03 独自ドメインセッションから呼び出せるAPIの制限、異なるクライアントからのセッション再利用の検知が追加される(note社による情報)
• 2021-05-17 mala→noteに連絡。情報開示したいが、修正内容に問題がないかの確認、独自ドメインから参照可能な情報がいくつか残っていることの指摘(通知、検索履歴、下書き記事)
• 2021-05-18 note→malaに連絡。修正不十分であり、追加で対策予定であるとの連絡。
• 2021-10 note→malaに連絡。独自ドメイン上での購入機能などを廃止して note.com に移動する対策を行ったとの連絡
• 2021-12 指摘された問題についてnote社の認識の範囲で修正が完了(note社による情報)
• 2022-11-29 時間が経過してしまったが公開して良いかどうかの打診
• 2022-12-23 note社によるフィードバックいくつかを反映して公開