Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Denial of Service in WordPress
From: Julius Kivimäki <julius.kivimaki () gmail com>
Date: Fri, 28 Jun 2013 22:10:17 +0300

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

- 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

- 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

Best wishes & regards,
Administrator of Websecurity web site

----- 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

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

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,
Administrator of Websecurity web site

----- 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 
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.


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.



Here are examples of these vulnerabilities:



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:





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,
Administrator of Websecurity web site

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]