记一次基于Union的sqlmap自定义payload

hw期间某晚上10点,某知名小朋友审计了一套bc源码,有sql注入,注入的位置比较刁钻,sqlmap无法识别,不能取证 (公众号转发务必说明来源,标注作者!)

hw期间某晚上10点,某知名小朋友审计了一套bc源码,有sql注入,注入的位置比较刁钻,sqlmap无法识别,不能取证

注入场景
  1. pay.php?id=pay`+/*_*/where+false 注入error
  2. pay.php?id=pay`+/*_*/where+false# 注入正常

Snipaste_2024-08-13_23-43-18.png

Snipaste_2024-08-13_22-54-36.png

sqlmap无法识别

微信图片_20240813223537-1723561048427.png

注入位置比较刁钻,小朋友说得保留

  1. pay`+/*_*/where+false

字段才可控,

在网上搜了一圈,没有找到基于union的自定义查询,于是下了些功夫,研究了sqlmap的union注入流程

union注入流程

union联合查询,用于合并左右两侧select语句的结果,得要求两侧select的列数相同,两侧select列数不同发生error,那注入就失败;因此 union注入必须得先进行order by的判断确定列数,后续才能拼接子查询测试。

Snipaste_2024-08-13_23-25-39.png

Snipaste_2024-08-13_23-26-34.png
所以,站点union注入失败的原因在于order by测试没命中

Snipaste_2024-08-13_23-07-38.png

sqlmap测试union注入的文件在data\xml\payloads\union_query.xml 根据发包提示信息和order by相关的是”Generic UNION query”模板

Snipaste_2024-08-13_23-49-57.png

网上转了一圈,参考报错注入和时间注入的修改request和response两处标签,通过正则等方式去匹配命中,发现无法过编译, 后续测试,union_query.xml的标签[vector]、[request]、[response]不可控,(修改后测试流程依旧没变化)。

猜测可能和子语句测试有关,站在sqlmap的视角,他肯定是无法识别当前子语句注入方式的,比如位置是在where后可控还是order by后可控,或者是逻辑符可控,比如例示列名 (SELECT * FROM users ORDER BY column_name)等,得构造某特定的类型才能识别,自定义类型,跟进到xml/payloads/boundaries.xml

自定义payload

boundaries文件几处属性是控制自定义字符的,preffix和suffix,把这里的preffix改为站点的自定义字段

Snipaste_2024-08-14_08-02-18.png
然后得考虑该字段如何去和union模板里的test组合问题,网上转了一圈,当boundaries的clause和where属性值包含union模板的clause、where两个属性值即会匹配组合

clause取值为1-9,联合查询有关的子查询有 where、order by,取值为1,3
Snipaste_2024-08-14_08-11-41.png

where取值为1-3,where标签,用来确定整体注入payload的插入位置,比如第一个注入参数,取值为1,第二个注入参数,取值为2,这里就默认为1

Snipaste_2024-08-14_08-14-26.png

  1. <boundary>
  2. <level>1</level>
  3. <clause>1,2</clause>
  4. <where>1</where>
  5. <ptype>1</ptype>
  6. <prefix>pay`+/*_*/where+false</prefix>
  7. <suffix>#</suffix>
  8. </boundary>

观察union模板的”Generic UNION query” where、clause标签是否能匹配

Snipaste_2024-08-14_08-20-04.png

没啥问题,发包测试

测试问题

再测试已经能识别到自定义的payload了,但探测的深度很有限,order by的注入得取两个值,一大一小来确定字段,从发包payload来看只发了order by 1

Snipaste_2024-08-14_08-22-46.png
把流量挂到burp看看,代理后,再次发包

Snipaste_2024-08-14_08-28-26.png

  1. pay`+/*_*/where+false order by 1#
  2. pay`+/*_*/where+false order by 4839#

这里命中了,但没识别出order by的注入

编码问题

在这折腾了好久,觉得是sqlmap的版本原因,下载了最新的版本,再次发包,再测试发现order by 4839#这部分包又不测试了,觉得是代理的问题,于是换了socks发现也一样,后续发现报文出问题了
Snipaste_2024-08-14_08-40-39.png

sqlmap报文编码导致自定义的字符失效了,被编码了%2B%2F%2A_%2A%2F

burp做个发包替换,

  1. %2B%2F%2A_%2A%2F->pay`+/*_*/where
识别注入

识别成功,order by

Snipaste_2024-08-14_08-45-34.png

后续的流程就很简单了,识别到order by 判断列数,union子查询拼接case条件从句

Snipaste_2024-08-14_08-48-54.png

Snipaste_2024-08-14_10-08-40.png
取证完成

Snipaste_2024-08-14_08-50-22.png

扩展思路
自定义前后缀

后续发现一种更便捷的方式,不用修改boundary,自定义前后缀,在sqlmap发包的时候提供

  1. preffix="pay`+/*_*/where"
  2. suffix="#"
  3. technique=U

这样发包会更精准,由于提供了前缀,sqlma后续不会从boundary取注入符,会调用默认的clause和where去匹配union_query.xml里的test模板,免去了其他符号的测试

完整参数

Snipaste_2024-08-14_09-03-02.png

  1. --proxy=https://127.0.0.1:8080 --prefix=pay`+/*_*/where+false --suffix=# -v 3 --technique U
  • 发表于 2024-09-09 10:00:01
  • 阅读 ( 3460 )
  • 分类:渗透测试

0 条评论

echoa
echoa

6 篇文章

站长统计