一种新的分词方法在机器学习中的应用 – 作者:littlegrass

两年前,从兜哥的《Web安全机器学习入门》这本书开始与机器学习结缘,慢慢了解了什么是贝叶斯、HMM、SVM,以及它们应用的场景。关于算法公式,在这里就不班门弄斧了,说实话很多都看不懂,“咱也不敢说,咱也不敢问”。

当前我们对于恶意请求的自动检测主要是基于黑规则的检测,众所周知,这种基于规则库的安全防御被动、滞后,无法检测未知的攻击,造成的影响就是漏报挺多,这也是引入机器学习的重要原因。

本文主要分享一下,在做基于HMM的SQL注入检测时遇到的一些问题及解决方法,至于HMM的原理及概念,有兴趣的同学可以看看《学点算法搞安全之HMM(上篇)》 这篇文章。https://mp.weixin.qq.com/s/Cc15keu4quPBZc1N4bS58g

0x01 建模思路

机器学习建模的整体思路如下:

1. 收集数据集

常见的SQL注入攻击载荷主要集中在请求参数中,解析GET、POST请求的参数值作为样本数据。此次项目收集了大约20万白样本数据。

2. 数据处理与特征提取

数据降噪,如去掉注释、urldecode等;

特征提取:包括分词、泛化、特征向量转化,本文采用自研的分词器,分词、特征转化二合一。

3. 使用HMM训练检测模型

4. 最后模型调优,并使用检测模型检测未知 URL

0x02 特征提取

1. 正则表达式分词与泛化

关于特征提取,刚开始使用的是正则分词+泛化的处理方式。这种方式也是目前使用较多的一种方式,毕竟正则简单易上手。以下列字符串为例:

image.png

使用正则re.split(r'( |,)’, ss)分词,结果为:

image.png

观察结果,不符合预期,效果不是很理想。对于sql来说,concat是个函数,属于关键字,需要单独分出来,否则后续不好泛化。在实际场景中,黑客们为了达成目的,一般都不走寻常路,不要奢望他们按常理出牌。也就是说payload会千奇百怪,出现各种变种,分隔符不固定,而为了能尽可能多的覆盖,正则也会变得越来越复杂,相应的执行效率也会直线下降。

对分词后的结果进行泛化,依据:

[a-zA-Z]泛化为A

[0-9]泛化为N

[\-_]泛化为C

其他字符泛化为T,泛化后的结果为:

99999泛化为N

union泛化为AAAAA

正则分词遇到的问题:

1>分词不精准,分隔符不固定,为了能尽可能多的覆盖,需要不断完善正则表达式

2>覆盖范围越广,正则越复杂、效率越低

3>采用单字符的特征提取,弱化了SQL Keyword的影响,字符串长度对预测结果的影响大于SQL关键字

4>没有突出SQL解析的特点

2. 基于SQL解析的词法分词

基于SQL解析的词法分词是一种新的分词方法,也是本次项目中使用的方法, 此方法将正则分词和特征向量提取合二为一,即分词器在返回分词结果的同时,也定义了特征向量值。基于SQL解析的词法分词逻辑很简单,分词器模仿sql解析器进行分词,逐个扫描字符串,遇到符号即返回,遇到字符即继续,以及检测解析出的字符串是否是keyword。

部分代码如下:

1. 定义SQL解析器可以识别的符号、运算符、关键字并预设特征向量值:

image.png2. 字符验证函数定义:

image.pngimage.png这个函数是用来判断字符是否可以被SQL标识器识别的。这里当初卡了很久,原因是因为结果不准确。对于ASCII字符集,高位Bit集合的字母都能被SQL标识器识别,对于7-bit的字符,则sqlIsEbcdicIdChar必须为1。后来又分析了SQL99, SQL/MM, and SQLJ: An SQL99, SQL/MM, and SQLJ: An Overview of the SQL Overview of the SQL Standards SQL : 1999, Formerly known as SQL3的语法定义, 其中比较值得注意的是对于char的识别鉴定, 根据分析sql各个标准中char类型的定义,首先进行了ascii码的判断方式,但返回结果并不理想;在查询了相关资料(sql的各种标准)后, 又引入了ebcdic这个字符集,做双重校验,结果终于准确了! 关于ebcdic的定义:http://www.astrodigital.org/digital/ebcdic.html,有兴趣的可以去研究下。

3. 字符串扫描:

image.pngClipboard Image.png如果字符是合法的SQL运算符则返回对应的状态值,如果字符是字母数字则继续扫描,直到指针越界或者IdChar为False

5. SQL 关键词识别                     

image.png

SQL标识器可以识别的关键字组成的字符串:

Clipboard Image.png关键字对应的字符串长度:

Clipboard Image.png关键字在zText中的索引位置(offset):

Clipboard Image.png

举列说明:

字符串:str = “INDEX”

首字母大写为:I,

长度:5

如果zText[aOffset[1]:aOffset[1]+5] == str.upper() 为True,代表此字符串为Keyword,否则为普通字符串。

zText aOffset aLen这些数组都是提前计算出来,目的是为了提高检索效率。

特殊说明:为了区别关键字和普通字符串,对关键字的特征向量值加了权重50000。

性能对比:

Clipboard Image.pngClipboard Image.png

总结:

1>针对简单的字符串性能优势不明显,但是放在复杂的日志环境中优势就能慢慢体现出来了,日志请求越长,效果越明显。

2>比简单正则覆盖范围广,比复杂正则速度快。

3>分词精准度高。

4>具有针对性,sql解析器识别的keyword能重点标记。

0x03 训练HMM检测模型

HMM进行文本异常检测,有两种方式:

以白找黑:相当于找不同

以黑找黑:相当于找相似

Clipboard Image.png以白找黑,是给HMM输入纯白样本,让其记住正常url参数的模型转化概率,然后找不同。本文采用的是以白找黑模型训练,部分代码如下:

Clipboard Image.png预测结果为:

Clipboard Image.png

定义T为阈值,概率小于T的参数识别为异常。阈值T过小,误报会少,但是漏报会高;阈值T过大,误报会多,但是漏报会少。本人的观点是接受误报,尽量做到不漏报。误报可以后续进行二次处理,如注入验证或者其他维度检测。

0x04 预测结果二次验证

事实证明,每天都会检测到大量结果为失败或者404的类似告警,导致系统存在大量误报。偶有成功的也会埋没在误报当中,久而久之报警处理人就不想再去查看,或者查看的不够仔细,从而导致被黑。因此就需要对检测结果进行二次验证。

为了完成这个目标,基于sqlmap改了一个简化版,用于验证GET方式的SQL注入是否成功。

第一步:先验证请求参数是否是动态的,如果不是,则忽略;

第二步:如果是动态参数,进行SQL注入检测,检测为True,则进入报警队列。

        以dvwa为例:http://localhost/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#,验证结果如下:

Clipboard Image.png目前此验证脚本为初版,只支持GET方式的部分注入类型验证。

0x05 结束语

我们在进步,黑产也在进步,而且是飞速发展。见识了黑产的群控和各种高级的设备,才知道我们在使用小米步枪和飞机大炮在战斗,这是一项艰巨的任务。技术无分善恶,但落后就要挨打!雄关漫道真如铁,而今迈步从头越!加油吧,少年!。

代码传送门:https://github.com/skskevin/UrlDetect/tree/master/tool/SQLTokenizer

*本文作者:littlegrass,转载庆注明来自FreeBuf.COM

来源:freebuf.com 2019-08-23 08:00:56 by: littlegrass

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论