なぜセブンペイは悪かったのか

起こったこと

7月1日 7payのサービスが開始した

未明から既に攻撃は発生していたものと思われる

7月2日未明 Twitter などで不正アクセスにより知らないうちに大量のチャージ及び利用が行われたと言う被害が大量に報告される


当初、7pay側はIDパスワードの再利用を避けるよう指示をしたとか正規でない方法でチャージされたとしても、それを保証しないという説明をサービスデスクで行なっていたなどという報告が上がっていた。

7月3日

  • 7Payは今回の不正利用についてホームページなどで掲載し、公に発生していることを認めた
  • 新たなチャージ及び新規登録について中止を発表した。ただし今現在においても利用自体は可能である。つまり不正にチャージされた金額については今も利用されている可能性がある。
  • 7Pay社社長が記者会見を行った。残念ながらそこから明らかになったのは経営層の技術に対するあるいはセキュリティに対する理解の浅さが判明しただけであった。
  • 公に認めた被害は以下のとおり
    • 約900名／約5,500万円　※2019年7月4日 6：00現在
    • 全額補償すると会見では言ったもののその条件は曖昧にしている

7月4日 事件発生

中国人2名による不正利用が通報され警察に逮捕された。供述によると指示役によってその場で ID 及びパスワードを連絡されそれを7名に登録その場で大量のタバコを買ったが、持ちきれなかったため一時的にその場を離れた時に店員が不正利用の痕跡に気付き通報、逮捕となった模様。

7月4日同日

7Pay社は、二段階認証を導入することを発表している。ただしその時期は不明でありいつ実装されるのかはわからない。なお、私見ではあるが、この二段階認証に関しては前日の会見で社長がまともにそのことに関して答えられなかったことに対する対応と考えられ、実際にアプリに実装されるような設計を始めているとは少し想像しにくい。
以上が現在までに判明している経緯である。

7Payは何が悪かったのか。見える３つの無策

大きく3つの問題点がある。 他にも様々なセキュリティ的な欠陥が明らかにはなっているが実際に被害にあった主原因としてはこの3つが考えられる。
  1. 7ペイは新規登録に対して本人確認を行っていなかった。
  2. 7ペイはパスワードの再発行について誰のパスワードにその通知を行う仕様としていた。
  3. 二段階認証について行っていなかった

本人確認について

経済産業省が示しているガイドラインにも４．アカウント作成時 において、「本人認証」について言及されている。
しかし、7ペイにおいてメールアドレスの登録こそ行わせるもののそのメールアドレス自体の正当性を図るため、一般的にメールの返送を行ってメールアドレスの確認を行っていなかった。
これについては、今回の事件に直接的に関係性があるわけではないが、セキュリティの軽視として1つ挙げられる。 登録したメールアドレスに本人であるかどうか返信してメールアドレスの正当性を確認するという方法を一般的に用いられているがそれを行っていなかった。これにより、あらかじめ漏れている ID 及びパスワードの組み合わせによって登録するリスト型攻撃を実現することは比較的容易である。ただこの場合、カードが不正利用された事が説明がつかないことや他に使っていないパスワードを使っているにもかかわらず被害があったという報告もあるため、これ自体は今回の被害に必ずしも関係するものではないと考えられる。

パスワードの再発行について

実際の攻撃に用いられた主なセキュリティ欠陥と考えられる。
つまり、利用者がセブンペイに登録を行うそれはカードの登録まで含めて行なっている状態とする。この状態で、メールアドレスとそれに結びついている生年月日、電話番号が分かりさえすれば他のメールアドレスに対してパスワードを発行画面を表示することができる。すなわちこれらの情報をあらかじめ不正に入手しているあるいは SNS などによって公開している情報によって不正に他人のアカウントを乗っ取ることが可能である。
また今回のアカウントに関しては元々存在しているサービスと結びついているものであるため当初から潜在的に会った脆弱性だと言える。ただし、当初は直接的に金銭と結びついていなかったことから整理をするメリットがなかったと考えられる。
しかしこの脆弱性が存在したまま、7ペイをそれに結びつけたためその脆弱性を知っている何者かがサービス開始と同時に不正利用を大量に行ったものと想像できる。
現に7月4日に逮捕された容疑者の供述によると指示役の連絡によって、 ID とパスワードを知らされたと供述している。つまり、逮捕された彼らはいわゆる出し子と呼ばれるような末端の人間であり実際に大きな利益を得ている指示役とは関係性が非常に薄いあるいは全くの無関係の人間だと想像できる、これは振り込め詐欺などのおよそ組織的構造の犯罪と酷似しており、計画的な犯罪であったと想像ができる。
整理すると7Payはセキュリティに対するおよそ基本的なセキュリティ設計を講じていなかった。そして潜在的な脆弱性に気づくことなく見事に（厳密な意味ではないが）ゼロデイ攻撃を受けたことによる被害であったと分析できる。

二段階認証がなかった

これは、仮に乗っ取りを受けたとしても、防御策の1つとしてあるべきものだった。
仮にパスワードの再発行を受けたとしても、例えばSNSによる二段階認証があったとするならば、本人の携帯でしか決済できなかったはずだ。
しかも、決して目新しい技術ではないし、他のペイ系のサービスでも実装されているような常識的なセキュリティ対策だ。
これは社長への記者会見でも指摘され、見事に答えられなかったことが、世間で話題に挙げられている。
以上、３つから入口対策の無策、脆弱性の放置、出口対策の無策という３つの無策が明らかになった。

7 Payはどうすればよかったのか

初歩的なセキュリティ設計をあらかじめ講じておけばよかったと言ってしまえば元も子もないがそれに尽きる。
事実として7ペイは他の QR コード型サービスの後発組であり分析できる立場にあったはずだ。それを怠って極めて低いセキュリティ設計のままサービスを開始してしまったことは経営層のセキュリティに対する認識が甘さによる大きな責任問題だと考えられる。
今日日、セキュリティ問題は常識的な話であって、いかにシステムに疎い人間だったとしても経営者として関わっている以上は顧客の財産を守る義務がある。故に最低限のリテラシーが必要でありそれを認識することは経営上義務といえる。
こうしておけばよかったセキュリティ対策についてはいくつか考えられる。

二段階認証

第一に二段階認証。これは会見でも指摘されていることであるが通常の ID パスワードのみならず SMS などの電話番号に紐付いたメッセージやアプリによってワンタイムパスワードを発行したりすることによって 、本人でかつその端末を利用していることをその場限りで保証できる仕組みだ。もっとも今回の脆弱性の中に電話番号という要素が含まれているため単純な SMS の二段階認証ではあまり功を奏しない方法ではあるといえる。

生体認証

二要素認証の文化的なものであるが携帯電話特有の方法である。携帯電話には今指紋認証機能がついているものがある。これによって本人であることを証明できる。もっともこれも端末に紐づいているものであるからして脆弱性を考えれば暴走すものでもない。

本人確認

本人確認。これが最も重要だったと 指摘していいだろう。パスワードを変更にするしても機種変更による引き継ぎをするにしても、本人確認を行うということを設計上設けておくべきであった。 7 P 側はこれを生年月日と電話番号という方法のみを取って、他のメールアドレスにパスワードを再発行させることができると言うことを手段としてとっていたが残念ながら生年月日と電話番号と言う組み合わせは今のダークウェブ上では視覚的に取引されている情報だと言ってもいいだろう。あまり意味のある情報の組み合わせとは思えない。やはり本来のメールアドレスにパスワード発行させることを限定するなどしておくべきであったし例えば他の SMS、 Twitter や Facebook などのアカウントと紐付けさせて、それを必須とするといった方法をとれば安易に第三者が乗っ取ることは不可能であったと思う。
本人確認を重要視するのは金融機関であればあるいは流通系であったとしても金銭を扱う立場であったとするならば重要な要素であり、何より7平和系列にセブン銀行という金融機関がある。金融庁から様々な施策が指示されている中に本人確認の重要性はきつく言われているものであって、その重要性をわからなかったというのは詭弁に過ぎない。

なぜ後発組にあったにも関わらず対応できなかったのか

ここからは蛇足である。なぜ後発組である7ページがセキュリティに対する対応をシステム的に取れなかったのか報道によれば関わっている開発会社は名だたる開発会社ばかりで極めて大規模かつステークホルダーが多数に及んでいたものと考えられる。裏を返すとこういった体制は責任の所在が曖昧になりがちであり意思決定も遅くなる。そして上意下達 の体制をとりがちでありその上位がセキュリティ関係に疎かったとしたならばそれが反映されることはないと言っていいだろう。ボトムアップでの情報も上位には届かなかっただろうとも想像できる。
それゆえにペイペイの不正利用事件や他の事件があったとしても肥大化している組織において方針を変えることができずそのまま安易なセキュリティ設定で期日を優先して サービスを開始したものだと想像に難くない。

彼らはこれから対応できるのか

蛇足ではあるがなぜ言及したかといえば、 7ペイ側は2段階認証を行うと発表したもののそれを迅速にできる体制にあるとは思えないからだ。また本質的な脆弱性を解決する方針を示していない。脆弱性自体を解決しない限り事件は再発する。その決定までにどれだけの時間がかかりその実装までにどれだけ時間がかかるのかその間はチャージもできないから7Payの利用のパイは閉じていくばかりだ。 果たして彼らは7Payの息がもつ間に事件を解決できることはできるだろうか？
一部ツイッターなどでは、二段階認証を７月１１日までに実装しろとベンダに指示した、などという情報もある。
…この期に及んで、経営層の責任感は皆無であり、ベンダに投げる形はあまりにも浅はかとしかいうしかない。

利用者はどうするべきか

セキュリティに関して常に最新の技術を取り入れるあり、その姿勢を経営層が示しているかどうか誰が指標になるだろう。
もちろん、個人のリテラシーを広めて、ID/パスワードの再利用をしないことはもちろん、二段階認証、生体認証などを行っていくべきだ。
それらの情報を調べて最終的には個人が個人で使用できるサービスを使うことが大事である。最終的に自分の財産を守るのは自分の責任であるのだから。

コメント

コメントを投稿

このブログの人気の投稿

リモートワークをLogicoolのマウスとキーボードで複数ＰＣ切り替えて優勝した

イメージ
デバイス多すぎるんやが問題 仕事上シンクライアントPCを支給されているのだけれども、当然キーボードとマウスが増えるのでとても面倒くさい。 シンクライアントPCはノートPCなのでノートのキーボード使えやって話でもあるけど、使いにくいでしょ？ ということで、自前のをつないでいるんだけれど、メインPCでも調べごとしながらしているとなかなか作業場が厄介になる。 メインで使っているのはMXREGOじゃない 上図のマウス１に当たる部分はLogicoolのMX REGOというトラックボールマウスである 「そういえばこれPC2台接続できるじゃない？ ということで、ついでにキーボードも切り替えできるものとしてK375sを購入した Logicool K375s Multi-Device Wireless Keyboard & Stand Combo 構成 問題点 シンクライアントPCにLogicoolのソフト入れられない シンクライアントPCなのでLogicoolのPCにUnifyingソフトウェアを入れることができない。 つまり設定することができない つまり詰んだ？ ぴえん🥺 解決法 「聞こえますか…UnifyingはBIOSで認識できるのです...」 アラサーおじさんが泣いていると直接脳内に声が聞こえました。 アメージング！ Unifyingレシーバーは直接デバイスとペアリングしているのです！ ここらへんの仕様を調べたのですが、Logicoolのホワイトペーパーとかも見当たらないし、今ひとつつかめないんですよね。 同じような無線仕様のBluetoothはアプリケーションレベルで解決してるっぽい？のですが、Unifyingはハードウェアレベルで解決してるようですね。 話はそれましたが、解決法はこうです。 メインPCに2つ目のレシーバーを挿す 通常どおりペアリングする そのレシーバーを外しメインPCには元のレシーバーを挿す シンクラPCに2つ目のレシーバーを挿す これで解決できました。レシーバー上にペアリング情報が残るのですね。なので、こういった他PCでペアリングして指し直して使うという取り回しができるようですね。 リモートワークも一組のキーボードとマウスですむようになった
続きを読む

VBAでのInterfaceやキャスト

前段 個人的に、Excel VBAを仕事で組む機会がある。 自由に組んでいるので、いろいろと設計方法、実装方法を考える。 VBAのインターフェース VBAにはJavaでいうextendsのような継承はない。 Interfaceがあるので、ポリモーフィズムを実現するときは、これを使うのが一つの方法論だ。 ただ、インターフェースは、というか、VBAはクラスのキャストができない。 インターフェイス自体が、そうする性質のものではないのだが、つい欲しくなるときがある。 Object型 さて、話は変わるが、VBAには、Object型というものがある。 平たく言うと、あらゆるクラスに適する型である。あらゆるクラスのスーパークラスと思うと話が早い。 そして、Objcet型からは元のクラスで実装したプロシージャを呼ぶことができる。ObjectによるポリモーフィズムもVBAでは可能、といえる。 なので、ダウンキャストを実現するために、インターフェイスでインスタンスが自己をObjectで出力するためのメソッドを定義してあげることで、スーパークラスからサブクラスへのキャストを実現する。 実装例 Class InterfaceClass '' プロパティ Public porp as String　 '' イミディエイトウィンドウに出力する Public Sub printOut() As String End Sub '' 自己をObject型で出力する Public Function Object() As Object End Function Class ImplementClass '' InterfaceClassを実装する Implements InterfaceClass '' スーパークラスのGet,Letのため、 '' 値を保持しておくためのプロパティ Private prop As String '' Getter Public Property Get InterfaceClass_prop() As String InterfaceClass_prop = prop End Property
続きを読む

SUPERHOTがいかにSUPERHOTか語りたい

イメージ
注意 ただの感想の垂れ流しです 全世界が驚愕した待望したゲーム性 SUPER HOT は、今までで3作でている。 SUPER HOT （以下SUPERHOT） SUPER HOT VR（以下VR） SUPER HOT : MIND CONTROL DELETE（以下DELETE） SUPERHOTは2013年にKickStarterでクラウンドファンディングされて、見事成立させできたゲームだ。 このゲーム性は、シンプルかつ非常に魅力的なものだった。 「自分が動いている間だけ時間が進む。自分が動かなければ（ほとんど）すべてが止まる」 映画MATRIXの有名な場面のように 弾丸が止まって見える を体現したゲームだったのだ。 死角から弾丸が発射されても、軌道を見てから紙一重で避けて、反撃する。そんな映画みたいな演出を実体験できる。 ブラウザでできるプロトタイプからそれが実現できていた。 プロトタイプを再生する-SUPERHOT クラウンドファンディングが成功して当然のゲームなのだ。 質実剛健なグラフィック SUPERHOTが発売されたものは、グラフィック自体は特に凝っているわけではなかった。すべて３Ｄグラフィックだが、ポリゴンチックで２０１３年当時でもきめ細かいグラフィックとは言えない。 ただ、その表現が非常にゲームとしてシンプルかつ機能美を追求したものだった。 敵は赤色 武器は黒色 ステージなどその他は白色 直感的でゲームを理解できる。そして、敵キャラクターはほとんど同じ造形のポリゴン。ただの記号だ。 ゲームはゲーム。下手な感情移入など不要。そう言わんばかりの作りだ。 先の「映画的な楽しみ方」を１００％没頭させるゲームなのだ。 シンプルなゲーム性に高い戦略性 しかし、一言でいうとこのゲーム「死にゲー」である。 ルールハシンプルだが、かなりの高い戦略性を求められる。 1対1で射撃戦を講じるなら余裕だろう。しかし、このゲーム敵がわんさか出て、１対多を必然的に求められる。 ３６０度どこから弾丸が飛んでくるか分からない。故に、全体を見渡しての状況把握が必要となる。 そうやって視点を動かしている間に背後を取られる、などというのもしばしば起こる。 そして、「ゲームオーバー」 さながら、ワンマンアーミーの過酷さ
続きを読む