本記事は、LITALICO Advent Calendar 2022のカレンダー2の19日目の記事です。
はじめに
こんにちは。
今年7月に株式会社LITALICOに入社しました、柴田と申します。
新卒でIT業界に入り、プログラマ/システムエンジニア経験は5年目です。
概要
本記事は、マルウェアに感染した場合の
特定・対処方法について、記載したものです。
皆さんは、自分の携わっているプロダクトが
マルウェアに感染してしまった……ということはありますか？
私たちシステムエンジニアは、
様々な言語・フレームワーク・ツールを使いながら、システムを開発しています。
それらは人間によって作られたものであり、従って完全ではありません。
脆弱性は日々報告され、それらの穴を突こうとマルウェアがシステムを狙っています。
セキュリティエンジニアが控えていて、
もしもの時は助けてくれる……なんてことがあれば安心ですが、
実際は、リリース前に脆弱性診断を外部のセキュリティエンジニアに依頼するくらいが
通例ではないでしょうか。
マルウェアの脅威は常にあり、私たちは、
それらを予防する感度だけでなく、
時には実際に対処する必要性を求められる可能性があります。
『もしもプロダクトがマルウェアに感染してしまったら』
『そして、その駆除をしなければならなくなったら』
落ち着いて対処できるようにしたいですよね。
今回は、2021年春頃に国内でも感染が複数観測された
kinsingとkdevtmpfsiを題材に、イメージトレーニングをしてみましょう。
トレーニング
導入
不審なプロセス
2021年、3月1日。
あなたは、プロジェクトマネージャー1人+システムエンジニア3人の
4人チームに在籍するエンジニアです。
全員フルリモートで働いており、
Laravel6を使って、基幹業務系プロダクトを開発しています。
フェーズとしては、リリースを間近に控え、プロダクトはほぼ完成し、
後はよりパフォーマンスを上げるだけ、という状態です。
スペックが本番と同等の検証環境が存在しており、
クライアントの様々な部署のステークホルダーが、最終フィードバックのために自由に触れるよう
検証環境は公開サーバに設置されています。
あなたは、自分が作成したバッチのパフォーマンスを上げるために
ああでもないこうでもない、とキーボードを叩いていました。
気づけば、時間は23時。
最後に検証環境にデプロイして、改善結果を計測して終わろう――
そう思って確認したところ、パフォーマンスが異様に悪くなっていることに気づきます。
コードのせいかと思いましたが、どうやらそうではなさそうです。
「検証環境、なんか重くないですか？」
ちょうど、他にもエンジニアの1人がオンラインだったので、
相談しつつメモリの使用状況を確認します。
すると、見慣れないプロセス「kinsing」と「kdevtmpfsi」により、
メモリが食いつぶされていることに気づきました。
マルウェアの発見
不思議に思ったあなたは、まず、
この正体不明のプロセスについてGoogleで検索します。
その結果、以下の情報が出てきました。
kinsing
- 違法にビットコインマイニングを行うマルウェア
- 感染したコンピュータのCPU及びGPUのリソースを利用して、仮想通貨を発掘する
- その結果、コンピュータの動作が非常に重くなる
kdevtmpfsi
- クリプトマイナー
- 暗号通貨の形で報酬を獲得するためにトランザクションの正当性を検証する
そう、マルウェアです。
つまりは、どこぞの不遜な輩が侵入し、タダ乗りして
今こうしている間にも小銭を稼いでいる、ということでした。
血の気が引くあなた方ですが、深夜のため、
プロジェクトマネージャーへの電話はすぐには繋がりません。
ただ、おそらく1時間以内には気づいてくれるだろうという信頼はあります。
あなた方は、プロジェクトマネージャーから許可がおり次第、
直ちにこのマルウェアを駆除できるよう、必要な情報を集めることにしました。
調査
マルウェアを駆除するには、以下の情報が必要です。
- 感染原因
- どうすれば再感染しない状態にできるか
- 上記を踏まえて、再感染を防止しつつ、現在実行されているマルウェアを駆除する手順
以下のステップで、上記の情報を揃えましょう。
ステップ1. 感染事例を探す
まずは、同様の感染事例を探します。
今でこそ、kinsingもkdevtmpfsiも、日本語の記事がそこそこヒットしますが、
あなたが探す2021年3月1日には日本語の記事はヒットしません。
Twitterでも、話題にはなっていないようです。
幸い、英語の記事を探したところ、以下が分かりました。
- facade/ignitionの脆弱性が感染原因と見られる
- マルウェアと同名のファイルと、cronファイルを削除すればよい
- ignitionを最新版にアップデートすれば再発しない
ですが、以下は不明です。
- ignitionの脆弱性とは、具体的に何なのか
- 記事に記載された内容で本当に適切・十分と言えるのか
- 最新版にアップデートする以外の対処方法はあるのか
対処するには、上記の不明点について裏を取り、
安全性の高い方法を選択する必要があります。
更に調べたところ、ignitionの最新版へのアップデートは
Laravel7以降しか対応していないため、
現在の環境ではすぐにアップデートできないことが分かりました。
リリースも迫った今、フレームワークのバージョンを変更することは
追加コスト発生などのリスクが高く、なるべく避けたいです。
ステップ2. 脆弱性の特定
脆弱性を特定にするにあたって、便利なのが
NVD（National Vulnerability Database）です。
NVDとは、NIST（National Institute of Standards and Technology）
即ち米国国立標準技術研究所が管理する、脆弱性情報データベースです。
情報の量が多く、質も信頼できます。
NVDで調べてみると、1件の記事がヒットしました。
以下の脆弱性があるようです。
facade/ignition
- 以下の条件が揃った時、認証されていない攻撃者が任意のコードを実行できる脆弱性がある
- ignitionが2.5.2以前のバージョン
- Laravelが8.4.2以前のバージョン
- デバッグモードがオン
確認してみると、たしかに
検証環境が上記条件に合致しています。
つまりは、上記の条件が揃わないようにする――デバッグモードをオフにすれば、
Laravel及びignitionのアップデートをせずに、再感染を防止できることが分かりました。
ステップ3. 駆除手順を組み立てる
駆除対象を特定する
まずは、マルウェアはどこにあるのかを確認します。
以下のようにfindコマンドを使って、確認しましょう。
❯ find / -name kinsing
/tmp/kinsing
❯ find / -name kdevtmpfsi
/dev/shm/kdevtmpfsi
次に、マルウェアが何をやっているのかを確認します。
すると、1分ごとにcronを実行しているようです。
以上から、下記の調査結果と合っていると思ってよさそうです。
マルウェアと同名のファイルと、cronファイルを削除すればよい
結論
上記を踏まえて、以下の対応を実施することにしました。
- 再感染しない状態にする
- cronを削除する
- マルウェアファイルを削除する
- プロセスを削除する
実行
ここまで調べたところで、プロダクトマネージャーから折り返しの連絡がきました。
準備していた以下の調査結果と、参考にしたソースを伝えたところ、
駆除の実施許可が出ました。
| 観点 | 調査結果 |
|---|---|
| 感染原因 | facade/ignitionの脆弱性を突かれたこと |
| どうすれば再感染しない状態にできるか | デバッグモードをオフにし、脆弱性を解消する |
| 上記を踏まえて、再感染を防止しつつ、 現在実行されているマルウェアを駆除する手順 |
1. 再感染しない状態=デバッグモードをオフにする 2. cronを削除する 3. マルウェアファイルを削除する 4. プロセスを削除する |
では、実際に駆除してみましょう。
マルウェア駆除
1. デバッグモードをオフにする
ignitionの脆弱性を利用不可にするため、
まずはデバッグモードをオフにして新規感染を遮断します。
APP_DEBUG=false
2. cron削除
マルウェアにより実行されているcronを削除します。
また、権限を設定する事で再生成を防ぎます。
❯ rm /var/spool/cron/apache
❯ mkdir /var/spool/cron/apache
❯ chmod 755 rm /var/spool/cron/apache
3. マルウェアファイル削除
マルウェアファイルを削除します。
同名のファイルを権限を設定して配置する事で、再生成を防ぎます。
❯ find / -name kinsing
/tmp/kinsing
❯ cd /tmp
❯ rm kinsing
❯ touch kinsing
❯ chmod 644 kinsing
❯ find / -name kdevtmpfsi
/dev/shm/kdevtmpfsi
❯ cd /dev/shm
❯ rm kdevtmpfsi
❯ rouch kdevtmpfsi
❯ chmod 644 kdevtmpfsi
4. プロセス削除
マルウェアが実行しているプロセスを削除します。
❯ pgrep -f kinsing | xargs kill -9
❯ pgrep -f kdevtmpfsi | xargs kill -9
5. 観察
最後に、メモリの使用状況が正常になっていることを確認し、
マルウェアの再発が起きないことを念のため見守って、駆除完了です。
事後処理
お疲れさまでした。
プロジェクトマネージャーに完了報告をしたら今日のところは寝て、
明日振り返りを行いましょう。
例えば、脆弱性をより早くキャッチアップするために
週次で脆弱性の簡易チェックをするなど、改善策を検討しましょう。
また、今回のケースでは、ignition自体の脆弱性とは別に、
公開サーバでデバッグモードがオンになっていたというリスクも見られました。
公開サーバでデバッグモードはオンにすることは、セキュリティリスクが高いタブー行為です。
何故デバッグモードをオンで公開してしまったのか。
それもチームで振り返り、防止に努めましょう。
おわりに
ここまで読んでくださり、有難うございます。
いかがだったでしょうか。
筆者はセキュリティエンジニアではありません。
ですが、この記事を通して、皆さんがマルウェアへの対処イメージを持ち、
いざという時への備えとなれば嬉しいです。