やっと、ベンダー側での全ての対応が完了したということが確認できたので、事の顛末を公開できる状況になったのですが、文京区の図書館システムは、個人情報が漏洩しかねない脆弱性を抱えていました。
自分の中での整理も含めて、どんな状況だったのかまとめておきたいと思います。
#自分には、Web アプリとか Web システムを作った経験はありませんが、見つけた時には「これは、ひでぇ…」と思いましたよ。
一体、どんな問題であったのか?
問題があったのは、文京区立図書館システムで使用されている ELCIELO という図書館業務のパッケージシステム。
2010 年 4 月にプロポーザル形式での業者選定で京セラ丸善システムインテグレーションに決まって、システム自体の稼働は 2011 年 1 月初めから。
自分は、富士通のシステムが使われていた頃から、Web での図書の貸出予約が出来るように利用者登録をしていたので、新システム切り替わりと同時にパスワードを変更して使っていたわけですが、新システムに切り替わって 1 ヶ月になろうかという頃、利用者メニューにログインしているときに、ふといや~な予感が…。
ロケーションバーに表示されている URL をよく見てみると、 "SID=" で始まる文字列が含まれている…。
「 https なページとはいえ、まさかセッション ID のことじゃないよねぇ...。」と思いつつ、次のような操作をやってみたところ…。
- 図書館サイトにアクセスして、利用者メニューにログイン。
- この時点では、"SID=" のパラメータは、URL に付いていないことを確認。
- 貸出・予約照会ページが表示されたら、画面上部にあるメニューから「パスワード変更」や「連絡方法変更」などをクリックして、一旦利用者メニュー内の別ページを表示。
- このページ遷移をしたタイミングで、"SID=" のパラメータが URL に付いたことを確認。
- 別ページが表示されたらメニューの「貸出・予約照会」をクリックして、貸出・予約照会ページに戻る。
- 戻ったら、ロケーション欄の URL を全選択して、コピー。
- 最初にログインしたのとは別の Web ブラウザを起動して、4. でコピーした URL をブラウザのロケーションバーにペーストして、図書館システムへのアクセスを実行。
すると、なんということでしょう。ID パスワードによる認証を華麗にスルーして、貸出・予約照会ページが表示されるじゃありませんか。orz
と、思わず呟いてしまったぐらいヤバいと感じたので、もう少し調べてみたところ、
- 利用者メニューへのアクセスリクエストに対する HTTP レスポンスには "Set-Cookie" が含まれていたが、ブラウザでCookie を受け入れないよう設定した状態でも、"SID=" 付きの URL を使うことで、ID パスワード入力をスルーして貸出・予約照会ページ表示することが可能。
#そもそも、違う Web ブラウザ間での URL コピペでログイン状態となる時点で、 Cookie を使ってないことは明白なんだけど。
- もう一度ログインしなおすことで、"SID=" の値が変化するものの、URL のコピー&ペーストでユーザ認証が回避されるという状況には変化なし。
ということで、"SID=" の部分がセッション ID を示すものであろうということが、ほぼ確定。
加えて、利用者メニュー内の終了をクリックすることで「ログアウトしました」と表示されるのでセッション自体もクローズされているのかと思いきや、その場合でもパラメータ付き URL 自体は 12 時間程度有効だということも判明して、セッション管理自体が非常に杜撰な状態であることが確認出来た次第。
#IPA への届け出後にわかったのだけど、実際には 30 時間ぐらい有効だった。
セッション ID と思しき値は、それなりの桁数ではあったけど、何らかの法則にしたがって生成されたのであろう英数字による文字列だったので、その気になればブルートフォース的に生成した文字列を使うことで利用者メニューにアクセス出来たかもしれず、セッション ID の有効期間が長いために不正に生成したセッション ID 的な文字列でのアクセス成功の可能性が更に高くなっていた可能性があったという状態だったわけです。(セッションハイジャック状態が作り出せる可能性があったと言っていいかも。)
届け出たのは良いものの…
再現手順や個人情報が漏えいする可能性があること(レファレンス受付フォームに、最初から氏名、住所、電話番号、メールアドレスがセットされている)などを取りまとめて、IPA に届け出たのが 2011 年の 1 月の終わり。
で、2 月初めには脆弱性情報としての取り扱いの開始連絡があったのだけど、その後は梨の礫。 10 月中頃に取り扱い状況を IPA に問い合わせたところ、「開発会社内のテスト環境での対応が完了し、本番環境へは年内に適用の予定」という返信が。
「ふ〜ん、じゃあ年末にメンテナンスするからシステム止めるよ、ってお知らせが出て、そのタイミングで改修されるのかなぁ〜」と様子を見ていたのだけど、特にメンテナンスのアナウンスも出ることなく 2012 年の年明けには対策版への入れ替えが終わっていたという…。(たまたま、借りたい本があって予約しようと、三が日の間にサイトにログインしたところ "SID=" のパラメータがつかなくなっているのに気がついた。)
システムが修正されたと思われることが判明したので、 IPA に届け出た内容が、その後どうなったのかの正月休み明けに確認メールを再度送ったところ、
運営者からのコメント:
- ----------------------------------------------------------------
脆弱性のご指摘をいただいたことにより、個人情報流出を防止する
対策を取ることができました。
- ----------------------------------------------------------------
という内容の返信が。
この時点で「Web サイトとして」の対策は終わった、ということなのだけど、「製品として」は対策されたのかどうかすらわからない状態。
このあと、2012 年の 3 月頭に、IPA からソフトウェア製品の問題(ELCIELO におけるセッション管理の不備)として取り扱うとの連絡があり、2012 年 3 月末には JPCERT/CC 経由で製品開発者に対する脆弱性情報の取得が行われることが決定したものの、その後は特に何の動きもなし。
起算日から 1 年経過すれば「情報非開示の取り下げ」が出来るので、IPA に状況確認のメールを送ったのが、 2013 年の 5 月初め。
それに対しては
- パッチリリース済み
- メーカーが納入先を把握できているので、JVN での公表はしない
- 納入先への告知とパッチ適用を順次実施中
- 全納入先への対応が完了した時点で、JPCERT/CC への報告を行う予定
という内容の返信を貰ったものの、再び待てど暮らせど連絡なしの状況に。
JPCERT/CC 扱いになって丸々 2 年、脆弱性発見からは 3 年以上経過してるのに、一向に動きが見えず、下手すりゃ対象システムのリプレースすら始まるんじゃないかという時間が経過したので、「情報非開示の取り下げ」をしたい旨、 IPA にメールしたのが、2014 年の 8 月中旬。
で、これに対する返信として「製品開発者側での対応が全て完了したことにより、取り扱い自体も終了」という内容のメールが送られてきたということで、発見から 3 年半かかって、やっと終息となった次第。
にしても、疲れましたわ
図書館システムで落とし穴っていうと、例のアレとか、この話に付随した anonymous 有効な FTP サービスが動いていた図書館システムが多数存在したとかが思い出されるわけですが、自分の住む自治体の図書館システムで穴を見つけたときは、本当にビックリしましたよ。
届け出た頃には気にしていなかったけど、よくよく考えればごく限られた範囲とはいえ「どのような本を借りているのか、また借りようとしているのか」ということも漏れていたかもしれなかったということは、図書館の自由に関する宣言にもある「利用者の読書事実」に関わることだよなぁ、と最近になって気がついた。
住所氏名もさることながら、「利用者の読書事実、利用事実」といったセンシティブな情報も扱っている、ということを関係者はどう捉えていたんだろうなといったところは、ちょっと話を聞いてみたいもんではあります。
それにしても、ホント、この件を吐き出せるようになって、一安心。いつ終わるのかもわからず、 3 年半も悶々としながら抱え込んでいるのは、結構つらいものがありました。
それにしても 3 年半は、ほんと長いです…。
そして文京区は ELCIELO を利用した図書館システムをリプレースする時期を表明しました。
現行の図書館システム、平成 27 年 12 月までということや、リプレースに向けて協力することと言った内容も明記されてました。そっちはそっちで、選定があるんでしょうから、この点もウォッチしておかないとね。
[From 図書館の指定管理者の募集が始まってました #文京区 - Soukaku's HENA-CHOKO Blog]
次期システムの選定の際には、脆弱性対応に関することも審査項目として入れていただきたいものです。
トラックバック(2)
さて、以前のエントリーで取り上げた、文京区の図書館システムとして使われている ELCIERO のセッション管理の不備に関する件、メーカから図書館に対してど... 続きを読む
生業として脆弱性検査をやっていない限り、Web サイトの脆弱性にぶち当たったりす... 続きを読む
コメントする