Re: [Full-disclosure] Denial of Service in WordPress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/28, Julius Kivimäki wrote: 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? no, he can't. there isn't such a scenario. this is one of those situations where in theory he is correct but in reality this is simply not an issue. there are a thousand other attacks one could do that would be more efficient and more effective (which others have been trying to explain to him) but he refuses to listen and insists this is a major problem. this is *not* an issue -- which is why everyone has been ignoring it for 5.5 years. - -chl - -- cool hand luke -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQF8BAEBCgBmBQJRz0VjXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RUE3NjY3OTY3NTE0RjAyMDgyRTNBQzAy QkE2NTVENTVDODgzNUVCAAoJECumVdVciDXrtT4IAJwAnbWUWrzLXuX29QO9Wsk1 nWbwOF4t0QgPaCnQckwD9r6a5/EpUIjSRD00yweXjL12ZX4RobtI18tri+h2bor3 xq9PQgsHCLe1XdU4CSAmmKpVb7Bd5YJExxH/JQJbZQdQS/KNZFvdGBKHsN4O6WYr E28H5kggpcBF1++iWp2WEBLdyoW9bGdRvtPukDkLOnLUGU28IAhxCtOlYGnjz1LE QmQvT3U4325sOKNJCdCuw3kCYnEEHY3/PlVDd/uVEiWt9w8mVzzTbUI3rjwYVagM VV9urMW9XnaaZ5VFQEUluh3jtofgfrd9d97/x/vSj2cuGMOSgvKbRg/T5XIg6JM= =7+mT -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Denial of Service in WordPress
Hello Michal! Yes, of course there are a lot of ways to make cross-site requests. But what is a benefit in using Looped DoS - do you see it? Looks like don't. I'll explain for you. One standard request (via img and other tags in HTML, etc.) leads to single request to target site. One request with using of Looped DoS hole (such hole by itself or artificially created from looping two redirectors) leads to 21 requests - in case of using redirector/redirectors with server headers (after 21st request modern browsers will stop it). And in case if there will be old IE or unlimited bot or there will be used my bypass techniques (using JS or meta-refresh at least in one from two redirectors) to bypass browsers restriction - one request leads to infinite number of requests. I.e. this is 21 times / infinite times more effective for attack. And besides using of link, frame or iframe to lead to Looped DoS, it's also possible to use other standard methods for making request. Such as img or other tags (in this case only server headers redirectors must be used). Which creates 21 (for modern browsers) or infinite number of requests (for old IE) from one image. Put a lot of images on forums and other sites, which allow img tag (via html or bbcode) to Looped DoS and there will be a lot of requests from single visitor of that page. Browsers detect redirect loops to prevent accidental mishaps and simplify troubleshooting, not to stop malicious attacks. Yes, you are right. But exactly this functionality to stop redirect loops (in all modern browsers) can help mitigate such attacks. Just not all techniques of this attack. Also remember that your company's browser Chrome (and some other vendors too) was trying to prevent looped redirect with using JS, but not good enough - as I showed in my Refresh DoS attack in 2008 in my project Day of bugs in browsers. So browsers vendors need to improve their redirect loops protection. Best wishes regards, Eugene Dokukin aka MustLive Administrator of Websecurity web site http://websecurity.com.ua - Original Message - From: Michal Zalewski lcam...@coredump.cx To: MustLive mustl...@websecurity.com.ua Cc: Ryan Dewhurst ryandewhu...@gmail.com; full-disclosure full-disclosure@lists.grok.org.uk Sent: Friday, June 28, 2013 9:19 AM Subject: Re: [Full-disclosure] Denial of Service in WordPress 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. You do realize that any browser can be made to issue a *lot* of requests to any other destination on the web - say, by instantiating a bunch of images, leveraging CORS, navigating iframes, etc? Browsers detect redirect loops to prevent accidental mishaps and simplify troubleshooting, not to stop malicious attacks. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Denial of Service in WordPress
I.e. this is 21 times / infinite times more effective for attack.
Not really, in terms of the bandwidth you can use up / the number of
requests you can create. You're essentially trading this:
for (var i = 0; i whatever; i++) {
var x = new XMLHttpRequest(); /* or new Image() or whatever */
...
}
...for this:
for (var i = 0; i whatever / redirect_limit; i++) {
for (var j = 0; j redirect_limit; j++) { /* implicit loop */
...
}
}
...and it shouldn't matter.
You can generate a ton of expensive traffic from within JS these days.
/mz
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Denial of Service in WordPress
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. You do realize that any browser can be made to issue a *lot* of requests to any other destination on the web - say, by instantiating a bunch of images, leveraging CORS, navigating iframes, etc? Browsers detect redirect loops to prevent accidental mishaps and simplify troubleshooting, not to stop malicious attacks. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Denial of Service in WordPress
, 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=logoutredirect_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 scriptdocument.location=http://site/wp-login.php?action=logoutredirect_to=http://site/WordPress_Looped_DoS.html;/script WordPress_Looped_DoS-2.html scriptdocument.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/
Re: [Full-disclosure] Denial of Service in WordPress
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-disclosurefull-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.uawrote: 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/343http://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-**urlhttp://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=logoutredirect_to=** http://tinyurl.com/loopeddos1http://site/wp-login.php?action=logoutredirect_to=http://tinyurl.com/loopeddos1 http://site/wp-pass.php?_wp_**http_referer=http://tinyurl.** com/loopeddos2http://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 scriptdocument.location=htt**p://site/wp-login.php?action=** logoutredirect_to=http://**site/WordPress_Looped_DoS.htmlhttp://site/wp-login.php?action=logoutredirect_to=http://site/WordPress_Looped_DoS.html **/script WordPress_Looped_DoS-2.html scriptdocument.location=htt**p://site/wp-pass.phphttp://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.htmlhttp://lists.grok.org.uk/full-disclosure
Re: [Full-disclosure] Denial of Service in WordPress
On Thu, Jun 27, 2013 at 11:50:47PM +0300, MustLive wrote: 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. Sooo... a bunch of browsers doing one request at a time (instead of doing a real attack) and which slow down if your server becomes unresponsive is a threat? Seriously, that might become a few hundred requests per second or so if a largeish amount of clients participates, but that shouldn't be able to bring down your server. 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. You said it – you'd need crazy bots for that. crazy bots with an absurd amount of bandwidth (since they're probably not just indexing your site). I think you'll have a hard time finding those – as far as I know, it's standard practice to put at least one second of delay between two requests, and that rate shouldn't be harmful at all. 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). Yeah, that could happen... but why only do one request at a time? Just use a javascript that reloads 100 images with src=targetsite at a time, and you have your attack completely without using any vulns (and some scriptkiddies actually did that, see http://loic.webs.com/). Tip: If you can do something without using a vuln or so, having a vuln for it is worthless. signature.asc Description: Digital signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
