Re: Denial of Service in WordPress

[Julius Kivimäki <julius.kivimaki () gmail com>]

If one wants to conduct such attacks, would it not be a million times
easier for them to use infected hosts to do thousands of requests per
second? (Per computer). Can you come up with a scenario where this "attack"
would actually be useful?


2013/6/28 MustLive <mustlive () websecurity com ua>

> **
> *Hi Julius!*
>
> Why do you think it will be very slowly? For last 5.5 years you the first
> said me concerning Looped DoS that requests will be sending very slowly. So
> think about it. Because all those web sites owners and all those web
> developers, in which web applications I've found Looped DoS
> vulnerabilities, after my informing fixed the holes or said that they will
> take it into account, but never used such argument.
>
> The requests speed will be the next (tested on
> http://tinyurl.com/loopeddos1):
>
> - In average 5.83 - 7 requests/s for looped redirect with 301/302
> responses. I.e. it takes 3-3.6 seconds for Firefox to make 21 request
> before blocking redirect loop (and showing error message). Situation is
> similar in other browsers, which support blocking. Didn't examine old IE,
> which doesn't block infinite loops, but the speed must be the same.
>
> - The faster will be working target web sites, the faster will be request
> rate.
>
> - It's for browsers, but there are also other clients. Especially such as
> bots with no redirection limits. Which can work even faster.
>
> - If the looped requests will be going inside one domain, then the speed
> will be faster (and it'll useful for attacking not only WordPress < 2.3,
> but also WP 2.3 - 3.5.2). And overload will not be splitting between two
> domains (like it's showing in my two examples with tinyurl.com).
>
> - Open two or more iframes with looped redirect to the same site, to
> multiply the speed of attack.
>
> - Make sufficient amount of clients (people or bots) to unknowingly
> participate in the attack, such as 1000 and more clients and it'll be
> sufficient to DoS the site on slow server.
>
> Note that every attack is going infinitely (at using appropriate clients
> or at using JS or meta-refresh to prevent normal browsers from
> stopping endless loop), not just single request from every client. No need
> to think that in 2013 every web site owner has resources like Google has.
> There are a lot of sites on slow servers and there are a lot of sites with
> redirectors (and even real Looped DoS holes are rare, but with using of
> redirectors it's possible to create such one at any web site with
> redirector).
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
> ----- Original Message -----
> *From:* Julius Kivimдki <julius.kivimaki () gmail com>
> *To:* MustLive <mustlive () websecurity com ua>
> *Cc:* Ryan Dewhurst <ryandewhurst () gmail com> ; full-disclosure<full-disclosure () lists grok org uk>
> *Sent:* Friday, June 28, 2013 12:59 AM
> *Subject:* Re: [Full-disclosure] 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 () websecurity 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 () gmail com>
> > *To:* MustLive <mustlive () websecurity com ua>
> > *Cc:* submissions () packetstormsecurity org ; full-disclosure<full-disclosure () lists grok org uk>; 1337
> > Exploit DataBase <mr.inj3ct0r () gmail 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 () websecurity 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
Hosted and sponsored by Secunia - http://secunia.com/