はじめに
前回、WinMergeの紹介の記事でふれた、XMLRPC API を経由した OS コマンドインジェクションの脆弱性を修正しました CVE-2021-20837について
弊社で、設置したものに対しては、対策済みなので特に問題はないのですが。。
別途、お問い合わせ、相談が増えてきたので・・・
内容
下記のファイルが追加されていました。0バイトのものは、失敗した感じです。
2021年11月ぐらいから起きているようで、作成されたファイルを探すにはSSHが使えれば、下記のコマンド10日前作成されたファイルを探すことができます。
すべてPHPで、レンタルサーバーだったので、mt-xmlrpc.cgi、アップロードされたファイルのパーミッションが変更され、動作しないようになっていました。
サーバ会社のほうが対策した感じかと思います。
10日前作成されたファイルを探すコマンド。コマンド操作して日からになるので別途-14400の部分は変更してください。
14400は10日*1*60*24
find /var/www/ウェブ領域のパス -type f -mmin -14400
オプション -mtime -10で１０日前
いくつかのサイトでアップロードされていたファイルのリスト
DIZ.php 0
shell.php 0
8q71g.php 1.11K
8z69v.php 193.10K
9scnl.php 193.10K
MDpHSGknJ1U.php 38.65K
Tj6Hh3pQlnK.php 23.46K
aqvy1.php 193.10K
b6fki.php 1.11K
fox.php 0
fox2.php 957
hmxuo.php 193.10K
k6va5.php 1.11K
lk648.php 193.10K
mclrj.php 1.11K
ns93k.php 193.10K
php.ini 111
rXCeL1wu6qP.php 19.33K
shell.php 192.75K
vne6i.php 1.11K
xyibu.php 1.11K
あとは、ウェブログを参照して、mt-xmlrpc.cgiのアクセスを確認して、作成されたファイルのタイムスタンプを確認、アクセスしたタイムスタンプ確認、その後、該当IPのアクセス禁止など
１つのサーバー、海外のアクセスが禁止になっているサーバー会社がありました。
対策
Movable Type 7 、Movable Type 6では、バージョンアップがすでに出ているので、そちらでバージョンアップするか。カスタムや、プラグインなどあってバージョンアップが難しい場合は、
wordpressのxmlrpc.php同様、mt-xmlrpc.cgiを削除するか、Movable Typeの場合、パーミッションを644など、000など設定、実行権限を無くすことで問題ないかと・・
Movable Type5以下の対応も同上で行います。
mt.cgi
上記以外、実行権限をなくしておくなど。検索など使用している場合はmt-search.cgiなどは実行権限つけておく
下記のフォルダーはバージョンアップ時に実行権限つける
mt-check.cgi
mt-wizard.cgi
mt-testbg.cgi
mt-upgrade.cgi
また、下記も外部から操作できるファイルなので、使用していない場合は、パーミッションの実行権限をなくしておいた方がよいですね。
mt-data-api.cgi
もしくは下記でhtaccessを行ってもよいですが、Movable Typeはperlで作成されているのでパーミッションで実行権限さえ、落とせば問題ないかと思います。
<Files "mt-xmlrpc.cgi">
Order Allow,Deny
Deny from all
</Files>
また別途、下記のようにmt.cgi自体にもベーシック認証などかけておいてもよいかと思います。
<Files "mt.cgi">
Order Deny,Allow
Deny from all
AuthUserFile /設置した絶対パス/.htpasswd
AuthType Basic
AuthGroupFile /dev/null
AuthName "Please enter username and password"
require valid-user
satisfy any
ErrorDocument 403 http://トップページのURL/
</Files>
パーミッションの実行権限をmt.cgiのみして、ベーシック認証かけておけば、外部から攻撃されるリスクは減るはずです。
mt.cgi自体、ログインしないとアクセスできない機構になっているので、ログイン後の操作などに脆弱性があっても、ログインしないと攻撃ができないはず・・
まぁ、システムに、絶対はないので・・リスク軽減ですね・・・
それでも、という場合は、編集サーバー、公開サーバーの形にして。編集サーバーをオンプレでするなど、あるかと・・お問い合わせが残りますが・・外部サービスとか・・
前回WinMergeの紹介時の出た差分を見ると下記が追加されたおり、追加していない場合、MT::XMLRPCServer以外の領域まで、みることができた感じでしょうか？
下記はmt-xmlrpc.cgiに下記行を追加することにより、MT::XMLRPCServerしか参照できなくした感じかと思います。
$server->dispatch_with( { 'mt' => 'MT::XMLRPCServer' } );
追記
r.5004 / 6.8.4のバージョン対応で、上記が誤りがあったようです。
間違って、パーミッション、mt-xmlrpc.cgiの削除せず、自分で修正しちゃうひとが出るかもしれないので、更新しておきますね。
旧
$server->dispatch_to( 'blogger', 'metaWeblog', 'mt', 'wp' );
$server->dispatch_with( { 'mt' => 'MT::XMLRPCServer' } );
下記に対応が正解なようです。
新
$server->dispatch_with( {
'mt' => 'MT::XMLRPCServer',
'blogger' => 'blogger',
'metaWeblog' => 'metaWeblog',
'wp' => 'wp',
} );
あまり詳しくは書けませんが、多くのインジェクションはsystem関数だったり、evalを使われます。
また、PHPが多い理由は、パーミッションを変更しなくても動作するという点でしょうか？パーミッションを変更しないと動作しない言語では手間なので
phpがつかわれるのでしょうね。
wordpressでは system(curl ダウンロードサイト)で指定されていて、プログラムコードなどアップロードダウンロードできるサイトから、バックドアが仕込まれていたりしました。この時、PHPの場合パーミッションを変更しなくても動作するので・・・
0バイトだったものはcurl wget等のTLSが古いので接続できなかった、親ディレクトリに書き込み権限ないなど考えられます。
最近は、オープンソース公開サイトも常時SSL化が進んでいるので、curl wgetなどopenSSLが導入されていないと、httpsでアクセスができないサーバーもあります。
バックドアの多くがphp製のファイルブラウザーだったり、base64でエンコードされ、コードが分からないようになっていたりします。
また、PHPでは、php.iniで禁止していても、php.iniをアップロードされることで、禁止していたものが有効にできてしまうので、ウェブルートにphp.iniを置いても動作しないなど対策は必要です。
Movable Typeの場合、動的モードでphpを使用していないのであれば、php自体を動作しないようにしておく。wget,curlなどの他サイトからダウンロードできるものは禁止しておくなどしておくなど考えられます。
さいごに
レンタルサーバーでは、レンタルサーバー側でmt-xmlrpc.cgiの実行権限をおとしているものもあります。
一度、借りているサーバーのサポートに相談するのが良いかと思います・・
では・・
