【IT168 评论】一封看似合理的电子邮件引发了2016年6月份最大的安全事件-日本旅游业巨头JTB793万条用户数据泄露，此次事件，自JTB2016年6月15日宣布被未知黑客入侵以来持续发酵，相关报不绝于耳。综合各方面的信息材料，基本可以还原出整个JTB被入侵的全过程。

　　根据日经新闻报道，此次入侵事件存在以下几个关键时间节点：

　　3月15日JTB员工打开钓鱼电子邮件，办公电脑被黑客植入木马

　　3月20日 第三方安全企业发现异常流量，但未引起JTB特别关注

　　3月21日 黑客开始抽取数据库中的核心信息

　　3月25日 黑客把数据库信息向外传输完毕

　　4月01日 发现黑客盗取数据留下的痕迹

　　6月10日 JTB确认此次黑客入侵损失

　　根据对该病毒程序的样本分析，可以重演黑客如何利用感染的商品信息控制服务器对“实用数据库”进行攻击，获取数据。下图描述了plugx在入侵pc机，感染内网多台服务器后,如何从数据库中盗取核心数据。

　　1：商品信息控制服务器被黑客的木马通过内网感染，#FormatImgID_3#木马将自己设置成名为QUEST software TOAD的进程。该木马会调用fmtoptions程序和相应的组件(通过替换dll文件植入恶意程序)，被攻击的#FormatImgID_4#fmtoptions程序建立了80端口的http服务。

　　2：海外的C&C(通讯与命令)服务器，通过该服务器上开放的http协议与被感染的fmtoptions程序进行通讯，发送经过压缩加密的命令到商品信息控制器。由于商品信息控制器被数据库服务器所信任。从而登录“实用数据库”，对数据库进行批量导出或混淆式导出。

　　3：导出的数据集被fmtoptions程序保存为CSV文件，通过web集群向未知的服务器发送数据。CSV使用后，会立即删除，隐藏黑客入侵的痕迹。

　　RAT(远程访问木马)的新特征：

　　RAT(remote access Trojan)是一种常见的攻击手段，入侵者可通过此类攻击达到窃取核心数据的目的，此次事件正是一次典型的RAT攻击。

　　对比以往的RAT攻击，此次安全事件暴露出新版本和以往不同的特点，而这些新特点也给我们带来了新的安全挑战。

　　特点一：目标明确，洞悉内网环境

　　此次JTB遭遇黑客从入侵到结束，总共用时11天。这说明黑客对JTB及其子公司内网部署结构和安全措施有相当深入的了解。并不像常见RAT那样采取被动的隐藏的方式通过长期的潜伏缓慢获取数据。而是采用了一种主动的方式(可能是fire hosed方式)，快速获取目标数据，并通过多台JTB机器向黑客控制服务器传送被盗数据信息。

　　特点二：黑客工具针对性强

　　根据JTB的公开说明，此次被植入的恶意后门是plugx。这是一款从2012年就被广泛使用的恶意后门。根据Sophos实验室首席研究员Szappi报告指出有一个变种的plugx从2013年开始就专门针对日本地区。这个变种的一个显著特点就是使用了大量仅在日本本地流行的软件漏洞。例如：Plugx原本用于本地系统提权的漏洞是利用了Microsoft Word存在的漏洞，但这个变种则是使用了日本人广泛使用的太一朗文字存储器存在的漏洞。

　　我们有理由相信，Sophos实验室提到的这个plugx变种很可能正是JTB遭到的恶意后门。这也揭示出了现在RAT攻击采取的技术会更加专业化，不再面向通用软件。而是根据当地的特色，甚至目标企业的特色制定专门适合当地的入侵软件。

　　特点三：数据获取手段隐蔽

　　此次黑客获取数据库中数据采用了可信工具直接访问数据库提取出关键数据的间接方式。并没有在数据库服务器上安装后门程序。这种通过可信机制获取数据库信任得到数据的方式。既隐蔽了自己的行踪，又分散了数据的流量给数据泄露的追查工作也带来了更大的挑战。

　　暴露的安全问题以及解决方案：

　　回顾整个事件发现黑客的攻击手法和强度都有不小的提升。整个事件仅11天黑客就完成了盗取数据库数据的过程，而JTB则花费了90多天才确定此次黑客盗取的信息。我们在惋惜JTB的不幸遭遇和惊叹于黑客技术升级迅速的同时。更为重要的是通过此次JTB暴露的安全问题，我们可以从中吸取什么教训，来避免类似事件在我们自己身上发生。

　　通过此次事件暴露出数据安全面临的3类典型安全隐患。

　　一、缺乏对核心数据的专业保护能力

　　二、内网安全管控能力不强

　　三、企业安全意识薄弱

　　一、缺乏对核心数据的专业保护能力

　　核心数据对于企业的价值越来越重要。核心数据往往被存放在数据库服务器中。因此数据库服务器的防护能力必须加强。数据库的防护的关键可以分为四个核心部分

　　1.数据的风险感知，及时发现异常行为

　　数据库面临的风险来自方方面面，感知风险是面对风险的关键的一步;如果在黑客开始攻击数据库的第一时间就感知到异常，完全可以立即发出警告并找到准确的攻击来源，采取措施。JTB在数据库服务器和应用之间缺乏一种对sql语句行为判断的有效过滤工具(数据库防火墙)，对访问数据库信息的语句没有管控能力，导致黑客在取得可信Ip和数据库用户信息后，能够利用数据导出工具对数据进行肆意获取。

　　数据库防火墙可以提供一种有效的感知风险的方式。通过对应用系统和数据库之间的数据访问行为进行学习，而形成应用和数据库之间的语法结构模型(应用的行为模型)。最终只允许严格符合模型中语法的sql语句从数据库中获取信息。一旦发现有不符合原语法模型的新型SQL产生，很可能标志着应用系统遭到了跨站劫持、恶意代码或注入攻击等。对于新型的sql语句进行警告并控制，并记录下该行为的来源(IP地址和程序名称fmtoptions)，作为审查的线索，从而在第一时间发现异常行为，感知风险，进行响应。

　　2.细粒度访问控制，对非常规请求进行限制

　　数据库防火墙不但可以对异常语句在入侵到数据库前及时作出分辨。还可以通过细粒度的访问控制有效的约束对数据库的访问行为，并且对符合规范的请求语句，在结果集上作出限制。JTB这个事件中虽然无法直接证明，但黑客获取数据库数据很可能是通过数据库信任的数据分析采集系统进行的。虽然请求语句是可信的，但如果黑客一次导出大量的结果集。数据库防火墙则会根据结果集行数限制的规则对操作进行阻断或拦截并提醒相关人员数据库中有异常流量。及时的阻断和拦截将有助于减小数据库外泄信息的条数，减小企业损失。

　　3.数据操作审计，实现安全追责和损失收集

　　JTB的数据库同时缺乏数据库审计工具。数据库审计工具多采用旁路的部署方式，对数据库性能毫无影响。可以审计到数据库上所有的流量。不怕黑客进入数据库后删除日志文件。数据库审计工具会清楚的显示出所有对数据库的请求和数据库的回复。一旦出现类似JTB的数据库数据泄露事件。可以在第一时间调取数据库审计产品，确认黑客到底拿走了什么数据。不需要花费将近3个月的时间去恢复CSV文件才能确定黑客给企业造成的损失。更重要的是不会造成消费者的恐慌心理。减小整个数据库泄露事件对企业的负面影响。并给安全机关提供有效的追查方向。

　　4.核心敏感数据实施必要的加密

　　JTB在存储数据的时候也犯了一个错误。不应该把核心信息存储成明文，而应该存储成密文，且采用基于上下文语境的强制访问控制来保护核心数据。在最坏的时候也能保障用户的核心信息不外泄。黑客即便拿到核心数据。但都是密文，同样也无法利用。

　　二、内网安全管控能力不强

　　企业对于外网的防护往往是不遗余力的，而对内网的检测和管控则或多或少都存在一些漏洞。Plugx在入侵了内网的一台PC机后会，利用这台PC机作为跳板在整个内网中传输含有plugx的木马程序。感染整个内网环境。如果采取更完善的内网环境的隔离和动态检测。相信不会这么大面积的感染内网环境中的机器，致使企业的账号密码都被plugx通过键盘记录器收集。以至于最后核心数据库被盗取。

　　三、企业安全意识薄弱

　　企业安全意识不强主要表现在两个方面上：1.从体制上，企业缺乏专业的安全团队保障整个企业的网络、业务、应用及系统安全。由于体制上的缺乏，导致了黑客入侵难以被发现。被发现也不会及时重视。一再贻误战机，最终导致793W数据外泄。2. 企业缺乏相关安全意识培训，致使员工安全意识薄弱。员工缺乏分辨钓鱼邮件的能力。回复邮件出现异常也未引起察觉。管理层也对安全威胁重视程度不足。早在19号第三方安全企业已经发出安全警告。管理团队仅采用对web服务器进行隔离、添加黑名单等治标不治本的手法。而没有在第一时间发现攻击的根源，导致本来可以减小的损失，并没有减小。

　　反思与总结：

　　对比JTB的三大失误和此次黑客入侵工具的三大特点不难看出。企业和黑客之间的战争正在悄然无息的全面升级。黑客越来越专业化，甚至根据不同的目标进行工具的优化。在整个企业安全的长城上寻找一丝一毫的切入口。任何一个缺陷最后都可能成为整个数据泄露的罪魁祸首。同样对于企业来说，随着互联网产业的发展，随着大量业务的互联网化。来自网络的威胁将逐渐成为未来企业将面对的最大威胁。如何解决好来自网络的威胁将成为困扰广大企业用户的长期问题。

  企业要想最终赢得这场与黑客之间的战争必须克服JTB犯的2大问题：一个是人的安全意识的问题、另外一个是核心数据的风险感知和安全防护的问题。不提高工作者、管理者、消费者的安全意识，安全永远是句空话。安全符合木桶原理，决定安全度的永远不是最长的板，而是最短的板。太多企业很注重自己的外网安全。但对内网安全特别是数据安全则重视程度并不足够。其实这是一种本末倒置的想法，黑客入侵企业网络，最希望的诉求就是获取数据库中的核心数据。当黑客进到内网遇到几乎“裸奔”的数据库服务器，兴奋程度可想而知。试想如果JTB在数据库前有数据库防火墙，数据库中的数据库恐怕没有这么容易被盗取;同样如果有针对数据库的审计产品相信JTB也不会为了弄清楚黑客从数据库中拿了什么，而花费近3个月的时间。

  给客户带来恐慌，给企业带来信任危机。哪怕JTB用数据库加密产品对数据库中关键字段加密，不是明文存放，至少保证客户信息在一段事件内的安全。期间通知客户进行修补，也能最大限度的避免损失。但可惜的是JTB对数据库什么都没做，于是黑客毫不费力的拿到了793W条核心数据。

　　你的企业想成为下一个JTB吗?不想就请给你的数据库加上安全防护吧，它远没你想的安全。