[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] XSS/injection/... evading technique
- From: "Ryan Barnett" <rcbarnett@xxxxxxxxx>
- Subject: Re: [WEB SECURITY] XSS/injection/... evading technique
- Date: Fri, 25 Jul 2008 10:55:52 -0400
------=_Part_19054_6971687.1216997752423
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
There are two important issues here -
1) Filter Evasion
The underlying issue you raise is valid. Basic text searching/matching
filtering mechanisms can have a difficult time handling the vast arays of
evasions. The point to keep in mind, however, is that the attacker has 2
items that must be met - evading filters, but also the code must still be
functionally equivalent and able to execute by the targetted back-end
system. The best example that I can think of is detecting XSS attacks.
RegEx filters can be relatively effective against inbound data as there are
usually a small sub-set of characters and a certain format that a client
should be sending. The more challenging aspect is trying to identify
malicious JS in outbound data. There are just too many ways to alter the JS
to evade signatures. While the evasion rate may be high, oftentimes the end
result of the evasion is that it morphs the code into a format that actually
breaks the JS in the browser. So, they may evade a filter but it breaks the
attack.
To your specific point about Comments, consider what I outlined above.
While nesting attack payloads inside of Comments may indeed help to bypass
basic filters that remove/ignore this data after normalization, this same
transport area will effectively prevent the back-end system from executing
it because it skips over the Comment data. The one exception, however, that
I can think of is the MySQL extension for Comments were you can actually
place DB commands inside of the Comment area and it will still be executed!
http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/#InlineComments
>From a WAF perspective, one way that we can address this is to do inspection
both before and after normalization. ModSecurity, for example, applies a
number of anti-evastion normalization functions (
http://www.modsecurity.org/documentation/modsecurity-apache/2.5.5/modsecurity2-apache-reference.html#transformation-functions)
to data before we apply our rules. There is a little used action however
called multiMatch (
http://www.modsecurity.org/documentation/modsecurity-apache/2.5.5/modsecurity2-apache-reference.html#N11554)
that will help to combat these issues. For the case of sql injection data
inside of Comments, this would allow us to identify the injection before the
replaceComments transformation function is applied. This is good from an
anti-evasion perspective, however there is some impact on overall
performance.
2) Impedance Mismatch
This is where you can run into issues if there are differences of
interpretation between systems that are analyzing the same data. A good
example of this is HTTP Request Smuggling. You have many network systems
that may inspect the inbound data (Network Firewall doing Deep Packet
Inspection, Network IDS/IPS, WAF, Reverse Proxy, etc...) and each of these
systems may interpret this as either 1 or 2 requests. The main question is
how does the destination web app interpret it?
I will say this - from an analysis and accuracy of intrusion detection
perspective, it is always best for these security systems to interpret the
data in exactly the same way as the protected web app. On the other hand,
from an auditing and logging perspective, it is oftentimes advantageous to
to ensure that the security system does not actually execute or act upon
metadata in the same way as the back-end web app.
One great example of this is in relation to a real SQL Injection attack that
we encountered with one of our customers (sanitized) -
GET /shoppingcart/login.asp?Email='%20or%201=convert(int,(select%20@
@version%2b'/'%2b@@servername%2b'/'%2bdb_name()%2b'/'%2bsystem_user*
))--sp_password* HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
User-Agent: Microsoft URL Control - 6.00.8862
Host: www.example.com
Connection: Keep-Alive
Notice the bolded "--sp_password" string at the end as it successfully
prevented this attack from being logged by the customer's back-end DB even
though they had DB auditing enabled. So while we wanted to normalize,
format, etc... the SQL Query data in the same way as the back-end DB would
see it, we did not treat that data as an actual command to "do something" as
the DB did.
--
Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache
On Thu, Jul 24, 2008 at 4:14 AM, Nick Gearls <nickgearls@gmail.com> wrote:
> Hello,
>
> I was thinking about an evasion technique for command/SQL/SSI injection,
> XSS, etc., and I wonder how to avoid this.
>
> The (known) problem: several languages accept comments in the middle of a
> command
> Ex:
> - MySQL & &SQL Server accept C-style comments: /* ... */
> - Javascript accepts C++-style comments: // ...
> - Perl, PHP accept # ...
> - SQL Server accepts -- ...
> - Coldfusion accepts <!-- ... -->
> This allows to embed a comment in the middle of a multiple words command
> (sometimes, although not often, even in the middle of a word) to evade
> detection.
>
> Let's use C-style comments as example.
> If I want to block "foo bar", it can easily be evaded as "foo /*...*/
> bar".
> We could remove comments; this is standard with most WAF; this solves the
> above problem, but it could in fact be worse !
> What about the following line:
> a="/*"; here is a command that should be blocked; a="*/";
> Because WAF and IDS use regex/string patterns and do not understand the
> real syntax, the complete command will be ignored.
> Note that even a single word pattern will be evaded.
> And we can obviously mix both:
> a="/*"; here is a command that /*...*/ should be blocked; a="*/";
>
> Any idea on how to solve that at a WAF/IDS level ?
> What mitigation technique could be used ?
>
> Note that Coldfusion comments are also very difficult to remove, as this
> would also remove real HTML comments. This leaves the door open to a
> combination of Coldfusion and Javascript XSS attack.
>
> Nick
>
>
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>
------=_Part_19054_6971687.1216997752423
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<div dir=3D"ltr"><div>There are two important issues here -</div>
<div> </div>
<div>1) Filter Evasion</div>
<div>The underlying issue you raise is valid. Basic text searching/ma=
tching filtering mechanisms can have a difficult time handling the vast ara=
ys of evasions. The point to keep in mind, however, is that the attac=
ker has 2 items that must be met - evading filters, but also the code must =
still be functionally equivalent and able to execute by the targetted back-=
end system. The best example that I can think of is detecting XSS att=
acks. RegEx filters can be relatively effective against inbound data =
as there are usually a small sub-set of characters and a certain format tha=
t a client should be sending. The more challenging aspect is trying t=
o identify malicious JS in outbound data. There are just too many way=
s to alter the JS to evade signatures. While the evasion rate may be =
high, oftentimes the end result of the evasion is that it morphs the code i=
nto a format that actually breaks the JS in the browser. So, the=
y may evade a filter but it breaks the attack.</div>
<div> </div>
<div>To your specific point about Comments, consider what I outlined above.=
While nesting attack payloads inside of Comments may indeed hel=
p to bypass basic filters that remove/ignore this data after normalization,=
this same transport area will effectively prevent the back-end system=
from executing it because it skips over the Comment data. The one ex=
ception, however, that I can think of is the MySQL extension for Comments w=
ere you can actually place DB commands inside of the Comment area and it wi=
ll still be executed! <a href=3D"http://ferruh.mavituna.com/sql-injec=
tion-cheatsheet-oku/#InlineComments">http://ferruh.mavituna.com/sql-injecti=
on-cheatsheet-oku/#InlineComments</a></div>
<div> </div>
<div>From a WAF perspective, one way that we can address this is to do insp=
ection both before and after normalization. ModSecurity, for example,=
applies a number of anti-evastion normalization functions (<a href=3D"http=
://www.modsecurity.org/documentation/modsecurity-apache/2.5.5/modsecurity2-=
apache-reference.html#transformation-functions">http://www.modsecurity.org/=
documentation/modsecurity-apache/2.5.5/modsecurity2-apache-reference.html#t=
ransformation-functions</a>) to data before we apply our rules. There=
is a little used action however called multiMatch (<a href=3D"http://www.m=
odsecurity.org/documentation/modsecurity-apache/2.5.5/modsecurity2-apache-r=
eference.html#N11554">http://www.modsecurity.org/documentation/modsecurity-=
apache/2.5.5/modsecurity2-apache-reference.html#N11554</a>) that will help =
to combat these issues. For the case of sql injection data inside of =
Comments, this would allow us to identify the injection before the rep=
laceComments transformation function is applied. This is good from an=
anti-evasion perspective, however there is some impact on overall performa=
nce.</div>
<div> </div>
<div>2) Impedance Mismatch</div>
<div>This is where you can run into issues if there are differences of inte=
rpretation between systems that are analyzing the same data. A good e=
xample of this is HTTP Request Smuggling. You have many network syste=
ms that may inspect the inbound data (Network Firewall doing Deep Packet In=
spection, Network IDS/IPS, WAF, Reverse Proxy, etc...) and each of these sy=
stems may interpret this as either 1 or 2 requests. The main que=
stion is how does the destination web app interpret it? </div>
<div> </div>
<div>I will say this - from an analysis and accuracy of intrusion detection=
perspective, it is always best for these security systems to interpret the=
data in exactly the same way as the protected web app. On the other =
hand, from an auditing and logging perspective, it is oftentimes advantageo=
us to to ensure that the security system does not actually execute or act u=
pon metadata in the same way as the back-end web app. </div>
<div> </div>
<div>One great example of this is in relation to a real SQL Injection attac=
k that we encountered with one of our customers (sanitized) -</div>
<div><font size=3D"2"><span style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><=
/span> </font></div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">GET /shoppingcart/login.asp?Email=3D'%20o=
r%201=3Dconvert(int,(select%20@@version%2b'/'%2b@@servername%2b'=
;/'%2bdb_name()%2b'/'%2bsystem_user<strong>))--sp_password</str=
ong> HTTP/1.1</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Accept: image/gif, image/x-xbitmap, image/jpe=
g, image/pjpeg, */*</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">User-Agent: Microsoft URL Control - 6.00.8862=
</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Host: <a href=3D"http://www.example.com";>www.=
example.com</a></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman=
'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-lang=
uage: AR-SA">Connection: Keep-Alive</span> </p>
</div>
<div> </div>
<div>Notice the bolded "--sp_password" string at the end as it su=
ccessfully prevented this attack from being logged by the customer's ba=
ck-end DB even though they had DB auditing enabled. So while we wante=
d to normalize, format, etc... the SQL Query data in the same way as the ba=
ck-end DB would see it, we did not treat that data as an actual comman=
d to "do something" as the DB did.</div>
<div> </div>
<div>-- <br>Ryan C. Barnett<br>ModSecurity Community Manager<br>Breach Secu=
rity: Director of Application Security<br>Web Application Security Consorti=
um (WASC) Member<br>CIS Apache Benchmark Project Lead<br>SANS Instructor, G=
CIA, GCFA, GCIH, GSNA, GCUX, GSEC<br>
Author: Preventing Web Attacks with Apache<br><br></div>
<div class=3D"gmail_quote">On Thu, Jul 24, 2008 at 4:14 AM, Nick Gearls <=
;<a href=3D"mailto:nickgearls@gmail.com";>nickgearls@gmail.com</a>> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hello,<br><br>I was thinking abo=
ut an evasion technique for command/SQL/SSI injection, XSS, etc., and I won=
der how to avoid this.<br>
<br>The (known) problem: several languages accept comments in the middle of=
a command<br>Ex:<br>- MySQL & &SQL Server accept C-style comments:=
/* ... */<br>- Javascript accepts C++-style comments: // ...<br>- Perl, PH=
P accept # ...<br>
- SQL Server accepts -- ...<br>- Coldfusion accepts <!-- ... --><br>T=
his allows to embed a comment in the middle of a multiple words command (so=
metimes, although not often, even in the middle of a word) to evade detecti=
on.<br>
<br>Let's use C-style comments as example.<br>If I want to block "=
foo bar", it can easily be evaded as "foo /*...*/ bar"=
.<br>We could remove comments; this is standard with most WAF; this solves =
the above problem, but it could in fact be worse !<br>
What about the following line:<br> a=3D"/*"; here is a comm=
and that should be blocked; a=3D"*/";<br>Because WAF and IDS use =
regex/string patterns and do not understand the real syntax, the complete c=
ommand will be ignored.<br>
Note that even a single word pattern will be evaded.<br>And we can obviousl=
y mix both:<br> a=3D"/*"; here is a command that /*...*/ sh=
ould be blocked; a=3D"*/";<br><br>Any idea on how to solve that a=
t a WAF/IDS level ?<br>
What mitigation technique could be used ?<br><br>Note that Coldfusion comme=
nts are also very difficult to remove, as this would also remove real HTML =
comments. This leaves the door open to a combination of Coldfusion and Java=
script XSS attack.<br>
<br>Nick<br><br><br>-------------------------------------------------------=
---------------------<br>Join us on IRC: <a href=3D"http://irc.freenode.net=
/" target=3D"_blank">irc.freenode.net</a> #webappsec<br><br>Have a question=
? Search The Web Security Mailing List Archives: <a href=3D"http://www.weba=
ppsec.org/lists/websecurity/archive/" target=3D"_blank">http://www.webappse=
c.org/lists/websecurity/archive/</a><br>
<br>Subscribe via RSS: <a href=3D"http://www.webappsec.org/rss/websecurity.=
rss" target=3D"_blank">http://www.webappsec.org/rss/websecurity.rss</a> [RS=
S Feed]<br><br>Join WASC on LinkedIn<br><a href=3D"http://www.linkedin.com/=
e/gis/83336/4B20E4374DBA" target=3D"_blank">http://www.linkedin.com/e/gis/8=
3336/4B20E4374DBA</a><br>
<br></blockquote></div><br></div>
------=_Part_19054_6971687.1216997752423--
Brought to you by http://www.webappsec.org
Search this site
|