某流媒体协议应急响应事件回放

1、背景：

         2014的X月Z号，我收到公司信息安全委员会的一封邮件，说收到了一封来自老外的Email，Email里面描述到我们的传统行业设备存在一些安全问题，并在他们公司的官网上发布了相关的信息，之后我瞧了一下他们的分析报告，才刚看一小段我就已经明白一切了，理由是，在2014的X月Z-9号的时候，我们自己内部也已经发现了此漏洞，在互联网设备上已经迅速打补丁修复，我同时也考虑到代码复用的问题，当时也立马给传统行业部门的人打电话发了邮件要求处理此事，但没想到来得如此之快，事情的影响也比我们想象得复杂。

2、原因：

         设备使用的某流媒体协议存在缓冲区溢出漏洞，设备代码未对输入数据的长度进行有效性过滤导致漏洞的产生。

3、危害：

         老外在公布漏洞的同时，也公布了可进行利用的exploit，利用该exp，可针对某一款具体型号的设备执行任意代码，可获取最高权限的shell，由于互联网上有大量这样的设备，进一步可利用进行分布式的攻击，可产生巨大危害。

4、风险分析：

         处理传统行业设备比互联网设备有困难是原因的，互联网设备的整体架构如下 :

可以看到，使用互联网设备的2个基础条件是：

（1）、设备能够连接互联网。

（2）、设备必须要注册到云平台，并且和指定的账户建立绑定关系。

而传统行业设备整体架构如下：

可以看到，传统行业设备是没有平台管理的概念的，这也是由各自行业的定位决定的，互联网行业注重用户黏性，更多的是卖服务，而传统行业偏向于卖设备或者“离线”的解决方案，即把产品卖掉就算完事了，后续只是故障后维修的问题，这跟传统家电行业没区别。

传统行业设备要在互联网上使用，需要通过某种方式，将服务端口映射到公网上，然后通过APP等客户端软件直接连接设备的端口进行通信，由于没有平台，我们感知不到这种通信的存在，因此对我们来说，这跟用户在自己的局域网内使用设备没有区别。

当发生安全漏洞时，对于传统行业来说，就很难“联系”到这些设备，没办法快速地告诉用户去升级，而对于互联网设备来说，只需要通过云平台直接推送升级补丁消息到客户端即可。

5、应急处理措施：

5.1、短期对策（减少损失）：

（1）、想尽一切可能的办法（电话、邮件等）联系到客户，启动一些可以缓解的措施，比如：如果非必须，可以将公网映射取消，如果有防火墙，可以根据exploit协助用户设置防火墙规则进行攻击流量拦截。

（2）、对于拥有自己离线平台的大客户，可以协助客户安装紧急补丁服务器，并通过离线平台向下属用户的客户端推送升级消息进行升级。

（3）、对于散落在互联网上的无法“联系”的设备，是一个头疼的问题，鄙人想到了一个以毒攻毒的方法，思路是：既然利用漏洞可以执行任意代码，而任意代码既然可以干做坏事，拿当然也就可以做好事，那么我们是不是通过这个漏洞来patch漏洞本身呢，甚至在patch后还可以帮设备查杀一下木马，进一步的，我们还可以写一个程序，自动每天检测世界范围内的新上线的有漏洞的设备，每出现一台就patch一台，可将风险降至最低。此方法在咨询阿里巴巴道哥后，也得到了认可，但存在一定的其它风险因素，还有很多细节需要处理，在此不再详述。

5.2、长期对策（预防措施）：

         回头看，引发此次事件的根源仍然在于传统行业设备对安全的疏忽，在早期就没有引入安全设计、开发和测试的流程，才导致产品容易出现问题，因此，长期来说要做的东西还很多，比如让传统行业设备开始慢慢过渡到互联网平台，建立产品SDL流程等等。

某流媒体协议应急响应事件回放