I am happy to announce the ModSecurity SVM Bypass Charity Challenge. This is a SQL Injection, XSS and Path Traversal Filter Evasion Challenge. Similar to the Trustwave ModSecurity SQLi Challenge, I setup ModSecurity to proxy to the following four commercial vulnerability scanner demo sites:
Often when implementing customised ModSecurity solutions we need to extend the built-in functionality via Lua scripting. One of the disadvantages to this approach is the added latency penalty paid for not using the native rules language. When web site performance is critical for business continuity, every additional millesecond counts. The current trunk code fixes a long-standing limitation where ModSecurity needed to create a new VM for each request, which added latency every time a Lua script was executed.
It's a question that I'm sure many fellow IT people out there have been faced with. Whether you're on ground zero doing systems administration and a server dies or wondering why all of a sudden orders on your website have slumped. It could literally be anything; a faulty device, software crash... maybe you got hacked? How do you know? Worse still, maybe something bad is happening right now and you haven't even realised yet!
Someone asked me about the Hash DoS attack recently disclosed at CCC, so I thought I would give a high level explanation of it here in case it benefits others as well. Hash tables are often used in programming languages to map data keys and values together. A comparable real world example could be a phone book which maps a person's name (the key) to their phone number (the value).
On a recent engagement we gained unrestricted administrative access to a certain proprietary web application by exploiting a Session Fixation flaw. According to the WASC Threat Classification v2, Session Fixation is an attack technique that forces a user's session ID to an explicit value.
One of the more useful features of ModSecurity is it's persistant storage capabilities. ModSecurity uses the SDBM library, which comes with the Apache Portable Runtime (APR). When using ModSecurity collections for anything beyond trivial use, you may quickly hit the arbitrary SDBM library limit of 1008 bytes. That limit is on the combined size of both the key and record length. When you hit the SDMB size limit, you get the following cryptic error message:
Recently a floating point DoS vulnerability surfaced in both PHP and Java. The crux of the problem is that PHP and Java apps go into an infinite loop and hang when trying to process numeric values in the (approximate) range of 2.2250738585072011E-208 to 2.2250738585072013E-208. For more information see here,here and here.
No matter how good a black list is there will always be a way to
their payloads using various characters. Billy Hoffman demonstrated
this very clearly in his book Ajax Security where he shows how to encode
payloads using whitespace and tabs (p.115-116). A better approach,
such as a whitelist, is needed to provide holistic protection for web
Recently we had a client application that allowed file uploads which was flooded with various viruses and malware that were uploaded to the server. The client's WAF requirements were to detect the malware before it hit the back-end server and blacklist the offenders. After all, if the client is uploading malware, you probably don't want to allow them access to the rest of your site either. This is, of course, a double edge sword, as it has the possibility of blocking valid IPs, such as those behind a NATted address. In this case, that was not a concern.
One of the more common complaints I hear about ModSecurity is that it breaks an application's functionality when put in front. While the complaint is mainly directed at the Core Rule Set (CRS) and not the ModSecurity engine, new users probably can't differentiate between the two and have very little documentation available explaining how to properly whitelist rules. This post if aimed at helping users understand the various options available to them when whitelisting CRS rules.