比特币勒索的趋势
近年来比特别勒索逐渐跳出Windows和移动端的限制,从勒索个人向勒索数据价值更高的金融、医疗、零售、教育等行业进发。2015年开始,有迹象表明,大部分贩卖比特币勒索负载的黑客团体在尝试并探索更多样威胁企业数据的方法。企业的关键数据主要保存在数据库中,因此和数据库相关的文件已经成为勒索软件的首要目标。据统计,2016年全年共有96%和81%的加密勒索软件会针对数据库数据文件和SQL文件进行加密勒索。
和数据库相关的文件已经成为勒索软件的首要目标
除了利用操作系统对数据文件实施加密勒索的手法外,安华金和攻防实验室总结发现了大量直接针对数据库的比特币勒索攻击,直接针对数据库的比特币勒索软件在不同场景下有较大区别。
针对数据库的比特币勒索攻击
随着黑客团体对数据库的深入了解,2016年底无论是云环境的数据库还是内网环境的数据库都遭遇了大规模勒索攻击。从2016年12月27日开始,云环境上的mongodb、ElasticSearch、Cassandra、redis、hadoop、CounchDB、MySQL等数据库接连遭到多个黑客团体实施比特币勒索,甚至出现一同台数据库被不同黑客组织重复勒索。此次大规模针对数据库的持续勒索攻击最终造成数以万计的数据库被黑客勒索。就在同一时段内,网数据库也遭遇了黑客的比特币勒索,虽然内网数据库被感染的数量远不如云上的数据库,但单笔勒索的费用要比云上数据库高出许多。
黑客在攻击云上数据库和内网数据库中采取了截然不同的思路,云上更类似我们前面提到的乱枪打鸟式。黑客基于43亿个IPv4地址做整体扫描,通过未设身份验证或弱口令,入侵数据库,利用拿到的数据库权限对数据进行删除、隐藏或转移,最后留下勒索信息。虽然这种类型每笔勒索费用不高,但庞大的基数还是给黑客团体带来了丰厚的利润。针对内网的数据库勒索则采取了完全不同的打法,他们在知名论坛上挂载夹杂恶意代码的专业工具,利用受害者使用工具的机会,把恶意代码注入到数据库中,在确认数据库有足够有价值的数据之后才实施勒索行为,反之则会潜伏在数据库上伺机爆发。这种勒索软件具有很强的隐藏性和反侦察性。
云上数据库的比特币勒索
针对云上数据库的比特币勒索具备明显的特征化和自动化,以2016年12月云上mongodb被勒索为例,此次攻击黑客整个过程完全采用了自动化脚本。攻击主要分成两大部分:第一部分是下图的红线区——扫描准备阶段。黑客利用脚本在43亿的IPv4上对27017(27017端口是mongodb安装后的默认通讯端口)端口进行批量扫描,通过指纹识别目标IP是否存在mongodb数据库,如果存在,再次尝试登录。如果登录成功则把IP记录在可入侵列表中,准备在第二阶段使用。(mongodb 默认安装无密码,只要知道IP和端口就可以访问)
针对云上数据库的比特币勒索具备明显的特征化和自动化
在黑客获得足够多的可入侵IP后,可以启动图中绿线的部分。这部分是实际进行勒索攻击的部分。自动化脚本从可入侵列表中批量取出IP地址,利用pymongodb登录目标数据库。然后通过mongodbdurp下载数据到指定服务器(后来发现此次有部分黑客根本没转移数据就直接删除,也就是说即便受害者付了赎金依然无法取回数据),删除数据库中数据,最后插入勒索信息,等待赎金。
删除数据库中数据,最后插入勒索信息,等待赎金
这种全自动化的勒索过程,往往需要目标数据库广泛存在安全漏洞或配置错误。12月份到1月份的云上数据库勒索惨剧就是利用了NoSQL数据库默认不做身份验证的缺陷。如果以足够的安全标准来配置数据库或积极升级,相信可以极大地避免此类勒索攻击事件发生。
内网数据库的比特币勒索
内网数据库的比特币勒索思路和云上的截然不同,不再是通过扫描和指纹发现数据库。而是通过把恶意代码隐藏在数据库工具中。例如同期爆发的Oracle比特币勒索,就是在Oracle知名工具PL SQL Developer中加入恶意代码。恶意代码在伴随PL SQL Developer访问数据库后,会根据当前的用户情况和环境采用不同的勒索路线,具体见下图。并且在勒索之前还会对数据库的创建时间做判断,以保证只勒索有价值的数据库。如果当前数据库创建时间较短,则会潜伏下来,等到数据库积累足够多有价值的数据再进行勒索。
Oracle比特币勒索
这种手术刀式的勒索方式相当精准,基本可以做到勒索的每一个目标都是有数据价值的库,该勒索软件在不同的用户权限下也会采取不同的策略进行勒索。如果能拿到SYS(红线),用户就会直接对系统表下手,把系统表转存到其他地方,再删除系统表以此威胁用户交钱。如果只能拿到dba账号(紫线),就采取删除所有非系统表的方式对客户进行数据勒索。如果只能拿到一般账号(绿线),就会采用锁账号的方式阻止用户访问数据库,从而实施勒索。
在这个数据库比特币勒索软件的身上,我们看到已经有一群黑客对数据库做了深入的研究,让勒索软件可能按照环境和当前权限实现各种不同的勒索方式。为了提高准确性,减少暴露自己的可能,黑客还对数据库建立时间做判断,没有十足把握绝不出手,最后还利用编码技术来躲避数据库扫描类工具对改恶意代码的检查,保证不会在潜伏阶段被受害者发现。
防护比特币勒索
比特币勒索有着向数据库深入的趋势,无论是乱枪打鸟的云上比特币勒索,还是定点打击的内网比特币勒索都应该引起各位数据库安全工作者的警惕。除了警告用户注意垃圾邮件、恶意广告和定期备份数据、数据库注意安全配置、使用高强度口令之外,我们还可以做得更多。
安华金和攻防实验室建议,帮助用户建立定期安全探查+预先防护的双重保障。针对数据库的定点型勒索攻击会有一定的潜伏期这一特点,定期做安全探查很可能在攻击行为真正爆发前,揪出潜伏在数据库中的威胁,预先做好防护工作,排除这些威胁,防止数据库信息或数据库业务遭受损失。
数据库漏扫的授权检测中有专门针对数据库中异常包、存储过程、触发器、各项参数以及后门的检测语句,这些检测语句可以帮助用户早发现、早铲除潜在的威胁。现在数据库漏扫工具已经可以准确检测出数据库是否被此次勒索软件入侵,并给用户提出修复建议。
仅仅依赖于漏扫的定期巡检是远远不够的,漏扫能发现的基本属于已经出现的安全威胁,不过对未知的安全威胁的探查能力不足。想要对未知的此类安全威胁做防护则需要具备能读懂SQL和能解密加密数据库两项能力的数据库防火墙。
能解密加密数据库的意思就是可以对Oracle的密文存储过程进行解密操作。第三方工具向Oracle发送大量数据,其中很多数据都会以加密包的形式发送,只有准确破解加密包的内容才可能为语法分析做好准备。Oracle的加密过程warp可以通过Oracle提供的函数完成,但Oracle并不提供直接函数进行解密,而需要自己实现。解密并不复杂,就是把上面wrap的过程反正来一次,首先通过网络分析把所有断包攒成一个整包,然后对这个加密的整包进行base64解码,接着将解码后的每个字节按照一张固定的替换表进行单独替换,替换后字符串按照LZ算法进行解压则可以获得加密存储过程的明文。
数据库防火墙
准确的破解这种加密存储过程的能力,不但在这个勒索案例中十分关键,也是防护未知第三方工具夹带恶意存储过程向数据库发送的关键。如果不能解决解密问题,最终只能对加密的恶意存储过程进行指纹比对。然而,指纹比对的误报率和漏洞率都是很高的(稍微调整下参数内容或名称就会使指纹匹配无法准确识别恶意包)。
能读懂SQL的意思是,基于SQL语法解析,联系上下文理解存储过程或包中是否存在恶意行为。在unwrap的支撑下数据库防火墙能把所有去向数据库的加密存储过程明文化,再通过SQL语法分析器对明文进行是否存在恶意行为的匹配。数据库防火墙在SQL语法分析器后不是单纯的就单句SQL进行行为分析,而是根据上下文环境的SQL行为对整个SQL语句包进行分析。当整个SQL语句包中存在命中安全规则的多个必要点时,则可以判断该语句包存在恶意行为,从而主动阻断该语句包,并向相关人员进行危险告警。至此,完成针对勒索或后门型数据库攻击的主动防护。
数据库防火墙、数据库漏扫,从不同层面和角度实现了360度防护数据库比特币勒索攻击。数据库防火墙依托上下文SQL语境,利用解密技术和SQL分析技术,动态抓出存在恶意行为的语句包进行实施拦截。数据库漏扫依托授权检测中针对数据库中异常包、存储过程、触发器、各项参数以及后门的检测语句,进行对已知威胁的检查,防止数据库中存在安全隐患。
360度防护数据库比特币勒索攻击
二者分别侧重于整个防护过程中的已知隐患扫描、特征隐患拦截和“恶源追踪”。但实际上,两者既是相互独立,也是相互联动的,数据库防火墙拦截下一个新型隐患,数据库漏扫则根据该新型特征更新扫描检测项。一旦漏扫发现安全隐患,数据库防火墙未发现,则数据库防火墙根据隐患特征更新防护策略,优化已有安全策略,进一步降低误报率。
小结
比特币勒索,一种需要构建整体防护体系来防护的攻击类型,需要通过多个角度相互验证才能在攻击爆发前发现攻击,并遏制攻击。针对数据库的比特币勒索,安华金和攻防实验室推荐采用两类产品,从多个角度展开立体化联合防御,以达到面对此类攻击数据库再无弱点可循的防护与应对目标。
(责任编辑:安博涛)