技術とか戦略とか

IT技術者が技術や戦略について書くブログです。

7payの脆弱性残存の原因の考察(形式的チェックの問題点、集団浅慮の問題点)

(2019/07/13に一部表現を見直しました。内容は変えていません。)
 
ニュースでも大々的に取り上げられていますが、7payがサービスイン直後にセキュリティ上の脆弱性を突かれて不正利用されてしまいました。
三者のログインを許し、クレジットカードから7payへのチャージ、及び7payでの購入をされてしまうことで、約900人の被害者数と約5500万円の総被害額を出してしまいました。
また、表立った実害は出ていないものの、7payのIDを無制限に作れるために登録特典のおにぎりが無限に手に入るという指摘もTwitter上でされました(https://twitter.com/athlonz/status/1146713927885082624?ref_src=twsrc%5Etfw)。
 
私は決してセキュリティの専門家ではなく、金融系SIer下流に生息する至ってノーマルなSEなのですが、この脆弱性を事前に発見するにはどのようにすれば良かったのか、自分の知識と経験を元に考えてみました。
 
■残存していた脆弱性の内容
下記の2つの記事にて詳しく書かれています。
 
「7pay緊急会見」で露呈した3つの大問題。なぜ脆弱なセキュリティ対策で開始したのか  BUSINESS INSIDER JAPAN

https://www.businessinsider.jp/post-194071

 
7payクレジットカード不正利用:第三者乗っ取りがあり得る致命的な2つの弱点(三上洋) - 個人 - Yahoo!ニュース

https://news.yahoo.co.jp/byline/mikamiyoh/20190704-00132766/

 
まとめると、下記の4つの脆弱性がありました。
 
①会員登録時のメールアドレスの確認方法の不備
 7payでは、IDとしてメールアドレスを使用している。
 この際、メールアドレスの有効性を確認していなかった。
 そのため、誤ったメールアドレスでも登録できた。
 また、後述の本人確認もされていなかったため、IDを無制限に作成できた。
 
②本人確認方法の不備
 一般的には、登録した電話番号にSMSを送る「二段階認証」が使われる。
 しかし、7payではこれをしていなかった。
 そのため、第三者が他人のメールアドレスで登録することが可能であった。
 また、IDとパスワードだけでログインできたため、リスト型攻撃に脆弱であった。
 
③パスワードリセットの方法の不備
 7payでは、パスワードリセットの際、以下の3つの情報の入力を求められる。
  ・生年月日
  ・電話番号
  ・会員ID(登録時のメールアドレス)
 この際、前述の二段階認証を行っていない。
 そのため、3つの情報を知っている第三者がリセットを要求することができる。
 (これらの情報はパスワードと異なり、会員名簿等から比較的容易に取得できる)
 更に悪いことに、パスワードリセットのメールアドレスを指定可能であった。
 そのため、リセットを要求した第三者がパスワードを変更できる状態であった。
 
④会員登録時の必須項目設定の不備
 会員登録時、登録ルートによっては生年月日を省略することができた。
 この場合、生年月日には固定値(2019/01/01)が設定される。
 このことが、前述のパスワードリセットの脆弱性を更に強めた。
 (生年月日を省略した会員については、2情報でリセット要求可能)
 
上記以外にも、被害発生時の初動対応の不備として以下の指摘もされましたが、それについてはこの記事では深く取り扱いません。
・パスワードリセット画面のメールアドレス入力欄をCSSで隠しただけ
 知識があればメールアドレス入力可能
・新規会員登録・チャージ機能は停止したが決済機能は停止しなかった
 既に第三者にチャージされてしまっていた場合に不正利用されてしまう
 
■形式的なセキュリティー審査の問題点
脆弱性の関する記事にて、気になる記述がありました。
 
「会見で同社は、「セキュリティー審査では脆弱性を指摘されなかった」とした」
 
どのような体制でどのような方法でセキュリティー審査を行ったのかは明らかではないですが、少なくとも何かしらのチェックは行っていたと考えられます。
 
7payは複数のベンダー(NTTデータNECNRIOracle)の共同チームであったと言われており、恐らくは日本で一般的なSIer主導の開発であったと思われます。
SIer主導の開発では、少人数の専門家チームが開発するというよりは、人月商売で開発者をかき集めてくる色が強くなるので、玉石混合の開発者が入り込みやすくなります。
セキュリティの専門家と言えるような開発者が然るべきポジションにアサインされていなかった可能性も十分にあります。
 
また、社内で審査したのか社外のサービスを使ったのかはわかりませんが、「セキュリティー審査」という表現をされる場合は、多くの場合は特定のチェック項目を形式的にチェックするという形になります。
形式的なチェックとしては、チェックリストや脆弱性診断ツールを用いたチェックがありますが、決められたチェック項目をチェックするという意味ではチェック方法に本質的な差はありません。
 
ここでは、形式的なチェックとして、Webで出回っているチェックリストを使ってみます。
Webで出回っているチェックリストとしては、IPAが発行しているセキュリティ実装チェックリストがあります。
試しにこれをやってみました。
(会員登録機能は既存サービスのomni7の機能なので全て対象外にする、という判断は行われていなかったものとします)
 
安全なウェブサイトの作り方:IPA 独立行政法人 情報処理推進機構

https://www.ipa.go.jp/security/vuln/websecurity.html

 
このチェックリストでは、①~④の脆弱性何れも発見できないと思います。
今回使用したチェックリストは高度な技術を用いたハッキング対策寄りであり、今回のような業務フロー上の問題を発見するのには不向きであったと思います。
もしかしたら、別のチェックリストを使用したり、もう少ししっかりチェックしたりすれば見つかるのかもしれませんが、選定したチェックリストやチェック者の技術力に依存してしまう(どこかで非形式的な判断を入れる必要がある)、ということは言えると思います。
正直、形式的なチェックでは限界があると思いました。
専門家による非形式的なチェックが必要だと思わされる事案だと思いますし、7payのセキュリティー審査も形式的なものであった可能性が決して低くないと思います。
(①~④の脆弱性は何れも言われてみれば当たり前のものであり、専門家でなくても発見できて当然だと思えるものなのかもしれませんが、後知恵無しの状態、しかも脆弱性含みの設計が正しい設計として仕様書に書かれている状態で発見できるかどうかは、また別の問題です。また、末端の開発者だと個々のモジュールの仕様書のみ渡されることも多く、システム全体の構成を理解することすら困難な場合が少なくありません。)
 
■社内の空気が原因である可能性
もしかしたら、社内の開発者は脆弱性に気付いていたかもしれません。
しかし、下記の記事に書かれている通り、脆弱性に気付いたとしても、脆弱性を残存させることのリスクを説明できない、説明できたとしても経営層が納得しなかった(リリース延期して脆弱性を対策する等の判断をしなかった)のかもしれません。
 
7Pay不正に潜む大きな脆弱性 システムの穴指摘できない社内の空気? - ライブドアニュース

https://news.livedoor.com/article/detail/16731357/

 
この記事にある通り、いち早く利益を出すためにリリースを急いだのかもしれません。
また、会見では「UX(顧客体験)をどう作っていくかという話と、セキュリティーをどう確保するかは、常にどうバランスさせるか難しい問題」という発言もあったので、利便性の高い快適なサービスにすることで、7payへの移行を促す戦略だったのかもしれません。
(7payは後発のサービスであり、予定通りリリースしたとしても先行者利益は得られない、その代わり既存サービスからシェアを奪う必要があるので、リリースを急いだ可能性よりも、既存サービスに負けないように利便性を重視した可能性の方が高いと個人的には思っています)
支配的な企業統治を行う経営者に「脆弱性は後で直せば良いから早くリリースする」「多少の脆弱性を犠牲にしてでも利便性を確保してnanacoや競合サービスからの移行を促してシェア拡大を図る」と言われてしまったら、開発者を束ねる管理者は何も言えないと思います。
 
利便性を重視して競合からシェアを奪う、という経営判断は必ずしも間違った判断ではありません。
しかし、今回の場合は、サービスイン直後に脆弱性を突かれ、大々的にニュースで取り扱われ、7pay(及びその親会社)の信頼を揺るがす結果となった(7payのシェア拡大が困難になった)ため、結果的には間違った判断であったと言えます。
 
今回の事例は、集団浅慮の失敗ケースの題材であるとも言えるかもしれません。
 
グループシンク(集団浅慮)とは?ジャニスが提唱する8つの症状や対策方法もご紹介  BizHint(ビズヒント)- 事業の課題にヒントを届けるビジネスメディア

https://bizhint.jp/keyword/76354

 
各々のメンバーが対等の立場で検討し、批判的な意見(今回のケースでは迅速なリリースや利便性を犠牲にしてでも、脆弱性を対策するべきだ、とする意見)も受け入れる体制が整っていれば、もしかしたら正しい判断ができたかもしれません。
こればかりは技術力でどうにかなる問題ではありません。経営者も巻き込んで、全社の意思決定のあり方を見直す必要があります。