As many of you may have heard, there is an interesting Java DoS scenario out -
http://www.exploringbinary.com/php-hangs-on-numeric-value-2-2250738585072011e-308/
http://blog.fortify.com/blog/2011/02/08/Double-Trouble
http://blogs.adobe.com/asset/2011/02/year-of-the-snail.html
When I first saw this issue, I quickly tweeted out a modsec rule that would identify if anyone submitted the example payload being shown in many PoC payloads -
SecRule ARGS|REQUEST_HEADERS "@contains 2.2250738585072012e-308" "phase:2,block,msg:'Java Floating Point DoS Attack',tag:'CVE-2010-4476'"
While this provides some protection, it was by no means comprehensive. Here is an updated ModSecurity ruleset. With the use of the ModSecurity Lua API, we (myself and Josh Zlatin/@Jamuse_ of PureHacking) came up with a new Generation 2 detection mechanism similar to what Brian Sullivan (Adobe) presented.
First step is to inspect the ARGS and REQUEST_HEADERS data using a regex to match on potential floating point or non-scientific notation version payloads -
SecRule ARGS|REQUEST_HEADERS "[0-9\.]{12}e[\-\+][0-9]{1,}|[0-9\.]{324}" \"phase:2,t:none,t:lowercase,nolog,pass,exec:/usr/local/apache/conf/modsec_current/base_rules/FloatingPointDoSAttack.lua"
If a payload is found that matches the regex check, ModSecurity will execute an external Lua script. The lua script then extracts out payloads, strips out the "." and then searches for the MagicDoSNumber. If this is found, then a TX variable is exported -
#!/opt/local/bin/luafunction main() local Pattern = "2225073858507201"; -- Get the ModSec collections local Headers = m.getvars("REQUEST_HEADERS"); local Args = m.getvars("ARGS"); for i = 1, #Headers do FilteredPattern,NumChanges=string.gsub(Headers[i].value, "[.]", "") for j in string.gmatch(FilteredPattern, Pattern) do m.setvar("tx.floatingpointdos", Headers[i].name) return ("Potential Floating Point DoS Attack via variable: " ..Headers[i].name .. "."); end end for i = 1, #Args do FilteredPattern,NumChanges=string.gsub(Args[i].value, "[.]", "") for j in string.gmatch(FilteredPattern, Pattern) do m.setvar("tx.floatingpointdos", Args[i].name) return ("Potential Floating Point DoS Attack via variable: " ..Args[i].name .. "."); end end return nil;end
Then we have one follow-up rule that checks if the TX:FLOATINGPOINTDOS variable is set -
SecRule TX:FLOATINGPOINTDOS ".*" "phase:2,t:none,log,block,msg:'Floating Point DoS Payload Found.',logdata:'Location: %{matched_var}',tag:'CVE-2010-4476'"
We have conducted some tests with different payloads and this appears to work pretty well. You can test by using the following curl command (adjust the target URL for your site) -
$ curl -H "Accept-Language: en-us;q=2.2250738585072012e-308" http://localhost/
This should create the following ModSecurity alert -
[Tue Feb 15 12:38:02 2011] [error] [client ::1] ModSecurity: Warning. Pattern match ".*" at TX:floatingpointdos. [file "/usr/local/apache/conf/modsec_current/base_rules/modsecurity_crs_15_customrules.conf"] [line "2"] [msg "Floating Point DoS Payload Found."] [data "Location: REQUEST_HEADERS:Accept-Language"] [tag "CVE-2010-4476"] [hostname "localhost"] [uri "/"] [unique_id "TVq5@sCoqAEAAACvFaYAAAAA"]
If you find any issues please let use know @ModSecurity.
