Movable Type XMLRPC API を経由した OS コマンドインジェクション

らら
らら

はじめに

前回、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で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のアクセス禁止など

1つのサーバー、海外のアクセスが禁止になっているサーバー会社がありました。

対策

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の紹介

前回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の実行権限をおとしているものもあります。

一度、借りているサーバーのサポートに相談するのが良いかと思います・・

では・・