两年前，从兜哥的《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. 正则表达式分词与泛化
关于特征提取，刚开始使用的是正则分词+泛化的处理方式。这种方式也是目前使用较多的一种方式，毕竟正则简单易上手。以下列字符串为例：
使用正则re.split(r'( |,)’, ss)分词，结果为：
观察结果，不符合预期，效果不是很理想。对于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解析器可以识别的符号、运算符、关键字并预设特征向量值：
2. 字符验证函数定义：
这个函数是用来判断字符是否可以被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. 字符串扫描：
如果字符是合法的SQL运算符则返回对应的状态值，如果字符是字母数字则继续扫描，直到指针越界或者IdChar为False
5. SQL 关键词识别
SQL标识器可以识别的关键字组成的字符串：
关键字对应的字符串长度：
关键字在zText中的索引位置(offset)：
举列说明：
字符串：str = “INDEX”
首字母大写为：I，
长度：5
如果zText[aOffset[1]:aOffset[1]+5] == str.upper() 为True，代表此字符串为Keyword，否则为普通字符串。
zText aOffset aLen这些数组都是提前计算出来，目的是为了提高检索效率。
特殊说明：为了区别关键字和普通字符串，对关键字的特征向量值加了权重50000。
性能对比：
总结：
1>针对简单的字符串性能优势不明显，但是放在复杂的日志环境中优势就能慢慢体现出来了，日志请求越长，效果越明显。
2>比简单正则覆盖范围广，比复杂正则速度快。
3>分词精准度高。
4>具有针对性，sql解析器识别的keyword能重点标记。
0x03 训练HMM检测模型
HMM进行文本异常检测，有两种方式：
以白找黑:相当于找不同
以黑找黑:相当于找相似
以白找黑，是给HMM输入纯白样本，让其记住正常url参数的模型转化概率，然后找不同。本文采用的是以白找黑模型训练，部分代码如下：
预测结果为：
定义T为阈值，概率小于T的参数识别为异常。阈值T过小，误报会少，但是漏报会高；阈值T过大，误报会多，但是漏报会少。本人的观点是接受误报，尽量做到不漏报。误报可以后续进行二次处理，如注入验证或者其他维度检测。
0x04 预测结果二次验证
事实证明，每天都会检测到大量结果为失败或者404的类似告警，导致系统存在大量误报。偶有成功的也会埋没在误报当中，久而久之报警处理人就不想再去查看，或者查看的不够仔细，从而导致被黑。因此就需要对检测结果进行二次验证。
为了完成这个目标，基于sqlmap改了一个简化版，用于验证GET方式的SQL注入是否成功。
第一步：先验证请求参数是否是动态的，如果不是，则忽略；
第二步：如果是动态参数，进行SQL注入检测，检测为True，则进入报警队列。
以dvwa为例：http://localhost/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#，验证结果如下：
目前此验证脚本为初版，只支持GET方式的部分注入类型验证。
0x05 结束语
我们在进步，黑产也在进步，而且是飞速发展。见识了黑产的群控和各种高级的设备，才知道我们在使用小米步枪和飞机大炮在战斗，这是一项艰巨的任务。技术无分善恶，但落后就要挨打！雄关漫道真如铁,而今迈步从头越！加油吧，少年！。
代码传送门：https://github.com/skskevin/UrlDetect/tree/master/tool/SQLTokenizer
*本文作者：littlegrass，转载庆注明来自FreeBuf.COM
来源：freebuf.com 2019-08-23 08:00:56 by: littlegrass
请登录后发表评论
注册