The bug comes from adding the following header to a web request like the following
Range: bytes=0-18446744073709551615As you can see, it's just a standard (64-bit) integer overflow, where 18446744073709551615 equals -1.
That specific header is harmless, it appears that other variations are the ones that may cause a problem. However, it serves as a useful check to see if the server is patched. If the server is unpatched, it'll return the following error:
HTTP/1.1 416 Requested Range Not SatisfiableFrom the PoC's say, a response that looks like the following means that it is patched:
The request has an invalid header nameHowever, when I run the scan across the Internet, I'm getting the following sorts of responses from servers claiming to be IIS:
HTTP/1.1 200 OK
HTTP/1.1 206 Partial Content
HTTP/1.1 301 Moved Permanently
HTTP/1.1 302 Object moved
HTTP/1.1 302 Found
HTTP/1.1 302 Redirect
HTTP/1.1 401 Unauthorized
HTTP/1.1 403 Forbidden
HTTP/1.1 404 Object Not Found
HTTP/1.1 416 Requested Range Not Satisfiable
HTTP/1.1 500 URL Rewrite Module Error.
HTTP/1.1 500 Internal Server Error
I suspect the biggest reason is that the "Range" header only is parsed when there is a static file being served. If a script generates the page, then it'll ignore the range. I also suspect that virtual-hosting gets in the way -- that unless the correct DNS name is provided, then it'll reject the request.
Thus, the testing is inconclusive. While I can find some vulnerable responses, just because a server gives me some other response doesn't mean it's not also vulnerable. Thus, I can't really say anything about the extent of the vulnerability.
It's an important message for companies using various tools to see if they are completely patched. Just because the tools can't find vulnerable systems doesn't mean you aren't vulnerable.
It's an important message for companies using various tools to see if they are completely patched. Just because the tools can't find vulnerable systems doesn't mean you aren't vulnerable.
This comment has been removed by the author.
ReplyDeleteHis scans are the least of your worries.
ReplyDeleteAsking whitehat to stop scanning you won't do much to stop blackhats, but we'll happily accommodate your request.
ReplyDeleteThe best way to opt-out is send us an email through the normal 'abuse' process.
Oh come on, your not really exempting ranges are you?
ReplyDeleteIf so can you do, 1-255.0.0.0/8
Can you share your script ?
ReplyDeleteJust as a heads up, besides your scan, we noticed scans from Chinese IP addresses ranging from 171.13.14.3 to 171.13.14.62 . Those individuals scanned one system per source IP, and scanned anywhere from 1 second to 39 minutes between attempts. (One destination IP each attempt, no overlap on source or destination.)
ReplyDeleteSo for those concerned, clearly others on the Internet are scanning for this, some with slightly distributed scanning. (if you want to call a single source /24 as at least slightly distributed)