Oracle数据库勒索病毒RushQL卷土重来，别慌，有对策!
mhr18 2024-10-15 11:05 18 浏览 0 评论
一、Oracle数据库勒索病毒死灰复燃
2018-11-19 国家信息安全漏洞共享平台正式发布通告“Oracle数据库勒索病毒RushQL死灰复燃”。转载原文如下：
从这封简短的通告我们可以发现，RushQL勒索病毒已经不是第一次肆虐Oracle数据库，早在2016年11月就已经在全球掀起了一场血雨腥风。当然，那时候它有个更响亮的名字“比特币勒索病毒”。
目光回溯到2016年11月，全国多家企事业单位遭受比特币勒索通知“你的数据库已被锁死，发送5个比特币到这个地址！”。用户在登陆Oracle数据库时出现如下勒索警告信息，被要求上交5个比特币来换取解锁数据库的服务。
时隔整整两年，RushQL勒索病毒卷土重来，发动新一轮的肆虐。我们不禁要反问自己：为什么我们会遭到同一勒索病毒连续攻击？数据库安全厂商能帮助数据库用户做些什么？
作为一家专注数据库安全的厂商，安华金和早已对RushQL勒索病毒进行了深度的解析并提供了解决方案。
二、勒索病毒攻击原理分析
早在2016年RushQL勒索病毒出现的时候，安华金和的攻防实验室就对该病毒做了深度分析，并提供了有效的检测和防护措施。
RushQL勒索病毒攻击的目标人群是数据库管理人员（DBA）。通过在CSDN等网站上恶意散播携带勒索病毒的PL SQL Developer（PL/SQL）软件程序，引诱用户下载并发起勒索攻击。
携带RushQL病毒的PL/SQL，解压后主目录的AfterConnect.SQL文件存在异常。官方的PL/SQL下AfterConnect.SQL是空文件，而异常的AfterConnect.SQL有 35KB。
该脚本的关键代码，采用了 Oracle数据库专用代码加密工具wrap进行了加密，我们对病毒脚本进行解密后发现，该脚本的主要功能是创建4个存储过程和3个触发器：
存储过程 DBMS_SUPPORT_INTERNAL
存储过程 DBMS_STANDARD_FUN9
存储过程 DBMS_SYSTEM_INTERNA
存储过程 DBMS_CORE_INTERNAL
触发器 DBMS_SUPPORT_INTERNAL
触发器 DBMS_ SYSTEM _INTERNAL
触发器 DBMS_ CORE _INTERNAL
三个触发器本身没有问题，问题在于存储过程。以DBMS_SUPPORT_INTERNAL为例，该存储过程的核心是两条SQL语句：
第1条SQL语句：SELECT NVL(TO_CHAR(SYSDATE-CREATED ),0) INTO DATE1 FROM V$DATABASE; IF (DATE1>=1200)
语句含义：根据创建数据库时间和当前时间差值做决定：是立刻入侵数据库实施勒索，还是先保持潜伏直到条件成熟再爆发进行勒索。判断条件为数据库实例创建时间距今是否满足1200天，一旦满足并重启数据库实例则执行第2条SQL语句。
第2条SQL语句：EXECUTE IMMEDIATE'create table ORACHK'||SUBSTR(SYS_GUID,10)||' tablespace system as select *from sys.tab