Re: [Full-disclosure] Denial of Service in WordPress

["MustLive" <mustlive@xxxxxxxxxxxxxxxxxx>]

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 
  To: MustLive 
  Cc: Ryan Dewhurst ; full-disclosure 
  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@xxxxxxxxxxxxxxxxxx>

    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/) 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), 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 
      To: MustLive 
      Cc: submissions@xxxxxxxxxxxxxxxxxxxxxxx ; full-disclosure ; 1337 Exploit 
DataBase 
      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@xxxxxxxxxxxxxxxxxx> 
wrote:

        Hello list!

        These are Denial of Service vulnerabilities WordPress. Which I've 
disclosed two days ago (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). 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/)), 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), 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-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="http://site/wp-login.php?action=logout&redirect_to=http://site/WordPress_Looped_DoS.html";</script>

        WordPress_Looped_DoS-2.html

        <script>document.location="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/