AMNESIA33：开源TCP/IP和谈栈系列缝隙分析与验证
颁布功夫 2020-12-14媒介
近期，，，，，，，，国表安全钻研人员在多个被宽泛使用的开源TCP/IP和谈栈发现了多个缝隙，，，，，，，，这一系列缝隙统称为AMNESIA33。。。 。。。。。这些缝隙宽泛存在于嵌入式和物联网设备中，，，，，，，，影响了多个行业领域（蕴含医疗、运输、能源、电信、工业节造、零售和贸易等），，，，，，，，目前已知领域内涉及了超150家供给商以及数以百万计的设备。。。 。。。。。与URGEN11和Ripple20分歧的是，，，，，，，，AMNESIA33影响的是多个开源TCP/IP和谈栈，，，，，，，，因而这些缝隙能够悄无声息地影响到无数个代码库、开发团队与各个公司的产品。。。 。。。。。目前已知的缝隙涉及到了智能家居、工厂PLC、SCADA设备与工控互换机，，，，，，，，电力监控等设备。。。 。。。。。
这些缝隙存在于uIP、FNET、picoTCP和Nut/Net等开源和谈栈上，，，，，，，，影响TCP/IP和谈栈的多个组件，，，，，，，，蕴含DNS、IPv6、IPv4、TCP、ICMP、LLMNR和mDNS等。。。 。。。。。其中蕴含多个严沉缝隙，，，，，，，，它们的CVE编号别离为CVE-2020-17437、CVE-2020-17443、CVE-2020-24338、CVE-2020-24336、CVE-2020-25111。。。 。。。。。
CVE-2020-17437（CVSS评分8.2）、CVE-2020-17443（CVSS评分8.2）可导致设备回绝服务。。。 。。。。。CVE-2020-24338、CVE-2020-24336、CVE-2020-25111（这三个CVSS评分均为9.8）都可导致远程代码执行(RCE)。。。 。。。。。其它28个缝隙的严沉水平各别，，，，，，，，CVSS评分别离从4到8.2。。。 。。。。。
由于IoT、OT、IT设备供给链的个性，，，，，，，，缝隙影响的设备多多，，，，，，，，影响领域广且持续功夫长，，，，，，，，缝隙建复的执行较难题。。。 。。。。。同时，，，，，，，，由于uIP、picoTCP开源和谈栈已经不再守护，，，，，，，，所以部门缝霞有补丁，，，，，，，，好多产品只能寻找代替技术规划或者是增长防备措施。。。 。。。。。
对于这些缝隙的防备缓解措施，，，，，，，，我们建议采取如下几个措施：
● 配置内网设备的DNS服务器为内网DNS服务器。。。 。。。。。
● 利用漏扫产品鉴别出选取问题和谈栈的设备资产，，，，，，，，对组织内可能存在问题的IoT、OT和IT设备进行风险评估。。。 。。。。。
● 防火墙及IPS产品参与AMNESIA33缝隙攻击鉴别特点，，，，，，，，监控恶意流量。。。 。。。。。
● 尽可能更新有关受影响和谈栈到最新版本。。。 。。。。。
下表是部门已经建复的和谈栈及版本：
TCP/IP和谈栈 | 建复版本 |
FNET | 4.70及以上 |
uIP-Contiki-NG | 4.6.0及以上 |
Nut/Net | 5.1及以上 |
CISA联盟分享了13个涉及到AMNESIA33缝隙的公司的产品建复建议，，，，，，，，蕴含了Microchip、Siemens等公司的产品，，，，，，，，详见参考链接[5]。。。 。。。。。
1、DNS和谈解析
DNS的要求和响应的根基单元是DNS报文（Message）。。。 。。。。。要求和响应的DNS报文结构是齐全一样的，，，，，，，，每个报文都由以下五段（Section）组成：
DNS Header是每个DNS报文都必须占有的一部门，，，，，，，，它的长度固定为12个字节。。。 。。。。。Question部门存放的是向服务器查问的域名数据，，，，，，，，通常情况下它只有一条Entry。。。 。。。。。每个Entry的体式是一样的，，，，，，，，如下所示：
QNAME是由labels序列组成的域名。。。 。。。。。QNAME的体式使用DNS尺度名称暗示法。。。 。。。。。这个字段是变长的，，，，，，，，因而有可能呈显戽数个字节，，，，，，，，但不进行补齐。。。 。。。。。DNS使用一种尺度体式对域名进行编码。。。 。。。。。它由一系列的label（和域名中用.宰割的label分歧）组成。。。 。。。。。每个label首字节的高两位用于暗示label的类型。。。 。。。。。RFC1035中分配了四个里面的两个，，，，，，，，别离是：00暗示的通常label，，，，，，，，11（0xC0）暗示的压缩label。。。 。。。。。
Answer、Authority和Additional三个段的体式是齐全一样的，，，，，，，，都是由零至多条Resource Record（资源纪录）组成。。。 。。。。。这些资源纪录由于分歧的用处而被分隔存放。。。 。。。。。Answer对应查问要求中的Question，，，，，，，，Question中的要求查问了局会在Answer中给出，，，，，，，，若是一个响应报文的Answer为空，，，，，，，，注明这次查问没有直接获得了局。。。 。。。。。
RR(Resource Record)资源纪录是DNS系统中极度沉要的一部门，，，，，，，，它占有一个变长的结构，，，，，，，，具体体式如下：
● NAME：它指定该笔纪录对应的是哪个域名，，，，，，，，体式使用DNS尺度名称暗示法
● TYPE：资源纪录的类型。。。 。。。。。
● CLASS：对应Question的QCLASS，，，，，，，，指定要求的类型，，，，，，，，常用值为IN，，，，，，，，值为0x001。。。 。。。。。
● TTL(Time To Live)资源的有效期：暗示你能够将该条RR缓存TLL秒，，，，，，，，TTL为0暗示该RR不能被缓存。。。 。。。。。TTL是一个4字节有符号数，，，，，，，，但是只使用它大于蹬宗0的部门。。。 。。。。。
● RDLENGTH：一个两字节非负整数，，，，，，，，用于指定RDATA部门的长度（字节数）。。。 。。。。。
● RDATA：暗示一个长度和结构都可变的字段，，，，，，，，它的具体结构取决于TYPE字段指定的资源类型。。。 。。。。。
DNS响应包如下图所示：
从上图中可知，，，，，，，，该Answers区段中存在9个资源纪录，，，，，，，，红框中暗示的是主机地址（A类型）资源纪录。。。 。。。。。
域标签label在DNS数据包里被编码，，，，，，，，每个通常标签的第一个字节代表这个标签的长度，，，，，，，，剩下的字母数字字符为标签自身(一些特殊字符也是能够的)，，，，，，，，但是最终结尾的字符肯定是以空字节结尾(即0x00)，，，，，，，，用来暗示域名的实现。。。 。。。。。举个例子，，，，，，，，如下图所示，，，，，，，，域标签第一个字符是0x03，，，，，，，，这代表第一个标签长度为3(即0x77 0x77 0x77 == “www”)，，，，，，，，同理，，，，，，，，0x62 0x61 0x690x64 0x75 == “baidu”，，，，，，，，最后能够看到以0x00结尾。。。 。。。。。
2、TCP垂危模式
为了发送沉要和谈数据,TCP提供了一种称为垂危模式(urgentmode)的机造，，，，，，，，TCP和谈在数据段中设置URG位,暗示进入垂危模式。。。 。。。。。通过设置垂危模式，，，，，，，，发送方能够在发送队列中优先发送这部门的数据，，，，，，，，并且不用在发送队列中列队，，，，，，，，而接管方能够对垂危模式采取特殊的处置。。。 。。。。。这种方式数据不容易接受被阻塞,服务器端法式会优先接受这些垂危的数据，，，，，，，，而不用进行列队处置。。。 。。。。。在TCP报文中界说了两个字段来标示垂危模式，，，，，，，，一个URG标志，，，，，，，，该标志暗示报文中有垂危数据，，，，，，，，另一个标志是垂危指针，，，，，，，，它标示垂危数据在传输数据中偏移地位。。。 。。。。。如下图所示：
下面我们对几个CVSS评分较高的缝隙进行分析：
1、CVE-2020-17437
CVE-2020-17437存在于uIP和谈栈的uip.c文件的uip_process函数中，，，，，，，，该函数重要是处置ip/tcp报文，，，，，，，，下图是uIP和谈栈对TCP报文中带有TCP_URG垂危指针标识时的处置代码，，，，，，，，若是编译时配置了UIP_URGDATA，，，，，，，，则法式会走到下面的if分支，，，，，，，，对垂危指针数据进行专门处置。。。 。。。。。
但是在默认情况下，，，，，，，，UIP_URGDATA并没有配置。。。 。。。。。代码会进入到else分支，，，，，，，，法式会跳过处置垂危指针数据，，，，，，，，并批改uip_len的数值。。。 。。。。。法式在批改uip_len的时辰并没有判断垂危指针的值，，，，，，，，当uip_len的值出格幼，，，，，，，，而垂危指针的值urgp出格大时，，，，，，，，就会引起整数溢出，，，，，，，，导致设备沉启或者是越界读写。。。 。。。。。
2、CVE-2020-24338
该缝隙呈此刻picoTCP/IP和谈栈中解析域名label的pico_dns_decompress_name()函数中，，，，，，，，该函数具体实现如下代码所示：
第95、96行初始化iterator，，，，，，，，name指向待解压缩的labels，，，，，，，，dest_iterator指向存放解压出来的labels的缓冲区，，，，，，，，大幼为256字节。。。 。。。。。第97行起头为while循环，，，，，，，，读取到字符串结尾空字节退出。。。 。。。。。第98行，，，，，，，，通过iterator&0xC0判断label类型，，，，，，，，若是为压缩label，，，，，，，，则通过packet定位到通常label地点的地位，，，，，，，，若是为通常label直接进入else代码块中，，，，，，，，第107行，，，，，，，，挪用memcpy将通常label拷贝到dest_iterator钟祝。。 。。。。。我们知路dest_iterator缓冲区大幼只有256字节，，，，，，，，而while循环退出前提为读到字符串结尾空字节，，，，，，，，因而当name长度超过256字节时，，，，，，，，导致dest_iterator缓冲区溢出。。。 。。。。。
3、CVE-2020-24336
该缝隙呈此刻contiki和谈栈中的ip64_dns64_4to6()中，，，，，，，，该函数职能是将ipv4类型的DNS数据包转换成ipv6类型的DNS数据包，，，，，，，，关键代码如下：
遍历Answer区段并更新到ipv6类型的Answer区段钟祝。。 。。。。。从第209行起头转换资源纪录，，，，，，，，具体实现代码如下所示：
首先判断TYPE是否是DNS_TYPE_A，，，，，，，，DNS_TYPE_A暗示该资源纪录为ipv4主机地址，，，，，，，，而后将对应区段拷贝到acopy钟祝。。 。。。。。第220行，，，，，，，，从资源纪录中直接取RDLENGTH，，，，，，，，前文已介绍，，，，，，，，该区段表征RDATA的长度。。。 。。。。。第227行，，，，，，，，判断len长度是否蹬宗4，，，，，，，，这里正常情况，，，，，，，，len应该为4，，，，，，，，由于ipv4地址长度为4个字节。。。 。。。。。若是len不蹬宗4，，，，，，，，则进入else语句中，，，，，，，，直接挪用memcpy进行RDATA数据拷贝。。。 。。。。。这里是存在问题的，，，，，，，，Ipv4主机地址长度不蹬宗4，，，，，，，，并没有验证主机地址的合理性并且len最大为0xFFFF，，，，，，，，直接拷贝可能导致缓冲区溢出。。。 。。。。。
4、CVE-2020-25111
在使用Nut/Net和谈栈的设备中，，，，，，，，NutDnsGetResourceAll()是处置DNS要求的函数，，，，，，，，其中处置DNS回答的函数是DecodeDnsQuestion()，，，，，，，，处置域标签的函数是ScanName()，，，，，，，，缝隙就呈此刻ScanName()函数钟祝。。 。。。。。如下图所示，，，，，，，，cp为指向域名第一个字节的指针(即第一个域标签的长度字节)，，，，，，，，*npp为即将被解析的域名buffer，，，，，，，，通过strlen()将整个域名长度赋值给rc,而后基于rc分配*npp buffer，，，，，，，，之后通过一个while，，，，，，，，循环处置每一个label。。。 。。。。。问题不言而喻，，，，，，，，cp是攻击者可控的，，，，，，，，由此能够节造*npp的大幼。。。 。。。。。而对于标签的长度，，，，，，，，即len变量，，，，，，，，直接从数据包中得到，，，，，，，，并没有做任何天堑查抄，，，，，，，，而后通过while循环处置。。。 。。。。。因而能够对len设置肆意的值，，，，，，，，即攻击者对*npp buffer可控的长度。。。 。。。。。由此能够在堆中造成越界写，，，，，，，，这可导致远程代码执行(RCE)。。。 。。。。。
5、CVE-2020-17443
CVE-2020-17443存在于PicoTCP和谈栈pico_icmp6.c文件钟祝。。 。。。。。问题代码位于pico_icmp6_send_echoreply（）函数中，，，，，，，，该函数的重要职能是回复ICMPv6应答数据包以响应对端的ICMPv6Echo(ping)要求。。。 。。。。。
我们能够看到，，，，，，，，第68行，，，，，，，，replay结构的缓冲大幼基于echo的报文中transport_len变量。。。 。。。。。在第84行，，，，，，，，法式从echo->payload向reply->payload地址复造了长度为echo->transport_len- 8大幼的数据。。。 。。。。。
把稳，，，，，，，，若是echo->transport_len幼于 8，，，，，，，，echo->transport_len - 8会导致整数溢出，，，，，，，，memcpy操作会导致缓冲区溢出。。。 。。。。。
在PicoTCP和谈栈攻击者通过机关恶意的ICMPv6数据包，，，，，，，，这个恶意的数据包ICMP报头幼于8，，，，，，，，会导致设备沉启或回绝服务。。。 。。。。。
缝隙验证
缝隙验证视频请查看ADLab公家号
参考链接：
[1] https://www.forescout.com/research-labs/amnesia33/[2]https://www.securityweek.com/amnesia33-vulnerabilities-tcpip-stacks-expose-millions-devices-attacks
[3] https://www.zdnet.com/article/amnesia33-vulnerabilities-impact-millions-of-smart-and-industrial-devices/
[4] https://tools.ietf.org/html/rfc1035
[5] https://us-cert.cisa.gov/ics/advisories/icsa-20-343-01
8827太阳集团积极防御尝试室（ADLab）
ADLab成立于1999年，，，，，，，，是中国安全行业最早成立的攻防技术钻研尝试室之一，，，，，，，，微软MAPP打算主题成员，，，，，，，，“黑雀攻击”概想首推者。。。 。。。。。截止目前，，，，，，，，ADLab已通过CVE累计颁布安全缝隙近1100个，，，，，，，，通过 CNVD/CNNVD累计颁布安全缝隙900余个，，，，，，，，持续维持国际网络安全领域一流水准。。。 。。。。。尝试室钻研方向涵盖操作系统与利用系统安全钻延注移动智能终端安全钻延注物联网智能设备安全钻延注Web安全钻延注工控系统安全钻延注云安全钻延祝。。 。。。。。钻研成就利用于产品主题技术钻延注国度沉点科技项目攻关、专业安全服务等。。。 。。。。。
京公网安备11010802024551号