Working on a WAF solution for the Nginx ecosystem provides a lot of opportunities for discussion, given that such work is a meeting of crossroads. Mixing high-performance engineering, WAF technologies, ModSecurity DSL, and the OpenResty community puts lua-resty-waf in a unique context. I often get asked about other WAF solutions for Nginx, including Naxsi, and how these solutions compare to ModSecurity, lua-resty-waf (and other security OpenResty libs), and commercial solutions. I haven’t spent a lot of time working with the Naxsi project, but I’ve poked at it enough to at least start putting some thoughts on paper.
security
(Re)Introducing lua-resty-waf
I’ve spent a good chunk of the last three months hacking away at ModSecurity compatibility with FreeWAF, and thanks to some employer sponsorship and noise from the community, there is enough feature-completeness and stability that it’s ready to sit as the latest tagged release. The project also wears a shiny new name tag: lua-resty-waf.
Mod_Security JSON Audit Logs, Revisited
Last year I took a look at generating Mod_Security audit logs as JSON data, rather than the module’s native format (which is… err… difficult to parse). My initial approach was incomplete, needlessly introduced additional dependencies, and leaked like a sieve; I ended up abandoning this to work on FreeWAF. Some new use uses came up that would benefit from more structured Mod_Security audit logs, so I’ve revamped a patch to emit JSON data using a more sane approach.
FL3R User Agent Comments – Unauthenticated Injection into Posts and Dashboard
The plugin FL3R User Agent Comments is vulnerable to a stored XSS attack that allows for arbitrary Javascript execution in the context of the admin dashboard, as well as injection into any page which displays comments.
FreeWAF Updates and New Features
January tends to be a pretty quiet month in the admin/operations world. Most people are still coming back from holiday, new yearly plans are being made, meetings are held, and the server monkeys… sit and watch the graphs scroll by. The rest of the world’s gradual return to work means the start of a seasonal upswing, but we’re still in a relatively low point, so that generally means a light workload. That extra free time has given me a chance to put in a good chunk of work towards FreeWAF, cleaning up code, adding new features, and interacting with a total stranger (score!). I’ve just tagged a new release, v0.4, which provides a handful of new features that were sorely missing:
Fancybox for WordPress – Zero Day and Broken Patch
A malicious iframe has been making its rounds due to a broken non-existent security check in the admin section of the Fancybox for WordPress plugin. Samples of affected sites indicate the vulnerability is being used to initiate a drive-by download targeting MSIE browsers (potentially targeting a recently-announced unpatched IE exploit?). The plugin exploit vector results from poor handling of unauthenticated requests to the plugin’s admin options page (taken from fancybox.php):
Fake Googlebot WordPress Login Bruteforce
… sigh.
A few hours ago we started seeing an interesting trend. A highly distributed set of clients is attempting to authenticate to WordPress sites using a very distinct pattern. Captures and initial analysis below.
Graveyard Tarpittin’
One of the advantages of having a rotating graveyard schedule (two weeks of 10 PM shifts, followed by two months of normal living) is that quiet nights allow for copious amounts of time to muck around on the Internet. One topic that’s piqued my interest over the last few days is tarpitting. Purposefully delaying responses seems a little more interesting than strictly rate limiting; it’s a little more of a retaliatory attitude, without causing any damage at the other end of the connection. Most of the writing I’ve found related to the idea is focused on lower-layer implementation (e.g. the TARPIT iptables module) or SMTP, so I decided to roll my own for HTTP services.
FreeWAF: A High-Performance, Scalable, Open Web Firewall
I’ve spent the better part of the last six months reworking the project I wrote for my Master’s thesis. The idea behind the project was to explore the costs, risks and requirements associated with developing a cloud WAF infrastructure, similar to what commercial cloud security providers like Cloudflare and Incapsula provide- and then provide that service free of charge. Totally unsustainable, of course, but as an academic exercise it was an incredibly educating experience. I’ve since decided to focus on releasing the source of the firewall engine powering the service, continuing to develop features and exploring new methods of anomalous and malicious behavior detection.
Bypassing CloudFlare’s Layer 7 DDoS Protection
Volumetric layer 7 (HTTP) DDoS typically relies on overwhelming the target by inundating the target with a large number of (pseudo) legitimate HTTP requests, the end goal being resource starvation (typically, CPU cycles or available bandwidth, e.g. NIC saturation). Because layer 7 attacks require a full three-way handshake, spoofing source information is impossible (though using a proxy is a viable alternative- remember the XMLRPC issues earlier this year?); as such, the ability to control a large number of attacking machines becomes critical as the size of the target increases. Of course, other forms of HTTP DoS exist outside of volumetric resource starvation (such as Slowloris), but I wanted to take a look at common methods of defending (and circumventing said defenses) against resource starvation attacks via HTTP. This will also serve to demonstrate the weakness in deploying WAFs that rely exclusively on signature-based matching.