S2-045の3回目としてS2-045のまとめを記事にします。
S2-045の脆弱性については今までのセキュリティ対策を考えさせられるきっかけになった脆弱性かと思います。
勉強会でもそういった内容をメインに話してきました。
なお、記事の内容については個人的見解であることをあらかじめご了承ください。
脆弱性が公開されてからの速さ
まずは何と言っても脆弱性が公開されてから、攻撃が行われるまでの速さがすごかったですね。
日本で結構大きなニュースにもなったGMOPGを例に確認していきましょう。
以下のURLを参考に確認します。なお記載の日付は全て2017年になります。
https://corp.gmo-pg.com/newsroom/pdf/170501_gmo_pg_ir-kaiji-02.pdf
・3/7：Githubで攻撃コード公開
・3/8：保険特約料支払いサイトへ攻撃開始⇒その後すぐにバックドアファイルが設置される
上記の通り、脆弱性の公表から攻撃までのスピードが物凄く速いです。2日に見えますが、時間を確認すると1日半位です。
GMOPGの担当者が脆弱性情報を受信（外部サービスから）する前に攻撃が成功されてしまっています。
GMOPGの対応はどうだったのか？
さて、次にGMOPGの対応について見てみましょう。同じURLで確認していきます。
3/9：脆弱性のWAFによる遮断の開始、その後すぐApache Struts2が稼働しているサービス停止
3/10：日付が切り替わってすぐにパッチ適応を実施
上記のとおり、GMOPGの対応については攻撃されていたこともあったかと思いますが、かなり早いタイミングで対応しています。
※対応自体はほぼ3日で行っています。
ちなみに以下の最新版のPCI DSS（Payment Card Industry Data Security Standard）の最新版である3.2.1でも以下のように記載されています。（PCI DSS要件6.2の個所）
以下は参考URL
https://ja.pcisecuritystandards.org/_onelink_/pcisecurity/en2ja/minisite/en/docs/PCI_DSS_v3%202_JA-JP_20180801.pdf
しかしGMOPGは大規模な情報漏洩に発展をしてしまいました。
クレジットカード番号6万件以上です。
この事件を非難するのは簡単ですが、この事件をきっかけに今後同じようにならないためにどうすれば良いかをしっかり考える必要があります。
今後どうすればいいのだろう？
決断（サーバを停止等の判断）をする際に運用を外部ベンダー等に任せっきりだとこういった際に判断が遅れ、被害につながる可能性が高いです。
なので、運用自体は任せていても、自社のサーバで使用されているフレームワーク(今回であればstruts2)やミドルウェア等のバージョンや脆弱性情報を常に監視し、危険な場合はすぐに対応（指示）できる体制になっていないと今後は危ないかと思います。
※脆弱性公開から攻撃までのスピードが物凄い速いので
現場に権限がない場合は、上司に相談やそこからさらに上層部への展開等、どんどん脆弱性の対応に時間がかかる可能性があります。
日本企業を批判するわけではないですが、大企業の役員の方々達が、フレームワークであるStrutsは自社で使用していても、もちろん知らないと思いますし。
そもそも、OSコマンドインジェクションやよく聞くSQLインジェクションだった、言葉自体を聞いたことがない人が多いのではないでしょうか。（個人的意見が物凄い入っています。）
CSIRTとかは今後、どこの会社にも必要になっていくと思いますが、本当にちゃんと機能できる会社が増えていくまでには、日本ではまだ時間がかかるんだろうなと思います。
こういった内容を以下の勉強会で話してきました。こんな長くはないですが、もう少し要点をまとめた形です。
今後も脆弱性自体のデモであったり、それに起因するインシデントの事件の話だったりを勉強会やブログでしていく予定ですので、応援して頂けると幸いです。
不明点や要望やこういったこともやって欲しいとの要望があれば、お問い合わせページやコメント、ツイッターからでも結構ですので、気軽にご連絡ください。
コメント