Message-ID: <CAPMrQTRWWLgqd3EROY05WfkHuzphRAGYdQ8jkEiv3b1RZ3fLgg@mail.gmail.com>
Date: Fri, 28 Jun 2013 22:10:17 +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

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@...security.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@...il.com>
> *To:* MustLive <mustlive@...security.com.ua>
> *Cc:* Ryan Dewhurst <ryandewhurst@...il.com> ; full-disclosure<full-disclosure@...ts.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@...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
>>
>>

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