中招ORACLE比特币勒索病毒——处理过程详解
目录
病毒告警
事件处理
1.修改job参数，防止病毒程序自启
2.杀掉job进程，停止正在运行的病毒程序自动任务
3.禁用数据库监听
4.杀LOCAL=NO的会话
5.查找病毒程序
6.删除病毒程序的存储过程、触发器
7.添加黑名单防止再次注入
8.恢复业务
数据丢失和问题回溯
1.检查数据丢失情况
2.Job的处理
3.原因分析
4.病毒事件梳理
总结与建议
病毒告警
某客户核心业务系统中招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就可以清理病毒程序。
总结与建议
ORACLE比特币勒索病毒可以追溯到2016年，国内很多用户的Oracle 数据库中病毒。时隔3年（事件发生于2019年），勒索病毒似乎卷土重来。
本次故障直接造成业务长时间无法连接数据库，造成数据永久丢失，原因就是不安全的PLSQL连接到了核心库。
几乎绝大多数客户端工具，在访问数据库时，都可以通过脚本进行一定的功能定义，而这些脚本往往就是安全问题的漏洞之一，来历不明的工具是数据库管理大忌。通过此次数据库勒索病毒事件可以看出，数据库安全的重要性，不要抱着“不会发生在我身上”的想法管理数据库，一切都是命运的安排。
为了防止勒索病毒不再发生，提高数据安全性，建议如下：
1.严格管理权限。回收所有业务用户的dba权限，在保障数据安全和应用可用的前提下，提供用户最小权限。
2.排查三方工具。大范围排查是否还可能有不明来源的第三方工具连接数据库，必须从官方渠道获取客户端连接工具。以下列出了常见客户端工具的脚本位置，需要引起注意
SQL*Plus: glogin.sql / login.sql
TOAD : toad.ini
PLSQLdeveloper: login.sql / afterconnect.sql
3.通过官方渠道下载补丁包。补丁包中也可能包含病毒程序，下载官方补丁包是基本规范操作。
4.设置白名单。限制IP登录，非白名单中的IP不允许登录数据库，提高数据的安全性。
5.日常巡检。把病毒扫描脚本加入日常巡检中，早发现早处理。
6.开启数据库审计。数据库审计在跟踪用户操作上更加全面，审计会捕获用户登录数据库及登录后的各项操作
中招ORACLE比特币勒索病毒——处理过程详解相关推荐
- python os模块安装方法_基于python中pygame模块的Linux下安装过程(详解)
一.使用pip安装Python包 大多数较新的Python版本都自带pip,因此首先可检查系统是否已经安装了pip.在Python3中,pip有时被称为pip3. 1.在Linux和OS X系统中检查 ...
- android启动页使用gif,android中使用react-native设置应用启动页过程详解
一.背景 在我们使用react-native进行编写代码的时候,当启动应用的时候,我们会看到如下界面 然而,这样的启动界面是非常的不又好,那么我们该怎么进行处理启动界面呢?有如下两种方案 二.方案 1 ...
- python中pygame模块下载_基于python中pygame模块的Linux下安装过程(详解)
pyhthon中pygame模块怎么安装?pyhthon中pygame模块怎么安装?鄙人为初二一名学生,闲来无事 钻研起电这句话还是建议问一下你们代课老师吧,因为你们老师是这方面专家,诺儿那边的话肯定 ...
- 数据库比特币勒索病毒攻击警示，云和恩墨技术通讯六月刊精选
各位亲爱的用户/读者朋友们: 为了及时共享行业案例,通告共性问题,达成知识共享和提前预防,我们整理和编辑了<云和恩墨技术通讯>(6月刊),通过对过去一段时间的知识回顾和故障归纳,以期提供有 ...
- uboot配置和编译过程详解
▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼ 分享一个大神朋友的人工智能教程.零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到 ...
- 国内首个比特币勒索病毒制作者落网，但过程有点好笑...
点击上方蓝色"程序猿DD",选择"设为星标" 回复"资源"获取独家整理的学习资料! 来源:扩展迷EXTFANS 所谓比特币勒索病毒,就是某一 ...
- 超实用的脚本——检查oracle数据库是否存在潜伏的比特币勒索病毒
转载来源 : 超实用的脚本--检查oracle数据库是否存在潜伏的比特币勒索病毒 : http://www.safebase.cn/article-254989-1.html 概述 分享一个工作中经常 ...
- WannaCry勒索病毒分析过程**中**（注）
WannaCry勒索病毒分析 中(注) 我犯了一个很大的错误,就是在做分析的时候没有确定函数的作用,在分析过程中有捉不到重点的毛病. 在WannaCry.exe的分析中,它在判断打开它的URL后,如果 ...
- @程序员，快收下这份比特币“勒索病毒”应对须知！
作者 | JiekeXu 责编 | 胡巍巍 风险从来都不是臆想和草木皆兵,就在你不经意的时刻,可能风险就突然降临到我们的身边. 发现比特币勒索病毒 业务账号无法连接数据库 2018年7月18日早上10 ...
最新文章
- jspstudy启动mysql失败_MySql启动数据库设置初始密码
- mysql存储过程分析
- fft的c语言和matlab对比_Matlab系列之程序控制
- arcade 物理系统_如何使用Python和Arcade库创建2D游戏
- Android UI系列-----ScrollView和HorizontalScrollView
- Qt程序启动画面QSplashScreen类
- ICLR'22 | 审稿结果统计速览
- 网络_简单实现远程唤醒与远程控制（Teamviewer）
- Entity Framework 5.0
- 第9章 逻辑回归 学习笔记 下
- RocketMQ消费端消息回退（消费重试）机制源码解析
- 如何在Linux上录制你的终端操作
- 关于vs08生成解决方案慢的解决方法
- 2019长江课堂作业答案_2019版长江课堂作业答案语文四年级
- cass生成里程文件桩号不全,cass生成桩号
- matlab创建个性化绚丽色彩图
- HDU 6080 2017百度之星程序设计大赛 - 资格赛
- 魔百和CM311-1a_YST代工_安卓9.0_S905L3A_卡刷固件包
- Airbnb是如何创造更好的邮件体验的
- kubernetes(K8S)容器部署，重新启动后，node节点提示notready无法正常工作。