Kona Site Defender is our flagship Web Application Firewall and DDoS Mitigation solution at Akamai. Back in the days of the Al-Qassam Cyber Fighters, Brobot ("It's not OK, bro"), and the "holy 100 Gbps attack!", we had a saying around Akamai: "Kona Site Defender customers come for the DDoS, but they stay for the WAF". The general idea was that it took a headline-grabbing DDoS attack to make customers and prospects aware that Akamai had a security offering. That was the end of 2012 and the beginning of 2013. In those days, analysts told us and our prospects that we had WAF customers *only* because we were good at mitigating DDoS attacks. We were only mildly offended, and we toiled on. Our work seems to have paid off: In 2017, cloud-based WAFs are more or less an industry standard, Kona is a perennial fixture in the Gartner WAF Magic Quadrant and analysts tell us that "Kona is on the short list of all Security buyers".
Get In Touch
Recently in Web Security Category
On Monday, March 6th, the Apache team patched a vulnerability in Apache Struts2 framework. Apache Struts is an open-source web application framework for developing Java web applications. The vulnerability exists in the Jakarta Multipart parser, which can be tricked into executing attacker-provided OGNL code. The impacted versions are 2.3.5 through 2.3.31, and 2.5 through 2.5.10 of the Apache Struts framework. If you are currently running an affected version of the software, malicious users could execute code on the system remotely by using a maliciously crafted Content-Type header. Successful exploitation does not require the user to be authenticated. Apache has classified the vulnerability as a "possible remote code execution"; however, the vulnerability is easy to exploit and allows code to be executed using the user context of the account running the Tomcat server. At least two working exploits have been seen in the wild already.
On Monday, February 27, 2017, security researcher Omer Gil published a blog post laying out a data exfiltration method called a "Web Cache Deception Attack." The attack leverages web caching functionality to potentially expose sensitive information or allow for account takeover (ATO) attacks. Caching is often used to reduce load and time-to-delivery for a web server receiving requests for content, but this attack shows ways in which, given certain web configurations, the caching feature can be misused to serve content not intended for caching. Both the caching proxy and the origin site can have individually valid configurations, but in concert lead to unexpected behavior in light of this new attack method. This attack affects all forms of web caching and is not limited to proxies or Content Delivery Networks (CDNs). Akamai is actively working with customers to identify configurations which may be affected and assist them in protecting their sites against this attack.
On February 23, 2017, Cloudflare released information on a bug that was disclosed by Google security researcher, Tavis Ormandy, in their content delivery network. The bug potentially exposed sensitive customer data to the Internet. Approximately 1 in every 3,300,000 HTTP requests may have contained potentially sensitive information. This information would normally be stored and cached by users and search engines as part of normal website sessions. This bug is similar to Heartbleed, in that uninitialized memory was accidentally being sent along with regular data. Unlike Heartbleed, which required malicious requests, this bug was in Cloudflare's HTML parser code, which means that sensitive data could be sent as part of normal client requests.
Over the last two years, Akamai has seen an increase in the number of customers who wish to run their own review of Akamai, either to satisfy their own information security or risk management program, or to gain the expertise to explain Akamai to their regulators and consumers. This increase is due to a confluence of factors, from Akamai's increased global sales presence, to heightened regulation of certain verticals by governments and other organizations. We expect to see demand for custom assessments continue to grow in 2017 and beyond, and we expect the breadth and depth of questions from customers to increase as well.
The other half asks "May I please have some more (application security)."
Another lifetime ago, way back in 2014, I wrote that "updating WAF rules is like flossing, everybody knows they should be doing it but it can be an easy step to forget and difficult to find the time to do it." At the time my conclusion was something along the lines of "so if you don't have time to do it, you should pay someone to do it for you". In hindsight that conclusion was flawed for two reasons: First my analogy at that point got a little bit weird - who in their right mind would let someone else floss their teeth for them? By the same token, what if you don't trust a 3rd party to update your rules for you? Some security professionals, quite rightfully, probably take better care of their apps than they take care of their own teeth, and they are perfectly able, thank you very much, of taking care of their apps and their WAF rules themselves. Some of the larger eCommerce companies and banks, for instance, have teams of 4, 5 or even 6 full time employees studying WAF rules, tuning configurations, and generally making sure that the bad guys are kept out while the good guys get through to their websites unmolested. Second, even if you are comfortable with someone else flossing your teeth or updating your rules, what if you can't afford to pay someone else to do it for you?
On Tuesday, February 1, 2017, security vendor Sucuri disclosed a severe vulnerability in the WordPress REST API in versions prior to 4.7.2. The vulnerability allows for remote, unauthenticated and easily automated modification of blog post and page content by manipulating a parameter payload. Sucuri, Inc. notified Akamai of this vulnerability in advance of the public disclosure, which allowed the Threat Research team to internally confirm exploitability and to develop a new rule for Kona Site Defender designed to protect customers from this vulnerability. It's important to understand the new Wordpress REST API before we discuss the technical details of the vulnerability.
Many customers ask Akamai about Disaster Recovery testing and Business Continuity planning as a part of their due diligence or risk management process. Customers expect to see a governance document maintained by a central authority, a list of systems with Recovery Point Objectives (RPO), Recovery Time Objectives (RTO), and a documented testing plan that is enacted quarterly or annually. Akamai reframes these questions to better match our approach to continuity and recovery, all of which we include under the umbrella of "resilience."
Have you ever tried to login to your favorite website and mistakenly typed the wrong user name and password once, or even twice? I bet you have. And what about submitting a third consecutive false attempt? In most cases, at that point a secure website will start questioning the integrity of your actions.
From a defense point of view, websites should suspend and limit false login attempts to confirm authenticity once abnormal usage is detected.
On December 29th, the United States Computer Emergency Readiness Team (US-CERT), in coordination with the FBI, released a document outlining recent attacks against US interests that have been attributed to the Russian government. To be clear, Akamai does not comment on the attribution of attacks. Rather we would like to inform our customers of what a reasonable, informed course of action should be regarding this new information.