论文题目

SYMTCP:Eluding Stateful Deep Packet Inspection with Automated Discrepancy Discovery

发表会议

Title:SymTCP: Eluding Stateful Deep Packet Inspection with Automated Discrepancy Discovery

Author:Wang, Zhongjie and Zhu, Shitong and Cao, Yue and Qian, Zhiyun and Song, Chengyu and Krishnamurthy, Srikanth V and Chan, Kevin S and Braun, Tracy D

Booktitle:NDSS 2020

一、论文摘要

DPI的一个重要特征就是其单独实现了一个关于网络协议栈的简化状态机，其和许多终端的实现不同。利用DPI和终端的网络协议实现的不同可以穿透DPI中间件。之前针对DPI的绕过攻击大多是基于人工构造对抗性报文，不仅耗时耗力，并且不方便在不同版本的DPI之间进行拓展。本文的工作就是实现了一个可以自动生成针对DPI对抗性报文的系统，其主要思想是利用DPI和终端的网络协议实现之间差异。本文利用符号执行技术自动化探索终端的tcp实现过程，明确了针对终端的逃逸(被DPI忽略但被server接受)和插入(被DPI接受但被server忽略)的报文；然后利用这些得到的报文针对DPI进行测试，来判断DPI针对这些报文的处理行为是否和终端相同。本系统可以咋一小时内生成数以万计的对抗性报文，并且我们测试了最先进的DPI设备，比如Zeek、Snort、GFW(中国长城防火墙)，不仅发现了已经暴露的逃逸策略，冰企鹅额也发现了一些从未发现的逃逸策略。并且本系统可以很方便地向其他操作系统或者DPI中间件进行拓展，本系统也可以作为DPI对抗性检测工具。

二、研究动机

当前针对DPI的绕过攻击研究大多数是基于人工分析其脆弱性，并且研究成果无法方便地向其他系统进行拓展，本文旨在研究并实现一个可以自动化生成DPI对抗性报文的系统，来绕过DPI检测。

三、脆弱性分析

DPI实现了其自身简化的TCP有限状态机，虽然TCP的具体协议有统一的标准，但是具体实现起来，不同系统中将会存在差异，这就导致DPI和终端系统针对accept/drop报文的认定存在一定的差异，利用DPI和endhosts之间存在的差异，我们可以绕过DPI的检测，传输一些非法的报文。

四、主要贡献

作者利用公式定义了insertion/evasion包，为之后探索TCP空间寻找insertion/evasion提出了一个通用的方法。

开发了一个端对端的原型系统SYMTCP，其可以自动化的发现DPI以及终端系统中TCP实现的差异。

将SYMTCP针对Zeek，Snort，Great Firewall of Chine(GFW)进行测试并发现了许多逃逸策略，并且本系统还十分方便的可以向其他系统或者其他DPI进行拓展。

五、背景介绍

(一)DPI绕过攻击

DPI主要是针对应用层报文进行判断，来认定其内容是否合法从来进一步选择是否放行报文。DPI首先从interface中抓取报文信息，经过parser处理之后生成parser output，然后利用pattern匹配进行判断，根据判断结果认定其内容是否合法。

DPI绕过的一个主要原因是针对TCP的实现，DPI和终端系统实现具体不一致，比如针对Snort来说，只要是RST packet的sequence number在接受窗口之内，这个RST packet就可以被Snort接受，但是针对最新版本的linux实现，RST packet的number必须确保其和rev_next报文相匹配。

DPI绕过的第二个原因是DPI不知道具体的网络拓扑信息，即其放行的报文不确保其可以作用于终端系统，比如一个TTL很小的packet，大概率是不会到达终端，即其对终端不起作用，但是其可以真实的作用的DPI中。

(二)符号执行引擎选择

本文选择了selective symbolic execution，由于其可以选择性的符号执行我们指定的程序范围内的程序代码，所以其可以更灵活以及方便地测试大型软件，比如linux内核，本文中针对linux内核中的tcp实现过程，利用符号执行过程进行路径探索，针对其余部分采用真实执行，这样通过符号执行过程和真是执行过程的切换，来实现针对linux内核的测试。

本文在具体实现环节，采用S2E作为实际环境，其提供了不同层级的执行一致性，可以在性能、completeness、soundness之间进行权衡。

六、解决方案

(一)问题定义

首先对问题进行抽象化，便于之后解决问题。前面的几个定义均是为了后面定义insertion/evasion包做准备。

1. TCP状态机

M = (Q, q0, Σ,Λ, T, G)

Q is the set of states,

q0 ∈ Q is the initial state,

Σ is the input alphabet, i.e., a TCP packet,

Λ is the output alphabet, i.e., the TCP data payload,

T : Q × Σ → Q is the state transition function, and

G : Q × Σ → Λ is the output function.

M表示有限状态机，Q表示状态集，q0表示起始状态，Σ表示输入字符集，Λ表示输出字符集，T表示状态转函数，G表示输出函数。

需要特别注意的是，输出对应的是存储应用层内容的buffer内的内容，而不是生成的tcp报文，一是因为DPI检测的内容主要是应用层报文，而是因为DPI对报文处理之后不生成任何特别的tcp报文。

2. Drop

T(q, P) = q ∧ G(q, P) = ε

当状态机M在q状态下处理报文P后，既没有状态的改变，也不产生任何的输出，那么认定报文P问drop报文。

3. Accept

T(q, P) != q ∨ G(q, P) != ε

当状态机M在q状态下处理报文P后，或者发生状态的改变，或者产生任何的输出，那么认定报文P问acceptdrop报文。

4. Bad Keywords and Alarm

将任何可以出发警报的内容称作bad keywords，并且认为其可以存储在一个tcp packet内，并利用过滤函数F来判断是否有keyword。

5. Synchronized

GMs (q0, P1...n) = GMd (q0, P1...n),  P1...n ∈ Σ

当server的状态机M在q0状态处理P1...n之后产生的输出，同DPI的状态机在q0状态处理P1...n之后产生的输出相同时，认为server和DPI和同步。

6. Evasion Packet

a .The server will accept every packet P1...n

b.When handling P1...n-1, the state machine of the server and the DPI engine are synchronized

c .F(GMs (TMs (q0, P1...n+r-1), Pn+r)) = 1 ∧ F(GMd (TMd (q0, P1...n+r-1), Pn+r)) = 0

需要满足三个条件，第一个是server可以accept报文序列 P1...n；第二个是在处理报文序列P1...n-1时，server和DPI是同步的；第三个条件是DPI不处理Pn报文，由于为了具有可观测行为，在P1...n报文序列后又添加了r个报文，其中第r个报文中含有bad keywords。

7. Insertion Packet

同Evasion报文相反。 

(二)状态过程选择

如上图所示，作者在进行符号执行过程之中，只针对状态机中LISTEM到ESTABLISH这一个阶段进行测试，这么做的原因主要有以下原因，首先因为其代表着完整的insertion/evasion报文的窗口可能；其次是因为本测试针对的报文序列长度最长为3，这个长度的报文可以完整的将状态机从LISTEN状态驱动到EATABLISH状态。

(三)符号化报文

符号化变量时，只符号化tcp header中除了source port以及destination port以外的内容，即上图中所示蓝色部分，对于IP层以及应用层内容，不进行符号化。

额外需要注意的是，由于checksum字段是需要根据ip层以及应用层信息计算，所以作者在实际过程中，针对checksum做了抽象，用0代表checksum为错误，用1代表checksum为合法字段。Options可选字段由于其有多种选择，再加上左右的排列组合，如果正常符号化会大大降低符号执行效率，因为根据监控流量中常见的options组合给options赋值。

(四)工作流程

程序工作流主要分为线上线下两个测试阶段，首先是进行线下测试，针对的linux kernel，看作是白盒子；然后是线上测试，针对的是DPI，看作是黑盒子。

1. Offline Symbolic Execution

线下针对linux kernel的测试属于白盒测试，首先需要确定的是程序边界问题。文章中提出了两种方法，一种方法是采用人工具体分析TCP实现的代码边界，但是这种方法比较费时费力；第二种办法是直接将net/ipv4单元编译成可执行文件，然后监控程序的执行的过程，当程序代码执行到对应的可执行文件代码地址内时，切换实际执行到符号执行，当执行代码执行在这个范围之外时，切换符号执行到实际执行。

而KLEE原本实现过程之中，在实际执行阶段也会记录约束，切换到符号执行过程时，会引入无关约束，导致求解复杂度增高，因此作者实现过程中，针对KLEE做了改动，去除了实际过程中对无关约束的记录；并且在符号执行过程中，并不会对if、else、goto等跳转作出特别的记录，其只针对基本块内部的执行过程，而对于基本之间的边界关系并不在意，而insertion/evasion的判断很大程度上取决于基本块之间的跳转关系，所以作者在实现系统时，也对基本快之间的跳转关系做了特别的记录。

在白盒测试阶段的输入为符号化的tcp packet seed，并且我们实现在linux kernel中标记了一些drop/accept点，比如当程序执行路径经过drop point时，认为此packet包被drop，当执行路径经过accept point时，认为packet被accept。然后利用混合符合执行进行路径探索，探索结束之后得到针对linux kernel的accept/drop packet以及对应的约束，以及linux kernel经过处理这些包的之后对应的tcp状态。

2. Online Probing

在线上针对DPI的测试为黑盒测试，其输入为针对linux kernel白盒测试得到的accept/drop packet以及对应的约束，此外还需要一些额外约束，比如initial sequence number、tcp flag等。将其放入求解器求解得到实际赋值的packet。此外还需要链接一些后续报文。

因为DPI属于黑盒测试，当我们利用事先得到的packet进行测试时，不知道其处理完这些packet之后处于的tcp状态，也就是说无法和linux kernel白盒测试之后的tcp state进行比对，无法知道DPI的tcp实现和linux kernel的tcp实现是否相同。因为我们需要根据他应当处于的tcp state(linux 白盒测试之后的tcp state)构造后续报文，使得其处理之后可以得到可观测反映。

当我们将求得的实际报文以及后续报文拼接之后，对DPI进行探测，根据观测其反应来判定其和linux白盒测试结果是否一致，得出报文是否是insertion/evasion报文。

七、实验结果

作者将系统测试了Zeek、Snort、GFW三个DPI，得到系统结果如下图所示。

根据上图可以看出针对每一款DPI，SYMTCP均测出了许多已知以及未知的evasion策略，具体逃逸策略如上图所示。

比如针对GFW发送报文FIN packet但是不带有ACK flag，此时GFW会断开连接并重连接，而linux则直接丢弃这个报文，仍保持连接，后续即可不经GFW检测发送未经检查的报文。

八、结论

在本文中，作者利用符号执行过程驱动生成insertion/evasion报文对抗DPI，我们利用TCP的具体实现在DPI以及linux kernel之间的不同，设计开发了一个端到端系统SYMTCP，并且将其针对注明的DPI进行了测试，如Zeek、Snort、GFW，其能力均得到了验证，并且本系统可以很方便的向其他系统或者DPI进行拓展。

[注意]APP应用上架合规检测服务，协助应用顺利上架！