8月12日,随着DEFCON的正式结束,今年全球两大最顶尖的安全技术爱好者盛宴——Black Hat和DEFCON也相继落下帷幕。最顶尖的技术交流盛会,自然少不了众多安全大厂的参与。今年,360依然入选了多个优质议题,主题涵盖模糊测试、漏洞利用链、智能合约、WiFi安全、芯片漏洞、协议安全等内容。

安全牛从中精选出三个有趣的攻防议题,将其核心内容分享给大家。

议题1. 适用于隔离环境下的隐蔽通信方式(Ghost Tunnel)

议题来源:360无线电安全研究院天马安全团队研究员 曹鸿健 & 秦明闯

针对隔离网攻击的议题,总是能吸引安全爱好者的兴趣,即使Black Hat并不是该议题——Ghost Tunnel(幽灵隧道)在安全会议上的首次“亮相”。

在今年4月的HITB,360天马安全团队就分享了这个适用于隔离网环境下的隐蔽通信议题。利用PC终端的无线模块,攻击者可以通过已植入的恶意程序(USB-HID攻击、钓鱼邮件等),调用OS层控制无线模块的API,通过在管理帧的相应字段替换数据,实现最多每秒255字节的隐蔽数据传输

255字节负载

该攻击有两个重要的特点:

一是几乎不受操作系统(适用win、macOS、Linux)和WiFi模块厂商的限制,只要设备包含无线模块,可以说是“通杀”;

二是攻击是在PC扫描WiFi列表阶段实现数据传输,不会建立WiFi连接,不会影响现有网络,且不会更改数据帧内容,所以用户完全无感知,隐蔽性极强。

不建立WiFi连接

据了解,如果要想发现类似的行为,安全人员需对802.11协议数据包进行分析审计,因为大量安全设备都工作在网络层,所以主机一旦被植入恶意程序,隐蔽传输行为就很难被发现。

相关链接:

https://github.com/360PegasusTeam/ghosttunnel 

议题2. 以LoRa智能水表为例的安全性分析

议题来源:360无线电安全研究院独角兽安全团队研究员 曾颖涛

LoRaWan是一种低功耗、广域的网络通信协议,可以满足物联网设备在无线通信时,对双向通信、端到端安全、移动和定位等需求。安全性是IoT设备在通信时的重要需求,所以LoRAWan协议在设计时就重点考虑了这个点,主要包括使用AES算法来确保应用通信和认证过程安全性,以及两层加密机制:端点设备和网络服务器共享的一个128位网络Session密钥;终端设备间在应用层共享的一个128位应用Session密钥。

LoRa网络架构

但是,360独角兽安全团队的研究员发现,常见使用LoRa的IoT设备并没有采用LoraWan这套标准协议,而是厂商自拟的私有协议。

以智能水表为例。LoRa水表的完整架构包括终端、网关、服务器和计费系统四部分。终端通过磁性传感器进行用水量的计数,网关采集终端的用户使用数据后,回传给服务器进行计费。

通过对水表终端和网关设备的硬件拆解,安全研究员找到了用于传输LoRa信号的SX1278芯片,并基于对LoRa射频信号的嗅探,逆向出了水表终端、网关和服务器间的通信协议。

逆向后的协议,暴露出了4个重大安全脆弱点:

  • 伪造水表对用户用水数据的计数结果(需要物理接触水表终端的磁性传感器);

  • 在水表和网关间,嗅探并伪造用户的用水数据(隐私泄露);

  • 通过伪造网关,给终端节点下发恶意指令并进行控制;;

  • 通过2G伪基站进行GPRS中间人攻击,伪造网关上传到服务器的数据。

LoRa智能水表风险分析

据介绍,该攻击的实现,有效范围在3-4公里,所以可以如果有足够多的嗅探节点,可以相对完整的覆盖整个小区。目前,厂商除了使用LoRaWan标准协议之外,还可以对所有传输的数据内容进行加密处理,并在传输的数据中加入计数值和签名,以最大程度保障设备间通信的安全性。

议题3. 以太坊智能合约重放攻击

议题来源:360无线电安全研究院独角兽安全团队资深安全专家 郑玉伟

今年6月,360公开了其发现的一系列区块链平台EOS的高危漏洞,引起了社会各界对智能合约安全性的广泛关注。但其实,更多的安全工作者早已经走在了这前面。

区块链的安全性这里就不再多做介绍。作为区块链重要的实现基础,“智能合约”本质上仍是软件,所以尽早发现安全漏洞及其可能的利用方式,并协助运营者在造成恶劣影响前完成修补,仍是安全工作者目前主要的关注重点。

此次360分享了一种针对以太坊智能合约的“重放攻击”漏洞,即发生在一个合约上的交易,在另外一个合约上也可以被确认为有效。一些智能合约在生成支付token的过程中,对签名的适用范围存在不当设计,导致用户的签名滥用,存在交易在合约上被重放的风险,从而给用户造成经济损失。

智能合约重放攻击示意

如图所示,用户A在合约RAContract1上给用户B转100个token,由于A没有以太坊,于是他通过代理C完成这笔交易,并支付C代理3个token作为费用,这会调用transferProxy 这个接口。但是在transferproxy的参数中,签名值sig仅与发起方A、接收方B、交易金额100、代理费用3、以及nonce(注:一个随机数)有关,签名密钥也只涉及到发起方A的私钥,与合约本身及代理C没有任何关系。而合约RAContract2的签名设计与合约RAContract1相同,所以在合约RAContract1上发生的交易时的签名,在RAContract2上依然有效。 那么B就可以利用该签名在RAContract2上发起一笔同样金额的交易,从而获得A在RAContract2上的额外100个token。

据360独角兽安全团队统计,截止到2018年4月27日,在遍历以太坊ERC20合约的基础上,共发现了52个合约存在此重放攻击风险。这其中,签名中不包含任何特定信息,即可直接重用的合约共10份,只做了简单限制(包含固定字符串)的合约共37份。这部分问题合约中,有近一半(24份)在一周内有交易记录。

据了解,此次发现的智能合约漏洞虽然没有之前的EOS漏洞影响面大,但在修补难度上,却远高于后者。EOS漏洞可以通过系统升级来解决,但智能合约一旦完成部署,根据代码及法律的逻辑,二进制代码不能做出任何修改,一旦出现安全问题,只能通过创建新合约(并将原有用户及资产进行迁移)来解决。这不仅会给发行方增加新合约创建及迁移用户的成本,还会带来各交易所在协议和资产方面的同步问题。

声明:本文来自安全牛,版权归作者所有。文章内容仅代表作者独立观点,不代表士冗科技立场,转载目的在于传递更多信息。如有侵权,请联系 service@expshell.com。