令和元年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1｜急いで開けたポートが招いた採掘マルウェア——情報処理安全確保支援士で学ぶDevOps時代のインシデント対応

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 令和元年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問1
• 主なテーマ: DevOps、暗号資産採掘マルウェア（クリプトジャッキング）、認証バイパス、ファイアウォールのフィルタリング設計、ルートキット、フォレンジック調査、実行環境の脆弱性管理、コンテナ技術の活用

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

「あとで直そう」「とりあえず動けばいい」——開発の現場では、こうした判断が日常的に積み重なります。新しい機能を3週間に1回のペースでリリースし続けるスピード感のある会社ほど、その積み重ねは速く、そして見えにくい。この事例は、まさにそうした「速さ」を武器にしてきた企業が、急いで開けた一つのポートをきっかけにマルウェアへ感染してしまう、情報処理安全確保支援士の午後Ⅱで出題されたセキュリティインシデントです。

舞台は、開発と運用を一体で回す「DevOps」（DevelopmentとOperationsを組み合わせた言葉で、開発チームが運用まで担い、頻繁にリリースを繰り返す進め方）を実践するインターネット広告事業者。攻撃者が狙ったのは、最新機能でも顧客データでもありません。試験的に動かし始めたデータベースの設定の甘さと、長年更新されていなかった土台でした。

この記事を読むと、暗号資産採掘マルウェア（他人のサーバの計算能力を勝手に使って暗号資産を掘る不正プログラム）がどうやって侵入し、痕跡を消し、別のサーバへ広がろうとするのか、そしてDevOpsという速い開発スタイルにどんなリスクが潜むのかが見えてきます。受験者には頻出のファイアウォール設計やインシデント対応の論点が詰まっており、経営者・管理職には「スピードと安全をどう両立させるか」という普遍的な問いを突きつける教材になります。

インシデントの概要

舞台となるのは、2010年創業・従業員120名のインターネット広告事業者S社です。インターネット広告の販売と、広告の効果測定サービスを提供しており、評判は良く、登録会員は2,000社を超えていました。

S社の効果測定サービスは、自社のWebサイト上で動く「アプリQ」というWebアプリケーションソフトウェアが支えています。アプリQは創業時から自社内で開発が始まり、いまも機能追加や改修が続き、おおよそ3週間に1回のペースでリリースされていました。これを担うのは、わずか5名のエンジニアからなる開発チーム。彼らは開発と運用を一体で行うDevOpsを実践し、外部クラウドサービスを積極的に使っていました。ソースコードのバージョン管理（誰がいつどこを変更したかを記録し、過去の状態にも戻せる仕組み）にはサービスHを、開発に関する情報のやり取りには、テキストファイルをアップロードしてURLで共有できるサービスGを利用していました。

順調に見えるこの体制には、しかし静かなほころびが潜んでいました。アプリQは頻繁に更新されるため、Webアプリの脆弱性診断（攻撃に使われうる弱点を洗い出す検査）が計画的に実施できず、1年に1回程度、不定期に行うにとどまっていたのです。実際、前年末に外部へ依頼して診断したときにはSQLインジェクション（入力欄に細工した命令文を送り込み、データベースを不正に操作する攻撃）の脆弱性が見つかり、改修しています。さらに深刻だったのは、OS（基本ソフト）、ライブラリ（よく使う機能をまとめた部品集）、ミドルウェア（OSとアプリの橋渡しをするソフト。これら三つを併せて「実行環境」と呼びます）を、創業時から全く更新していなかったことでした。

アプリQは、W社のデータセンタにあるサーバAの上で動いていました。サーバAはDBMSサービス（データベース管理システム。会員情報などを保存・処理する基盤）であるサービスCと連携し、そこには効果測定のデータと、入会時に登録された会員情報が保存されていました。サーバAの負荷状況は、S社の開発用LAN（社内ネットワーク）上のPCから遠隔監視されており、この監視ツールの導入を容易にするためにコンテナ技術（アプリと実行環境を一つの箱にまとめて隔離して動かす仮想化の仕組み）が使われていました。

何が起きたのか

物語が動き出すのは9月のことです。開発チームは、試験的に新しいアプリDと、DBMS-Rという別のデータベースサービスを、同じサーバAの上で動かし始めました。開発用LANのPCからDBMS-Rのデータを参照・更新したい。さらに、ネットワーク経由で外部からDBMS-Rを通してOSコマンドを実行する機能（以下、遠隔コマンド実行機能）も使いたい——その要望に応えるため、彼らは「急きょ」サーバAのポート6379/tcpを開放しました。

ここに、後の悲劇の種がまかれます。サーバAのファイアウォール（通信を許可・遮断する関門）のフィルタリングルールでは、誰からでも（送信元「全て」から）ポート6379/tcpへの通信を許可する設定になっていました。本来そのポートを使うのはS社の開発用LANのPCだけのはずなのに、インターネットのどこからでも到達できる状態だったのです。一般論として、6379/tcpはRedis（メモリ上で高速に動くデータベース）の既定ポートとして広く知られており、攻撃者が真っ先に探しにくる番号です。「急いでいたから、とりあえず全部許可した」——その小さな油断が、世界中のスキャナに自社のドアを開け放つことを意味していました。

10月のある日、W社から一本の連絡が入ります。「あなたの会社のサーバAが、データセンタ内のほかのサーバを探索するアクセスを繰り返している」。初期対応にあたった開発チームのPさんは、サーバAのCPU使用率が100%に張り付いていることに気づきました。何かが、サーバの計算能力を食い尽くしている。Pさんはマルウェア感染を疑います。

S社の経営陣は、セキュリティ専門企業U社の情報処理安全確保支援士（登録セキスペ）であるB氏に、インシデント対応の支援を依頼しました。B氏は状況から、サーバAのストレージを対象にしたフォレンジック調査（コンピュータに残されたデジタルな証拠を保全し、何が起きたかを分析する調査）を実施するよう助言します。

調査の結果、サーバAは「マルウェアX」に感染していたことが判明しました。幸いにも、U社は過去にこのマルウェアXを解析した経験があり、その目的・侵入方法・機能が分かっていました。マルウェアXの目的は二つ。一つは暗号資産の採掘プログラムをダウンロードして実行すること、もう一つはほかのサーバへ侵入することです。つまりこれは、感染したサーバの計算資源を奪って暗号資産を掘りながら、さらに増殖していくタイプの攻撃でした。

侵入の手口は巧妙かつ機械的でした。マルウェアXはまずポート6379/tcpが開放されたサーバをインターネット上で探し回ります。見つけたら、そのサーバ上のDBMS-Rに接続を試みる。接続方法は二通りで、脆弱性を悪用して認証（本人確認）をすり抜けるか、パスワードを辞書攻撃（よく使われる単語を片端から試す手法）で突き止めるか。S社のDBMS-Rは、まさにこの入口を素通りされてしまいました。そして攻撃者は、不正に遠隔コマンド実行機能を利用してサーバへ侵入したのです。

ここからのマルウェアXの動きは、フォレンジック調査によって生々しく再現されました。侵入後、マルウェアXは遠隔コマンド実行機能を使い、`curl`（コマンドラインでURLからデータを取得・送信するツール）でサービスG上に置かれた攻撃用スクリプトをダウンロードして実行します。その結果、定期的に処理を自動実行する仕組みであるcron（クーロン）の設定が書き換えられ、以降の不正な活動が次々と自動で走るように仕込まれました。

そして、ここで攻撃者は意外な行動に出ます。`iptables`（Linuxの通信を制御するファイアウォール設定ツール）を使って、ポート6379/tcpへのパケットを破棄するルールを、ファイアウォールルールの先頭に挿入したのです。自分が入ってきたドアを、自分の手で閉じる——一見すると不可解なこの動きには、攻撃者なりの合理性がありました。続いてマルウェアXは、`rm`コマンドで自身の活動痕跡が残るログファイルをいくつか削除し、隠蔽用のルートキットY（侵入や不正プロセスの存在を管理者の目から隠すツール群）を`curl`でダウンロードして、DBMS-Rプロセスの実行権限でインストールします。さらに本命である暗号資産の採掘プログラムを`curl`で取り込んで実行し、最後に、ポート6379/tcpが開放されているほかのサーバへの侵入を試み始めました。W社が検知した「ほかのサーバを探索するアクセス」は、まさにこの増殖活動だったのです。

ルートキットYの隠蔽は、技術的に見ても巧みでした。Linuxでプロセスの稼働状況を見るときによく使う`top`コマンドは、内部ではライブラリの関数を通じて`/proc/123`のような（プロセスIDごとの）ディレクトリ内のファイルにアクセスし、その情報を読み取って表示します。ルートキットYはこのライブラリ関数を書き換えてしまうため、`top`コマンドを実行しても、暗号資産の採掘プログラムのプロセスだけが結果から消える。管理者がいくら監視ツールをのぞいても、CPUを食い尽くしている張本人が見えない——そういう状態が作り出されていたのです。

それでも、調査はもう一つ重要な事実を明らかにしました。ネットワーク経由でサーバA上のDBMS-Rにアクセスしていたのは、S社のPCを除けばマルウェアXによる1回だけ。遠隔コマンド実行機能による不審なコマンド実行も、SSH（Secure Shell。離れた場所からサーバを安全に操作するための仕組み）サービスへの接続も、マルウェアX以外には正規のS社のPCからのものしかありませんでした。これらの事実から、S社は「サーバAから会員情報の漏えいはなかった」と結論づけました。被害は、計算資源の盗用という限定的なものにとどまったのです。