记一次勒索病毒下的Oracle数据恢复

【先声明，未经本人允许禁止转载抄袭】

分享一次oracle数据库在被勒索病毒加密的情况下是如何最大程度挽救数据的。

春节后，开工前，我们例行检查各项目的系统运行情况时，在某项目的服务器上发现了这样一个文本。

 

经检查，两台服务器全部遭受到勒索病毒的攻击，应用程序、数据库文件及备份数据均被恶意加密。通常，在检查数据库故障的时候，我都会习惯先登陆SQL*PLUS来查看数据库的运行状态，然后再查看告警日志。当调用SQLPLUS命令的时候，发现由于大批量的恶意加密，操作系统的常规应用程序已经无法被调用。

 

 

 查看告警日志，发现每个日志文件的头部均存在一定篇幅的乱码，继续向后翻阅，发现后续的主体字符是正常的状态，尾部存在少量加密。结论是文件头部被加密或篡改，并在文件尾部生产加密信息，但文件主体还是完好的。如果此判断为真，那么绕开勒索病毒直接恢复数据块就具备了成功的可能性。

一般来说，勒索病毒在整个加密过程与RSA Session Key的加密过程基本一致，病毒作者通过随机生成的AES-256 key对文件进行加密，要想解密这类文件，必须得有RSA Session Private Key，而此文件又被RSA Public Key加密了。所以，必须等待病毒作者释放手中的RSA Private Key才能完全解密。好在Oracle数据的特殊结构，以及数据文件通常都比较大，导致勒索病毒要全盘加密它们时要花费大量时间和CPU，因此这些勒索软件一般仅部分加密其内容，这就给了我们在数据文件底层恢复数据的机会。

  翻阅日志到尽头，获取了数据库最后一次进行自我拯救的时间节点，找到了在它完全崩溃前最后一刻给我们留下的报错信息。

在确认病毒已停止传播后，将全部数据库文件及日志文件拷贝出来，放到了一块移动硬盘里。为了判断数据块加密逻辑同时检查被加密的数据块数量，首先编写脚本，对系统表空间（SYSTEM）进行逐个数据块的读写检查，以确认文件加密范围。  

 

 出乎意料的是，系统表空间的895个数据块全部可以正常读写。这个结果令人比较困惑，根据扫描结构判断，病毒既然没有锁定数据块，那大概率是破坏或修改了一部分数据信息。

 为了进一步诊断数据块的实际情况，准备采用BBED（Oracle Block Brower and EDitor Tool）进行深度校验。BBED是用来直接查看和修改Oracle数据块的一个内部工具，它可以直接修改Oracle数据文件块的内容，在一些极端恢复场景下比较有用。该工具不被Oracle服务支持，需要自行编译。它是一个非常危险的工具，稍有不慎数据库将会万劫不复。

常规的BBED是只能在编译Linux环境下，由于我们的数据库是运行在Windows环境下，需要先基于Windows环境编译BBED。

 

尝试通过set命令关联到数据文件，BBED要求关联的数据文件必须是一个有效的Datafile，这里不得不赞美BBED优秀的识别能力，篡改后的数据文件被成功识别了。通过BBED对系统表空间进行检查，检查结果再次令人惊讶。除了文件头被破坏外，勒索病毒居然还精准的修改了文件头里边的属性信息，11G版本的系统文件居然被病毒贴上了10G的标签，这一系列恶意修改直接影响了后续的扫描效果。

通过BBED对表空间数据文件进行几次随机的读取后，基本确认了数据块是能够恢复的。由于1号文件文件头损坏，无法找到Rootdba，需要手工指定Block。

 恢复数据的第一道坎就是获取数据字典（Dict）,有了这套目录我们才能精准的识别各类用户、表数据。在这种极端情况下，BBED无法帮我们获取数据字典。为了获取数据字典，我先后尝试了论坛上一些大佬前辈们编写过的恢复工具，但均以失败告终。由于勒索病毒的恶意修改，其中多数工具都无法识别数据文件，直接报错提示“这些不是数据库文件”。虽然没有成功，但其中“某某数据恢复工具”的一项报错信息给了我一定启发，那就是先手动提取数据库版本、表空间号、相对文件号，再来推算其余的信息。

 

 

由于数据库已经完全崩溃，无法查阅系统视图，为了获取以上各项信息，我再次翻开了备份出来的日志文件，在我自己的Oracle环境中进行了数据挖掘（Logmine），最终获取了需要的信息。

但当我编译好属性后再次检测，依然失败了。

突然想起BBED可以从Datafile中直接获取数据，为了验证可行性，开始对部分数据进行挖掘测试。BBED可以搜索关键字，使用Find命令在指定的Block中查找指定的字符串，可以显示出字符串及其偏移量，在Block中的字节数可以从Offset 0 搜索到Top 或者从当前的Offset 搜索到Top。至此确认了一小部分数据表中的数据是可以恢复的。

 

 

庆幸的是，勒索病毒只修改了文件头，我决定干掉这部分数据，参照状态健康的数据文件，通过BBED对数据文件头进行了修改。至此，数据文件已具备恢复数据块的条件。

为了高效、批量、完整的恢复全套数据，必须要对所有数据文件实现一次完整扫描。扫描过程持续了半小时左右，至此数据结构几乎已完整呈现。再深一步提取，一些DDL类的SQL甚至已经浮出水面。有些SQL并不是直接可以使用的，有些字符没有被顺利转换成可被Oracle识别的格式，需要手动调整。

随后我尝试了通过BBED实现Online表空间Copy Offline表空间数据的特殊操作。实现原理是“The copy command is used to copy blocks from one location to another. As with other commands, the file or filename and offset can be specified, or the DBA can be specified instead.”通俗的理解，就是把一个块的内容拷贝到另一个块中。

在BBED及一些论坛工具的帮助下，同时连接两套数据文件，数据块得到了提取。比较遗憾的是由于索引、主键等数据存放在了特殊的位置，被病毒破坏掉了一部分，不过好在我们可以通过其他项目的数据库来提取这些创建DDL，进行批量处理。

最终通过我正常的数据库环境，导出了6个用户的表数据，历时9个小时完成了这次数据恢复的主要工作内容。

这是一次从未有过的大战，希望能够把经历分享出来与大家共勉，我们应时刻警惕，保持对病毒的敬畏，做好网络防护及日常备份，向勒索病毒说“不”。

行之所向，莫问远方