iPX社員によるブログ

iPX社員が"社の動向"から"自身の知見や趣味"、"セミナーなどのおすすめ情報"に至るまで幅広い話題を投下していくブログ。社の雰囲気を感じ取っていただけたら幸いです。

月からのブタによって学べること

「Moonpig」

f:id:ipx-writer:20161122084705p:plain
月のブタ？なんか無意味な名前ですね。初めて聞いたとき僕は「バカバカしい」し
か反応はできなかった。
それで、今回のブログに「バカ」なことがいっぱい。しかし、このブログのメッ
セージは重要　－　情報セキュリティ。
今回の記事担当のベーカーです。iPXはISO 270001認証で会社としてはいつも個人情
報や機密情報の安全を最優先しています。それに関する時期的な訓練とテストを
ちょうど今月受けたので僕は今回の話を思い出しました。

Moonpigはイギリスにあるネット通販会社で、主にはカスタムなグリーティングカー
ドの販売です。僕はああいうのにあまり興味がないですから、その会社はずっと
「どっかで聞いたことあるような名前だね」程度でした。でも、2015年第二週に
Moonpigはどれだけバカかが広報されました。これがトム・スコット氏の素晴らしい
YouTubeビデオ（“The Moonpig
Bug” https://youtu.be/CgJudU_jlZ8 [英
語]）とその元のポール・プライスが書いたブログ
（http://ifc0nfig.com/moonpig-vulnerability/
[英語]）のおかげで僕が初めて聞きました。（このブログはほとんどトム・スコッ
ト氏のビデオからです。）

内容を説明する前にまずはスマホアプリ開発基本の一部を復習しましょう。アプリ
を作るといずれにサーバーとやり取りすることになって、ユーザー・アカウントを
管理しないといけないです。デバイスに直接パスワードを保存したらどれだけ危険
かは当たり前ですから、初回のログインのみユーザー名とパスワードをサーバーに
送信して、以降は変わりにサーバーにもらったトーケンを使います。ちゃんとした
アプリはほとんどこのやり方を使っています。

Moonpigのアプリもこのようなことをやりましたが…

バカポイントその1

Moonpigが使っているトーケンはランダムじゃなくて、ユーザーの顧客番号そのまま
でした！もしその番号がばれたら後で取り消しできない。だれかの顧客番号を見つ
かったら、その人のアカウントとクレジットカードを使ってサイトで買い物できる
だけじゃなくて、その人の個人情報もGETできます。（そのままです。APIの
「GET」コマンドだけですべて表示できます！）

見られるのは想像通りの「名前」、「メールアド」、「住所」、「郵便番号」や
「電話番号」。それに、「誕生日」や「フェースブックのユーザー名」などもあっ
た。クレジットカード情報を調べてみたら、「カード会社・種類」、「有効期
限」、「名義人」と「最後の４桁」が出てきます。（「せめて前１６桁じゃなかっ
たのは小さなありがたいことけどね…」とプライス氏がコメントしました）

上記のデータがあればなりすまし犯罪は決して難しいことじゃないです。この前そ
れほどのないデータ量でハリウッド芸能人のiCloudアカウントがハッキングされて
しまった（ソーシャル・エンジニアリングで）。スコット氏は「そのデータでアマ
ゾンのアカウントを乗っ取れば高級高速サーバーを借りて、ビットコインでも採掘
する」と言いました。

もし自分の番号がばれたと思ったら唯一の行動方針が自分のアカウントを完全に削
除するだけ。
のはずですが…

バカポイントその2

これが元のブログとビデオに載っていなかったが、後で分かったことは削除依頼を
したら、ただサーバーDBに「Deleted」フラグを立てて非表示にするだけ。非表示だ
から検索に出てこないですが、APIと顧客番号を使えばまだ全部見られます。

ということでアカウント削除してしまうと、自分がやろうとする「個人情報保
護」だけは効果なし。つまり、顧客番号が知られたらある意味でおしまいになりま
す。

でも、何人かの方が今「顧客番号を大事にすれば大丈夫じゃない！」と考えていま
す。確かに、ちゃんとした会社は皆UUIDなどのアルゴリズムでほぼランダムな長い
コードを顧客番号として使用して、推測だけで当てられることがほぼあり得ない。

…当時のMoonpig社のことを「ちゃんとした会社」といえたのか？

バカポイントその3

Moonpigの顧客番号の決め付け方がこうでした：

  • 最初の登録者の番号が「１」となりました。
  • その次の方が「２」となりました。
  • その次の…

…まぁ、大体わかりますね、連続的に付けていただけでした。もし自分が「247」で
したら、直前の人が「246」で、次のが「248」でした。その人たちの名前が分から
ないかもしれないですが、それが問題ないです。ただAPIを使って名前を調べればい
いです。

しかも、それだけじゃなくて…

バカポイントその4

普通に同じデバイスからたくさんのAPIの要求が速く来てしまうとサーバーが何かお
かしいかと検知して、そのデバイスを一時的にブロックしておきます。これが「速
度制限」(英:rate limiting)と呼ばれます。

Moonpigのサーバーは速度制限機能を全く使わなかったです。

こうして、一つのシンプルなforループだけでMoonpigの客さん3百万二人全員の個人
情報全部入手可能でした。

本当にそんなに簡単でした。この4つのポイント合わせてこのことが学校の教科書に
「やってはいけない例」として載せられます！

というところで本当はまだ終わっていないです。

バカポイントその5

プライス氏がこの脆弱性を見つかったのは2013年の8月でした。その時に直接
Moonpigに知らせときました。しかし、約一年半後、2015年の年明けに確認したら脆
弱性がまだありました。それでプライス氏がブログで広報しました。

ITセキュリティ業界のエチケットは他社のシステムに脆弱性を見つけたら、知らせ
てから1か月くらいその会社以外に内緒をすることです。プライス氏はその16倍の時
間を待ってあげましたのにMoonpigは解決しませんでした。解決しようとしている姿
さえ見せませんでした。

Moonpigのアンドロイドアプリが2010年に初リリースされました。プライス氏のブロ
グがニュースになった2~3日後にアプリが使っているAPIをオフラインにしまし
た。合わせて5年間この脆弱性があって、その間に見つけてしまったのは一人だけで
したか？そうだと誰も保障できません。

学べること

2015年3月にMoonpigがリニュアルされた新しいアプリをリリースしました。きっと
たくさんのハッカーが今回のソフトに脆弱性を探しまくっているのでしょうが、見
つかったというニュースは今までにないですからもう解決できたとMoonpigがやって
言えます。

でも、何で見つかってから1年半以上かかりましたか？何でトーケンが取り消しでき
ない顧客番号でしたか？何で顧客番号が順次的でしたのか？開発者が一体何を考え
てこのシステムを作ったのか？こういう質問が答えるまでにこの事件はいずれ再発
するでしょう。Moonpigじゃなくても、どこかの会社で。

せめて、再発防止として今回の話からいくつかのポイントが学べますね。

  • ユーザー認証必要があったら、自分の認証システムを作ろうとする前

に、FacebookかGoogleのAPIが使えるかの確認がおすすめです。

  • 順次的な数字を使う必要が限りになるべく使わないようにすること。
  • セキュリティを考えているときに、「どうやってこのシステムを守ろうか」とい

う考え方じゃなくて、まずは「どうやってこのシステムを壊せるか」の立場からス
タートした方がいいです。世の中にその全く同じ考え方の人がきっといるでしょ
う。

  • 脆弱性の知らせがもしどこかから入ってきたら、素直にその人に「ありがと

う」とお礼を言って、その脆弱性の修正は何よりも最優先にすること。

僕は教科書を書くつもりはないですが、もし書くことになったらこの話だけは丸ご
と1章ができます。

そして、その教科書の後ろの用語集に「バカ」を引いてみたら、定義の文の代わり
にMoonpigのロゴを載せましょうか？

*1

*1:＊（ちなみに、パスワード管理に興味がある人に、同じスコット氏のこのビデ オ‐https://youtu.be/8ZtInClXe1Q [英 語]‐がいいスタートです。）