7を頭文字にする電子決済サービスの炎上を見てて思うこと。既存不適格。目的によってセキュリティポリシーの深さを考えよう。

https://www.businessinsider.jp/post-194660
Fiddlerのスマフォ版があるとは、、、あるか、あるよね、作るよね。

一瞬だけ7payの現場にいたことがあります。能力不足や適性違いで3か月で切られましたが。

もともとセブンーイレブンアプリってものがありました。支払いや入店によってバッチがもらえるアプリです。そのバッチがたまると商品と交換できることがゴールでした。nanaco番号を登録することもできます。
nanaco番号が少しだけ魅力的に見えますが、それでもセブンーイレブンアプリはのっとったところで旨味はない。攻撃者の興味を引くことはありませんでした。だから下記の仕様でも問題なかったわけです。
(画像)
 外部ID認証がオムニサーバーと関連しておらず、完全に独立している。
セキュリティ的に最善を尽くしている形ではないのは確かです。今回は実際にそこを突かれたわけですし。ですが、費用対効果を考えるとどこかで折り返さざるを得ません。もともとのセブンーイレブンアプリのサービス内容なら、セキュリティについてここで折り返して問題なかったのでしょう。

ただし、決済サービスとなると話が変わります。もともとのセブンーイレブンアプリにかける価値がなかった労力や捕まるリスクに価値が出てきます。明らかな”金”が絡むと攻撃者の目の色が変わるということですな。
さらに7payサービスをセブンーイレブンアプリに組み込むことになったのは6か月前の仕様変更だったということです。

https://blogs.yahoo.co.jp/centrair100/66748161.html

年の瀬が迫る段階で、7payを急遽現在の仕様である「セブン-イレブンアプリへの追加機能」とすることに変更された。7payの開発にかかわる企業をよく知る関係者によると、この段階でアプリの開発企業が変更されたという。
無茶な仕様変更に最初の企業が降りましたね、、、、。
大急ぎでかき集められた業者は「バーコードをはじめとする7Pay機能」に特化したのでしょう。すでに出来上がっていたログイン機能に注視することはなかった。もしくはログインまで意識を広げることができなかった。そのログインは決済サービスを取り扱うにはレベルが低かったんだけどね、、、、。
法律用語で「既存不適格」というものがあります。当時の法律に準拠して作ったのに、その後の改正により法に当てはまらなくなってしまった家を言います。震災の時によく問題になっています。
今回のログインの仕様は「既存不適格」だったんでしょう。既存のセブンーイレブンアプリとしては十分だったが、電子決済アプリとしてはそうではなかった。
※気づいていた、不安視していた可能性はあり。リリース前から気づいているバグや脆弱性を無視してリリースし、後から直すのはよくあることなので。「この日にリリースする!」とプレスリリースしちゃうと体面だけでもリリースしなくちゃ恥をかくんですよ。

セキュリティを考えてみた-1.まだ浅い

・⓪番目としてオムニ7のAPIサーバーからワンタイムトークンを取得。
・②の時にidやexIdSiteIdとともにワンタイムトークンを返す。
これじゃまだ甘い。攻撃者も⓪番目の通信を行ってワンタイムトークンを取得して②を通信すればいい。
「IPアドレスで3回失敗したら30分間エラーを返す」も考えたけど、攻撃者はIPアドレスを移動しながら攻撃してくるだろうから意味はないなぁ。

セキュリティを考えてみた-2.アプリ固有キーを通信じゃ無理

・アプリの固有キーをハッシュ化して付随。固有キーと外部IDの組み合わせがオムニ7のAPIサーバーにあるDBと一致したらOKを返す。
同じアプリで別のキーで入れないし、スマフォを買い換えたらログインできなくなる。

セキュリティを考えてみた-3.ここまでしないとだめか?

・⓪番目として「(乱数or個体番号)+年時月分日秒+salt」暗号化で作ったキーを送る。
・⓪番目を受け取ったオムニ7のAPIサーバー。キーを解凍して1分以内であることを確認。(乱数or個体番号)を保持。ワンタイムトークンを返す。
・①。SNSと通信。外部IDを取得
・②.外部IDと「(⓪で使用した乱数or個体番号)+年時月分日秒+salt」、⓪で受け取ったワンタイムトークンをオムニ7のAPIサーバーに送る。
・②で受け取ったオムニ7のAPIサーバーはキーを解凍して1分以内であることを確認。(乱数or個体番号)の一致の確認。ワンタイムトークンの一致を確認。外部IDをDBと確認。
 
こんな感じかなぁ。肝はアプリが作ったキーをオムニ7のAPIサーバーがチェックしているところ。攻撃者はオムニ7のAPIサーバーの作るワンタイムトークンをコピることはできても、アプリが作ったキーを生成することはできまい。

現場的にはこんな感じ?

たぶんこんな感じだったんだと思う
基本設計
ログイン機能は既存のものなので気にしない。新規参入者ならなおさら「既存機能のチェック」なんて守備範囲を広げるようなことはしない。

詳細設計
ログイン機能は既存のものなので気にしない

開発
ログイン機能は既存のものなので気にしない

単体テスト
ログイン機能は既存のものなのでスルー。テストのターゲットの画面に行くまでの手順に過ぎない。

結合テスト
ログイン機能は既存のものなのでスルー。テストのターゲットの画面に行くまでの手順に過ぎない。

結合テスト
ログイン機能は既存のものなのでスルー。

、、、、あれ?これって現場としては「今回のことのメイン原因は俺じゃねーよ」ですね。
ログイン機能担当者は「7pay側が言ってこい」だし、7pay担当者は「ログイン機能が甘い」だし。ボールが真ん中に落ちた感じ。
他チームへの無関心がこうなったとは思いたくないなぁ。みんな必死だったもん。

どうやったら気づけたかなぁ。完全に別動隊の大規模テストチームが作成されたはずで、そのテストチームって大きなリリースがあると作成されて、終わったらいなくなってました。本当に別動隊なんです。その人たちはドキュメントをすべて確認した後テストしてたから、セブンイレブン-アプリのログイン機能も7pay機能もフラットに見てたはず。ま、その人たちも守備範囲を選定しなくちゃいけないから「ログイン機能は変更ないから守備範囲外」にしちゃったかなぁ。
んじゃ、誰が気づけた?
※候補を考えたけど〇〇担当者みたいな感じで個人を槍玉にあげる格好になっちゃうのでここまでにしておきます。

個人的な問題点。これを見て問題に思いつけるか

上までと論点が変わります。ここまでは既存サービスと新規サービスの融合時のこと。
ここからはサービスごとの結合について。

この記事を、2点でまとめようと思ってました。
1.PCの性能やネット環境が強力になってきていて総当たりが簡単になっている。現場の開発者が『俺たちは知ってるから気づくだけで普通はわかんねーよ』というバグやセキュリティホールはつぶさなくちゃいけないですね
2.新たにサービスを追加するときに、既存のサービスが適合するか気づきたいですね。
だけど、私としての問題はそこじゃなかった
下の資料を見てください。上の図を半分にしただけです。
このドキュメントを見て、今回の抜け道に気づけます?
この図が頭に入っていたなら結合テスト実施時に、あるいは気づけるかもしれない(変化のない画面を見ながら「今①が走ってるなー、んで②が走るねー」ぐらいなら想定できる腕は持っています)。けど基本設計の段階で気づけたか?最大限にうぬぼれても”これ(SNS)とこれ(オムニ7のAPIサーバー)がつながってないのが怖いけど、こういったもんかねー”までが精いっぱいかなぁ。

どうやったら気づけたか。現場セキュリティの弊害

最初にも書きましたがFiddlerのスマフォ版があるとはあるんですね。記事で初めて知りました。けど、言われてみれば誰かしら作りそうです。ルーターのログが見れれば、一目瞭然だろうしね。

ほとんどの現場がそうであるように、7payの現場もPCには許可されたアプリしかインストールできませんでした。「これしか使うな!」ではなく、ある程度のフリーソフトは申請すれば許可を出してくれていたから窮屈さは感じませんでした(というか先人の開発者さんたちが主だったフリーソフトは許可を通してくれていた)。
スマフォはテスト用が用意されてました。私はセブン-イレブンアプリだけを使って、chromeを立ち上げることさえ躊躇してました。そこにFiddlerなどの指定外アプリを入れようとは思わなかったなぁ。余計なことして怒られたくないと思ってたし。

やり玉に挙げやすいのは7PAY設計者かなぁ。「電子決済サービスに耐えられるログイン機能であることを確認する」を怠った。二段階認証になってることの確認とか。でも新規参入なら担当外の機能に目が行くわけがないよなぁ。
開発製造者には気づく余裕はないか。コードを書くので精いっぱいだよね。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です