关注网络安全
和行业未来

证书过期?私钥泄露?掌控您的证书和私钥,维护网站安全和声誉!

hana.lv阅读(17)评论(0)

数字证书,作为网络世界的身份证,提供了一种在Internet上验证通信实体身份的方式,其作用类似于司机的驾驶执照或日常生活中的身份证。譬如,Web Server通过提供自己的数字证书来证明自己的身份,用户得以确认所访问的网站就是想要访问的网站,建立起通信双方的信任关系。数字证书应用除服务器证书外,还包括电子邮件证书,代码签名证书,文档签名证书等。保证证书的有效性对用户和企业来说都是至关重要的。

就在2018年12月22日,因美国政府关门导致许多 TLS 证书已经过期,证书无人续订,无人管理,这使得许多站点无法被公众访问。该问题还影响到了与.gov域相关的许多证书,用户无法完全访问这些站点。证书若不续签,我们可能会看到更多的政府网站出现问题。

在当代,证书管理已成为企业的主要负担。企业规模越大,管理问题就越严峻。对证书管理策略没有前瞻性会给您带来什么样的问题?

死亡五指

使用武侠风的标题,揭示证书管理不善会带来的五个噩梦场景:

  • 证书到期导致的服务意外中断
  • 糟糕的证书/密钥管理导致的审核失败或违规
  • 服务器证书和密钥泄露/滥用
  • 代码签名证书和密钥泄露/滥用
  •  CA泄露; 流氓CA,用于MITM或网络钓鱼(流氓证书)

这些都是当你的证书过期时会发生的事情,任何一个场景的发生都会带给您“可观”的成本。

场景 预测成本
证书到期导致的服务意外中断成本 $11,122,100
由于无文档或糟糕的密钥管理导致的审核失败/不合规的成本 $14,411,500
服务器证书和密钥滥用的成本 $13,423,250
代码签名证书和密钥滥用的成本 $15,025,150
CA泄露或用于MITM或网络钓鱼的流氓CA的成本 $13,219,850
总成本 $67,201,850

一切始于可见性

对于大多数组织而言,大规模证书管理的可见性是证书管理三大痛点之一。 他们不知道他们有多少证书和密钥,他们不知道是谁订购了证书,他们也不知道证书什么时候到期。有调查显示,该痛点比例为71%。

                                                         数字证书面临的最大挑战

许多组织表示他们没有足够的的IT安全人员来维护和保护密钥和证书,不知道IT安全需要管理多少密钥和证书,更不用说在整个生命周期内保护密钥和证书了

如何帮助企业避免证书管理的痛点?在它反噬之前,企业需要先一步的采取行动了。

优质的证书管理平台

通过投资优质的证书管理平台,可以避免证书管理的痛点。 一些供应商都有很好的相关产品,譬如KeyManager(官网地址:https://keymanager.org/),它扫描您的网络并管理所有发现的证书,提供证书可见性和管理证书生命周期所有阶段的界面。

证书管理给人的感觉是昂贵且复杂的, 但并非如此。 从长远来看,这不是一个沉没成本(已经付出且不可收回的成本),这是一项投资,因为证书管理不善的代价是更加惊人的。

文中提及的调查数据及结果来源于:71% of Organizations don’t know how many certificates & keys they have

您的SSL/TLS证书应该采用ECC加密算法了

hana.lv阅读(85)评论(0)

RSA的日子已屈指可数了,相比RSA,ECC更轻、更快、更安全。

我们一直在谈论ECC,让我们诚实的讨论一下吧。ECC看起来有点抽象,这可能不利于提高它的采用率。目前发行的大多数SSL/TLS证书使用的都是RSA公钥加密。我们之所以知道是因为我们卖了很多。

据我所知,ECC的使用率低很大程度上归因于大众认为基于ECC的加密系统在用户的浏览器和操作系统上没有得到广泛支持。

然而,事实并非如此。

所以,我们将讨论对“ECC不被支持”的错误认为,然后我们将讨论ECC本身、它的优点,以及为什么应该在SSL/TLS证书中使用它。

让我们开始讨论吧!

所有现代的操作系统和浏览器都支持ECC

SSL/TLS行业一直受到不再适用的传统观点的束缚。从HTTPS速度较慢的观点,到网站不收集个人信息所以不需要SSL的谬论,无所不包。虽然在一段时期内所有这些观点都是真的(在一定程度上),但在当代情况大不一样了。

这其中就包括了ECC没有得到终端用户广泛支持的观点。

服务器对ECC的支持可能是不同的。以下是主流操作系统对ECC的具体支持情况:

操作系统 最低版本要求
Apple OS X OS X 10.6
Microsoft Windows Windows Vista
Red Hat Enterprise Linux 6.5
IOS IOS 7.x
Android OS 3.x
Microsoft Windows Phone 7.x

以下是4个最流行的浏览器兼容ECC的情况:

浏览器 最低版本要求
Apple Safari 4
Google Chrome 1.0
Microsoft Internet Explorer 7
Mozilla Firefox 2.0

的确,Windows XP 用户和古董级设备可能无法兼顾对ECC的支持,这就完美的过渡到我们下一个观点。

高瞻远瞩,不要留恋过去—不要把互操作性置于安全性之上。

RSA已时日不多,在过去的两个月里,我们详细介绍了针对RSA和许多过时的SSL/TLS部署的漏洞。共同的认知是,打着互操作性的名义继续支持老旧的、脆弱的加密系统和算法,会给企业招致不必要的风险。

相信我,我充分理解为什么需要互操作性。企业不愿将任何人拒之门外。但是,如果你继续遵循此想法,你就会错失享有ECC具有的几大优势。

  • ECC密钥更短,意味着ECC将占用更少的资源却有更高的性能;
  • ECC更易扩展,随着RSA密钥更长只会让SSL/TLS面临更多的麻烦。
  • ECC并不太容易受到量子计算机的安全威胁,这是很重要的一点。

让我们对ECC的工作原理做一个粗略的解释,然后我们将讨论您在获得SSL/TLS证书时应该选择ECC而不是RSA所能获得的好处。

椭圆曲线加密101

很久以前,Vincent Lynch(现就职于DigiCert)写了一篇关于ECC的优秀总结,旨在五分钟内告诉你需要知道的一切。如果你能抽出时间,我强烈推荐它。以下是缩减版:

椭圆曲线密码学顾名思义,是一种利用椭圆曲线的数学原理进行加密的方式。感觉有点儿抽象,我之前提到过这一点,这也是我所指的部分。

我们从什么是x轴开始。你可能会笑出声,但这对理解ECC非常重要。椭圆曲线的每一点都通过x轴上映射——即图上的水平线——这就是椭圆曲线对称性的来源。

现在我们来讨论一下打点。画一条漂亮的椭圆曲线,通过在上面作图来解释我在说什么。在椭圆曲线上绘制A、B两个点,只有私钥的所有者知道。

连接A、B两点绘制一条直线,直线会与椭圆曲线在第三个位置相交,相交的点是我们所关心的。以x轴为对称轴会将此象限中的点(下图中第一象限的点)映射到第四象限。你可以看到,连接AB,与椭圆曲线在第三个位置相交,相交的点以X轴为对称轴进行对称得到点C。

现在重复一遍上面的操作,这次连接A、C两点绘制一条直线,在椭圆曲线上找到相交的点,以X轴为对称轴进行对称,绘制它的镜像点D。

以上称为打点。而交点的数量,或者说点的数量,只有私钥持有者知道,不具备相关知识的人是不可能解密它的。

显然,这是一个公钥密码系统,用于密钥对称交换,类似于RSA。但它通过椭圆曲线生成密钥,而非使用质因数分解。两者都完成相同的任务,但是ECC有一些明显的优势。

ECC密钥更短

RSA密钥很笨重。行业标准是2048位,而一些组织选择使用更长的密钥。还有一个主要的缺点:由于密钥的大小影响RSA加密所需的计算资源,密钥越大,所需资源越多,这可能导致您的网站性能滞后。当讨论RSA的扩展性问题时,我们会对此做更深入地讨论,但对RSA来说,更大的问题是密钥大小与它的安全性不相称。随着密钥长度的增长,安全性的强度不会以相同的程度提高。

相比RSA, ECC密钥不仅更短,而且很难破解。举例来说:根据通用安全(Universal Security)的一项研究,计算机破解一个228位RSA密钥所消耗的能量大约足以烧开一茶匙水。破解同样大小的228位ECC密钥所需的能量将超过煮沸地球上所有水所需的能量。

差距显而易见。

以下是一份ECC密钥大小的具体情况,以及与它们安全性对等的RSA密钥的大小:

ECC密钥大小 RSA密钥大小
160位 1024位
224位 2048位
256 位 3072位
384 位 7680 位
521 位 15360 位

需要关注的是,美国国家安全局(NSA)要求所有Top Secret文件和文档都必须使用384位ECC密钥加密。换作RSA,将是 7680位的RSA密钥,真的是相当笨重。

这很好地引出了我们下一论点。

ECC扩展性优于RSA

正如我们所提到的,从所需资源角度来说,RSA比ECC更昂贵。因式分解需要相当多的计算资源。现代加密技术面临的威胁越来越大,所需RSA密钥的长度也越来越大,它只会变得越来越昂贵。

这将最终导致RSA的消亡。

同时,还有一个更紧迫的问题。特别是对大型公司和企业来说。当规模足够大时, 所有这些SSL/TLS握手的费用和所有解密都可能成为您网络的最大负担。这就是为什么许多企业卸载SSL作为整个SSL/TLS部署的一部分。通过将这些流程卸载到专用设备上,可以释放应用服务器上的资源,从而提高网站的整体性能。

现在让我们应用我们所知道的ECC和RSA的差别:与ECC密钥相比RSA密钥扩展性更差。随着威胁的增长,密钥长度需要更大,这将给网络造成越来越大的压力。另一方面,ECC扩展性好,所需资源少。

对于规模较小的公司来说,这可能不是什么大问题,但随着规模的不断扩大,它终将成为你需要关心的问题。ECC会解决你的烦恼。

ECC更好的抵抗量子计算的安全威胁

在我们开始之前,为防评论区有人坚持认为:ECC在其最常见的迭代中并不具备抗量子性。它可以被Shor算法的修改版本破解。但是,有一种基于椭圆曲线的密码学展示出了前景:超奇异椭圆曲线同源密码术。

我们不打算讨论超奇异椭圆曲线和同源性图,因为量子计算目前还不可行,我也不是数学专业的学生。但SIDH,像其名称一样,相比竞争对手,它有两大优势:更短的密钥规模和完美的前向保密性。

简单介绍一下完美的前向保密性。很受隐私倡导者欢迎的一个属性,即使私钥被破解,它生成的会话密钥也不会受到损害。这在RSA中从技术上是可行的,但它需要寿命短的密钥,这就意味着需要定期的密钥旋转,如上所述,生成新的RSA密钥非常昂贵。而ECC密钥更短,容易旋转,很适合这种模型。

这是属于PFS的部分,我们将在今年春天晚些时候更深入地讨论它。

如何获得ECC SSL证书?

ECC SSL证书的获得与订购SSL证书一样简单。大多数SSL服务商和CA会在支持ECC的证书中提供一个ECC选项。虽然Sectigo和一些Symantec/DigiCert证书已经支持ECC,但并不是所有的都支持。

最重要的是:ECC的成本并不比RSA高。

无论从密钥大小,扩展性和长期有效性,它都是一个更好的密码系统。

您甚至不需要获取新的SSL证书来进行切换。大多数SSL服务商都免费提供重颁发SSL/TLS证书。您只需进入操作面板,选择证书,选择重颁发,使用ECC证书签名请求(CSR)来生成订单即可(前提是您的证书支持它)。

无论哪种方式,ECC证书都不难获得。为什么不用呢?

 

二月行业新闻回顾

hana.lv阅读(116)评论(0)

本月大事件:

来自阿联酋的DarkMatter拥有一个证书颁发机构。

DarkMatter, 阿联酋一家颇具争议的公司,对证书颁发机构的可信度提出了一些问题。

据Reuters(路透社)报道,DarkMatter是“Project Raven” 的幕后黑手,在该项目中,NSA(美国国家安全局)的前雇员为UAE(阿联酋)实施了攻击性的黑客行动。包括监视人权活动家,据路透社报道,特别包括了针对被判10年监禁的Ahmed Mansoor的监视行动。

Claudio Guarnieri,Amnesty International的技术专家,他指出DarkMatter已经申请了Mozilla的证书根存储。不久之后,Electronic Frontier Foundation (EFF)要求Mozilla拒绝这个请求,并提到DarkMatter已经有了一个能够颁发浏览器信任的TLS证书的中间证书。

DarkMatter中间证书由QuoVadis签发,该证书颁发机构最近被DigiCert收购。

Mozilla的Wayne Thayer在Mozilla安全策略列表上发起了一场讨论,询问如何处理这个问题。“本讨论的目的是确定Mozilla是否应该通过将由QuoVadis签名的中间CA证书添加到OneCRL来不信任DarkMatter,并拒绝待处理的根包含请求。”Thayer写道。

本月短新闻:

文稿来源:Feisty Duck

Google Chrome 72 丢弃HPKP,不再支持TLS1.0和TLS1.1!

hana.lv阅读(176)评论(0)

Mozilla发布Firefox 65 几个小时后,谷歌也发布了最新的Chrome 72,并为Windows、Mac、Linux和Android用户提供了更新的版本。

注:谷歌Chrome增加了下载驱动保护功能。

虽然在过去的3-4个版本中,谷歌在Chrome UI和UX(用户界面和用户交互)方面的变化已经给用户带来了很大的影响,但是如今的版本变化对浏览器的底层Web APIs和协议的影响更大。

在所有的变化中,Chrome 72有三个重要的更新是用户需要知道的。其中最重要的是完全删除对基于HTTP的公钥固定(HPKP)标准(RCF 7469)的支持。

谷歌早在2017年10月就宣布了关于HPKP的长期计划,并在2018年3月发布的Chrome 65中首次丢弃了HPKP。

由于已被丢弃,Chrome会在网站所有者的开发控制台上显示错误。现在它被弃用了,所以Chrome不再支持使用HPKP的网站,拒绝固定公钥。幸运的是,这不会影响到太多的网站,因为HPKP实现起来很麻烦,只有很少的网站曾经使用过它。

目前支持HPKP的网站所有者可能应该停止了,作为世界上最受欢迎的浏览器,Chrome将不再支持密钥固定。

Chrome 72版本的第二个主要变化是不会呈现任何通过FTP协议加载的资源。

Chrome将继续显示FTP目录列表,但当网站加载一个托管在FTP链接上的图像或JavaScript文件时,替代呈现图像或运行文件,Chrome会提示用户下载它。

Chrome 72的第三个主要变化是不再支持过时的TLS 1.0和TLS 1.1标准。这一举动只是Chrome 81采取的取消支持这两个标准的第一步。Chrome 81计划在2020年初发布。

谷歌曾在去年与Apple、Microsoft和Mozilla一起宣布过这些计划。Apple、Microsoft和Mozilla表示,他们将在各自的浏览器上执行这些计划。

Chrome 72不再支持TLS 1.0和TLS 1.1,这意味着当用户访问遗留有TLS 1.0或1.1证书的HTTPS站点时,Chrome会在开发人员控制台显示错误,但不会阻止用户访问站点。从Chrome 81开始,将会阻止用户访问。

Chrome现在的新版本号是72.0.3626.81。Windows、Mac、Linux和Android用户使用Chrome的内置更新器能够安装更新。完整的Chrome 71修改日志在此查看

在Chrome 72中,谷歌修复了58个安全漏洞,详情点击链接。来自 Chromium和 Google Developers 团队的两篇博文详细介绍了Chrome 72以开发人员为中心的特性。

文稿来源:ZDNet

新的TLS加密破坏攻击也会影响新的TLS 1.3协议

hana.lv阅读(302)评论(0)

一个学术团队上周披露了一个新的加密攻击,它可以攻破加密的TLS流量,允许攻击者拦截并窃取以前认为安全可靠的数据。

这种新的降级攻击没有像大多数加密攻击那样具有花哨的名字,但是它甚至可以攻击TLS 1.3协议(2018年春天发布的TLS最新版本),其被公认为是安全的协议。

新的加密攻击本身并不新鲜,它是原始Bleichenbacher oracle攻击的新变种。

原始Bleichenbacher oracle攻击是以瑞士密码学家Daniel Bleichenbacher的名字命名的,他在1998年演示了第一次实际攻击,针对RSA使用PKCS#1 v1编码方式的加密系统。

多年来,密码学家已经找到了原始攻击的多种变种,例如

20032012201220142014201420152016(DROWN)2017(ROBOT), 和 2018

产生这些攻击变种的原因是:TLS加密协议的作者们仅仅以添加对策的方式使得猜测RSA解密密钥的尝试更加困难,而不是替换不安全的RSA算法。

这些对策已在TLS标准(RFC 5246)的第7.4.7.1节中定义,许多硬件和软件供应商多年来一直误解或未能遵循标准协议规定。

这些在实施恰当应对措施(指前文RFC文档描述的应对措施)方面的失败导致许多支持TLS的服务器,路由器,防火墙,VPNs和编码库仍然容易受到Bleichenbacher攻击变种的影响,这些攻击变种在不正确的应对措施中发现并利用了存在的问题。

2月6日发表的一篇技术论文中描述了最新的Bleichenbacher攻击变种,题为“ Bleichenbacher之猫的9条命:针对TLS协议实现的新缓存攻击 ”。

来自世界各地的七位研究人员再次发现另一种破解RSA PKCS#1 v1.5的方法,RSA PKCS#1 v1.5,目前用于加密TLS连接的最常见的RSA配置。除了TLS之外,这种新的Bleichenbacher攻击也会对谷歌新的QUIC加密协议有效。

研究人员表示,“为了攻破TLS的RSA密钥交换,攻击巧妙的利用了缓存访问时序的侧信道泄漏”。

即使是较新版本的TLS 1.3协议(其中RSA使用率保持在最低水平),在某些情况下也可以降级为TLS 1.2,新的Bleichenbacher变种攻击得以实施。

研究人员说“我们对九种不同的TLS实现进行了预防缓存攻击的测试,其中七个被发现是易受攻击的:OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL, 和 GnuTLS。”

2018年11月,当研究人员发表他们研究论文的初稿时,上述所有受影响的库同时发布了更新版本。

有关更多详细信息,请关注已经为这些新的Bleichenbacher攻击变种分配的安全漏洞CVE标识:CVE-2018-12404,CVE-2018-19608,CVE-2018-16868,CVE-2018-16869和CVE-2018- 16870。

两个不易受攻击的库分别是 BearSSL 和 谷歌的BoringSSL

文稿来源:ZDNet商业技术新闻网站

庆祝OpenSSL诞生20周年

hana.lv阅读(290)评论(0)

在20年前,1998年12月23日,OpenSSL首个版本发布。OpenSSL并不是这个项目最初计划的名字(译注:原名OpenTLS),在官网上线前的几个小时,才被更改为了OpenSSL。来回顾一下OpenSSL早期的一些历史,其中的一些背景之前并没有文档记录。

早在20世纪90年代末,Eric Young和Tim Hudson就因为他们在开源SSLeay库上的工作成就而闻名。SSLeay被广泛用于Apache和(当时的)第三方SSL模块,用于构建开源、安全的Web服务器。在1998年,他们都为C2Net工作,改进SSLeay和使用它的产品。C2Net以其旗舰产品Stronghold Web Server而闻名。Stronghold Web Server是基于开源软件编译和构建的产品,并且提供支持服务。关键的一点,其能够在全球范围内提供和使用强加密技术。在现在看来这似乎微不足道,但在当时,从美国出口的加密产品,如Web服务器和浏览器,都只能使用有限的弱加密技术。(译注:Export of cryptography from the United States

Eric和Tim决定离开C2Net加入创造了商业SSL工具的RSA公司,因此SSLeay的未来并不明朗。1998年10月14日,在旧金山的第一次ApacheCon会议上,在我与Ralf Engelschall的一次讨论中诞生了OpenSSL项目,Ralf Engelschall是Apache核心开发人员。几个月后,我们继续了讨论,并于12月16日建立了一个邮件列表,邀请SSLeay专家Stephen Henson参与我们当时称为OpenTLS的项目。Apache核心开发者和Apache-SSL的作者Ben Laurie也在几天后独立宣布了启动SSLeay新版本的意图。

Ralf从公开的SSLeay 0.8.1和0.9.0b版本以及C2Net未发布的0.9.1b版本中获取源代码,将其导入OpenTLS CVS仓库。我们对这些文件做了一些清理工作,我们自己添加了一些补丁,也从社区中添加了一些知名的补丁,最终形成了0.9.1c版本。

就在公开发布之前的最后一刻,我们将项目名字从OpenTLS更改为OpenSSL:原因在于TLS协议RFC尚未发表,TLS作为缩略词在当时鲜为人知,而SSL缩略词已被广泛认可,因此在名称中使用SSL有助于用户理解SSLeay 到OpenSSL的过渡。幸运的是,我们同时保留了这两个域名。

1998年12月23日,我们开通了www.openssl.org网站,发布了OpenSSL-0.9.1 c版本和源代码库。

在这繁忙的一周中,我们一直在与Ben和Stephen沟通项目的对接和合并,圣诞节假期后不久,我们发布了完整的项目公告。所以最初的项目团队是由Ben Laurie, Paul Sutton, Ralf Engelschall, Stephen Henson,Mark Cox和我组成,除了Stephen Henson之外,所有人都是Apache HTTP Server的核心开发人员。

在最初的15年里,OpenSSL成员主要是由兼职的一小部分人组成,在那些年里,成员不断地发生波动和变化。大约5年前,我们扩大了这个小组,开始引入规范的政策。截至今天,我们已经形成一个体系,其中一组贡献者可以评审并对提交的代码作出变更,并且有管理委员会来监督这个项目。OpenSSL的资金主要来自赞助商的慷慨捐赠。我们还提供有偿合同支持服务,偶尔也会签订合同来开发某些新功能。我们使用这些资金主要是用来支付项目中全职研究员的工资。研究员们负责维护基础设施,修复bug和安全问题,审查补丁等更多的其他工作(您可以从发送到OpenSSL-project邮件列表的每月报告中看到他们在做什么)。许多公司还免费提供员工时间为OpenSSL项目工作。

第20年是激动人心的一年,对版本号方案进行了重大更改,许可协议切换到了Apache License 2.0,并且刚刚开始了一个针对初学者的新的FIPS验证项目。尽管SSL的所有版本现在都已被弃用(译注:SSL协议在SSLv3之后更名为TLS1.0协议)),但我们也不太可能很快将其重新命名为OpenTLS。

图为2018年11月OpenSSL管理委员会在爱丁堡城堡前举行的面对面会议。从左至右依次为: Paul Dale, Kurt Roeckx, Richard Levitte, Matt Caswell, Mark Cox, Tim Hudson。Viktor Dukhovni (图中未见)也是其中一员。

文稿来源:OpenSSL博客

十二月行业新闻回顾

hana.lv阅读(261)评论(0)

本月大事件:谷歌启动CECPQ2,TLS新的后量子密钥交换算法

量子计算机有可能危及目前使用的几乎所有公钥加密系统的安全性。这在TLS社区引发了关于如何面对这种威胁的讨论。

谷歌开发人员Adam Langley宣布谷歌将很快部署一种的新的TLS密钥交换算法—CECPQ2 (combined elliptic curve and postquantum key exchange)。它是结合了经典的X25519椭圆曲线密钥交换算法和HRSS密钥交换算法的一个变体。

HRSS是NIST后量子密码学竞赛的参赛作品之一,也是NTRU算法的一个变体。谷歌将会使用HRSS变体,因为该变体的一个改进可以避免原始方案中偶尔出现的罕见故障。

谷歌于2016年开始使用NewHope算法测试后量子密钥交换;此密钥交换被命名为CECPQ1。但这只是一个暂时的实验,几个月后就结束了。

本月短新闻:

文稿来源:Feisty Duck

在喜达屋数据泄露中,5亿万豪宾客记录被盗

hansen阅读(315)评论(0)

全球最大的连锁酒店万豪国际集团今天披露,不知名的黑客入侵其子公司喜达屋酒店的客人预订数据库,并带走了大约5亿客人的个人信息。
喜达屋酒店及度假村集团于2016年被万豪国际以130亿美元收购。该品牌包括瑞吉酒店,喜来登酒店及度假村,W酒店,威斯汀酒店及度假村,雅乐轩酒店,Tribute Portfolio,Element Hotels,艾美酒店及度假村 ,豪华精选,福朋喜来登酒店及设计酒店。

该事件被认为是历史上最大的数据泄露事件之一,仅次于2016年雅虎黑客攻击,其中近30亿用户帐户被盗。
自2014年“未经授权的一方”设法未经授权访问喜达屋的客人预订数据库以及复制和加密信息后,自2014年以来,喜达屋物业遭到破坏。
万豪在收到内部安全工具发出的关于试图访问美国喜达屋客串预订数据库的警告后,于今年9月8日发现了该漏洞。
11月19日,对事件的调查显示,未经授权访问数据库,其中包含“2018年9月10日或之前有关喜达屋酒店预订的客人信息”。
被盗酒店数据库包含近3.27亿客人的敏感个人信息,包括姓名,邮寄地址,电话号码,电子邮件地址,护照号码,出生日期,性别,抵达和离开信息,预订日期和通信偏好。
什么令人更担忧?对于某些用户,被盗数据还包括支付卡号和支付卡到期日。

但据万豪称,“支付卡号码是使用高级加密标准加密(AES-128)加密的。”攻击者需要两个组件来解密支付卡号码,“此时,万豪还未能排除两者的可能性。”
该公司在一份声明中说:“该公司尚未完成在数据库中识别重复信息,但认为它包含了在喜达屋酒店预订的多达约5亿客人的信息。”万豪证实,对此事件的调查仅发现未经授权访问单独的喜达屋网络,而非万豪网络。它还开始向可能受影响的客户通报安全事件。
该酒店公司已经开始通知监管当局,并告知执法部门,并继续支持他们的调查。
由于数据泄露属于欧盟通用数据保护条例(GDPR)规定,如果发现违反这些规则的话,万豪可能会面临1700万英镑的最高罚款,即每年全球收入的4%。

十一月行业新闻回顾

hana.lv阅读(93)评论(0)

本月大事件:用侧信道攻击加密

新的研究表明,加密代码通常容易遭受侧信道攻击。

一种名为PortSmash的攻击展示了如何在现代CPUs的超线程功能中利用侧信道。相关的攻击PoC(Proof of Concert)在GitHub上公开了,同时还有一篇研究论文

侧信道攻击的核心思想科林·珀西瓦尔在13年前就发表过。OpenSSL代码易受攻击的原因是它具有基于秘钥的分支。OpenSSL已经发布了一个安全建议

此外,影响OpenSSLDSAECDSA算法的另一种不相关的侧信道攻击已被修复。有关攻击的细节尚未公布。OpenSSL已经发布了1.0.2q、1.1.0j和修复的1.1.1a版本。

本月短新闻

  • ZDNet报告说,来自Paragon Initiative的Scott Arcizewski发现许多用PHP编写的内容管理系统插件代码中使用了CURL而没有验证证书。
  • 物理学家米哈伊尔迪亚科诺夫(Mikhail Dyakonov)在IEEE Spectrum中指出,量子计算机不太可能实现。一个大型的量子计算机将能够破解当今的公钥密码系统,而公钥密码系统最近推动了后量子加密的研究,但目前还不清楚能够破解加密的量子计算机能否成为现实。
  • 在一篇研究论文中公布了一种名为Return of the Hidden Number Problem(简称RHNP)的侧信道攻击。今年6月,NCC Gruop在一篇博客文章中宣布了这起攻击事件;大多数受影响的库已被暂时修复。
  • HTTP的下一个版本很可能称为HTTP/3,加密传输将基于QUIC协议。丹尼尔斯坦伯格在一篇博文中解释了其中的细节

文稿来源:Feisty Duck

赛门铁克发现朝鲜APT组织Lazarus攻击金融机构的关键性工具

hansen阅读(363)评论(0)

10月2日,美国国土安全部(DHS)下属的US-CERT发表了一则针对朝鲜APT组织Lazarus(Hidden Cobra)的技术性预警公告,公告指出,在DHS、DoT(财政部)和FBI的共同努力下,发现了Lazarus用于在全球实施ATM网络犯罪的恶意软件样本和多个威胁指标(IOCs),DHS把Lazarus组织的该系列恶意网络犯罪命名为“FASTCash”攻击。10月8日,安全公司赛门铁克(Symantc)发表报告声称,已经发现了Lazarus组织用于“FASTCash”攻击的关键性工具。

自2014年以来,Lazarus在全球多个国家实施了多起网络犯罪,入侵索尼公司、攻击韩国金融媒体机构、窃取孟加拉央行8100万美元、攻击美国国防承包商和比特币交易所、发起WannaCry勒索攻击。DHS透露,根据美国政府的可信合作伙伴评估,Lazarus仅针对金融机构的“FASTCash”攻击窃取金额就达数千万美元。

赛门铁克的发现

赛门铁克研究人员透露,Lazarus组织在开展FASTCash攻击时,首先会找点入侵目标银行的网络,接着渗透进入负责ATM交易的交换应用服务器,最终在这些服务器上部署一些此前我们从未识别的恶意软件 – (Trojan.Fastcash) 。之后,Lazarus攻击人员会发起欺诈性的现金提取请求,其部署的恶意软件则负责请求拦截监听,并会向负责ATM交易的交换应用服务器返回假冒的请求响应,以此实现对ATM系统的现金窃取。

根据US-CERT的预警公告反应,Lazarus于2017年发起了一起攻击事件,其分别从全球30多个不同国家的ATM机系统中同时提取转移了大量现金。同样的攻击也在2018年发生过,这一次,Lazarus从23个不同国家的ATM机系统中窃取了大量现金。

FASTCash Infographic.pngLazarus开展FASTCash攻击的具体流程

为了实现从ATM机系统中欺诈性的转移现金,Lazarus攻击者具体的做法是,在负责ATM交易的交换应用服务器中,向某个运行的合法进程注入一个高级交互执行程序(Advanced Interactive eXecutive, AIX),这个恶意的AIX程序包含了构造假冒ISO 8583消息报文的逻辑(ISO8583金融交易报文是银行业和金融服务业常用的数据消息格式,常用于终端交易设备中)。Lazarus这种假冒ISO 8583消息报文的技术此前未曾被发现过,通常的认为是Lazarus通过使用脚本来控制服务器实现转账交易欺骗。

ISO8583金融交易报文:是银行业和金融服务业常用的 ISO 标准,该标准指定了一个消息格式,设备和发卡行之间可以使用该消息格式来交换信用卡数据和借记卡数据,该标准通常为销售点设备和自动取款机所采用。消息本身通常包含有关交易金额、交易发起位置、卡的帐号以及银行分类代码的信息。接收数据的应用程序可以有多种用途,例如在多个银行帐户之间转移资金、支付账单或手机充值。

赛门铁克及时发现了这种注入到ATM交易应用服务器中的恶意软件,并把它命名为 Trojan.Fastcash,实质上它属于木马类恶意程序,且包含了两个主要功能:

1、监视传入服务器的消息,并在请求到达交易服务器之前,拦截攻击者生成的欺诈性交易请求

2、为了形成欺诈性交易请求,其中包含了生成一个假冒响应的程序逻辑

赛门铁克对FASTCash攻击的发现样本

一旦Trojan.Fastcash被成功部署在负责ATM交易的应用服务器中,其将会读取所有传入服务器的网络流量,并扫描流量中包含的 ISO 8583报文请求,而且它还会探测流量消息中,攻击者用来执行交易的银行主账户号(Primary Account Number,PAN),如果有银行主账户号出现,Trojan.Fastcash就会尝试修改涉及该账户号的消息。

Lazarus会根据不同的金融机构目标,实行不同的账户号消息修改方法,如果消息修改成功,Trojan.Fastcash会针对向ATM应用服务器发起的欺诈请求,返回一条假冒的现金转账批准响应,最终,Lazarus的转账申请就会被ATM应用服务器放行,从而成功实施了现金转账。

经分析,以下是Trojan.Fastcash用来生成假冒批准响应的一个程序逻辑。这个特殊样本会根据攻击者传入的欺诈请求,构造以下不同三个假冒响应之一。

当ISO8583报文消息的类型标识 == 200,也就是ATM发生交易行为,和POS机型磁条卡的服务点输入方式码从90开始时,Trojan.Fastcash有以下程序逻辑:

If Processing Code starts with 3 (Balance Inquiry):

Response Code = 00 (Approved)

Otherwise, if the Primary Account Number is Blacklisted by Attackers(否则,如果攻击者将主帐号列入黑名单):

Response Code = 55  (Invalid PIN)

All other Processing Codes (with non-blacklisted PANs):

Response Code = 00 (Approved)

在这种情况下,攻击者似乎内置了根据他们自己设置的黑名单账户号有选择性地进行转账交易,但是,该功能在这样本中并没有成功实现,其黑名单检查机制总是返回“False”。

赛门铁克发现了和Trojan.Fastcash相关的几种不同特洛伊木马变种,且每种都使用了不同的响应逻辑,赛门铁克认为这些变种都是针对不同金融机构的特定交易处理网络而定制的,因此其具备的响应逻辑有所不同。

另外,被Lazarus组织用于FASTCash攻击的银行主账户号(PAN)都是真实存在的,根据US-CERT的预警公告,这些被攻击者用来发起交易的账户号不太活跃或是零余额状态,而攻击者控制这些账户号的方法也暂不清楚,可能是攻击者的自行开卡,也可能是其它攻击活动中窃取的账户。

截至目前,在所有对FASTCash攻击的报告中,都提到了由于银行应用服务器的AIX操作系统更新不及时,存在漏洞,导致被攻击者入侵的说法。

Lazarus对金融机构的持续威胁

最近的FASTCash攻击表明,对金融机构的攻击不是Lazarus的一时兴起,很有可能是其长期的主要活动。如同2016年的对孟加拉国央行的现金转移案一样,FASTCash攻击反映了Lazarus对银行系统和交易处理协议有着深入的研究理解,并且能发现存在漏洞的银行网络,并成功从中窃取转移现金,作案手法相当专业。

总之,Lazarus会持续对金融部门造成严重威胁,相关单位和部门应采取必要措施,确保其支付系统及时更新并处于安全状态。

防护建议

1、及时更新操作系统和相关应用软件;

2、关注并更新近期容易被攻击者利用的应用软件漏洞;

3、及时更新应用服务中涉及的AIX操作系统。

IoC

D465637518024262C063F4A82D799A4E40FF3381014972F24EA18BC23C3B27EE (Trojan.Fastcash Injector)

CA9AB48D293CC84092E8DB8F0CA99CB155B30C61D32A1DA7CD3687DE454FE86C (Trojan.Fastcash DLL)

10AC312C8DD02E417DD24D53C99525C29D74DCBC84730351AD7A4E0A4B1A0EBA (Trojan.Fastcash DLL)

3A5BA44F140821849DE2D82D5A137C3BB5A736130DDDB86B296D94E6B421594C (Trojan.Fastcash DLL)

*来源:symantec