[fuzz论文阅读] Sharing More and Checking Less: satc

Sharing More and Checking Less: satc

背景

1. 嵌入式系统的漏洞驻留在其开放的web服务中
2. 现有的web漏洞检测,不适用于此类web服务(开销、假阴假阳)
3. 本文利用前后端共享的关键字定位参考点
4. 从嵌入式系统中寻找bug的关键点在于从前端web中寻找处理用户数据的后端代码,那些输入会被后端处理

satc工作流程

1. 解压固件包,识别前后端文件
2. 从前端文件中提取关键字
3. 在后端文件中定位关键字处理函数,找出与用户输入相关的点
4. 进行污点分析

satc解决的问题

1. 从前端中提取关键字

   1. HTML中根据关键字提取,例如ID、NAME、ACTION等
   2. XML是格式化的,用正则进行匹配
   3. JavaScript使用抽象语法树,扫描节点
   4. 对于提取出的关键字进行过滤(特殊字符、长度、取左值)
   5. 寻找边界二进制文件(处理关键字的函数)

2. 从后端中识别输入项

   1. 显示关键字–>寻找函数调用者(函数参数信息)
   2. 隐式关键字–>寻找函数调用者(函数内部信息)
   3. 跨进程调用–>cross process enrty finder(基于共享关键字)

3. 敏感输入的污染分析(.路径探索、污点分析)

   1. 粗粒度污染分析引擎

      
      • 规定三种形式的函数: 可汇总函数(strcpy)、通用函数(不调用不可汇总函数)、嵌套函数
      
      • 根据函数种类的不同,进行污染分析,其中对于单纯指令(包括可摘要函数)直接用污点分析规则,对于嵌套函数,需要标记 retv 或者 par

   2. 有效的路径探索

      
      1. 重点检测内存溢出和命令注入
      2. 基于敏感度的指导策略,删除不包含sink function 的路径
      3. 调用者的汇总,将需要分析的函数分为两类,sink functions & guiding functions, 调用sinkfunction 的放入guiding functions集合

   3. 路径优化策略

      1. 两个问题,sanitizers function 导致无限循环; parsers function 导致污染不足。

      2. to parser,将解析路径都走一遍,确保s2也会被设置为污染源

         

      3. to sanitizer,选择最长的路径

         

实现

1. 编程语言 --> python
2. XML解析 --> 标准库
3. JavaScript --> Js2py
4. inputRecongnition --> Ghidra & extended kartonte’s cpf
5. taint engine --> angr
6. MIPS fix

评价

实验背景:

1. 数据集:各厂商的固件共计39个,其中ARM架构32个,MIPS架构7个,每个固件差不多26M
2. 对比工具:karonte 目前最先进的嵌入式静态BUG搜索工具
3. bug检测:可追踪溯源,在真实环境下

三个问题:

1. satc 是否能够有效的检测漏洞,效率与其他类似软件相比怎么样?

   1. 检测出的 0 day

      

   2. 对比情况

      

2. satc识别关键字的准确率怎么样?

   1. 关键字识别

      

3. satc污染分析的准确率和效率怎么样?

   1. 路径融合
   2. 路径优化
   3. 污染引擎

   以上三点都优化了准确率,提升了效率

未来期望

1. 可扩展性
   • 只要系统符合通过关键字在前后端传递信息,就可以使用satc的思想进行BUG探索
2. 隐式关键字处理
   • 尝试寻找隐藏模式,更好的处理前后端之间的关系
3. 效率 & 准确率
   • satc得到的了很好的平衡
4. 加密和模糊
   • satc未来的工作,对于加密或模糊后的数据,不能很好的识别,关注现有的反混淆技术