工控安全入门(九)——工控协议逆向初探

阅读量    89484 |   稿费 300

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

在工控领域,我们会遇到许多协议,为了进行安全研究,经常需要对协议的具体内容进行探索,今天我们就来聊聊关于工控协议逆向的问题。

在接下来的几篇文章中,我会简单介绍一下常用的协议逆向方法并配合一些实战,当然,从未知到已知的探索过程不仅仅需要代码上的实践,还需要数学上的分析与建模,所以在这几篇文章中不仅会有工控、协议的知识,还有大量的数学内容,因为我本身不是搞学术研究的,所以一些东西也只是略微了解而已,如果大佬们发现有什么错误请在评论中指出,我一定仔细查看。还要感谢@bitpeach大佬的文章让我了解到了很多知识。

按照分类,工控协议一般可以分为以下两种:

  • 公开协议,这里的公开主要是说它是公开发表并且无版权要求的,我们介绍的modbus就属于这一种。
  • 私有协议,顾名思义就是厂家自有的,为正式公开的,我们介绍过的西门子S7comm就属于这一种。

但不论是公开协议还是私有协议往往都具有一定的未知性。像是modbus,虽说大部分信息我们都是了解的,但是还有很多function code是厂商自己偷偷用的,像是施耐德我们之前就提过,有自己的0x5a来实现一堆高权限操作;S7comm这类的私有协议就更不用说了,要不是前辈们的逆向工程,我们其实是对协议内容一无所知的。我们今天要聊的就是对于这类未知的逆向过程。

对于协议的逆向我们也是分成两类方法:

  • 基于网络轨迹的逆向,即对抓取的流量包进行分析,利用各类数学分析、推理,对数据进行切分、关系预测、生成状态机等等,从而推断出协议的部分内容、进行fuzz等操作。
  • 基于接收端程序的逆向,即对协议数据的接收端程序进行逆向分析,从而得到协议的内容,这也是现在常用的方法,像是最近S7commPlus的逆向就是借助分析上位机的OMSp_core_managed.dll组件来实现的。

当然,这两种逆向方式都需要结合相应的设备进行调试来完成,也完全可以两种方式结合,先基于网络轨迹大致判断协议格式、关系,再通过逆向程序加以完善。这篇文章我们就首先看看基于网络轨迹的逆向。

 

基于网络轨迹的逆向

考虑到我们为入门教程,所以我们选用的数据包并不是真正的”未知“协议,我们使用系列第一篇文章的modbus数据包来进行分析,我们将其TCP以上均视为未知部分

如图的包,我们将modbus部分的数据视作

x00x00x00x00x00x04x00Zx00x02

现在看上去还是毫无头绪?没关系,我们一点点来

确定协议字段的基本知识

确定协议字段说白了就是根据流量包中的大量流量对比,”猜“出来哪些数据应该是一个字段,这个过程中涉及到协议分析算法,而这些算法又是由一些重要的数学模型、算法构成的,我选取了《Network Protocol Analysis using Bioinformatics Algorithms》、《基于网络协议逆向分析的远程控制木马漏洞挖掘》两篇论文中的某些部分进行简要说明,来大致了解一下这部分理论知识(因为我们是要做实际分析,所以涉及到研究部分的算法等理论我就不再细化了)。

LD(LevenShtein Distance),假设我们有A、B两个字符串,A经过插入、删除、替换字符的最短过程变为B,经过的步骤表示两个字符串的差异。如:

A = "modbus"
B = "modicon"

显然我们需要把子串”bus“换为”ico“,然后添加字符”n“,所以LD(A,B)=4,python实现代码如下:

def normal_leven(str1, str2):
    len_str1 = len(str1) + 1
    len_str2 = len(str2) + 1
    # 创建矩阵
    matrix = [0 for n in range(len_str1 * len_str2)]
    # init x轴
    for i in range(len_str1):
        matrix[i] = i
    # init y轴
    for j in range(0, len(matrix), len_str1):
        if j % len_str1 == 0:
            matrix[j] = j // len_str1
    for i in range(1, len_str1):
        for j in range(1, len_str2):
            if str1[i - 1] == str2[j - 1]:
                cost = 0
            else:
                cost = 1
            # 若ai=bj,则LD(i,j)=LD(i-1,j-1)   取矩阵对角的值
            # #若ai≠bj,则LD(i,j)=Min(LD(i-1,j-1),LD(i-1,j),LD(i,j-1))+1   在对角,左边,上边,取最小值+1
            matrix[j * len_str1 + i] = min(matrix[(j - 1) * len_str1 + i] + 1, matrix[j * len_str1 + (i - 1)] + 1,matrix[(j - 1) * len_str1 + (i - 1)] + cost)

    return matrix[-1]

str1 = ''
str2 = ''
a = normal_leven(str1, str2)
print(1-a/max(len(str1), len(str2)))
print(type(1-a/max(len(str1), len(str2)))

LCS(Longest common subsequence),这个和大家理解的两个字符串求最大子序列有些不同,这里的字符并不一定要连续出现。如:A与B的最长子序列为”mod“,所以LCS(A,B)=3,而我们将A变为”m o d b u s“,LCS(A,B)仍然为3,所以,如果LCS(X,Y)=0,那么立即推,X、Y没有任何一个字符相同。在论文中包括了GSA(全局序列对比)与LSA(局部序列对比),GSA用在对协议域的理解上,而LCS则是对相似序列进行聚类。编程中,我们可以使用Needleman/Wunsch算法来求解。我们还是以上面的两个字符串为例

m o d b u s
0 0 0 0 0 0 0
m 0
o 0
d 0
i 0
c 0
o 0
n 0

首先我们将矩阵初始化,即上述表格,接着按照公式进行填充

若ai=bj,则LCS(i,j)=LCS(i-1,j-1)+1

若ai≠bj,则LCS(i,j)=Max(LCS(i-1,j-1),LCS(i-1,j),LCS(i,j-1))

该公式其实非常简单,如果行列字符一样,则填充的值为它左上角的值加1,如果不一样就是左上角、上边、左边的最大值。按照这个标准我们从第一行开始填,得到如下结果

m o d b u s
0 0 0 0 0 0 0
m 0 1 1 1 1 1 1
o 0 1 2 2 2 2 2
d 0 1 2 3 3 3 3
i 0 1 2 3 3 3 3
c 0 1 2 3 3 3 3
o 0 1 2 3 3 3 3
n 0 1 2 3 3 3 3

然后从右下角进行回溯操作,若ai=bj,则走左上角;若ai≠bj,则到左上角、上边、左边中值最大的单元格,相同的话优先级按照左上角、上边、左边的顺序,直到左上角为止。最终按照如下规则写出表达式(_表示插入字符或者是删除字符操作)

  • 若走左上角单元格,A+=ai,B+=bi
  • 若走到上边单元格,A+=ai,B+=_
  • 若走到左边单元格,A+=_,B+=bi

多序列对比,实际上是LCS的扩展,采用引导树、非加权成对群算术平均法等来进行,非加权成对群算术平均法即UPGMA算法,这是一种聚类算法,在我们前面已经得到的距离的基础上进行操作,将距离最小的两个节点进行聚合,然后再次计算新的节点间的距离,最终生成演化树。

演化树(Phylogenetic tree),在多序列对比中生成的树,其实就像是生物进化图那样,由根衍生出一个一个节点,如图所示为DNA系统的演化树,我们所要建立的演化树是关于协议的数据的,通过这种方式来寻找协议流量中的相似部分。

建树的方法主要有两大类,一类是基于距离的,一类的基于character的。我们上面提到的就是基于距离的建树方式,一般来讲,基于距离的方法将数据抽象为距离,从而有了较快的处理速度,但是其抽象过程中会有信息量的损失;而基于character的方法是在一个已有的模型上建立的,所以需要有一个靠谱的模型,但好处就是我们的信息不会丢失。

广义后缀树(Generalized Suffix Tree),用来实现求解最大公共子串、匹配字符串、找重复串等等,这里说的最大公共子串就是我们平时理解的:连续的、相同的字符串。比如”modbus“和”m od i c o n“,那么这俩的最大公共子串就是od而不是上面的”mod“。该技术常用于病毒的特征码提取。下面举个栗子来解释一下:

假设我们现在有modbus、modicon两个字符串,对于modbus,后缀有:

s
us
bus
dbus
obus
modbus

我们将其按字典序排序,然后建立树,根节为空,每个字母为一个节点,从根到叶子就对应了一个单词,如图所示

我们还可以对单节点链条进行压缩,当然这个单词所有的链条都是单节点的……然后我们将modicon也按后缀,然后插入到这个树中,重合的部分即为公共子串(因为我不知道怎么画图,所以你们就自行想象一下吧)。

聚类(cluster),大白话就是分类,一是用来对流量进行粗略分类,二是用来对提取的字符串进行分类。具体涉及的包括了k紧邻算法、关键词树算法等等

以上是一些基础性的问题,有了以上的基础,我们可以大致将流量包的分析归为以下几步:

  • 粗略聚类,提取主要分析的流量,并将相似的流量首先分到一起
  • 采用各类算法来对字段进行划分
  • 根据某些字段再次进行聚类
  • 对一类的流量进行关系分析

Netzob划分数据

netzob是一种基于网络轨迹的逆向工具,目的就是为了分析未知协议,当然还有其他的一些,比如PI等等,我们这里就以netzob为例进行操作。

首先当然是要安装,netzob需要大量的前置包,安装很麻烦,很有可能遇到各种错误,因为和实际环境有关,所以我也没法全部列举出来,大家安装时自行尝试吧

apt-get install python-dev      #提前需要安装的库
apt-get install python-impacket
apt-get install python-setuptools
apt-get install libxml2-dev
apt-get install libxslt-dev
apt-get install gtk3
apt-get install graphviz
git clone https://github.com/netzob/netzob.git
cd netzob
python3 setup.py develop --user  #开发者友好模式

以上步骤完成后我们就可以在python3中import了

from netzob.all import *

当然也可以python3 setup.py install来安装友好的图形化界面,使用./netzob即可打开,但是在我的机器上出现了问题,大家可以自行尝试。如果实在是安装不成功的同学,官方也给了docker镜像

docker pull netzob/netzob
docker run --rm -it -v $(pwd):/data netzob/netzob  #pwd为当前位置,挂载到根目录下的data

搞定后我们就可以开始干活了

m = PCAPImporter.readFile("modbus.pcap").values()

该条语句用来导入我们的流量包,我们可以查看一下它的说明

参数主要关注两个,一个是importLayer,这是指定我们要分析的data是在哪一层,以我们modbus来说,是基于tcp的,所以data就相当于是tcp往上一层,所以填5,如果是S7comm呢则要考虑你要分析哪一层再进行选择;另一个是bpfFilter(Berkeley Packet Filter),也即是伯克利包过滤的意思,这是一种语法,可以指定你要选择哪些流量,如下所示:

host 0.0.0.0 and (port 138) #筛选出ip为0.0.0.0且端口为138的流量包

接着我们进行符号化,即筛选出所有相似的流量,这里就涉及到了我们之前提到的数学知识

s = Symbol(messages = m)

可以看到提取出来的就是相似的流量就是我们流量包中的modbus部分,这一步就相当于我们上面提到的粗略聚类,Netzob将modbus部分的流量提取了出来,并将这些流量放到了一起。但是现在我们还是啥也看不出来,我们希望能够对data再次进行分析,对比得到哪些字符应该是一块的,哪些是分开的。

Format.splitStatic(s)

该方法用来将我们的data根据相似性与静态分布规律,划分为几个Field,当然,我们也可以通过“肉眼观察法”使用splitDelimiter(symbol,ASCII(“Z”)来进行人工的划分。这一步相当于“采用各类算法来对字段进行划分”,也是核心部分,如图即为划分Field后的symbol

我们就以第一组为例,打开wireshark来检查一下分析的结果

真正的划分如下:

'x00x00'  | 'x00x00' | 'x00x04'  | 'x00Z' | 'x00x02'

可以看到差距较大,观察流量包后发现,主要原因是因为modbus的前四个字段在该流量包中区分不太“明显“,以第一个字段举例,modbus用了两个字节表示事务标识符(即Transaction identifier ),但在这些流量中最多最多就是x00x01,根本就没有用到低字节,所以在划分时被认为是两个字段了。同理,长度字段也是如此,该流量包中的length也没有用到低字节,所以也被划为了两个字段。

知道了情况我们就可以对症下药了,一是我们引入新的流量包,选取一些数据量较大、情况足够全面的流量,可以稍加完善;二是我们通过不断的尝试和日常积累进行手动划分,比如每种协议基本都有的length字段、标识字段等等进行手动划分。但是由于协议本身的规定与限制(比如,虽然给了两个字节,但是实际上并没有使用低字节,厂商只是为了扩展或者对齐),我们只可能完善,但绝不可能完美划分字段,不过仅仅是这样对我们的帮助已经很大了。

之后我们要进行的步骤为“根据某些字段再次进行聚类”,但是这里由于我们对于哪个是关键字段并不清楚,所以暂时放弃这一步。

接下来我们要做的工作就是要猜测字段的含义,当然我们通过这种方式绝对不可能“猜”出来“Z”是施耐德专用的功能码,我们能做的是推理这些字段之间的关系。

for symbol in symbols.values():
    rels = RelationFinder.findOnSymbol(symbol)

    print("[+] Relations found: ")
    for rel in rels:
        print("  " + rel["relation_type"] + ", between '" + rel["x_attribute"] + "' of:")
        print("    " + str('-'.join([f.name for f in rel["x_fields"]])))
        p = [v.getValues()[:] for v in rel["x_fields"]]
        print("    " + str(p))
        print("  " + "and '" + rel["y_attribute"] + "' of:")
        print("    " + str('-'.join([f.name for f in rel["y_fields"]])))
        p = [v.getValues()[:] for v in rel["y_fields"]]
        print("    " + str(p))

RelationFinder为我们提供了不同的关系分析方法,这里我们选择使用基于符号的分析方法,也就是对我们之前进行过Field划分的符号进行分析。

当然,这只能探索符号内部的关系,像是我们的数据包,我们只能发现length字段,但是已经是非常大的进步。为我们之后进行测试、逆向程序都省下了不少功夫。

 

总结

虽然说了不少东西,但大多还是以理论为主,实际上代码就撩撩几行,当然这也是我们协议分析的第一步,在之后的文章中我们将基于这部分内容,继续进行探索。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多