「CEOに身代金を要求したい」
こんにちは、PSIRTマネージャのただただし(tdtds)です。この記事はfreee Developers Advent Calendar 2021 18日目です。
freeeにjoinしてから早くも14ヶ月がすぎました。freeeでは毎年10月に全社障害訓練をしていて、昨年は入社したてで右も左もわからないままAWS上の本番環境(のレプリカ)に侵入してDBをぶっ壊す役目をさせられたのも良い思い出です*1。
で、上の「CEOに身代金を要求したい」という物騒な相談は、今年の訓練計画の話です。話を持ち掛けてきたのはCIOの土佐。昨年は主要サービスが落ちて、開発チームが対応にあたる中、ビジネスサイドも顧客対応などで訓練参加しましたが、今年はさらに、経営サイドまで巻き込もうというゴール設定がされたわけですね。腕が鳴ります。
![攻撃者がCEOに4BTCを要求している](https://cdn-ak.f.st-hatena.com/images/fotolife/s/sho/20211213/20211213225033.png)
ゴールから考える演習シナリオ
というわけで、このゴールにたどり着く訓練シナリオを考えることになりました。こういうのはゴールから逆算して考えるのが良さそうです。せっかくなので、ガチの標的型攻撃でいきたいと思います。
身代金要求と聞いてまっさきに思い浮かぶのはランサムウェアですが、freeeのようなクラウドネイティブな会社では、社員のローカル端末には一時的なキャッシュがある程度で、失われたら困るようなデータはほとんどないため、ランサムウェアはリアリティがありません。やはり経営陣が一番「お金を払いたくなる」のはAWS上の本番DBでしょう。ターゲットは決まりです。
![本番サーバに侵入してデータを奪取し、DBを破壊する](https://cdn-ak.f.st-hatena.com/images/fotolife/s/sho/20211213/20211213225242.png)
とはいえAWSに侵入するのはかなり骨が折れます。とりわけハードルが高いのは二要素認証です。といいつつ、実はもう、心当たりがありました。セキュリティ屋の常として、日常生活に潜むセキュリティホールを探してしまう癖があるのですが(あるんですよ)、今回の訓練のためにその引き出しから恰好のネタをひとつ提供しましょう。
かねてから、freeeの社内SNSを眺めていて「スマホを機種変したので二要素認証をリセットして欲しい」という依頼がされているのをちょくちょく目撃していました。コロナ禍でほとんどの社員がリモートになる中、リアルに会うことなくこのような依頼を処理せざるをえないとはいえ、もはやfreeeは全社員の顔と名前が一致する規模の会社ではありません。依頼者が本人かどうか、確認するすべはないわけです。つまり、SNS上で誰かになりすませれば、IdPの二要素認証を入手できることになります。
![CITに対して「2FAをリセットして」と依頼している](https://cdn-ak.f.st-hatena.com/images/fotolife/s/sho/20211213/20211213230226.png)
次に解決すべきはSNSへの侵入手段になりました。ちょうどそのころ、Electronic Arts社がSlackのセッション情報を盗まれる事件がありました。これをそのまま使いましょう。訓練に時事ネタを入れるのはリアリティアップになります。freeeのほとんどの開発者が使っているGoogle Chromeは、セッション情報を含むcookieを、特定のパスにあるsqlite形式のファイルに保存していて、暗号化されているそれを抜き出す方法も公知になっています。暗号解読用のキーはmacOSではkeychainに入っています。そうそう、IdPへのパスワードも一緒にkeychainから抜き出せれば、本番環境への侵入に必要な情報はすべて揃います。
![被害者の端末がCookiesとパスワードを送信している様子](https://cdn-ak.f.st-hatena.com/images/fotolife/s/sho/20211213/20211213230526.png)
こうして、残るはターゲットにした開発者の端末への侵入するだけになりました。それも侵入するだけでなく、怪しまれることなくkeychainのパスワードを入力させる必要があります。ここではサプライチェーン攻撃を使いましょう。開発者がよく使うツールが、いつのまにかマルウェア化していたという想定です。
今回はそのツールを自作することにしました。本体は無害だけど、依存先のライブラリが乗っ取られていて、そこからマルウェアの侵入を許すという、過去にも実際に悪用されたことのある手法を模倣します。ツールの実行時ではなく、インストール時にkeychainにアクセスし、ユーザにパスワード入力を促します。誰にも身に覚えがあると思いますが、インストール時に特別な権限を要求されることはよくあります。よくありすぎて、多くの人は何も考えずにパスワードを入力してしまうシチュエーションです。
さらにこのマルウェアは、crontabにバックドアを仕込みます。攻撃者が待ち構えるC2サーバ*2へ接続しにいくリバースシェル*3です。インストール時に直接接続しにいかないのがポイントです。インストール時にアウトバウンド接続を試みるふるまいはAntiVirusやEDRを警戒させる傾向があるので、時間差で別プロセスから接続する方がばれにくいのです。そしてcronに仕込むことで端末を再起動されても再接続されます。実際、今回の侵入プロセスで、freeeのEDRはいっさい反応しませんでした。というか、反応しない手法だけを選んで作っているわけですが。
![攻撃者がマルウェアを配備して被害者に送り付ける様子](https://cdn-ak.f.st-hatena.com/images/fotolife/s/sho/20211213/20211213230730.png)
こうして、
- ツールの導入とともにcookieとパスワードを盗み出し、リバースシェルでC2サーバに接続
- cookieからセッションを復元して社内SNSへ侵入
- 社員になりすまして二要素認証をリセットし、自分のスマホに二要素認証をセットアップ
- C2サーバから被害者端末に侵入してAWSにログイン
- 本番環境を探し出してDBをダンプして持ち出す
- DBを破壊してから、社内SNSでCEOに脅迫状を出す
という一連の流れを実現できるキルチェーンが構築できました。なにひとつ不自然なところのない、完璧な標的型攻撃シナリオの完成です。ちなみにfreeeがAWSにログインするためにどんな方式を使っていて、どのIdPで二要素認証を実現しているか、社内SNSに何を使っているかなども、すべて公開されている情報から得られることを検証してあります。OSINT*4という技法です。
障害訓練スタート!
さて、こうしてできたシナリオは、去る10月28日に実行に移されました。
社内には「10/28に何かが起きること」「本番環境としてある試験環境が使われること」だけが周知されています。オペレーションはPSIRTのメンバが、自宅からわざわざ普段と別のネットワークを経由して、自分自身を攻撃することで実行しました。一般的に「サイバー演習」では破壊行為まではしませんが、今回の主眼は「障害訓練」なので、模擬環境とはいえ実際に障害を起こすところまで実施します。想定通りに本番DBへ侵入してまんまとデータを盗み出し、ご丁寧にバックアップまですべて消し去ってしまいました。PSIRTやSREは、業務上とても強い権限を持っているので、やれることは全部やった感じです。容赦ない。
![【訓練】佐々木さん、こんにちは。あなたの従業員のアカウントをハックした。あなたの会社のデータベースからデータを抽出し、データベースを破壊しました。データの拡散を防ぐため、明日の13時までに4BTCを入金してください。データのサンプルを添付する。あなたの大切な友人より。](https://cdn-ak.f.st-hatena.com/images/fotolife/s/sho/20211214/20211214110548.png)
社内は大混乱です。開発チームは通常のインシデント対応にならい、次々と不調になるサービスの対応にかかりきりになります。同時に脅迫状を送られた経営陣も極秘の検討グループを立ち上げたので、両者はしばらくディスコミュニケーション状態になりました。相反する決定が行われたり、一方がすでに知っていることを他方が調べ続けていたり等、交通整理役ができるまで混乱は続きました。
とくに難しかったのは、攻撃者や攻撃ルートの特定です。なりすましは完璧なので、犯行が内部犯なの外部からの攻撃なのかは、すぐには見分けがつきません。侵入経路はリバースシェルなので、外部から直接の侵入形跡すらないのですから。問題のアカウントがPSIRTメンバのものだったので、なぜかPSIRTが全員疑われて障害対応から締め出されそうになるなど、はたから見ているとまるでコメディのようでした。
それでも破壊されたDBは各所からデータをかき集めると数時間で復旧できることが判明したり、身代金は払わずちゃんと警察に届け出る選択をするなど、想定外だったり想定内だったりのさまざまな成果をあげて、訓練は無事(?)終了しました。
訓練を終えて
昨年の訓練でもそうでしたが、すぐに現場が自発的な改善活動にとりかかるのはfreeeのいいところです。とくに二要素認証のリセットに関しては、本人確認プロセスを追加する対策が訓練翌日に追加され、いまでは今回のシナリオを実行するのは不可能になりました。苦労して作ったシナリオがすぐ陳腐化してしまうのは嬉しくもあり、寂しくもあり。また、大規模障害時のコミュニケーションについても、効率よく交通整理を行う方法が検討され始めています。
サービスが依存しているライブラリやフレームワークの安全性をどう担保するかについても、開発組織をあげての取り組みが始まりそうです。以前から脆弱性管理の仕組みはあったのですが、こういうものは開発者全員の意識が高くないと継続的な運用にはつながりません。訓練を通じてそういう雰囲気を醸成できたのも、今回の大きな成果ではないかと思います。
![障害訓練から疑心暗鬼に陥っているので 正直に答えていいものか悩んでいる (by shinichiro matsuzawa)](https://cdn-ak.f.st-hatena.com/images/fotolife/s/sho/20211210/20211210185350.png)
ともあれ、多くの社員にトラウマを残す、とてもいい訓練になったようです。みんな、セキュリティ意識が高まりましたね!
この話は攻撃に参加したPSIRTのtaichiと一緒に、明後日12/20(月)に行われるfreee Tech Nightでもお話する予定です。よかったら参加してみてください!
追記: 本編のアーカイブあります
PSIRTでは仲間を募集中!
今回のような、身内を攻撃することを通じてセキュリティ向上に取り組む人たちのことを「Red Team」と呼びます。私は、freeeくらいの規模の事業会社は自前のRed Teamを持つべきだと考えていて、PSIRTの中に常時稼働する本物のRed Teamを作り上げるのが当面の目標です。もちろんそのためには、攻撃を受けて立つBlue Teamも必要です。Red / Blue Teamを作ってみたい方、セキュリティ未経験でもOKです、一緒に働いてみませんか!
明日は shallow1729 さんが MySQL の話をしてくれます。お楽しみに!
*1:漫画の力でリモート下の障害訓練をモチベートせよ で描かれたルカワくん役をやりました。
*2:Command and Control server。攻撃者がリモートから侵入先の端末を操作するためにつかうホスト。
*3:reverse shell。接続の方向が一般的とは逆向き(内→外)になっているリモートシェルの一種。
*4:Open Source INTelligence。公開された情報だけを使って行う偵察・諜報活動のこと。