20亿数据被窃取 全国最大实时公交APP险遭血洗

信息互联时代，不可否认的是，企业的发展越来越多的依托信息技术的演进，大多数企业利用信息化手段提高产出效率，提升产品质量，可还有些企业却想通过信息技术窃取别人的商业数据，妄图利用这种“省时省力”的方法打倒竞争对手，赢得商业战役。近期爆出的意见数据泄露事件就是这样一个活生生的例子。
事件回顾
7月12日，全国最大的实时公交软件“酷米客”被爆出大量后台数据遭泄露，窃取者竟是同行业竞争对手“车来了”。本次泄漏事件涉及“酷米客”大量核心商业数据，间接造成近20亿损失。法网恢恢，7月11日，车来了CEO被南山警方以非法获取计算机系统数据罪拘留。在进行分析之前，小编先做了一下事件梳理：
2014年 酷米客发现一个ip集群，盗取服务器上数据
2015年10 月 酷米客发现在北京的数据被大肆盗取
2016年 01月 谷米科技公司向南山分局报案
2016年06 月 车来了CEO被南山分局拘留
2016年07月 11日 嫌疑人被批准逮捕，案件处于侦查阶段
场景推演
安全事件爆出后，我们在进行技术分析之前，需要先搞清楚数据泄露的原因，才能够提出有针对性的安全加固方案，而找出泄露根本原因必须尝试还原场景。
我们看到，整个事件的核心目标是数据。在还原场景前，我们必须先搞清楚哪种数据被泄露。对于公交手机软件来说，两种数据至关重要：一种是用户个人信息，另外一种是公交车实时返回的GPS数据。GPS数据决定公交手机软件对公交车位置的播报是否准确，是“酷米客”核心业务的基础和支柱。我们通过被爆出遭泄露的三个关键数据进行判断：

1. 酷米客”每天收集的数据大约15亿条;
2. 酷米客注册用户大概有400万;
3. 从2014年开始，就有一个IP集群每天登录“酷米客”服务器上百万次，偷取数据。
   如果攻击者的目标是用户信息，则不需要每天登陆服务器且取多次，如此高的访问频率，只有一种可能，攻击者窃取的是GPS实时返回的公交车定位数据。
   我们结合公交车软件业务运作方式，抽象出 “酷米客”的数据传输架构，软件的工作运行流程如下图所示：
   

   1470124654-2846-07

4. 酷米客在公交车上安装了车载GPS，车载GPS每10秒向GPS信号接收口发送GPS信号。GPS信号报告公交车当前位置。
   

5. GPS信号接收集群处理GPS信号，整合出公交车所在经纬度的数值信息。并把相关信息存储到后台的数据库服务器中。
   

6. 为了保证安全数据库集群把加密后的数据库数据传输到支持服务的数据库上准备为用户查询提供数据。
   

7. 用户通过手机上的app软件访问后台服务器的支持数据库查询出自己所关心的数据，数据在app上被解密还原成明文展现给客户。
   

此次事件中黑客盗取了存放在支持服务数据库中的加密数据。根据“酷米客”员工的说法：攻击者是采用模拟用户登陆访问，从实时公交app获取公交信息。攻击者制作的模拟访问软件能同时模拟几百万甚至更多的用户访问登陆软件，这些访问把结果数据综合起来就能获得公交实时数据，再次处理后，通过APP发布信息。这样一套访问-获取-发布流程，最终数据输出，只比酷米客的数据晚几毫秒。由此分析得出：整个事件的关键是如何在数据流上对非正常用户的流量进行拦截。作为一个互联网公司，相信酷米客的信息安全意识不会很弱，显然，目前现有的数据安全防护不足以抵御此类攻击。
解决方案
通过对攻击特点进行分析，我们发现，此类攻击防御的关键点在于：如何从数据特征上分析出是人工登陆还是软件模拟登陆，识别登录类型成为解决问题的关键点。我们可以从两个层面进行识别：
一、 在网络层面，通过识别ip的特征行为来判断是否是非用户操作。

1470124631-7416-07

　　基于网络层面可以通过后台服务器流量统计和日志分析来识别是否是非用户操作。竞争对手盗取公交信息实时数据，必然是频繁、大并发量、规律的获取数据。通过以上特点可以制定出具针对性的策略：

1. 在单位时间内对每个ip可访问后台服务器的次数做限定、每次访问减1，直至减到0为止，如果该IP继续访问后台服务器，可返回验证图片让用户填写验证码，以保证访问者是真实用户而非恶意软件。
   

2. 对单一ip的同一时刻大量的访问进行减速处理。通过锁的方式，延长单个ip请求的所有数据回复速度，使大并发短期内拿不到所有数据。让实时数据过期无效。
   

3. 机器发起访问的频率比较固定，不像人的操作，间隔时间无规则，我们可以给每个IP地址建立一个时间窗口，记录IP地址最近12次访问时间，每记录一次滑动一次窗口，比较最近访问时间和当前时间，如果间隔时间很长判断是用户行为，清除时间窗口;如果间隔不长，返回验证图片让用户填写验证码。这种方式较为常见，可以在一定程度上减缓酷米客遭到的入侵，但并不是一个完善的解决方案。
   

二、 在数据层面，通过对请求数据的特征和规律判断是否是非用户操作。
通过网络层能做到的只能是通过对统计数据的分析，事后区分操作者是用户还是软件，很难及时发现数据被盗取。相比之下，从数据层面的识别方法更准确、快捷。
在后台应用服务器和支持服务的数据库之间部署数据库防火墙，通过数据库防火墙的应用关联功能可以把对后台服务器提出的请求语句、请求ip、用户信息等与最终向数据库中提取的sql语句做关联。比如：一般情况下杭州的IP应该查询杭州的公交数据信息，如果杭州的IP查询北京的公交信息，这很可能是模拟软件伪装成用户，这样在返回公交信息数据库前，数据库防火墙会阻断数据库的回包，向后台服务器发送信息，让后台服务器向可以链路发送身份验证图片，一旦身份验证图片通过则发送被阻断的数据库回包。如果身份验证超时或不通过，则把该ip纳入数据库防火墙黑名单，以后、、凡是杭州ip请求北京数据的行为直接阻断，不发送到数据库端。这样既及时的阻止了数据被盗取，又减小了数据库的查询压力。
总结
以上两种识别阻断方案针对本次攻击事件提出，虽然可以解决眼前的问题，但并非是最佳的长期解决方案。下次黑客从哪来？用什么方式？采用什么技术？攻击的流量有什么特征？面对不断来袭的未知威胁，未雨绸缪，加强核心数据的感知风险能力，才能形成主动的数据安全防护能力。
数据安全的感知风险能力依托于，从应用请求和数据库sql语句之间的固定映射关系以及请求语句和sql语句的特殊特征。可以通过学习的方式自动完成数据库和固定应用之间的可信语句模型搭建，只允许符合语法模型的应用请求和sql语句从数据库中获取信息。一旦发现有不符合原语法模型的语句，表示数据库可能遭到非法访问，对语句进行警告并控制，并记录下该行为的来源(IP地址和使用用户名)，作为审查的线索，以达到在第一时间发现异常行为，感知风险，进行响应。
反思
迈向大数据时代，核心数据已成为企业的核心竞争力，越来越多的泄漏事件显示，攻击者的目标已逐渐转向企业核心数据库，而现实是，大多数企业的网络安全防护仅仅停留在传统的边界安全部署，对于数据库本身的安全防护则少之又少。“酷米客”的事件以窃取者被逮捕而告终，但如果事情换一个结局，窃取者没有被抓获，那么“酷米客”将要面临的也许是用户、业务的流失，乃至行业地位不保。
法律在努力保护我们，但事后追责只能挽回经济损失，失去的数据、用户、商誉无法弥补，对企业未来的业务影响更是难以预计，面对未知的安全挑战，提前感知，主动防御，全面保护企业核心数据资产，就是保护企业的长远发展。

转自：20亿数据被窃取 全国最大实时公交APP险遭血洗