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: submissi...@packetstormsecurity.org ; 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 <mustl...@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/).
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/_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
