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 <mustl...@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 <ryandewhu...@gmail.com> > *To:* MustLive <mustl...@websecurity.com.ua> > *Cc:* submissi...@packetstormsecurity.org ; > full-disclosure<full-disclosure@lists.grok.org.uk>; 1337 > Exploit DataBase <mr.inj3c...@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 <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/<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<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/ >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/