5步建立起更好的IoT安全基线
作者: 日期:2017年12月14日 阅:4,641

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

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,限制缺乏基本安全控制的联网设备的增值扩散,就显得越来越重要。

相关阅读

首届小米IoT安全峰会的四个精华议题

CES 2017大会上新登场的7种IoT安全产品技术

安全大师施奈尔:全球各国都应该开始考虑监管IoT安全

 

关键词:

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章