[转]著名安全专家Litchfield对Oracle开火

著名的数据库安全专家 Litchfield为自己赋予的使命就是告诉全世界数据库软件并不安全——特别是Oracle的数据库。Litchfield曾经公开批评Oracle,甚至要求Oracle首席安全官Mary Ann Davidson下台。

Litchfield认为,长期以来,Oracle及其用户在安全领域里一直象鸵鸟一样把头插在沙子中。 Oracle采用了错误的方式来解决安全问题。

英国下一代安全软件的合作创办人Litchfield正在进行一场圣战。今年一月,他出版了一本Oracle黑客手册。手册的封面上说为读者提供了完整的访问和防护Oracle系统的方法。

在批判Oracle的同时,Litchfield却对微软极力推崇。他曾经公开声称微软最新的数据库软件SQL Server 2005是安全的。这种声明一定严重的伤害到了微软的主要竞争对手Oracle。Oracle已经眼看着一大块数据库市场划归了华盛顿Redmond的软件巨人。

在上周召开的Black Hat DC大会上,Litchfield讨论到了一种新的袭击技术使Oracle数据软件的漏洞问题更加严重。他向ZDNet澳洲的姐妹网站CNET News.com解释了揭露漏洞的必要性。

问:为什么您对数据库安全如此关注?还有其他那么多软件。 Litchfield: 数据库安全对于任何组织机构来说就象是王冠上的珠宝。这个星球上的每家机构都有数据库,而这组织机构存在的活力之源。没有什么比从源头进行把握更有效的安全措施。我们能够在周边进行安全工作,但是如果软件本身带有SQL injection这样的漏洞,那么安全措施就前功尽弃了。

我与Oracle的关系已经有所缓和。

尽管有防火墙,尽管网络服务器已经被锁定,但是网络应用中的SQL injection缺陷就能让我们一路畅通的进入数据库服务器的后端。如果这个数据库没有采用最低权限,或者没有完全打好补丁,那么我们就能对数据库进行充分的访问并攫取全部数据。

数据库必须是安全的。问题是在最近以前,没有人真正的处理过数据库服务器的后端。也就是说过去人们采取的都不过是外围安全措施。

最近您对Oracle的数据库相当关注。是有什么特别的原因让您对Oracle倾注更多吗? Litchfield:是的。SQL Server 2005是安全的。因为微软解决了问题。Oracle正在解决问题。对于IBM,我研究过DB2和Informix,并为他们指出了从缓存溢出到权限增加等大约50个bug,IBM安全部门的反应是成熟的。

最近,Oracle安全部门的反应就没那么成熟。他们气势汹汹的,与“这个家伙在让我们的产品更安全”的想法完全相反。不过他们的态度现在有所好转。Oracle正在开始理解我和他们站在同一条战线上,只是彼此的看法不同。

当Oracle这样的厂家态度强硬时,您就会变得更加强硬? Litchfield:是的。很遗憾我正是这样行事的。但是如果你不得不保护自己,那么就保护自己吧。我更愿意去工作,就象我对微软和IBM那样,与他们的安全响应团队一起工作。我们与微软和IBM拥有良好的关系。有什么比良好的关系好的成事方法呢?我可不想站在浑水中互相指责。

我与Oracle的关系有所缓解,他们理解这并不是一场意志上的对决。我努力使他们了解他们数据库所存在的问题,因为这些问题对我造成了直接的对影响。如果有人闯入数据库服务器然后窃取了我的信息,付出代价的是我,而不是Oracle

有人可能会认为这有点象敲诈。 Litchfield:我可从来没有向Oracle索要过财物。如果人们这么想,那么他们得到的信息可能有误。

 

 

那么微软也没有雇用你来说SQL Server 2005是安全的? Litchfield:我说微软的产品是安全的但是没有从微软那里得到什么报酬,如果任何人在SQL Server 2005中找到bug,那个人最好是我。如果别人找到什么bug,它会破坏我将来判断产品是否安全的能力。因此,如果在SQL Server 2005中的确存在bug,我希望是我首先发现。我很期待。

 

 

微软过去和现在是否是NGS软件的客户? Litchfield:NGS的确在微软工作,但我们并不是受雇来说他们是安全的——我们被雇来使他们的产品更安全。对于微软和NGS来说,现在以及将来的独立性都很重要。否则我们工作的正确性以及微软为使产品更安全所进行的努力就会遭到怀疑。这就是NGS 依然在为微软的产品提出安全建议的原因。

 

 

我听说您曾经担任SQL Server 2005的安全审计工作,是这样吗? Litchfield:我不能说具体的说到我们所做的项目。这样,如果有人对SQL Server是否比Oracle安全的问题存在疑问,他所要做的就是想想包括那么多顶级研究人员在内的很多人都曾经研究过两个产品,寻找过安全漏洞。而SQL Server已经很长时间没有被发现问题了。我再重复一遍,如果有人在SQL . . . → Read More: [转]著名安全专家Litchfield对Oracle开火

历数几款第三方的Oracle数据库安全及漏洞扫描软件

NGSSQuirreL-for-Oracle_5

虽然oracle公司自有一套丰富的数据库产品线, 包括 oracle advanced security, VDP , Database vault , lable security , Database FireWall 等等。

但我们还是有必要关注一些第三方的 安全工具, 这些安全工具的主要用途 包括: 漏洞扫描,风险评估,安全建议,审计等。

 

Secure Oracle Auditor - Secure Bytes 的产品 图形化的集中式审计工具, 可以自定义审计策略; 并分析数据库风险, 产品主页: http://www.secure-bytes.com/soa.php

软件截图:

 

 

Oracle Database Encryption Wizard For Oracle – Relational Database Consultants, Inc (RDC)的产品 主要功能是 数据加密, 支持 AES256 . . . → Read More: 历数几款第三方的Oracle数据库安全及漏洞扫描软件

如何禁止特定用户使用sqlplus或PL/SQL Developer等工具登陆?

logon_plsqldeveloper

最早想要实现禁止某些特定用户使用SQLPLUS或PL/SQL Developer等工具登陆是在2010年的3月,当时发现用户的一套数据库中有大量的用户使用老版本的PL/SQL Developer登陆,具体的版本号记不清楚了,大约是PL/SQL Developer 5的版本,是否正版授权不得而知, 反正就是一个办公室里有大量的阿姨、大叔都靠这个图形化工具访问数据库,做一些必要的数据操作,主要是一些SQL查询语句,有时候他们还会用工具栏查一些对象(search object),正是因为他们使用了老版本的PL/SQL Developer,造成在使用一些widget的时候会引起Oracle出现一些非致命的ORA-00600错误,虽然这些600错误不会导致严重的问题,但是只要是出现在告警日志Alert.log中的600还是需要我们去分析。

当时我的想法是直接从Oracle的角度禁止普通用户以PL/SQL Developer工具登陆,虽然当时没有真的这样做。 题外话,要真的这么做了,估计那一办公室的阿姨、叔叔都要找我的麻烦,他们可不会用SQLPLUS来登数据库;让他们升级PL/SQL Developer到高版本的想法也基本可以打住,让阿姨、叔叔们升级可要比登天还难。

Google了一番,没有找到太多有用的信息。

闲来无事,我在著名的Oracle-l Freelist邮件列表中发了一封邮件,集思广益:

 

Hello every, Anyone can advise how to ban plsql developer connect to oracle? The plsql developer search widget may cause some ora-600 warning in alert log . So I want to ban any connection using plsql developer.

 

Oracle-l . . . → Read More: 如何禁止特定用户使用sqlplus或PL/SQL Developer等工具登陆?

Find password cracker in 11g

在11g中默认启用了对登录注销操作LOGON/LOGOFF的审计,详见<11g默认审计选项>。利用这一点我们可以很方便地从审计日志中找出数据库中的密码暴力破解者。如以下演示:

C:\Users\Maclean Liu>sqlplus system/try_password@G11R2 SQL*Plus: Release 11.2.0.1.0 Production on Mon Jul 4 21:37:44 2011 Copyright (c) 1982, 2010, Oracle. All rights reserved. ERROR: ORA-01017: invalid username/password; logon denied select username,userhost,terminal,timestamp,action_name,os_process from dba_audit_trail where returncode = 1017 order by timestamp desc; USERNAME USERHOST TERMINAL TIMESTAMP ACTION_NAME OS_PROCESS ——————– —————————————- ——————– —————— —————- ———— SYSTEM WORKGROUP\MACLEANLIU-PC MACLEANLIU-PC . . . → Read More: Find password cracker in 11g

11g默认审计选项

11g默认启用强大的审计选项,AUDIT_TRAIL参数的缺省值为DB,这意为着审计数据将记录在数据库中的AUD$审计字典基表上。Oracle官方宣称默认启用的审计日志不会对绝大多数产品数据库的性能带来过大的负面影响,同时Oracle公司还推荐使用基于OS文件的审计日志记录方式(OS audit trail files)。

注意因为在11g中CREATE SESSION将被作为受审计的权限来被记录,因此当SYSTEM表空间因磁盘空间而无法扩展时将导致这部分审计记录无法生成,这将最终导致普通用户的新会话将无法正常创建,普通用户将无法登陆数据库。在这种场景中仍可以使用SYSDBA身份的用户创建会话,在将审计数据合适备份后删除一部分记录,或者干脆TRUNCATE AUD$都可以解决上述问题。

当AUDIT_TRAIL设置为OS时,审计记录文件将在AUDIT_FILE_DEST参数所指定的目录中生成。全部这些文件均可以随时被删除或复制。

注意在默认情况下会以AUTOEXTEND ON自动扩展选项创建SYSTEM表空间,因此系统表空间在必要情况下还是会自动增长的,我们所需注意的是磁盘上的剩余空间是否能够满足其增长需求,以及数据文件扩展的上限,对于普通的8k smallfile表空间而言单个数据文件的最大尺寸是32G。

以下权限将对所有用户审计:

SQL> select * from v$version; BANNER ——————————————————————————– Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 – 64bit Production PL/SQL Release 11.2.0.2.0 – Production CORE 11.2.0.2.0 Production TNS for Linux: Version 11.2.0.2.0 – Production NLSRTL Version 11.2.0.2.0 – Production SQL> select * from global_name; GLOBAL_NAME . . . → Read More: 11g默认审计选项

Oracle Advanced Security:Column Encryption Overhead

在Oracle 10g中出现了column encryption列加密特性,通过对列上的数据加密实现数据安全性的目的。当然实现这一加密特性是有代价的,一方面会导致所加密列数据每行所占磁盘空间字节数增长,另一方面会消耗更多的cpu和内存资源。

当使用Oracle的TDE(transparent data encryption)加密数据表的某一列时将导致该表上每行数据所占用的空间大致增加33-51个字节,这几十个字节用作以下用途:

其中20个字节用以对加密值的完整性检查,该部分可以通过’nomac’选项来省略 同时加密会填补加密值到16个字节(如果列本身长度不够的话),举例来说如果是9个字节长度的number类型,那么加密该number字段时就会需要将该数据填补到16个字节,也就是额外地多用了7个字节 加密时默认采用salt选项(default),salt是指一串长度为16个字节的随机string,在数据被正式加密前这串string将会被添加到列上,这种做法使得黑客无法通过比对已知的密文来匹配加密值(steal patterns of ciphertext to known ciphertext);salt总是位于加密数据的末尾;该部分可以通过no salt选项来省略。

注意默认使用salt选项加密的列是不能创建索引的,所以强烈建议加密列时强制使用no salt选项!加密列上的索引不支持范围扫描操作(Range scans on encrypted columns can’t use index),而加密表空间(encryption tablespace)没该限制。

SQL> create table enctab (t1 int encrypt); Table created. SQL> create index ind_enc on enctab(t1); create index ind_enc on enctab(t1) * ERROR at line 1: ORA-28338: Column(s) cannot be . . . → Read More: Oracle Advanced Security:Column Encryption Overhead

Addressing Data Privacy,Regulatory Compliance,and Insider Threats

Protecting data privacy is harder for our customers today than it’s ever been.

In a recent report, the Identity Theft Resource Center cited a record 443 breaches in the U.S. in 2007, up 40% from the previous year. This represents more than 127M records with sensitive identity or credit card information that have been . . . → Read More: Addressing Data Privacy,Regulatory Compliance,and Insider Threats

Oracle Database Security-Competing against Microsoft SQL Server 2008

Data Security and Compliance Databases Now The Most Valuable Enterprise Asset More data means more value to the bad guys Digital data explosion: 1800 exabytes by 2011 (IDC) Insider theft and fraud is now top of mind for IT groups Business partners implicated in 40% of data breaches (Verizon) Hackers attacking from inside the firewall . . . → Read More: Oracle Database Security-Competing against Microsoft SQL Server 2008