ATTENTION!!!ORACLE比特币勒索病毒——处理过程详解

病毒告警

某客户核心业务系统中招ORACLE数据库勒索病毒。 告警日志出现自动任务执行错误,对象被锁,并出现“你的数据库已被SQL RUSH Team锁死  发送5个比特币到这个地址166xk1FXMB2g8JxBVF5T4Aw1Z5aZ6vSE (大小写一致) 之后把你的Oracle SID邮寄地址 sqlrush@mail.com我们将让你知道如何解锁你的数据库”的信息(别发,数据丢失他们找不回来,病毒程序云和恩墨可以处理)。当时的告警日志如下:

事件处理

修改job参数,防止病毒程序自启

alter system set job_queue_processes=0;

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

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

禁用数据库监听自启动,关闭监听,防止携带病毒的客户端再次连接

srvctl disable listener

srvctl disable scan_listener

srvctl stop listener

srvctl stop scan_listener

杀LOCAL=NO的会话

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

查找病毒程序

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

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

--一般会跟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.

在启动数据库前,需要将出入病毒的连接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)

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

 

 

数据丢失

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张表。(小广告:数据库中病毒或者数据丢失,可以联系云和恩墨团队进行专业处理)

 

 

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。

原因分析

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

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

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

总结与建议

ORACLE比特币勒索病毒可以追溯到2016年,国内很多用户的Oracle 数据库中病毒。时隔3年,勒索病毒似乎卷土重来。

本次故障直接造成业务长时间无法连接数据库,造成数据永久丢失,原因就是不安全的PLSQL连接到了核心库。

几乎绝大多数客户端工具,在访问数据库时,都可以通过脚本进行一定的功能定义,而这些脚本往往就是安全问题的漏洞之一,来历不明的工具是数据库管理大忌。通过此次数据库勒索病毒事件可以看出,数据库安全的重要性,不要抱着“不会发生在我身上”的想法管理数据库,一切都是命运的安排。

为了防止勒索病毒不再发生,提高数据安全性,建议如下:

1.严格管理权限。回收所有业务用户的dba权限,在保障数据安全和应用可用的前提下,提供用户最小权限。

2.排查三方工具。大范围排查是否还可能有不明来源的第三方工具连接数据库,必须从官方渠道获取客户端连接工具。以下列出了常见客户端工具的脚本位置,需要引起注意

SQL*Plus: glogin.sql / login.sql

TOAD : toad.ini

PLSQLdeveloper: login.sql / afterconnect.sql

3.通过官方渠道下载补丁包。补丁包中也可能包含病毒程序,下载官方补丁包是基本规范操作。

4.设置白名单。限制IP登录,非白名单中的IP不允许登录数据库,提高数据的安全性。

5.日常巡检。把病毒扫描脚本加入日常巡检中,早发现早处理。(小广告,恩墨白求恩产品可以检查出数据库是否带病毒,免费!(https://bethune.enmotech.com)

6.开启数据库审计。数据库审计在跟踪用户操作上更加全面,审计会捕获用户登录数据库及登录后的各项操作

展开阅读全文
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值