[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] Normalization of page response times to prevent timing attacks in a production environment?
- From: bugtraq@xxxxxxxxxxxxxxx
- Subject: Re: [WEB SECURITY] Normalization of page response times to prevent timing attacks in a production environment?
- Date: Mon, 5 May 2008 16:24:16 -0400 (EDT)
Thanks for the reply Ryan,
Regarding the slowing down of responses how has this impacted a production site in your experience/others on the list?
Besides modsec what other approaches have you/others used to doing this. Where there situations where this was impractical
or the wrong thing to do/why?
Regards,
- Robert
> Timing attacks such as this (and Blind SQL Injections that use waitfor,
> etc...) are certainly interesting research areas especially when
> organizations no longer return detailed error message text.
>
> I have used ModSecurity's "pause" action (
> http://www.modsecurity.org/documentation/modsecurity-apache/2.5.2/modsecurity2-apache-reference.html#N11621)
> on several previous occassions. Most of my research was based on attempting
> to prolong an attackers automated scans. Sidenote - this was for Government
> clients and not any eCommerce sites. The idea was that they wanted to
> conduct tracebacks so they wanted to "keep them on the line" so to speak as
> long as possible.
>
> For this type of application of the pause action, I would guess that it
> could work to help address this type of enumeration. If you look at one of
> the example graphics they showed (
> http://www.sensepost.com/blogstatic/2007/08/dxsrt.png) you can see that in
> the scan - the failed attempts returned in 2ms while the successful one took
> 5ms. So, as an example, if you were to profile the response times for
> failed authentications to your site's login page vs. a successful one, you
> could use ModSecurity's pause action to slightly slow down the processing
> for the failed auths to match that of your successful one.
>
> Keeping the 2ms for failed and 5ms for successful, then here would be
> and example rule to delay the failed auth response for 3ms (which would then
> match the time for a successful one) -
>
> SecRule REQUEST_URI "@streq /path/to/login.php" \
> "chain,phase:4,t:lowercase,nolog,pass,*pause:3*"
> SecRule RESPONSE_BODY "your sign in information is not valid"
>
> Hope this info helps.
>
> --
> 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 Mon, May 5, 2008 at 2:17 PM, <bugtraq@xxxxxxxxxxxxxxx> wrote:
>
> > Hello List,
> >
> > Has anyone had any experience with normalizing page response times on
> > timing attack vulnerable pages in a production environment?
> > If so would you care to share your experiences with the list?
> >
> > Background:
> > http://www.sensepost.com/blog/1303.html
> >
> > Regards,
> > - Robert
> > http://www.webappsec.org/
> > http://www.cgisecurity.com/
> > http://www.edevelopment.org/
> >
> >
> >
> > ----------------------------------------------------------------------------
> > Join us on IRC: irc.freenode.net #webappsec
> >
> > Have a question? Search The Web Security Mailing List Archives:
> > http://www.webappsec.org/lists/websecurity/
> >
> > Subscribe via RSS:
> > http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> >
> >
>
> ------=_Part_8165_15818408.1210013864466
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> <div>Timing attacks such as this (and Blind SQL Injections that use waitfor, etc...) are certainly interesting research areas especially when organizations no longer return detailed error message text.</div>
> <div> </div>
> <div>I have used ModSecurity's "pause" action (<a href="http://www.modsecurity.org/documentation/modsecurity-apache/2.5.2/modsecurity2-apache-reference.html#N11621";>http://www.modsecurity.org/documentation/modsecurity-apache/2.5.2/modsecurity2-apache-reference.html#N11621</a>) on several previous occassions. Most of my research was based on attempting to prolong an attackers automated scans. Sidenote - this was for Government clients and not any eCommerce sites. The idea was that they wanted to conduct tracebacks so they wanted to "keep them on the line" so to speak as long as possible.</div>
>
> <div> </div>
> <div>For this type of application of the pause action, I would guess that it could work to help address this type of enumeration. If you look at one of the example graphics they showed (<a href="http://www.sensepost.com/blogstatic/2007/08/dxsrt.png";>http://www.sensepost.com/blogstatic/2007/08/dxsrt.png</a>) you can see that in the scan - the failed attempts returned in 2ms while the successful one took 5ms. So, as an example, if you were to profile the response times for failed authentications to your site's login page vs. a successful one, you could use ModSecurity's pause action to slightly slow down the processing for the failed auths to match that of your successful one.</div>
>
> <div> </div>
> <div>Keeping the 2ms for failed and 5ms for successful, then here would be and example rule to delay the failed auth response for 3ms (which would then match the time for a successful one) -</div>
> <div> </div>
> <div class="O">
> <div style="mso-line-spacing: '80 30 0'; mso-margin-left-alt: 144; mso-char-wrap: 1; mso-kinsoku-overflow: 1"><span style="FONT-FAMILY: 'Courier New'; mso-ascii-font-family: 'Courier New'; mso-bidi-font-family: Arial">SecRule REQUEST_URI "@streq /path/to/login.php" </span><span style="FONT-FAMILY: 'Courier New'; mso-ascii-font-family: 'Courier New'; mso-bidi-font-family: Arial">\</span></div>
>
> <div style="mso-line-spacing: '80 30 0'; mso-margin-left-alt: 144; mso-char-wrap: 1; mso-kinsoku-overflow: 1"><span style="FONT-FAMILY: 'Courier New'; mso-ascii-font-family: 'Courier New'; mso-bidi-font-family: Arial">"chain,phase:4,t:lowercase,nolog,pass,<strong>pause:3</strong></span><span style="mso-ascii-font-family: 'Courier New'; mso-bidi-font-family: Arial">"</span></div>
>
> <div style="mso-line-spacing: '80 30 0'; mso-margin-left-alt: 144; mso-char-wrap: 1; mso-kinsoku-overflow: 1"><span style="mso-ascii-font-family: 'Courier New'; mso-bidi-font-family: Arial"><span style="FONT-FAMILY: 'Courier New'; mso-ascii-font-family: 'Courier New'; mso-bidi-font-family: Arial">SecRule RESPONSE_BODY "your sign in information is not valid"</span></span></div>
>
> <div style="mso-line-spacing: '80 30 0'; mso-margin-left-alt: 144; mso-char-wrap: 1; mso-kinsoku-overflow: 1"><span style="mso-ascii-font-family: 'Courier New'; mso-bidi-font-family: Arial"><span style="FONT-FAMILY: 'Courier New'; mso-ascii-font-family: 'Courier New'; mso-bidi-font-family: Arial"></span></span> </div>
> </div>
> <div>Hope this info helps.</div>
> <div><br>-- <br>Ryan C. Barnett<br>ModSecurity Community Manager<br>Breach Security: Director of Application Security<br>Web Application Security Consortium (WASC) Member<br>CIS Apache Benchmark Project Lead<br>SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC<br>
> Author: Preventing Web Attacks with Apache <br><br></div>
> <div class="gmail_quote">On Mon, May 5, 2008 at 2:17 PM, <<a href="mailto:bugtraq@xxxxxxxxxxxxxxx";>bugtraq@xxxxxxxxxxxxxxx</a>> wrote:<br>
> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hello List,<br><br>Has anyone had any experience with normalizing page response times on timing attack vulnerable pages in a production environment?<br>
> If so would you care to share your experiences with the list?<br><br>Background:<br><a href="http://www.sensepost.com/blog/1303.html"; target="_blank">http://www.sensepost.com/blog/1303.html</a><br><br>Regards,<br>- Robert<br>
> <a href="http://www.webappsec.org/"; target="_blank">http://www.webappsec.org/</a><br><a href="http://www.cgisecurity.com/"; target="_blank">http://www.cgisecurity.com/</a><br><a href="http://www.qasec.com/"; target="_blank">http://www.qasec.com/</a><br>
> <br><br>----------------------------------------------------------------------------<br>Join us on IRC: <a href="http://irc.freenode.net/"; target="_blank">irc.freenode.net</a> #webappsec<br><br>Have a question? Search The Web Security Mailing List Archives:<br>
> <a href="http://www.webappsec.org/lists/websecurity/"; target="_blank">http://www.webappsec.org/lists/websecurity/</a><br><br>Subscribe via RSS:<br><a href="http://www.webappsec.org/rss/websecurity.rss"; target="_blank">http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br>
> <br></blockquote></div><br><br clear="all">
>
> ------=_Part_8165_15818408.1210013864466--
>
----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Brought to you by http://www.webappsec.org
Search this site
|