WordPress DDoS and other HTTP Reflectors
Lately, there has been a lot of buzz about reflection and amplification attacks extending DDoS harm. The new kid on this attack block is NTP. NTP, or Network Time Protocol, is an amplification attack that is an emerging form of DDoS. This attack relies on the use of publically accessible NTP servers to overwhelm a victim’s system. While DNS attacks are still an old favorite, recently there has been a new rash of HTTP-based amplification attacks having a more significant impact than the past standard network floods.
There are two schools of thought when using HTTP Reflectors and Amplifiers. One is to make your CDN network a weapon for DDoS, with the intended injury result of major financial harm. Similarly Google Docs can be used as a weapon to just keep loading pages up over and over to help auto-generate a super high bill. (/blog/security/2012/05/spreadsheets-as-ddos-weapon/). When you combine a couple of the ideas together, you can see how easy it is to build a botnet with free online accounts that automatically can load up pages over and over.
Recently a number of folks have begun putting together variations of the Google Docs Attack with CDN Cache poisoning. Their premise is that they want to bypass the CDN and hammer the origin server with a heavy load, using Google Docs as the delivery method. This yielded an impressive 750Mbit flood from just a single spreadsheet instance. In the other variation, using multiple copies of the same doc, they could easily run the CDN bill into the ground and mask their activity by not hitting the origin server. I expect we’ll start to see a variety of these kinds of perpetual http attack reflectors in the future with some using CDN as a financial weapon and others using it as a technical weapon.
The WordPress DDoS exploit is another easy to use exploit. It requires a simple command from a shell such as:
$ curl -D – “www.anywordpresssite.com/xmlrpc.php” -d ‘<methodCall><methodName>pingback.ping</methodName><params><param><value><string>http://www.sitetoattack.com</string></value></param><param><value><string>www.anywordpresssite.com/postchosen</string></value></param></params></methodCall>’
The “XMLRPC” pingback function is inherent in WordPress. It’s a feature. Hackers have figured out ways to get the pingback function to attack other people’s sites. They can choose one of two versions if the site to attack uses a CDN. First is to bypass the CDN and use random URL strings to bypass the CDN and hit the origin server. Second is to simply allow object cache hits which can cause financial costs to the customer as providers charge unit costs for traffic.
Luckily the WordPress exploit requires data to post in the request, or it could be used in the GoogleDocs exploit. However, it probably won’t take long for people to learn about the API’s at Google open for folks to use in order to create these kind of “self licking ice cream cones” for DDoS. No botnet is required.
Now, imagine if somebody had 15-20,000 fake Facebook accounts and decided to paste “links” to your web page from all of those accounts? These links would cause a heavy page load from their fetch engine as it gets a number of the images from the page to use as an icon. Facebook now would be hyper loading your pages. Or even worse, they learned how to use the Text/SMS gateway nefariously for Facebook to automatically post Facebook posts from SMS and use free SMS services? The list of reflection possibilities is endless.
The difficulty in fighting these types of attacks is that incorrect defense mechanisms are put into place. DDoS services that require you to “swing” your datacenter traffic over to them to “clean” the traffic are expensive, and generally only used for emergencies. Network reflection attacks often require these kinds of Emergency Services such as Radware’s Defense Pipe. When HTTP reflectors and perpetual HTTP requests come in, on premise is mandatory.
What happens when somebody launches embedded queries into Google Docs? It bypasses the CDN (if you have one), and hits the database. If this is constant, it can add latency which costs money and can even decrease revenue if it were an eCommerce siteby slowing down pages and forcing people to leave your site. When a hacker tunes an attack to the point where it increases your latency and raises cost in bandwidth, do you swing traffic to your DDoS service? What does that do for latency?
These are some of the reasons why you’d be foolish to put multiple point solutions together in an attempt to stop it. Having a DDoS Protection Service in place to help stop DDoS attacks can help mitigate these kinds of threats.