【情報システム部 活動報告】Ｓｋｙ情シス通信Hardening 2024 Convolutions参加レポート

15チームが競った
熾烈を極めるサイバー攻撃との戦い！

【事前準備】 10月の競技会に向けた戦いは8月から始まる！

➊ 無事に選考を通過

応募フォーマットに熱く意気込みをつづった結果、二人とも無事に選考を通過することができました。そう、選考を通過しなければ、大会には出場できません。例年募集開始は7月です。気になる方はHardening Project公式Xアカウントをフォローしましょう。

❷ チームビルディングの実施

運営の方々によってチーム分けが行われ、2024年は全15チームで競うことになりました。私が配属されたのは、ミギーのほか歴戦のエンジニアや広報部門の方、大学生などさまざまな背景を持つ7人構成のチーム。ミギー以外、初参加のメンバーです。8月中旬のチーム発表の後、10月の本戦に向けてどのチームもほぼ毎週オンラインでチームビルディングを実施。私たちは、毎週火曜日の21時から全員参加で行いました。

❸ 相互理解と役割分担

お互いのことを何も知らない状態からスタートするため、まずはそれぞれの得意分野を申告したり、担当している業務について報告する相互理解からスタート。各自が競技で力を発揮できるよう、スキルチェックシートを活用して役割分担を決めることにしました。ハードニング競技会は、技術力だけでなく、ビジネスを衛る力も採点の対象です。そのため、攻撃が行われている間にも各チームでECサイトの売上を競います。当然、在庫管理や発注を担当するメンバーも必要です。私はインフラ統括者として、Active Directoryユーザーのパスワードを一括で変更するスクリプトの作成や、DNSサーバー（BIND）の構築、VyOSの動作検証、MySQLのバックアップ用シェルスクリプト作成など技術面を担当することになりました。

❹ サイバー攻撃対策のリストアップとスクリプトの準備

競技会中にどのような攻撃が行われるかを想定し、事前の対応が可能な対策と、攻撃が成功してしまった場合の対処方法を検討。過去2回この競技会に参加した経験を持つミギーの意見も参考にして、ランサムウェア攻撃に備えたバックアップや復旧の手順などを確認しました。

❺ 競技会当日に使用する資料の準備

対策や対応が固まってきたら、競技会で実際に活用するスクリプトファイルや資料を作成します。資料の中には、稟議書やインシデント報告書も。そして、情報漏洩が発生してしまった際には、関係機関への報告書の提出も必要です。さらに、運営から呼び出されて経営層への報告が求められる可能性もあり、誰がその役割を担うのかも決めておかなければなりません。競技会当日は、サイバー攻撃からビジネスを衛る際、求められる内容をたっぷり体験できます。

• ※ 「ひよこまめ教習所」ハンズオントレーニングのご紹介はこちら

【競技会直前】 競技会3日前の衝撃！！

競技会3日前に知った予想外の展開

ハードニング競技会では、毎年新しい試みが実施されます。今年もいくつかありましたが、私にとっては3チームで一つの連合を組む「JV（ジョイントベンチャー）」という仕組みが衝撃でした。競技会3日前に配布された資料（例年は前日配布）に書かれていたのは、「3つのチームで一つのJVを形成する連合形式を取り入れる」「優勝は、最優秀JVの中で、総合売上が最も高いチームの中から決まる」ということ。そして「JV共有で管理するサーバー」の存在です……。 過去の大会よりも衛る対象が増えた衝撃を感じる間もなく、急いで自チームのJV担当を決めなければなりません。チームリーダーをほかのメンバーに押しつけてしまったような気がしていたため、JV担当には自ら立候補しました。そして、すぐさまJVを組むことになったほかの2チームの担当者と打ち合わせを実施。現役のCSIRTメンバーで、過去2回の競技会経験のある私がJV代表を務めることになりました。初回の打ち合わせは、基本方針と競技会当日までに決めることを話し合い、1時間で終了。

競技会前日

チームメンバーが一堂に会し、各自がこれまでに準備してきたことを確認。私はインフラを担当する学生さんとファイアウォールの設定等について話し合ったのですが、結局、事前準備は夜中の2時までかかりました……。また、同じJVのほかの2チームの代表と、初動対応についての認識合わせも実施。できることは、ほぼやったつもりで本番に臨みました。

【競技会当日】 ついに競技会当日。8時間の戦いが始まる

情報漏洩を指摘したメールが届く

競技中、下記のようなメールが届きました。

どうやらファイルサーバーが外部に公開されてしまっていたようです。自チームでは、ファイルサーバーから当該ファイルをすでに削除していたため、待避させたファイルを確認したところ、報告者の情報は含まれていませんでした。JV連合の2チームにも確認してみると、1チームは同じ状況。もう1チームは、問い合わせた時点ではまだ当該ファイルが外部から閲覧可能でしたが、そのファイルにも報告者の情報は見つかりませんでした。 そこで、報告者にはここまでの調査結果を返信して、本件は終了。われながら、JVの代表としてうまく立ち回れたと思っていました。このレポートを作成するまでは……。

報告者の本当の目的は？

本レポート作成のため、あらためて冷静になって当時のやりとりを見返すと、競技会中には気づかなかった怪しい文字が目に留まりました。こちらから送ったメールに返信された送信元には「kuromame6」の記載が。「kuromame6」とは、ハードニング競技会での攻撃者の名称です。報告者からの最初のアクションは、問い合わせ用のフォームからだったため、送信元メールアドレスやIPアドレスは判別できません。そして、すでに当時の環境が残っていないため、一連のやりとりを攻撃メールだと判別することはできませんでした。しかし、一般的に問い合わせフォームは攻撃の標的にされやすく、脆弱性対策が欠かせない対象です。おそらく何か起こっていただろうことは想像に難くありません。競技会には手遅れですが、自社での対策は間に合います。弊社のWebサイトには問い合わせフォームが各種存在しますので、早速担当者へ対策に漏れがないか確認するよう連絡しておきました。

対策を練って挑んだランサムウェア攻撃。結果は？

各チームには、衛るべきECサイトが3つ（ショップが3つ）割り当てられています。そこに対してランサムウェア攻撃が行われることは想定済みです。しかし、攻撃されたタイミングでは、まだデータベースのバックアップが完了していなかったため、復旧できず……。さらに想定外だったのは、同じECサイトが再びランサムウェアの被害に遭ったことです。ようやくバックアップが完了したと喜んだのもつかの間。バックアップデータも暗号化されていました……。ランサムウェアあるあるです。 一方で2度も攻撃しておいて、なぜか攻撃者からはその後の脅迫や要求がなかったのをラッキーだと思っていました。これには裏話があって、DNS（Domain Name System）の設定ミスが原因で、本来届いているハズのメールが届いていなかったのです……。

JVサーバーでやってしまった自爆

パスワードを初期設定から変更することは、とても重要です。もちろん、データベースに対しても同様ですが、競技会という特殊な状況を考慮すると、変更によるECサイトへの影響が気になります。そこで、JVサーバーのデータベースのパスワードは変更しないことにしましたが、代わりに外部からの3306ポート宛て通信をiptablesコマンドでブロックしました（iptables -A INPUT -p tcp --dport 3306 -j DROP）。 すると、ECサイトにアクセスできなくなるトラブルが発生！ECサイト自身がDBへアクセスする通信もブロックしてしまったようです。急いで「127.0.0.1から送信され、宛先ポートが3306であるパケットを許可するコマンドを追加（iptables -A INPUT -s 127.0.0.1/32 -p tcp --dport 3306 -j ACCEPT）」して無事に解決できましたが、ほかのメンバーをハラハラさせてしまいました。

ほかにもさまざまな攻撃や自爆が怒濤のように押し寄せ、必死に対応しました。そして、気がついたときには終了の合図が……。こうして私たちの8時間が終わりを告げました。

【競技会3日目】 3日目の発表・報告・表彰イベント「Softening Day」

サーバーの一つにWebShellが置かれていた

存在に気づくことができませんでした。今回は置かれていただけで攻撃に使用されることはありませんでしたが、サイバー攻撃でよく使われているにもかかわらず、意識できていなかったことが悔やまれます。

ユーザー権限の見直しに対応漏れ

Administrator以外のユーザー権限を普通のユーザー権限に修正したつもりだったのですが、対応漏れが……。残念ながら、自分たちで気づくことはできず。不要な管理者権限をそのままにしておくことは、非常に危険です。また、ブロードバンドルーターのパスワード変更には手が回りませんでした。どちらもしっかり対応できているチームもあったので、ここでポイントが取れなかったことが悔やまれます。

プレスリリースの下書きファイルが公開状態に

サーバーには運営側が準備して公開された2ページ構成のプレスリリースファイルが置かれていました。特に気にしていなかったのですが、このファイルにも注意点が。公開済みの文中に未公開の3ページ目、下書きファイルへのリンクが貼られていました。公開していない情報に外部からアクセスできる状況が自社で発生していたらと考えるとゾッとしますね。 ある製品のファンの中には、その製品の新バーションのプレスリリース公開前に一足早くこっそり見ることを楽しみにしている人たちがいるそうです。彼らはその企業のプレスリリースファイルの命名規則を知っていて、公開前の下書きファイルを見て楽しんでいるのだとか。これは、公になれば株価に影響するかもしれない事実です。プレスリリースを下書きファイルとしてサーバーに置くことの問題点を認識させられました。弊社の場合、Webサイトに関しては広報部が制作から更新までのすべてを担当しているため、情報システム部は関与していません。この記事をご覧になっている情報システム部門のほとんどの方が同じような状況ではないでしょうか。自社の対応状況を確認しておく必要がありそうです。