令和3年度 秋期 情報処理安全確保支援士試験 午後Ⅰ 問1｜推測されたパスワードと「踏み台」にされた保守サーバ——情報処理安全確保支援士で学ぶリモート保守とSSHのセキュリティ

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

• 試験区分: 情報処理安全確保支援士
• 出典: 令和3年度 秋期 情報処理安全確保支援士試験 午後Ⅰ 問1
• 主なテーマ: リモート保守、SSH、公開鍵認証、パスワード推測攻撃、暗号資産マイニング（クリプトジャッキング）、ファイアウォール設定、SSH Agent Forwarding、フィンガプリント

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

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

システムの保守を外部の業者に任せる——これは多くの企業にとって、ごく当たり前の運用です。けれども、外部から自社サーバにログインできる「保守の入口」は、攻撃者から見れば、そのまま「侵入の入口」になり得ます。

情報処理安全確保支援士試験の午後Ⅰで出題されたこの事例は、小売業の会社を舞台に、リモート保守用のサーバが第三者に乗っ取られ、暗号資産を採掘するプログラムを動かす「踏み台」にされてしまうインシデントを描いています。原因は、ゼロデイ脆弱性のような高度なものではありません。保守員が設定していた「推測されやすいパスワード」が突破口でした。技術的にはありふれた失敗ですが、だからこそ、誰の身にも起こり得ます。

この記事を読むと、なぜ保守用のサーバが狙われるのか、SSH（暗号化された遠隔ログインの仕組み）の認証をどう強化すべきか、公開鍵認証やSSH Agent Forwardingが何を守るのか、そしてファイアウォールで接続元を絞ることがなぜ効くのかが見えてきます。受験者にとってはSSH・FW・ログ調査の総合演習であり、外部委託で保守を回す企業の経営者にとっては「委託先の認証管理まで自社の責任」と気づかせる教材になるはずです。

インシデントの概要

舞台は、従業員1,000名の小売業J社です。J社は、顧客情報を「顧客管理サーバ」で一元管理していました。この大切なサーバの保守作業は、M社という外部の業者に委託しており、M社の保守員2名（保守員1、保守員2）が担当していました。

J社のネットワークは、ファイアウォール（FW）で内外を仕切る構成です。インターネットに面したDMZ（社内ネットワークと外部の中間に置く緩衝地帯）には「保守用中継サーバ」が置かれ、その奥のサーバLANに顧客管理サーバがありました。保守の流れはこうです。保守員は、まず保守PC（保守作業用のPC）から保守用中継サーバにSSHで接続し、そこからさらに顧客管理サーバへSSHで接続する。中継サーバを一段はさむ「踏み台型」の構成でした。

保守PCには、社内に常設された保守PC-Aのほか、M社が保守員ごとに貸与する保守PC-B・保守PC-Cがありました。後者はスマートフォンでテザリング（スマホの回線を使ってPCをインターネットにつなぐこと）して接続するため、固定のグローバルIPアドレスは付きません。認証方式は、いずれもパスワード認証。保守用中継サーバ上の利用者ID（保守員1はop1、保守員2はop2）には一般利用者の権限を、顧客管理サーバ上の同名のIDには特権利用者（管理者相当）の権限を与えていました。さらに、SSHの成功・失敗は認証ログに、コマンド実行の内容は操作ログに記録される仕組みです。

一見すると、踏み台型の構成とログ取得で、相応に守られているように見えました。けれども、この設計には一つの穴がありました。保守用中継サーバへの「インターネットからのSSH接続」を、事前申請があったときだけ一時的に許可する運用にしていたのです。便利さのための例外が、攻撃者にとっての好機になりました。

何が起きたのか

異変が見つかったのは、6月16日のことでした。J社のシステム管理者であるFさんが、ファイアウォールのログ（FWログ）を眺めていて、不審な記録に気づきます。調べてみると、保守用中継サーバの上で、暗号資産を採掘するプログラム（プログラムH）が動いていました。しかも、それは定期的にインターネット上のサーバへ通信を試みていたのです。誰かが、J社の保守用中継サーバを、勝手に暗号資産マイニングの「踏み台」にしていました。

Fさんは、外部の情報処理安全確保支援士（登録セキスペ）であるS氏の助言を仰ぎます。S氏は「保守作業の関連書類、FWログ、SSH認証ログ、操作ログを調べ、保守員にヒアリングを」と方針を示しました。翌日、Fさんが調査結果を持ち寄ります。

時系列を組み立てると、こうでした。6月14日、保守員2から「保守PC-Cを使って7時から9時30分まで顧客管理サーバの保守を行う」という事前申請が出ていました。これに従い、J社のシステム管理者はファイアウォールの設定を変更し、その時間帯だけインターネットから保守用中継サーバへのSSH接続を許可していたのです。FWログを見ると、申請された時間帯に、二つのグローバルIPアドレスから保守用中継サーバへSSH接続がありました。

ここで、ログの食い違いが浮かび上がります。操作ログには、6月14日8時に「op1がプログラムHを設置した」という記録が残っていました。一方で、SSH認証ログを見ると、op1は7時30分から認証の失敗が84回も続いた末に、7時40分にようやく認証に成功していました。op2のほうは7時20分に一度で認証成功。そして保守員へのヒアリングでは、保守員1は「保守作業など実施していない」と回答し、保守員2は「保守PC-Cで申請どおり作業し、ほかには何もしていない」と答え、その証言は申請・操作ログ・作業報告と矛盾しませんでした。決定的だったのが、「op1に設定されているパスワードが、推測の容易な文字列だった」という事実です。

すべてがつながりました。第三者が、保守作業のために一時的にSSH接続が許可されていた「その時間帯」を突き、op1の単純なパスワードを総当たり的に推測し（だから84回もの失敗が続いた）、最終的にログインに成功して、保守用中継サーバにプログラムHを仕込んでいたのです。保守員2の正規の作業（op2）と、攻撃者の不正ログイン（op1）が、たまたま同じ時間帯に重なっていたために、ログが交錯していました。

幸いだったのは、被害がそこで止まっていたことです。FさんとS氏が追加調査を行うと、保守用中継サーバにプログラムHが設置された記録は見つかったものの、そこから顧客管理サーバを含む他の機器へアクセスした記録は見つかりませんでした。攻撃者が手に入れたのは、あくまで保守用中継サーバ上の「一般利用者権限」のop1。顧客管理サーバへ進むには別の特権アカウントが必要で、そこまでは到達していなかったのです。影響範囲は保守用中継サーバだけにとどまり、顧客情報の漏えいはなかったと結論づけられました。とはいえ、一歩間違えば顧客情報の流出につながりかねない、危うい侵入でした。