ウェブシェル攻撃とは？検出と予防の方法は？

ウェブシェルとは何か？

ウェブシェルと呼ばれる悪意あるコードは、攻撃者がウェブサーバを乗っ取り、他の攻撃を実行するために使われます。システムやネットワークに侵入した後、攻撃者はウェブシェルを導入し、継続的な遠隔アクセスの手段として利用します。

リモートの攻撃者は、ウェブサーバにウェブシェルを正しく配置できた場合、悪意ある命令の実行やデータ窃取を行うことが可能です。Gallium グループや Lazarus グループといったハッカー集団が、ウェブシェルを利用した攻撃を実施した事例が確認されています。

‍

ウェブシェルの仕組み

• ‍継続的な遠隔アクセス

ウェブシェル内に用意された裏口を通じ、攻撃者は外部からサーバへアクセスできるようになります。各攻撃の度に新たな脆弱性を突く必要はなく、中には利用した脆弱性を修正して、他者による再利用や検出を防ぐ攻撃者も存在します。

特定の攻撃者だけがアクセスできるよう、いくつかのウェブシェルではパスワード認証等の対策が講じられています。さらに、ウェブシェルは難読化され、配置場所がウェブインデックスに登録されにくい工夫もなされています。

• ‍権限昇格の促進

制限されたユーザ権限で実行されるウェブシェルの場合、システムの脆弱性を突いて root 権限を取得することが可能です。root 権限を手にした攻撃者は、ソフトのインストール、権限変更、ユーザの追加や削除、メッセージの閲覧、パスワードの窃取など、ほぼすべての操作を行えます。

• ‍攻撃のピボット及び展開

攻撃者はウェブシェルを用いて、内部や外部の追加ターゲットへの攻撃を展開できます。ライブホスト、ファイアウォール、スイッチなどの情報収集には数週間要する場合もあり、攻撃者は発見を逃れるため、極力目立たないよう行動します。

• ‍ボットの大量感染 Bots

ウェブシェルを利用して、サーバが攻撃者によって支配されるボットネットに組み込まれることがあります。攻撃者は、ウェブシェルと連動するコマンド＆コントロールサーバを通じて、侵入されたシステムに命令を送ります。

この手法は、大量のデータ転送容量を必要とする一般的な DDoS 攻撃手法でもあります。攻撃者は、ウェブシェルが設置されたシステムそのものを狙うのではなく、その資源をより有望なターゲットに転用します。

ハッカーによるウェブシェルの利用

ウェブシェルを利用するには、まず攻撃者がウェブシェルを送り込むためのシステムの脆弱性を発見する必要があります。通常は、サーバやその設定の脆弱性を悪用して配置され、以下のような例が考えられます。

• アプリ、ファイルシステム、管理の脆弱性
• リモートファイルインクルージョン (RFI) およびローカルファイルインクルージョン (LFI) の脆弱性
• リモートからのコード実行
• 公開されたネットワークインターフェース

ウェブシェルの設置に成功すると、攻撃者はリモートから標的ホスト上でスクリプトを実行し、企業のサーバに保存された機密データへアクセスすることが可能になります。

‍

ウェブシェルの種類

ここでは、ウェブシェルのファイル形式について見ていきます。

1. Bind Shell

対象デバイスに設置されるシェルの一種が Bind Shell です。ホスト上の特定のポートに結び付けられ、着信接続を待ち受けます。これにより、攻撃者はリモートから標的ホスト上でスクリプトを実行できます。

2. Reverse Shell

Reverse Shell（または Associate Back Shell）と呼ばれるものは、逆の動作を行うシェルです。攻撃者はリモートコマンド実行の脆弱性を突いてウェブシェルを送信し、標的ホストが攻撃者のデバイスへ接続するよう誘導します。これは Bind Shell とは対照的です。

3. Double Reverse Shell

Reverse Shell の一例として Double Reverse Shell があります。この場合、着信を待っていた攻撃者のデバイスが標的ホストに接続し、さらに攻撃者側へ戻る接続が2つのポートを通じて行われます。データと応答の通信は、それぞれ別々のチャネルに分割されます。

ウェブシェルの検出方法

システム管理者がウェブシェルの存在を疑う場合や、通常の点検を行う際に確認するポイントは以下の通りです。

まず、サーバのアクセスログやエラーログ内で、頻出するキーワードがないか確認してください。ファイル名やディレクトリ名が含まれる場合もあります。下記の例は、Apache HTTP Server のアクセスログから「record」という文字列を検索する方法です。

root@secureserver:/var/www/html# feline/var/log/apache2/access.log | awk - F\" ' { print $1,$2 } ' | grep "record"

--> 192.168.5.26 - - [30/Feb/2020:08:30:53 +0100] GET/demo/shell.php?file=/and so forth/passwd

非常に長い文字列がないかも確認してください。これはエンコードが施されている兆候であり、一部のバックドアはコードの行数が多いことがあります。

root@secureserver:/var/www/html/demo# awk 'length($0)>100' *.php

--> eval(gzinflate(base64_decode('HJ3HkqNQEkU/ZzqCBd4t8V4YAQI2E3jvPV8/1Gw6orsVFLyXefMcFUL5EXf/yqceii7e8n9JvOYE9t8sT8cs//cfWUXldLpKsQ2LCH7EcnuYdrqeqDHEDz+4uJYWH3YLflGUnDJ40DjU/AL1miwEJPpBWlsAxTrgB46jRW/00XpggW00yDI/H1kD7UqxI/3qjQZ4vz7HLsfNVW1BeQKiVH2VTrXtoiaKYdkT4o/p1E8W/n5eVhagV7GanBn0U7OCfD7zPbCQyO0N/QGtstthqJBia5QJsR6xCgkHpBo1kQMlLt6u++SBvtw5KSMwtG4R2yctd0mBNrlB3QQo4aQKGRgRjTa0xYFw1vVM9ySOMd44sSrPe…

過去 X 日以内に改変されたファイルを検索してください。下記の例では、前日に変更された *.php ファイル内のウェブシェルを探していますが、画像等に埋め込まれている可能性もあるため、すべてのファイルの変更点を確認することが重要です。

root@secureserver:/var/www/html/# find - name '*.php' - mtime - 1 - ls

--> root@secureserver:/var/www/html/# find - name '*.php' - mtime - 1 - ls
2885788 4 drwxrwxr-x 2 secuser 4096 Apr 30 06:590/demo/shell.php
2886629 4 - rw-rw-r- - 1 secuser 260 Apr 29 11:25/demo/b.php
2897510 4 - rw-r- - r- - 1 root 35 Apr 29 13:46/demo/source.php
2883635 4 - rw-r- - r- - 1 www-information www-information 1332 Apr 29 12:09 ./ma.php

システム上で、不審な接続やトラフィックがないか注意してください。

root@secureserver:/var/www/html/demo# netstat - nputw
--> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.5.25:37040 192.168.5.26:8181 ESTABLISHED 2150/nc
tcp 0 0 192.168.5.25:22 192.168.5.1:52455 ESTABLISHED 2001/sshd: secuser
tcp6 1 0 ::1:46672 ::1:631 CLOSE_WAIT 918/cups-perused
tcp6 0 0 192.168.5.25:80 192.168.5.26:39470 ESTABLISHED 1766/apache2
tcp6 1 0 ::1:46674 ::1:631 CLOSE_WAIT 918/cups-perused

.htaccess ファイルの変更も確認してください。以下は、攻撃者が実施する可能性のある .htaccess ファイル変更例です。

# AddType ディレクティブは、指定されたファイル拡張子に所定のコンテンツタイプを関連付けます。

AddType application/x-httpd-php .htaccess
AddType application/x-httpd-php .jpg

‍

ウェブシェル攻撃の予防と緩和策

• ‍WAFを導入

ネットワークトラフィックを分離することで、Web アプリケーション Firewall（WAF）は、ウェブシェルや悪意あるペイロードが環境に送り込まれるのを防ぎます。ファイアウォールは、最新のセキュリティパッチに沿って常に更新することが重要です。

• ‍ファイル整合性監視

ファイルの変更は正規のタイムスタンプと比較され、差異があれば該当ファイルがブロックされるかセキュリティ警告が発せられます。

• ‍サーバ構成の確認

サーバの設定を綿密に検証することで、ウェブサーバや OS の脆弱性を発見し、修正することが可能です。

• ‍ネットワークのセグメント化

ネットワークセグメントを分離することで、攻撃者が横展開により全体のネットワークへアクセスするのを防げます。

• ‍重要ディレクトリの名称変更

不正なファイル転送を防ぐため、アクセス可能なディレクトリはできるだけ無効化すべきです。転送機能が必要な場合、重要ファイルのデフォルト名を変更して見つけにくくし、権限のあるユーザだけが変更にアクセスできるようにしてください。

また、ウェブサーバにアップロード可能なファイル種類のホワイトリストを作成してください。

• ‍EDRの活用

EDR（エンドポイント検出・対応）やログシステムを利用することで、ウェブシェル攻撃に対処できます。これらのシステムは、システムコールやプロセス継承の異常、悪意ある挙動の兆候を監視してウェブシェルを検出します。

• ‍プラグインの数を減らす

WordPress のアドインは、誰でも作成可能なため攻撃の入り口となりやすいです。信頼できる開発元のものだけを導入し、不要なプラグインは削除してください。

Wallarmによるウェブシェル攻撃への対策

Wallarmの業界を先導するWeb Application Firewallは、C&Cサーバと通信するウェブシェルやその他の脅威から貴社のアプリを守ります。高度なウェブトラフィック解析により、攻撃を未然に防ぎます。

Wallarmは、WAFに加えて、アプリ、API、マイクロサービスに対して、FAST、API Security Platform、先進的なボット対策、DDoS対策、攻撃解析、クライアントサイド保護など、包括的なセキュリティを提供します。