Fox on Security

セキュリティリサーチャー(インシデントアナリスト)で、セキュリティコンサルタントのキタきつねの独り言。専門はPCI DSS。諸々のお問合せ(取材、執筆、各種お問合せ等)はフォックスエスタ (https://foxestar.hatenablog.com/)をご覧ください。

イオンカードの不正利用

このニュースを聞いた時に思ったのが、小さなECサイトとは違い一定以上のセキュリティ対策を実装している(であろう)金融系の会社でも結構な被害が出てしまうのか・・・という事でした。

www.nikkei.com

 

 

■公式発表 インターネットサービス「暮らしのマネーサイト」での不正ログイン発生のお知らせおよびパスワード変更のお願いについて

 

イオンマークのカード会員さま向けインターネットサービスの「暮らしのマネーサイト」およびスマートフォンアプリの「イオンウォレット」において、外部で不正に取得したと思われるID・パスワードを使った“なりすまし”による不正ログインが発生し、カード会員さまの情報が第三者によって閲覧された可能性、および一部会員さまの情報が改ざんされていたことが判明しました。今後の調査の進捗により対象件数や状況は変動する可能性がありますが、現時点で判明している事実と対応状況についてご報告いたします。

このたびの不正ログインは、2019年5月28日から6月3日までの間、ID・パスワードを使った“なりすまし”により行われたもので、1,917名のカード会員さまが不正ログインされた可能性があることが確認されました。そのうち、一部のカード会員さまにつきましては、不正ログイン後に登録電話番号が改ざんされ、スマートフォン決済アプリへの登録・認証に使用され、カードが不正利用されていることが確認されております。

(公式発表より引用)

 

◆キタきつねの所感

事件の公式リリースの方を見てみると、

f:id:foxcafelate:20190615065558p:plain

短期間(6日間)に攻撃を受けていた様です。不正ログインが成功した1,917件を6日で割ると、1日あたり320件弱となります。(想像ですが)パスワードリスト攻撃であればログイン失敗がかなり出てくると思うので、検知が出来る可能性もありますが、フィッシングが起因の様なリリースも出ているので、900万以上の会員数を持つ事から考えると、防衛側が気づきにくい攻撃であった事が想像されます。

ここまでであれば、個人情報閲覧(の可能性による個人情報漏洩事件)だけで終わったと思いますが、イオングループの場合、その他のアプリとの連携もスムーズだったので、

 

一部のカード会員さまにつきましては、不正ログイン後に登録電話番号が改ざんされ、スマートフォン決済アプリへの登録・認証に使用され、カードが不正利用されていることが確認されております。

(公式発表より引用)

 

カード不正利用の被害まで達した様です。私の理解では、、、

 

「暮らしのマネーサイト」へ不正アクセス ※IDとパスは外部で漏洩

>「暮らしのマネーサイト」の登録携帯番号を不正変更 

>「イオンウォレット」新規登録 

>「暮らしのマネーサイト」登録携帯電話番号に認証確認 

>「イオンウォレット」ショッピングで不正利用

 

という感じの構図でしょうか。ショッピングは換金性の高い金券か、家電でも買われたのかと思いますが、この構図だとすると、事件規模が大きくなった問題点は2つ考えられると思います。※今回記事は長いです

 

1つはユーザ側のミスです。ほぼ間違いなくフィッシングに引っかかっています。

 

イオンカードのリリースを見ると、今回の不正アクセスについての事件リリース(6/13)と、明らかにそれに関係したと思われる『フィッシング注意』のリリース(6/14)が並んでいます。

f:id:foxcafelate:20190615064600p:plain

 

中を見ると・・・電子メールやSMSで偽画面に誘導され認証情報を窃取されない様にご注意下さい。というフィッシングメールに対するリリースを出すまでの何ががあった事を受けての注意喚起です。

 

f:id:foxcafelate:20190615071552p:plain

 

イオンカードの通常の注意喚起に、今回のフィッシングメールとも類似しているのかと思われる内容(分かりやすい例示)がありましたので引用しますと、

f:id:foxcafelate:20190615072136p:plain

 

イオンクレジットサービスのカード申込画面に酷似したサイトやイオンスクエアメンバーの会員規約を利用しID/PWを入力させるサイトにご注意ください

 

まったく同じフィッシングメールではないかも知れませんが、2019年4月のイオンカードの注意喚起では、フィッシングメールが飛んできて、

f:id:foxcafelate:20190615072521p:plain

 

ひっかかってしまう(カード情報を入力してしまう)方が結構いたのだろうな・・・と推測させる、注意喚起となっていました。

f:id:foxcafelate:20190615072557p:plain

 

1つ目の問題点であるフィッシングにユーザがひっかかる点について、イオン側には恐らく責は無いと思います。ユーザ=お客様でもあるのでイオン側は強く言えないかと思いますが、ユーザ側のレベルがあまり良くなかったので、この手のフィッシングに引っかかったというのが事件の起因である事は間違いない様です。

今回のフィッシング文面はもっとひっかかりやすい内容だったかも知れませんが、会員数が多ければ一定数のユーザがひっかかる場合があるのは仕方が無い事だと(個人的には)思います。

 

2つ目の問題。

イオン側の不正ログインへの検知ですが、総当たりやパスワードリスト攻撃ではなかった様に思えますので、AI検知(リスクベースや振る舞い検知)などが実装されて無ければ、正常のログイン試行とほぼ同じで、ログインエラーも多くなかったとすれば、防げないのは仕方が無いかなと思います。

では何が2つ目の問題かと言うと、携帯電話番号の不正変更部分です。推測になりますが、ここが簡単にできてしまったとすれば、イオン側の対策の甘さが指摘されても仕方が無い気がします。

最近では(私が登録している)多くのサイトでは、携帯番号あるいは登録メールアドレスが変更になった際に、追加認証で携帯番号にSMSが飛んできたり、登録メールアドレスにメールが飛んできます。

重要情報の変更に関してユーザ側に知らせる。もちろんユーザ側が気づかない事は多々あるかも知れませんが、大規模な攻撃を仕掛けられた場合、この対策がしっかりしているだけで、早い段階で攻撃を止められる可能性が高くなります。

登録変更(申請)を一時保留し、登録携帯番号へのSMSや登録メールアドレスからの承認手続きをする、とシステムを変更(本人認証を強く)してもスマホ買い替えなどは頻繁(日常的)には発生しないのでユーザ側の利便性が落ちる事は無いかと思います。

 

問題点という訳ではありませんし、単なる結果論ですが、イオンGとしては、あまりにもグループ内のシステムが連動しすぎていて(便利になりすぎていて)換金性が高い商品にたどり着けるルートの検証(シナリオテスト)がおろそかになっていたのかな、という事も感じます。

IDとパスワードに頼った会員サイトは、破られる危険性があるという前提でシステムを見直しする(追加認証をどこにかけるか、あるいは検知対策を裏で考える等々)事が必要ではないでしょうか。

 

 

余談です。やはり「システムメンテナンス」が掲載されています

 

f:id:foxcafelate:20190615062510p:plain

 

 

しかし、それ以上に気になったのが、今回の事件とは直接の関係性は無いのですが、URLです

f:id:foxcafelate:20190615075551p:plain

 

 

「.do」つまり、公式サポートが2013年に切れているApache Struts1を使っている

と推測されます。

 

 

イオン程の大企業ですので、外部のサポートベンダーにStruts1のサポートをさせている、あるいは内部のIT技術者さんらが安全性を十分に確認しているのだとは思いますが、Struts2でも大きな事件(GMO-PG、ぴあ、Equifax等々)が発生した様に、オープンソースフレームワークは外部から狙われる対象であるだけでなく、脆弱性が頻繁に出てくるものもあります。

 

例えばIPAは、Struts1は『知りません』(※自社のリスクですよ・・・)というスタンスです。

f:id:foxcafelate:20190615075952p:plain

なお、このページで対象とするのは「Apache Struts 2」 です。「Apache Struts 1」は既に2013年4月5日を以ってサポートが終了しているため対象外としています。

 

 

もっと古い記事(2016年)では、もっとはっきりとIPAは言い切っています。

scan.netsecurity.ne.jp

 

また、15件のうちApache Struts 1が影響を受ける脆弱性対策情報は2件であったが、すでに公式サポートが終了しているため、通常は脆弱性対策情報は公開されない。IPAでは、早急にApache Struts 2や他のフレームワークなどに切り替えることを検討する必要があるとしている。

(ScanNetSecurity記事より引用)

 

例えればWindowsXPをずっと使っている様な状態であり、もっと深刻な(0ディ)脆弱性が出た場合に、Apache公式サポートが既に無い訳ですから、かなりの影響が出てしまう可能性があるのではないでしょうか。

 

システム変更には大きな痛みを伴うのかも知れませんが、早期に(サポートが有効な)フレームへの移行が必要ではないかと考えます。

 

f:id:foxcafelate:20190615081339p:plain

 

更新履歴

  • 2019年6月15日AM(予約投稿)