Eight Year Anniversary at Akamai Blog Reposting - I Once Was Blind but Now I Can See

 

I recently celebrated my eighth work anniversary at Akamai so I thought I would repost this blog post I made shortly after joining Akamai.  It is as true today as ever.

I Once Was Blind but Now I Can See

CDN-based WAF + Big Data Intelligence is a Gold Mine for This Security Researcher

CDN-based WAF + Big Data Intelligence is a Gold Mine for This Security Researcher

I am frequently asked by friends and colleagues why I joined Akamai's Threat Research Team.  I can boil it down to three main reasons: People, Technology and Data.         

The first reason is people.  Don't get me wrong.  This is not a slight on my former colleagues.  They were all great.  The fact is that, for me, I was missing being stimulated and challenged by other web application defense security researchers that live and breathe web application threats.  I found it here in Akamai's Threat Research Team.  At the top of that list is Ory Segal.  Ory and I have known each other for years going back to our time as board members for the Web Application Security Consortium (WASC).  We have some similar backgrounds with regards to leading WAF and DAST research teams and we had always toyed with the idea of someday working together.  Well, that day finally came last June.  It is exciting for me to work with Ory and to try and tackle these challenging web application security issues.  Besides Ory, there are also many other talented security researchers on the team and I want to mention two of them specifically.  Or Katz was an old colleague of mine from Breach Security days and I am glad to work with him again.  He excels at taking a larger view of our dataset and identifying attack patterns and new malicious campaigns.  Ezra Caltum has also been awesome to work with.  We share a common bond that can only be understood after going through the fires of having to create and maintain large scale WAF signatures!  The excellence of people does not end there and extends outside of the Threat Research Team.  The engineers in charge of the Ghost platform are incredible and the management team is dynamic and forward thinking.  All in all, it is a fantastic group of people to work with. 

The second reason I joined Akamai is the technology.  My main area of research focus is for the Kona Security product line including WAF.  I have spent more than a decade working with both open source (ModSecurity) and commercial (Breach Security/Trustwave) WAFs.  From a security researcher's perspective, one of the largest issues I had was a lack of visibility.  The main challenge was with the traditional drop-ship WAF-in-a-box model.  We would sell WAF servers to customers and then we would never see any actual data from them unless there was a false positive problem.  This lack of real-time alert data was very frustrating.  How was I supposed to verify if the protection logic was working?  How was I supposed to identify new attack techniques and trends without access to real data?  I tried to make due by utilizing web honeypot systems and they did provide some level of value but nothing can compare to the real thing.  This situation made me very envious of CDN/Cloud-based WAFs.  Now this is the way to go!  There are many advantages to this deployment model.  This model is more agile from a security perspective.  What if there is a new 0-day vulnerability or some new attack tool that is released?  How quickly can your WAF vendor respond and get protections out to customers?  With a cloud-based WAF, that time-to-respond metric is much lower than drop-ship WAFs. 

The final reason that I joined Akamai is access to data.  Data is gold to security researchers and here at Akamai, we have the mother load of data in our Cloud Security Intelligence (CSI) big data platform.  CSI holds more than 4 petabytes of intelligence data.  For me, when I used to be starving for any scraps of web attack data to feed on, getting access to CSI data is like the all-you-can-eat buffet!  Now I am able to see attacks that span across multiple customer domains, track botnets that are part of DDoS campaigns and even attackers attempting to validate stolen login credentials.  Once I was blind but now I can see...  And I am loving every minute of it! 

So, what does all this mean to you?  If you were a fan of my previous web application security/defense posts on the Trustwave SpiderLabs blog, then you are going to be happy because I am planning to start blogging again here on the Akamai blog.  It took me a while to ramp up here and to finish work on some high priority goals but I am now ready to get back to blogging.  Gotta run for now though as there is a distributed SQL Injection botnet I have to analyze!

WordPress XML-RPC PingBack Vulnerability Analysis

There were news stories this week outlining how attackers are abusing the XML-PRC "pingback" feature of WordPress blog sites to launch DDoS attacks on other sites. This blog post will provide some analysis on this attack and additional information for websites to protect themselves.

Not A New Vulnerabilty

The vulnerability in WordPress's XML-RPC API is not new. Here is data from the WordPress bug tracker from 7 years ago.

While the vulnerability itself is not new, it has only been within the past couple years that attack code/tools have been made available. This has certainly helped increase attacks by ScriptKiddies and resulted in more actual DDoS attacks.

WordPress XML-RPC Pingback DDoS Attack Walkthrough

The XML-RPC pingback functionality has a legitimate purpose with regards to linking blog content from different authors. The issue is that this functionality can be abuse by attackers to use the XML-RPC pingback feature of a blog site to attack a 3rd party site.

Patsy Proxy Attacks

SpiderLabs colleague Daniel Crowley gave a great presentation at DerbyCon in 2012 entitled "The Patsy Proxy: Getting others to do your dirty work" where he discussed various scenarios for sending attack traffic through 3rd party sites/services that will forward data onto other sites. (Slides here). Additionally, there have tools released in the community that extend this concept. One such tool is called "DDoS attacks via other sites execution tool (DAVOSET)" and it has the capability to send attacks through many different public sites that will forward traffic. Here is an example listing of URLs from DAVOSET -

As you can see, sending attack data through a "Patsy Proxy" site is quite easy. Now let's take a look at the WordPress XML-RPC Pingback issue.

WordPress XML-RPC Pingback DDoS attack

Here is an example attack command using curl -

The YELLOW highlighted data is a WordPress "Patsy Proxy" site while teh ORANGE highlighted data is the target/victim website. It is important to note for testing purposes that you must include the "Content-Type: text/xml" request header data otherwise the XML-RPC service will not treat the request as valid and will issue the following response:

With the previous request sent by the attacker, the Patsy Proxy WordPress site then initiates this HTTP request to the target/victim site -

Notice that the format of the HTTP request is only two lines:

• URI
• Host request header

This intelligence can be used by Web Application Firewalls (WAFs) that are protecting the victim sites to identify attack requests. Normal web browsers send many more request headers. While the pingback DDoS attack doesn't utilize any type of amplification as other more recent network protocol attacks (e.g. NTP), requests can cause more damage on the victim site if the URI is initiating a computationally expensive back-end query or process.

Protections

Disable XML-RPC

It is possible to disable the XML-RPC process altogether if you do not want to use it. There are even plugins that will disable it.

Disable Pingback Reqests

You may also disable the pingback feature by adding the following to your functions.php file:

Identify Initial Pingback Requests

By using a WAF, you can identify inital pingback XML attack requests on your WordPress site. We have added rules to our commercial SpiderLabs ModSecurity rules package to identify this attack.

Identifying Pingback Initiated Requests on the Victim Site

As mentioned previously, even though the construct of the URI line might be dynamic, the fact is that all proxies XML-RPC pingback requests will only have two lines in the HTTP request. WAFs can be used to identify these anomalies and then respond (perhaps by pushing out IP based blocking to infrastructure systems).