Date: Fri, 28 Jun 2013 00:59:34 +0300
From: Julius Kivimäki <julius.kivimaki@...il.com>
To: MustLive <mustlive@...security.com.ua>
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: Denial of Service in WordPress

So basically this results in client sending HTTP GET requests very slowly.
How will that lead to DoS? (We aren't in 1980 anymore)


2013/6/27 MustLive <mustlive@...security.com.ua>

> **
> *Hello Ryan!*
>
> Attack exactly overload web sites presented in endless loop of redirects.
> As I showed in all cases of Looped DoS vulnerabilities in web sites and web
> applications, which I wrote about during 2008 (when I created this type of
> attacks) - 2013.
>
> Particularly concerning web applications, before WordPress, I wrote about
> Looped DoS in Power Phlogger (2009), OpenX/Openads (2009), MODx (2012). If
> you don't understand this type of attack, you should asked in previous
> years. Since it's ~5,5 years old attack, since I created in beginning of
> 2008. And I consider it as a thing which people should be aware about (like
> about XSS and CSRF). So I recommend you to read my 2008's articles on this
> topic.
>
> First I've described Looped DoS in November 2008 in my Classification of
> DoS vulnerabilities in web applications (http://websecurity.com.ua/**
> 2663/) <http://websecurity.com.ua/2663/)> and then in more details
> in article Looped DoS (http://websecurity.com.ua/2698/). In standard case
> Looped DoS happens when web applications is redirecting on itself (endless
> redirect). Browsers vendors long time ago became fighting with such state -
> like Mozilla in earlier versions of their Mozilla browser added "Redirect
> Loop Error" warning (the same function later received Firefox). But not
> Internet Explorer. In beginning of 2008 I was not using Opera (so can't say
> in which version they added this protection) and there was no Chrome, and
> among my browsers only Mozilla and Firefox had such protection, but IE was
> affected. And exactly IE was the most popular browser that time, so such
> attack would be working in most clients.
>
> Besides, as I always noted in my articles, that there can be such clients,
> like spiders and other bots (with no limits on redirects), which can
> overload looped site (sites) by going such link. Anyway with time there was
> appeared more browsers with "Redirect Loop Error", so later I created two
> methods of bypassing "redirect limit" in browsers and described them in
> February 2009 in my article Hellfire for redirectors. About them I've
> mentioned in my last advisory. The first one is presented in looped
> redirector (http://tinyurl.com/hellfire-**url<http://tinyurl.com/hellfire-url>),
> which I made for that article and the second method - it's using JS (both
> redirects or one redirect on JS and one via 301/302), because browsers only
> blocks endless redirects which use only server headers. With using this
> methods of creating "Redirector hell" the attack will work in all browsers.
>
> If standard case Looped DoS (redirecting on itself) is rare, then there
> are large number of redirectors out there. Which can be used also for DoS
> attacks. So I used them and created attack described in articles
> Redirectors' hell (http://websecurity.com.ua/2670/) and Hellfire for
> redirectors (http://websecurity.com.ua/2854/). Never translated these
> articles to English. This attacks (between two redirector services and
> between web site and redirector service) allow to create Looped DoS from a
> redirector at any site, just needed one redirector to have predictable
> address, like in case of TinyURL's custom alias feature. After that in 2009
> in my articles "Redirectors: the phantom menace" (
> http://websecurity.com.ua/3495/) and "Attacks via closed redirectors" (
> http://websecurity.com.ua/3531/) I wrote about all possible attacks via
> open and closed redirectors, including Looped DoS. So all who want could be
> familiar with this attack.
>
> > This just affects the client though right?
>
> This DoS only going on client side unlike other types of DoS (see my
> classification), but issue of web application is in allowing Looped DoS
> state. You see error message very quickly because you are leaving in 2013
> (where already many browsers protect against simple form of Looped DoS) and
> using secure browser - use a browser without this protection (like IE) and
> have fun.
>
> > From my understanding you'd have to get the user to click on the tinyurl
>
> How the attack must go to benefit the attacker. One way is to give people
> (with vulnerable browsers) to click the link and see endless loop - it'll
> not give enough overload on target server, since people will quickly close
> the browser's tab/window. Another one is to give that link to crazy bots
> (like from search engines), who has no limits on redirects - it'll
> endlessly connect to target site/sites and overload them. Even better way
> is to put iframe which leads to such redirector at some sites (the more the
> better) - it can be ad network with such "fun banner" or hacked web sites
> with added iframe or via persistent XSS hole. While people will be at such
> sites the browser in background will be infinitely sending requests to
> target site/sites (in case of WP redirectors it will be two sites for the
> first attack with using of tinyurl.com and one site in case of the second
> attack, which works in all WordPress, including WP 3.5.2). The more time
> people spend on particular page with injected iframe with endless redirect
> and the more people are visiting such sites, the more effect will be. No
> need to ask people to "participate in DoS attack", their browser will be
> automatically "participating" via Looped DoS attack (just by entering in
> any way this endless loop).
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
> ----- Original Message -----
> *From:* Ryan Dewhurst <ryandewhurst@...il.com>
> *To:* MustLive <mustlive@...security.com.ua>
> *Cc:* submissions@...ketstormsecurity.org ; full-disclosure<full-disclosure@...ts.grok.org.uk>; 1337
> Exploit DataBase <mr.inj3ct0r@...il.com>
> *Sent:* Thursday, June 27, 2013 8:34 PM
> *Subject:* Re: [Full-disclosure] Denial of Service in WordPress
>
> This just affects the client though right? So doesn't DoS a WordPress
> blog, just presents an error message to the user if they click on a crafted
> link. How could this be used in the real world to cause any risk?
>
> From my understanding you'd have to get the user to click on the tinyurl,
> which would then show them a browser redirect error? If this is the case,
> how does this benefit an attacker?
>
>
> On Thu, Jun 27, 2013 at 7:28 PM, MustLive <mustlive@...security.com.ua>wrote:
>
>> Hello list!
>>
>> These are Denial of Service vulnerabilities WordPress. Which I've
>> disclosed two days ago (http://websecurity.com.ua/**6600/<http://websecurity.com.ua/6600/>
>> ).
>>
>> About XSS vulnerabilities in WordPress, which exist in two redirectors, I
>> wrote last year (http://seclists.org/**fulldisclosure/2012/Mar/343<http://seclists.org/fulldisclosure/2012/Mar/343>).
>> About Redirector vulnerabilities in these WP scripts I wrote already in
>> 2007 (and made patches for them). The developers fixed redirectors in WP
>> 2.3, so Redirector and XSS attacks are possible only in previous versions.
>>
>> As I've recently checked, this functionality can be used for conducting
>> DoS attacks. I.e. to make Looped DoS vulnerabilities from two redirectors
>> (according to Classification of DoS vulnerabilities in web applications (
>> http://websecurity.com.ua/**2663/) <http://websecurity.com.ua/2663/)>),
>> by combining web site on WordPress with redirecting service or other site.
>> This attack is similar to looping two redirectors, described in my articles
>> Redirectors' hell and Hellfire for redirectors. The interesting, that
>> looped redirector (http://tinyurl.com/hellfire-**url<http://tinyurl.com/hellfire-url>),
>> which I've made at 5th of February 2009 for my article Hellfire for
>> redirectors, is still working.
>>
>> -------------------------
>> Affected products:
>> -------------------------
>>
>> Vulnerable are all versions of WordPress: for easy attack - WP 2.2.3 and
>> previous versions, for harder attack - WP 3.5.2 and previous versions. The
>> second variant of attack requires Redirector or XSS vulnerability at the
>> same domain, as web site on WP.
>>
>> ----------
>> Details:
>> ----------
>>
>> Denial of Service (WASC-10):
>>
>> It's needed to create Custom alias at tinyurl.com or other redirector
>> service, which will be leading to wp-login.php or wp-pass.php with setting
>> alias for redirection.
>>
>> http://site/wp-login.php?**action=logout&redirect_to=**
>> http://tinyurl.com/loopeddos1<http://site/wp-login.php?action=logout&redirect_to=http://tinyurl.com/loopeddos1>
>>
>> http://site/wp-pass.php?_wp_**http_referer=http://tinyurl.**
>> com/loopeddos2<http://site/wp-pass.php?_wp_http_referer=http://tinyurl.com/loopeddos2>
>>
>> Here are examples of these vulnerabilities:
>>
>> http://tinyurl.com/loopeddos1
>>
>> http://tinyurl.com/loopeddos2
>>
>> This attack will work for WordPress < 2.3. At that Mozilla, Firefox,
>> Chrome and Opera will stop endless redirect after series of requests,
>> unlike IE.
>>
>> To make this attack work in all versions of the engine, including
>> WordPress 3.5.2, it's needed that redirector was on the same domain, as web
>> site on WP. For this it can be used any vulnerability, e.g. reflected XSS
>> or persistent XSS (at the same domain), for including a script for
>> redirecting to one of these redirectors:
>>
>> WordPress_Looped_DoS.html
>>
>> <script>document.location="htt**p://site/wp-login.php?action=**
>> logout&redirect_to=http://**site/WordPress_Looped_DoS.html<http://site/wp-login.php?action=logout&redirect_to=http://site/WordPress_Looped_DoS.html>
>> **"</script>
>>
>> WordPress_Looped_DoS-2.html
>>
>> <script>document.location="htt**p://site/wp-pass.php<http://site/wp-pass.php>
>> "</script>
>>
>> This attack will work as in WordPress 3.5.2 and previous versions, as it
>> isn't stopping by the browsers (endless redirect).
>>
>> Best wishes & regards,
>> MustLive
>> Administrator of Websecurity web site
>> http://websecurity.com.ua
>>
>> ______________________________**_________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-**disclosure-charter.html<http://lists.grok.org.uk/full-disclosure-charter.html>
>> Hosted and sponsored by Secunia - http://secunia.com/
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists