中招ORACLE比特币勒索病毒——处理过程详解

liuzhilongDBA

已于 2023-03-11 22:23:45 修改

阅读量2.7k

点赞数

分类专栏： ORACLE 文章标签：勒索病毒 SQL RUSH Team afterconnect.sql

于 2019-06-12 15:30:03 首次发布

无版权，随便玩儿

本文链接：https://blog.csdn.net/qq_40687433/article/details/91529920

版权

ORACLE 专栏收录该内容

176 篇文章 3 订阅

订阅专栏

病毒告警

事件处理

1.修改job参数，防止病毒程序自启

2.杀掉job进程，停止正在运行的病毒程序自动任务

病毒告警

某客户核心业务系统中招ORACLE数据库勒索病毒。告警日志出现自动任务执行错误，对象被锁，并出现“你的数据库已被SQL RUSH Team锁死发送5个比特币到这个地址166xk1FXMB2g8JxBVF5T4Aw1Z5aZ6vSE (大小写一致) 之后把你的Oracle SID邮寄地址 sqlrush@mail.com我们将让你知道如何解锁你的数据库”的信息（别发！）。当时的告警日志如下：

事件处理

1.修改job参数，防止病毒程序自启

alter system set job_queue_processes=0;

2.杀掉job进程，停止正在运行的病毒程序自动任务

ps -ef |grep j0|grep -v grep|awk '{print $2}'|xargs kill -9

3.禁用数据库监听

关闭监听自启动，关闭监听,防止携带病毒的客户端再次连接

srvctl disable listener

srvctl disable scan_listener

srvctl stop listener

srvctl stop scan_listener

4.杀LOCAL=NO的会话

ps -ef|grep LOCAL=NO|grep -v grep|awk '{print $2}'|xargs kill -9

5.查找病毒程序

select owner,object_name from dba_objects where object_name like '%FUN9%'

select owner,created,object_name,OBJECT_TYPE from dba_objects where object_name like '%DBMS_CORE%';

select owner,created,object_name,OBJECT_TYPE from dba_objects where object_name like '%DBMS_SYSTEM_INTERNAL%’;

select owner,created,object_name,OBJECT_TYPE from dba_objects where object_name like '%DBMS_SUPPORT%';

OWNER CREATED OBJECT_NAME OBJECT_TYPE

-------------------- ------------------- ------------------------------ -------------------

APPUSER01 2019-05-24 10:58:06 DBMS_CORE_INTERNAL PROCEDURE

APPUSER01 2019-05-24 10:58:06 DBMS_SYSTEM_INTERNAL TRIGGER

APPUSER01 2019-05-24 10:58:05 DBMS_SUPPORT_INTERNAL PROCEDURE

APPUSER01 2019-05-24 10:58:06 DBMS_SYSTEM_INTERNAL PROCEDURE

APPUSER01 2019-05-24 10:58:06 DBMS_STANDARD_FUN9 PROCEDURE

6.删除病毒程序的存储过程、触发器

--伪装成系统对象的病毒程序，一般会跟9个空格，最好是通过sql拼凑drop语句

SQL> drop PROCEDURE APPUSER01."DBMS_CORE_INTERNAL ";

Procedure dropped.

SQL> drop PROCEDURE "APPUSER01"."DBMS_SYSTEM_INTERNAL ";

Procedure dropped.

SQL> drop PROCEDURE "APPUSER01"."DBMS_SUPPORT_INTERNAL ";

Procedure dropped.

SQL> drop TRIGGER "APPUSER01"."DBMS_SYSTEM_INTERNAL ";

Procedure dropped.

SQL> drop PROCEDURE "APPUSER01"."DBMS_STANDARD_FUN9";

Procedure dropped.

7.添加黑名单防止再次注入

在启动数据库前，需要将出入病毒的连接IP查找出来加入黑名单，以防再次发生病毒注入。通过监听日志查找问题时间段的PLSQL连接

[oracle@host01 trace]$ fgrep "24-MAY-2019 10:5" dd1.log |fgrep "establish" | fgrep "plsql"

24-MAY-2019 10:50:05 * (CONNECT_DATA=(SERVICE_NAME=service1)(CID=(PROGRAM=C:\PLSQL Developer\plsqldev.exe)(HOST=host1)(USER=user1))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.xx.xx.xx)(PORT=xxx)) * establish * epmjc * 0

24-MAY-2019 10:51:01 * (CONNECT_DATA=(SERVICE_NAME= service1)(CID=(PROGRAM=C:\Program Files\PLSQL Developer\plsqldev.exe)(HOST=host1)(USER=user1))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.xx.xx.xxx)(PORT=xx)) * establish * epmjc * 0

…

查找所有节点的监听日志，发现疑似携带病毒的机器IP有5个，并同时检查下面ip对应机器上的三方程序是否有异常。

检查这些机器是否携带病毒需要时间，为了及时恢复应用，将上述5个ip全部加入数据库黑名单，sqlnet.ora添加配置示例如下

TCP.VALIDNODE_CHECKING=YES

tcp.excluded_nodes=(xxx.xx.xx.xx,xx.xx.xx.xx)

8.恢复业务

启动监听，检查数据库（注意：因为还有job没有删除，job_queue_processes仍然为0），联系应用验证数据一致性和可用性。

数据丢失和问题回溯

1.检查数据丢失情况

APPUSER01用户下的表丢失数据，通过数据库历史视图查找数据库truncate操作

SQL> select * from dba_hist_sqltext where upper(SQL_TEXT) like '%TRUNCATE TABLE%';

DBID SQL_ID SQL_TEXT COMMAND_TYPE

---------- -------------------------- -------------------------------------------------------------------------------- ------------

2584110390 b1undrf93t007 DECLARE job BINARY_INTEGER := 1; broken BOOLEAN := TRUE; next_date DATE := SYSDA 47

2584110390 48v643w2mr5ax DECLARE job BINARY_INTEGER := 1; broken BOOLEAN := TRUE; next_date DATE := SYSDA 47

2584110390 9up4qgk4udmq3 DECLARE job BINARY_INTEGER := 1; broken BOOLEAN := TRUE; next_date DATE := SYSDA 47

…

108 rows selected.

从上面的历史sql视图可以看出，数据库在注入病毒后，于2019年5月24日11：02分钟左右病毒程序truncate了约108张表。

2.Job的处理

病毒程序创建了超级多的job

select count(*) from dba_jobs where schema_user='APPUSER01' and what like '%truncate%';

count出来大概有4kw行，system表空间都要撑满了

逐条删除job需要花很多时间，可以使用并行来跑

begin

for i in (select job from dba_jobs

where schema_user='APPUSER01' and what like '%truncate%' and mod(job,4)=0 )

loop

dbms_ijob.remove(i.job);

end loop;

end;

大概跑了20+小时，干掉了这些病毒程序的job。

Remove操作有点类似delete，基表job$的段空间是没有收缩的，水位线仍然是4kw的时候那么高。虽然查询dba_jobs很慢，但是出于安全考虑没有降低基表的水位线，但是实测trunc是没有问题的，可以备份jobs，然后trunc job$，再创建job应该就没问题。注意：不要使用move，move会使job$上的索引失效，而且基本无法创建索引，也无法创建job。

3.原因分析

我们检查了可疑IP中的4个，发现PLSQL中的AfterConnect.sql和login.sql都没有异常。其中afterconnect.sql的大小应该是0字节，login.sql打开后只有一句注释“- -Autostart Command Window script ”。如果这两个文件里有其他内容，应该怀疑是病毒。

但最后一个IP，没有在本地，通过本地360扫描出了病毒程序

4.病毒事件梳理

在2019年5月24日10:58:05业务某机器通过携带病毒的PLSQL连接到数据库的APPUSER01用户，导致了该数据库被注入勒索病毒。2019年5月24日11:02该病毒程序删除了APPUSER01下的部分数据，2019年5月27日11:15病毒程序阻止了数据库会话登陆，抛出勒索比特币告警信息，从而导致此次业务长时间中断和数据丢失。

本次病毒事件本质是携带病毒程序的客户端连接数据库后sql注入。该比特币勒索病毒程序创建了大量的job，通过job在数据库中捣乱，包括删数据、抛出比特币勒索信息、锁定数据等等。只要删除这些job就可以清理病毒程序。