CVE-2023-46604 AMQ RCE漏洞應急響應實錄

一、事件背景

Apache ActiveMQ是最流行的開源、多協議、基于 Java 的消息代理。它支持行業標準協議，用戶可以從多種語言和平臺的客戶端使用AMQP協議集成多平臺應用程序。

2023年10月26日，Apache ActiveMQ官方發布新版本5.15.16，修復了一個遠程代碼執行漏洞，攻擊者可構造惡意請求通過Apache ActiveMQ的61616端口發送惡意數據導致遠程代碼執行，從而完全控制Apache ActiveMQ服務器。

2023年10月27日，由于公司有外包開發系統存在該漏洞，服務器被攻擊者入侵，我們安全部開始了應急響應和推動加固工作。

二、應急處置過程

2.1 10月27日

上班路上，收到飛書監控群安全告警，到公司后立馬登錄云安全中心控制臺看到告警如下：

由于云安全中心沒有提示【攔截成功】，且該云賬號的云安全中心為免費版，我們認為攻擊者大概率入侵成功，必須立刻啟動應急響應。

2.1.1 入侵分析

詢問研發和運維人員系統情況，確認網站可以正常訪問。
搜集受攻擊服務器相關信息，包括關聯域名、IP、域名、端口，確定攻擊入口。查看安全組，發現服務器都開放了8161和61616端口，百度后了解到這兩個是AMQ的端口，其中8161是控制臺web服務，61616是JAVA消息服務。
搜索AMQ存在的漏洞，發現10月25日新出了一個Apache ActiveMQ 遠程代碼執行漏洞，只要AMQ版本低于5.15.16，攻擊者就可以利用61616端口進行攻擊。查看公司系統，發現AMQ版本是5.15.10，基本上可以判斷這是攻擊入口。
與研發、運維確定加固方案，需要加白61616端口。由于該系統邊緣端設備部署在客戶工廠，邊緣端設備已經封裝公司的程序，程序需要訪問AMQ 61616端口，客戶出口不一定具備固定IP，因此只能按照官方公告升級AMQ服務端到5.15.16版本，實施升級需要協調外包軟件開發商參與，需要時間比較長。
由于業務不能停，61616端口不能關閉和加白，只能由安全部先清理木馬，并且祈禱清理后不會再被攻擊者入侵。

2.1.2 清理木馬

登錄服務器，未發現可疑賬號

cat /etc/passwd

檢查定時任務，未發現可疑任務

crontab -l

根據云安全中心的告警，查看/var/tmp目錄，木馬文件configs.conf、auditd、polkitd、atd都不存在，可能是木馬自己刪除自己以隱藏自身。使用find命令進行全盤搜索，發現存在configs.conf文件，使用rf -rf命令刪除；使用stat對其余列出的文件逐一檢查，未發現mtime或ctime為10月26日-27日的auditd、polkitd、atd文件

ls -al /var/tmp

find / -name auditd

find / -name atd

find / -name polkitd

find / -name configs.conf

rm -rf /etc/selinux/configs.conf

rm -rf /usr/local/share/configs.conf

根據云安全中心的告警，檢查惡意進程kstrp，使用readlink /proc/[pid]/exe命令，發現該進程指向木馬文件/var/tmp/atd，確認是惡意進程，使用kill -9 [pid]逐一殺掉kstrp惡意進程

[root@ecs tmp]# ps -ef | grep kstrp

root  16303  1 0 06:49 ?    00:00:00 [kstrp]

root  16304 16303 0 06:49 ?    00:00:00 [kstrp]

root  16305 16303 0 06:49 ?    00:00:00 [kstrp]

root  20583 19373 0 12:04 pts/3  00:00:00 grep --color=auto kstrp

[root@ecs tmp]# readlink /proc/16303/exe

/var/tmp/atd (deleted)

[root@ecs tmp]# kill -9 16303

殺掉kstrp進程后，觀察一段時間未再出現。

2.1.3 第二次應急

本以為本次應急告一段落，結果晚上再次出現安全告警，需要再次進行應急：

重復白天的操作，殺掉所有kstrp進程，檢查并刪除所有找到的木馬文件configs.conf、auditd、polkitd、atd
根據云安全中心告警，檢查所有ksoftirqd/0進程。由于ksoftirqd/0是linux內核進程，因此必須使用readlink /proc/[pid]/exe來分辨出偽裝的惡意進程，避免誤殺

[root@ecs tmp]# readlink /proc/21944/exe

/var/tmp/polkitd (deleted)

[root@ecs tmp]# ps -ef | grep 21944

root  21944 19411 0 20:46 ?    00:00:00 [ksoftirqd/0]

root  25284 22161 0 23:07 pts/0  00:00:00 grep --color=auto 21944

[root@ecs tmp]# kill -9 21944

執行上述清理操作后過2分鐘再次彈出安全告警，發現服務器再次生成configs.conf文件以及ksoftirqd/0進程，懷疑守護進程未全部清理干凈，再次進行檢查，發現存在多個守護進程ksoftirqd/0

[root@ecs tmp]# systemctl status 25480

● session-21.scope - Session 21 of user root

Loaded: loaded

Drop-In: /run/systemd/system/session-21.scope.d

└─50-After-systemd-logind\x2eservice.conf, 50-After-systemd-user-sessions\x2eservice.conf, 50-Description.conf, 50-SendSIGHUP.conf, 50-Slice.conf, 50-TasksMax.conf

Active: active (abandoned) since Tue 2021-08-24 14:57:57 CST; 2 years 2 months ago

CGroup: /user.slice/user-0.slice/session-21.scope

├─12556 /opt/jdk1.8/jre/bin/java -Xms64M -Xmx1G -Djava.util.logging.config.file=logging.properties -Djava.security.auth.login.config=/mnt/server/...

├─12803 /opt/zbox/run/apache/httpd -k restart

├─12804 /opt/zbox/run/apache/httpd -k restart

├─12805 /opt/zbox/run/apache/httpd -k restart

├─12806 /opt/zbox/run/apache/httpd -k restart

├─12910 /bin/sh /opt/zbox/run/mysql/mysqld_safe --defaults-file=/opt/zbox/etc/mysql/my.cnf

├─13143 /opt/zbox/run/mysql/mysqld --defaults-file=/opt/zbox/etc/mysql/my.cnf --basedir=/opt/zbox/run/mysql --datadir=/opt/zbox/data/mysql --plug...

├─13161 /opt/zbox/run/apache/httpd -k restart

├─19410 [ksoftirqd/0]

├─19411 [ksoftirqd/0]

├─19412 [ksoftirqd/0]

└─25480 [ksoftirqd/0]

清理掉所有守護進程并刪除configs.conf木馬文件后，繼續觀察半小時，沒有出現新的告警、configs.conf、auditd、polkitd、atd木馬文件和kstrp、ksoftirqd/0進程，終于可以下班。

[root@ecs tmp]# kill -9 19410 | kill -9 19411 | kill -9 19412 | kill -9 25480

2.2 10月31日第三次應急

雖然AMQ的61616端口依然開著，但幾天未收到告警，本以為攻擊者已經遺忘了我們公司，結果下午收到阿里云封禁服務器的通知，原因是服務器對外進行了DDOS攻擊。

由于3天沒告警，我們初步認為服務器沒被入侵，屬于誤封，發起工單和阿里云進行溝通，得出兩個結論：

我們服務器的確有對外發起DDOS攻擊，PPS達到xx萬。
為什么云安全中心未檢測到異常，而前幾天可以？回復：沒有采集到，所以就沒告警。

在沒有任何告警信息的情況下，我們再次進行了艱難的排查，主要步驟如下：

服務器突然很卡，難以操作。查看服務器云監控，發現公網、內網帶寬流量飆升
使用tcpdump，發現大量外聯包，使用iftop查看發現訪問該IP流量達到1.72Gb

常規ps、top、netstat、cat /etc/passwd等檢查命令，未發現異常
繼續尋找隱藏的惡意進程，最終發現偽裝成內核進程的惡意進程ksoftirqd/0被mount到了/dev/vda1目錄，所以ps、netstat、top等命令都無法找到，卸載后殺掉進程。通過lsof命令可以看到，運行的惡意文件是/mnt/server/activemq-5.15.10/bin/linux_amd64，運行后就把自己刪除了

[root@ecs ~]# cat /proc/mounts | grep proc
/dev/vda1 /proc/18034 ext4 rw,relatime,data=ordered 0 0
[root@ecs~]# umount /proc/18034
[root@ecs~]# ps -ef | grep 18034
root  11715 26645 0 22:30 pts/2  00:00:00 grep --color=auto 18034
root  18034  1 2 05:49 ?    00:29:50 [ksoftirqd/0]
[root@ecs~]# lsof -p 18034
COMMAND  PID USER FD   TYPE  DEVICE SIZE/OFF   NODE NAME
linux_amd 18034 root cwd   DIR  253,17  4096 6816173 /mnt/server/activemq-5.15.10/bin
linux_amd 18034 root rtd   DIR  253,1  4096    2 /
linux_amd 18034 root txt   REG  253,17 5398528 6816523 /mnt/server/activemq-5.15.10/bin/linux_amd64 (deleted)
linux_amd 18034 root  0r   CHR   1,3   0t0   1031 /dev/null
linux_amd 18034 root  1w   CHR   1,3   0t0   1031 /dev/null
linux_amd 18034 root  2w   CHR   1,3   0t0   1031 /dev/null
linux_amd 18034 root  3u  IPv4 261919304   0t0   TCP ecs:52766->20.89.141.233:icl-twobase2 (ESTABLISHED)
linux_amd 18034 root  4u a_inode   0,10    0   6358 [eventpoll]
linux_amd 18034 root  5r  FIFO   0,9   0t0 261080142 pipe
linux_amd 18034 root  6w  FIFO   0,9   0t0 261080142 pipe
linux_amd 18034 root  7u  IPv4 261590289   0t0   TCP ecs:35772->194.49.94.12:32675 (ESTABLISHED)
[root@ecs~]# kill -9 18034

使用tcpdump、top、ps等命令繼續觀察服務器，未發現異常
要求研發和運維關閉61616端口，未升級完AMQ前，不得開放

2.3 11月2日

所有AMQ升級到5.15.16，重新開放61616端口，并且已驗證不能再觸發漏洞，本次應急響應終于正式告一段落。

三、安全建議

對 AMQ的8161、61616端口增加IP白名單限制。
升級AMQ到安全版本。
引入外包軟件開發商時，應對軟件的組件進行安全評估，并要求軟件開發商履行漏洞修復職責。

四、IOCs

4.1 域名&&IP

172.245.16.125/down

4.216.93.211:9865/x.sh

4.216.93.211:25001

47.243.142.18:443

4.216.93.211:5981/ix.sh

146.56.217.27/7LvMgjN2.sh

119.45.155.12/7LvMgjN2.sh

82.115.220.81/bins/x86

194.49.94.12

20.89.141.233

39.103.151.239

39.99.235.57

183.136.225.9

2151.m.x8.eyes.sh

0.tcp.ap.ngrok.io

okfile.cc/az

www.bailong8888.com/long

long.amdc6766.net

149.28.237.94.vultrusercontent.com

4.2 文件名

/var/tmp/polkitd

/var/tmp/atd

/var/tmp/auditd

/var/tmp/configs.conf

/etc/selinux/configs.conf

/usr/local/share/configs.conf

/usr/local/share/man/configs.conf

/usr/local/share/man/man1/configs.conf

/mnt/server/activemq/bin/linux_amd64

4.3 文件hash

bf0e3caacbe6ccc28b7678d1ec551ca7

8e5672c5f7a049316a902b7d449165c6

0d763111a051c06368d4d25efeb08a05

9dd7853e4915795c528e89bb2548d894

36522b9120906d4f91d7087e5c7ce20c

4.4 進程名

kstrp

ksoftirqd/0

五、參考資料

AMQ官方公告

阿里云漏洞庫-Apache ActiveMQ遠程代碼執行漏洞（CVE-2023-46604）

CSDN-Apache ActiveMQ RCE漏洞復現（CNVD-2023-69477）

FreeBuf-剛披露就被利用，攻擊者盯上了Apache ActiveMQ 漏洞