Struts2脆弱性を狙ったハッカーと対決した12時間
かなり昔の話なので、あまり参考になる話ではないと思いますが
久しぶりMr.ROBOTという海外ドラマを観ていたら懐かしくなったので記事にしようと思いました。
もう10年くらい前の話なので、経験が浅く根拠のない自信に満ち溢れていた若かりし頃の話なので
あまり参考になりませんがそのときのお話になります。
Struts2脆弱性とは
Apache Struts2で構築されたWebアプリケーションに対して、特定のHTTPリクエストを送信することで
任意のJavaコードが実行することができてしまう。
結果的に任意のOSコマンドや不正プログラムを実行することができてしまいす。
国内におけるStruts2脆弱性による被害の一例
パブリック情報です。
| 被害を受けたサイト | 被害 | 所感 |
|---|---|---|
| 大手メガネ屋さんのオンラインショップ | 個人情報流出の可能性 | 検知遅れ |
| 国土交通省 | 顧客情報流出の可能性 | 検知遅れ |
| 総務省 | 個人情報流出の可能性 | 検知遅れ |
| チケット販売サイト | クレジットカード情報流出の可能性 | 検知遅れ |
ハッカーと対決した12時間の話
ここからは時系列ベースで書いていきます。
保守しているWebサイトの表示が遅い と連絡を受けて調査開始
19:00
Webサイトの表示が遅いといった報告を受けました。
当時はプライベートクラウド上にWebサイトで動かすことが常識だった時代なので
ギリギリのスケールでWebサイト運営することが多く
Webサイト上でちょっと何かがバズるとアクセス集中が発生して
Webサーバのプロセスが重くなることで、Webサイトの表示が遅くなることが多々ありました。
そんなときはWebサーバを再起動して、解決することがほとんどでした。
この日もアクセスログやプロセスを確認し
Webサーバのメモリ使用量の肥大化を確認、とりあえず再起動して様子を見ることに。
状況：
** Webサイトの表示が遅い**
対応：
** Webサーバを再起動して様子をみる**
再起動してもWebサイトの表示速度は改善されないので本格的調査に乗り出す
21:00
再起動してもWebサイトの表示速度は改善されず
Webサーバのメモリ使用量は再び肥大化
アクセスログを確認するもDDoS攻撃を受けているわけでもない。
原因がわかるまではWebサイトがダウンしないように定期的に再起動を繰り返す対応をしていた。
状況：
** Webサイトの表示が遅い問題解決せず**
対応：
** Webサイトのダウンを防ぐ為にWebサーバを定期的に再起動して様子をみる**
対策会議
22:00
当時はStruts2脆弱性はメジャーではなかったので、この攻撃の被害がわからず
管理者と相談した結果、Webサイトを一時的に止めるといった判断にはならず
『Webサイトは止めずに、防衛する』といった判断になった。
各領域に詳しい先輩達にヘルプを要請して
対策会議を実施。
状況：
** Webサイト負荷の原因わからず**
対応：
** 対策会議を行い、対策を練る**
23:00
対策会議での決定事項
・疑わしいIPアドレスをひたすらブロックする
※海外からの利用者はほぼいないので、海外IPアドレスを見つけてはブロックする
・BOTからのアクセスを一時的に封じる
※User-AgentでBOTからのアクセスをわかるようにしているものについては一時的にブロックして負荷を軽減 & アクセスログの蓄積を軽減する
・アクセスログを総なめし、疑わしいアクセスを分析する
・負荷が高まったら再起動は継続して行う
疑わしいアクセスをどう分析するか
全200画面ほどのWebサイトで、一部複雑な機能で細かいGETリクエストが発生するものの
正規表現である程度、アクセスログを機能ごとに分布することができる
アクセスログを機能ごとに分布したときに少数に分布されるアクセスが非常に疑わしい。
こんな機能あった？ ってアクセスが出てくるはず
1アクセスあたりの応答時間は通常1秒以内である。 極端に応答時間が長いリクエストは疑わしい。
状況：
** 状況変わらず**
対応：
** 疑わしいアクセスを分析して対策する**
終電無くなる
24:00
終電がなくなったが、もはやそんなことはどうでもよかったです。
『防衛する』『勝利する』頭の中はそれだけでした。
01:00
Struts2脆弱性を狙った攻撃とバッファオーバーフロー攻撃を同時に受けていた
対策会議での決定事項が徐々に成果を出し始める
Struts2脆弱性を狙った攻撃とバッファオーバーフロー攻撃を同時に受けていたことがわかった。
後者はたぶん囮。
・疑わしいIPアドレスをひたすらブロックする
→ 効果なし
・BOTからのアクセスを一時的に封じる
→ 効果なし
・アクセスログを総なめし、疑わしいアクセスを分析する
→ 『https://****.?redirect:』といったredirect:を含むパターンのリクエストが少数分布していた。
当該のリクエストパターンをmod_rewriteで禁止することで、アクセスをブロック
→ 特定の検索キーワードを使用したアクセスの応答時間が異常に長くスレッドが滞留することでサイト負荷が高くなっていた
（こっちは囮だったっぽい）
当該のリクエストパターンをmod_rewriteで禁止することで、アクセスをブロック
状況：
** 攻撃・負荷の原因を特定**
対応：
** 攻撃・負荷の原因を対策**
攻撃が止んだ
02:00
攻撃が終わったが、もう電車ないじゃん
あれ？ 12時間も対決してないじゃん
いやいや 本当の敵はこれからだ。
03:00
再び攻撃が始まらないか待機。
ここからはひたすらアクセスログと睡魔との戦い。
05:00
始発で上司が会社に到着
労いの言葉をもらえるものだと思っていたら、甘かったです。
上司が驚くべき一言を放つ！
『今テンプレートメールするから報告書いてね』
07:00
報告書を何度も書き直し、OKが出たのがこの時間。
最初に連絡を受けてから12時間経過していました。
状況：
** 最強の敵は上司？**
対応：
** 眠いけどがんばって報告書を書いた**
後日談
セキュリティ会社の調査を受けた
セキュリティ会社の調査を受け、Webサイトへの被害はなかったことが判明。
まさかのSEO対策の為のURL静的化がWebサイトを守っていた。
当時流行していたURL静的化。
動的URLを静的URL化することで、Google対策が有利になるといった昔のSEO手法
『redirect:』の攻撃は、静的URLを動的URLに書き換えられる過程で、無効化されていたためリクエストが末端まで到達していなかった。
※mod_rewriteでアクセスを完全に遮断する前も、mod_rewriteでURLが書き換えられまくった結果、リクエストが空ぶっていた。
直接的に負荷を与えていた囮攻撃は
短いリクエストでも解釈に時間がかかる為、結果的にバッファーオーバーフロー攻撃となるものなので
データへの被害はなかった。
これは我々の大勝利と言っても過言ではないと思う！！！！
この頃は、Struts2脆弱性というワードは有名ではなかったけど
徐々にニュースで見かけるようになり、対策の遅れの恐ろしさを感じました。
当時保守していたWebサイトは被害は受けなかったもののの、ネットワークレベルで二重にも三重にもセキュリティが強化され
難攻不落の堅牢なWebサイトになりました。
ここの管理者は本当にすごかった。
詳細は省きますが、Webサーバそのものにも沢山セキュリティ対策を入れました。
メジャーどころで言えば以下のような対策
・許可しているリクエストパターンのみ実行可能にする
・同じIPアドレスから1秒あたりに受け付けられるリクエスト数を制限
ニュースで沢山、話題になったのにもかかわらず
他のWebサイトで被害が続いたのをニュースで何度も見かけましたが、管理者の対応の遅さ・判断の甘さは本当に怖いと思いました。
結局最後まで当時の上司から労いの言葉はなく
厳しい言葉が続いたが、あの人は今元気にしているのであろうか。
状況：
** 被害なし**
対応：
** 大勝利**
あれから10年くらい経過しているけど、ニュースを探していたら、最近でも被害が発生していることがわかった
自分の中では過去の話なんだけど
割と最近もニュースになっていて驚きました。
Struts2を使用していたら最低限やったほうがいい対策
| 対応 | 対応詳細 | 所感 |
|---|---|---|
| Struts2のバージョンアップ | Struts2は脆弱性が見つかる度に対策版が出るので、対策版が出たらすぐにアップデートする | 脆弱性発覚→対策の流れなので常に攻撃側が先手を取っている |
| Apacheと連携 | Apacheと連携することでWebサーバ到達前に対策 | - |
| mod_security(Apache) | コストがかからない。設定の柔軟性が高い。 | - |
| mod_rewrite(Apache) | 想定しないリクエストの大半は弾ける | - |
| mod_dosdetector(Apache) | 単一IPアドレスからの連続攻撃を自動で遮断してくれる | - |
おしまい