GMOペイメントゲートウェイ社（以下GMOPG）という、クレジット決済代行を取り扱う、
国内最大手の会社がクレジットカード番号を流出させたとして、
3/10以降大きく報道されました。
この事故から、我々エンジニアが学ぶべき事は何でしょうか？
発生した事象について
CVE-2017-5638とはなにか
ファイルアップロードにおけるマルチーパートヘッダーの解釈部分に脆弱性があり、
リモートコード実行（RCE）が可能な状態であったらしい
本投稿の趣旨から外れるので、詳しくは調べていません。
経緯・経過
- 3/6 脆弱性情報が公開されたらしい (Cf. Apache Struts 2における脆弱性 (S2-045、CVE-2017-5638)の被害拡大について )
- 3/8 IPAが情報を掲載 (Cf. Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045) )
- 3/9 JVNが情報を掲載 (Cf. JVNVU#93610402 Apache Struts2 に任意のコードが実行可能な脆弱性 緊急)
- 3/9 GMOPGが調査を開始、同日中に攻撃の可能性を検知し、サイト停止 (Cf. 不正アクセスに関するご報告と情報流出のお詫び )
- 3/10 GMOPGが適時開示 (Cf. 不正アクセスに関するご報告と情報流出のお詫び )
影響
Struts はこれまで何度もリモートコード実行（RCE）脆弱性が見つかっているが、
GMOPGという、決済代行最大手が被害にあったとして、大々的に報じられる事となりました。
※GMOPGがSIしたサイトでの被害であり、
GMOPGのメインビジネスの部分が突破されたわけではないようです。
どうすれば、回避または、被害を軽減できたか
①Lacの報告によれば、このゼロデイ攻撃は、脆弱性情報が公開された直後は、
攻撃試行も成功も少なかったようである。
※徳丸先生から、「ゼロデイではない」とご指摘を受けました。
よくよくかんがえたら確かにゼロデイではなかったので訂正します。
（引用元：Apache Struts 2における脆弱性 (S2-045、CVE-2017-5638)の被害拡大について）
GMOPGは3/10 18:00から調査を開始して、6時間後にはサイト停止の判断をできているので、
3/7から調査を開始できていれば、このような重大インシデントに繋がっていなかった可能性があります。
②Strutsは、JVNによればリモートコード実行脆弱性（RCE)だけで、過去何度も発生させています。
(引用元：JVN iPedia - 脆弱性対策情報データベース)
何度も繰り返し繰り返し同じような脆弱性をだすということは、
・Strutsの開発体制が貧弱か、
・Strutsの設計思想自体がこの脆弱性を排除できないか、
・もしくはその両方
つまり、とても商用で使えないフレームワークであるとも言えます。
※ScutumというWAFの会社は2014年時点でStrutsを「控えめに言ってもどうしようもない」と形容しています。
(Cf. 例えば、Strutsを避ける - WAF Tech Blog ｜ クラウド型 WAFサービス Scutum)
後知恵かもしれませんが、Strutsを利用するという判断自体が間違いだったかもしれません。
我々はエンジニアは、ここから何を学ぶべきか
この常に悪意に晒されるWEB開発世紀末ヒャッハーな世界で、
善良なる小市民である我々はどう自分たちを守るべきでしょうか？
今回の事件から我々が得られる教訓は以下の2点です。
-
脆弱性情報が公開されたらマッハで対策を打てるようにする
- 自社または自分が保守している公開システムで利用しているサードパーティ製のミドルウェア、ライブラリ、フレームワークをすべて把握しておく
- 利用しているサードパーティソフトの脆弱性情報を毎日収集する
※MyJVNはAPIを公開していますので、非常に自動化しやすいと思います。
※Lac社やIPAは、注意喚起情報のRSSを公開しています。
Lac：https://www.lac.co.jp/lacwatch/feed.xml
IPA：https://www.ipa.go.jp/security/rss/info.rdf
-
サードパーティ製品を新たに採用するときは、JVNで過去の脆弱性検出状況を確認する
特に似たような問題を数回起こしているような製品は採用を避ける
最後に
私は仕事柄、GMOPGの担当者と年数回お会いしていますが、
非常に誠実で信頼できる会社だと思っています。
今回の件で評判を大きく落としてしまいましたが、
コアであるオペーレション能力が大きく毀損したわけではありません。
今回の危機を乗り越えてより優れた会社となることを祈ってやみません。