5步建立起更好的IoT安全基线

企业接入点制造商Ruckus又补上了一堆指令注入漏洞，这些漏洞可致ZoneDirector控制器和Unleashed AP虚拟控制器被黑客完全掌控。其中一个漏洞，与去年被披露的Ruckus Web-GUI问题极端相似。虽说任何足够复杂的软件都难免出现漏洞，但仍有几个缓解方法可以大幅减小成功漏洞利用的影响。

[[213358]]

2017年，没理由让某些设计缺陷在一个又一个产品中不断复现。安全人员是时候开始对供应商期待更多了。

以下几个安全操作，我们应纳入IoT安全基线来考虑：

1. 别再什么都用root权限来运行

或许在嵌入式Linux早期，资源限制让开发者不得不放弃传统基于用户的安全模式，而转向什么都用root用户来执行。时至今日，再没有任何借口连Web服务器都以uid为0的最高权限来运行了。

默认情况下，管理界面应以较小权限运行，只可执行部分特权操作。只要Ruckus采用了任何形式的权限分离，就不会发生曝出的漏洞被直接用于完全入侵的状况。

2. 反跨站请求伪造令牌应普遍应用

跨站请求伪造(CSRF)是嵌入式设备中最常见的安全缺陷之一。再加上大多数IoT产品本就设计成盲目信任局域网，或压根儿不能恰当地验证身份令牌，情况就更严重了。

如果Ruckus在接到漏洞报告之后就实现了CSRF防护，这些新漏洞最多也就能算作是内部人威胁。然而，现实是，编写JavaScript代码在局域网上定位设备并中继转发攻击，并不是太难的事。

3. 建立漏洞利用缓解机制

防御技术最近几年有了长足发展，但没看到嵌入式设备对此有何利用。很多设备都没采用地址随机化(ASLR)、位置无关可执行文件(PIE)，或不可执行(NX)之类的技术。虽然这本身不是什么漏洞，这些技术也并不完美，但它们确实抬高了利用内存崩溃漏洞的门槛。

当然，供应商们采用更新一点的技术，比如控制流完整性(CFI)，甚或某些运行时杀软，也很棒。但这不是不采用早在15年前就可供Linux使用的安全功能的理由。

4. 身份验证请求

设备默认来自局域网的请求已通过验证的情况太普遍了。比如说，Belkin WeMo智能开关就允许用户家庭网络中的任何人进行控制，并关联上你的家庭账户。Mios Vera智能家居控制器想要启用任何形式的身份验证，都要求用户翻遍各设置选项才能找到，如果其间遇到互联网服务中断，还会让设备无法使用。

同时，Control4智能家居系统需要身份验证才能登录App，但设备却无需任何令牌或口令，就可以通过基于XML的协议接受指令。授权机制的缺乏或脆弱，再加上CSRF，可使恶意网页在无需受害者之前已验证过的情况下，就直接操纵设备。

5. 别再用那么多的HTTP

即便不通过Web浏览器访问设备，也很有可能有台Web服务器正在运行。路由器和智能家居控制器之类设备的Web管理界面，通常都是攻陷设备的最大攻击界面。虽然路由器这种东西的管理界面极少被用到，但HTTP服务器却是一直在运行，随时等待接收请求。

HTTP服务器的使用意味着，托管恶意Web内容的攻击者(可能是恶意广告)，可以直接向服务器发出请求。即便CSRF缓解措施就位，Web服务器实现中的漏洞本身，往往就是致命的。

举个例子，多款NETGEAR路由器，为其所有管理功能使用了基于时间戳的CSRF防护，但因为该Web服务器中的一个低级错误，这些路由器都可通过CSRF进行利用。

理想状态下，我们当然更希望看到大多数设备通信，都从HTTP迁移到更专用的协议上来，比如消息队列遥测传输协议(MQTT)，这样就基本上能对跨站和跨协议漏洞利用免疫了。配置页面之类的情况，或许HTTP/HTTPS是最佳选择，但既然用到它们的时候极少，又何必随时开启呢?

一个简单的解决方案是，用个按钮或其他某种非HTTP触发器，来启动管理界面，然后在特定超时期限后自动禁用。

总结

以上5个相对简单的策略显然不算完整，但实现它们确实可以大幅减小攻击界面。随着现实世界IoT攻击的增多，比如曾经的Mirai和现在的Reaper，限制缺乏基本安全控制的联网设备的增值扩散，就显得越来越重要。