【7pay、Omni7問題】企業、利用者、メディア、エンジニアは何を教訓にすべきか：「今知りたい！ システムを守る認証の実態」セミナー（2/2 ページ）

[宮田健，＠IT]

セキュリティ診断事業者から見た、認証における課題と対策

セキュアスカイテクノロジー 取締役CTO はせがわようすけ氏

　セキュアスカイテクノロジー 取締役CTO（最高技術責任者）の、はせがわようすけ氏は、同社が行っているセキュリティ診断や、国内に設置されたWAF（Web Application Firewall）の検知状況から見た、認証に関する現状の課題を解説した。

　はせがわ氏もやはり、パスワードリスト攻撃に注目する。これまでパスワードリスト攻撃の被害に遭った企業組織において、不正ログインの試行件数と成立件数から「不正ログインの成功率」をチェックしたところ、「0.44〜9.98％の成功率であることが分かった」（はせがわ氏）という。はせがわ氏は独立行政法人 情報処理推進機構（IPA）が2014年に調査した「オンライン本人認証方式の実態調査報告書」（PDF）で、「複数のサービスサイトで同一のパスワードを利用していると回答している利用者が25.4％いる」と記載されていることに着目。実際の攻撃では、それよりも低い数値が出ていることに関して、「そもそもそのログインIDが存在していないことが多い」と述べる。

「パスワードリスト攻撃による不正ログイン防止に向けた呼びかけ」（IPA）から引用した不正ログイン成功率。C社が突出して多いものの、ほとんどが10％以下の成功率だった

　ところが2018年6月、日本国内のECサイトで発生した不正アクセスによる情報漏えいでは、1938件のログイン試行に対し490件が成功、実に攻撃成功率は25％という高い値をたたき出した事案が発生する。これはまさに、IPAによるパスワード再利用率に近い数値だ。この攻撃は、事前に新規登録機能の二重防止機能を利用することで、リストのスクリーニングを行っていたことが、その後のECサイト側の調査報告書で分かったという。

　このことから、はせがわ氏は「たとえサービス提供者が脆弱（ぜいじゃく）性診断を実施したからといって、アプリケーションの全機能が検査されるわけではない。一部の機能のみを検査する場合もあるため、『脆弱性診断を実施した』ことがあっても、安全であるわけではない」と指摘。特に既存機能にサービスを追加し、あらためて脆弱性診断を行う際に、既存機能は診断対象から外される傾向が強いという。

　「例えば当初、ポイント情報とカード会員番号程度の情報を扱っていたポイント管理システムを稼働させていたサービス提供者が、その後、個人情報をひも付けてクレジットカードのような決済機能を追加した場合も、新たに作成した部分だけが脆弱性検査の対象になると、システム全体の脆弱性が残っていることに気が付けない可能性がある」（はせがわ氏）

　はせがわ氏は、企業ができる対策として「企画段階からセキュリティを意識した分析、設計を考える」「脆弱性診断において重要な機能を診断対象から外さない」「基礎的で地道な対策の積み重ねが、攻撃コストの引き上げにつながる」としていた。

特定のサービスを対象としたものではないが、システムの拡張／追加開発により、脆弱性検査の対象外になるエリアが残る可能性がないか、気を付けなくてはならない

その裏には“被害者がいる”？　脆弱性情報の取り扱い方

　今回のセミナーは、JNSAが認証の現状とその技術的な背景を解説するために、記者に向け開催されたものだった。その中でココンの林氏は、「どうしても伝えたい」ことを講演冒頭に語っていた。それは記者、メディアが脆弱性情報をどう伝えるべきなのかという点だった。

　2019年7月11日、セブン−イレブンアプリの一部としてリリースされていた「7pay」のインシデントに関して、セブン・ペイおよびセブン＆アイ・ホールディングスが運営する「Omni7」などが「【重要なお知らせ】アプリサービスでの外部ID利用によるログイン一時停止について」を公開した。林氏が問題視したのは、この正式な報の数時間前に、メディアの報道が先行していたことだ。林氏はOmni7が公開したURLに「190712」が含まれることから、「本来は各関係機関と調整した上で、翌7月12日に停止の報が出るはずだったのではないか」と指摘する。

Omni7が2019年7月11日に公開した「【重要なお知らせ】アプリサービスでの外部ID利用によるログイン一時停止について」のURL「https://www.omni7.jp/general/static/info190712」

　この情報のリーク元ははっきりしない。また、脆弱性が存在していることを隠すことによる安全性確保は無意味であることに間違いはないだろう。しかし林氏は、おそらくこのお知らせを出すために、必死にコーディネーションを行っていたのではないかと推測する。

　「どこに脆弱性があったのかは、お知らせのタイトルを見ればある程度分かるだろう。停止してからちゃんと公表しようとしていた脆弱性の情報を、前倒しして公開したということについて、メディア側はもう少し注意してほしい。外部連携先などと必死に頑張ってコーディネーションしている人の作業が台無しになってしまったのではないか」（林氏）

　この点に関しては、“情報発信者”としての責任をもう一度考える必要があるのではないだろうか。メディアの一員である筆者や＠IT編集部はもちろん、SNSやブログなどを活用しているエンジニアも同様に考えてほしい。今回の件で、エンジニアもSNSやブログなどで多くの情報や臆測を発信していた。脆弱性に関する情報は、公開の仕方を間違えると、露出する情報によっては、“人の人生を左右しかねない”可能性を持っている。「消費者保護の観点でどのように情報を扱っていくべきか」「それが単なるゴシップ的な側面での独りよがりな発信になっていないか」は常に考えるべきポイントといえるだろう。

　なお、もしもWebサイトやアプリなどに脆弱性を発見した場合は、SNSやブログに投稿する前に、下記、IPAやJPCERT/CCが運用している脆弱性情報ハンドリングのフローに従い、報告を行うように心掛けてほしい。

• 脆弱性関連情報の届出受付：IPA 独立行政法人 情報処理推進機構
• JPCERT コーディネーションセンター 脆弱性対策情報