Denial of Service (DoS) exploits are widely available to exploit CVE-2015-1635, a vulnerability in HTTP.sys, affecting Internet Information Server (IIS) . The patch was released on Tuesday (April 14th) as part of Microsoft's Patch Tuesday. Due to the ease with which this vulnerability can be exploited, we recommend that you expedite patching this vulnerability. Update: We are seeing active exploits hitting our honeypots from 78.186.123.180. We will be going to Infocon Yellow as these scans use the DoS version, not the "detection" version of the exploit. The scans appear to be "Internet wide". [We will have a webcast live from SANS 2015 in Orlando at 6pm ET. For details, see https://www.sans.org/webcasts/100152 . If you are attending SANS 2015: Osprey Room 1 at the Swan hotel] Updated Section 6 information regarding Information Disclosure issue. Based on posts on Twitter, 171.13.14.0/24 is also sending the exploit code in "somewhat targeted" scans. Version of the exploit seen used in these scans:
FAQ1 - Which Versions of Windows Are Vulnerable? Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. HTTP.sys is used by any version of IIS running on one of these operating systems. HTTP.sys was introduced with IIS 6. 2 - Will an IPS protect me? Yes. If you have the right rules installed. For example, here is a simple rule for Snort: alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg: " MS15-034 Range Header HTTP.sys Exploit"; content: "|0d 0a|Range: bytes="; nocase; content: "-"; within: 20 ; byte_test: 10,>,1000000000,0,relative,string,dec ; sid: 1001239;) (byte_test is limited to 10 bytes, so I just check if the first 10 bytes are larger then 1000000000) Watch out, there are some tricks to bypass simple rules, like adding whitespace to the Range: header's value. More info here. 3 - Will the exploit work over SSL? Yes. Which may be used to bypass your IDS or other network protections 4 - Have you seen active exploits "in the wild"? Not yet. We have seen working DoS exploits, but have not detected them in our honeypots. Erratasec conducted a (partial) scan of the Internet using a non-DoS exploit with the intend to enumerate vulnerable systems. 5 - How do I know if I am vulnerable? Send the following request to your IIS server: GET / HTTP/1.1 Host: MS15034 Range: bytes=0-18446744073709551615 If the server responds with "Requested Header Range Not Satisfiable", then you may be vulnerable. Test Scripts: (powershell removed as it doesn't support 64 bit intergers... worked without error for me, but something else may have been wrong with it)
6 - Can this vulnerability be exploited to do more then a DoS? In it's advisory, Microsoft considered the vulnerability as a remote code execution vulnerability. But at this point, no exploit has been made public that executed code. Only DoS exploits are available. [Turns out, the file does not have to be > 4GB. Tried it with a short file and it worked. The >4GB information came from a bad interpretation of mine of the chinese article in the "Resources" section] 7 - How to I launch the DoS exploit? In the example PoC above, change the "0-" to "20-". (has to be smaller then the size of the file retrieved, but larger then 0) 8 - What is special about the large number in the PoC exploit? It is 2^64-1. The largest 64 bit number (hex: 0xFFFFFFFFFFFFFFFF) 9 - Any Other Workarounds? In IIS 7, you can disable kernel caching. 10 - Is only IIS vulnerable? Or are other components affected as well? Potentially, anything using HTTP.sys and kernel caching is vulnerable. HTTP.sys is the Windows library used to parse HTTP requests. However, IIS is the most common program exposing HTTP.sys. You may find potentially vulnerable components by typing: netsh http show servicestate (thx to @Gmanfunky) 11 - Will IIS Request Filtering Protect Me? No. IIS Request Filtering happens after the Range header is parsed. References: https://ma.ttias.be/remote-code-execution-via-http-request-in-iis-on-windows/ Thanks to Threatstop for providing an IIS server for testing.
--- |
Johannes 4068 Posts ISC Handler Apr 17th 2015 |
Thread locked Subscribe |
Apr 17th 2015 5 years ago |
"... ISS server". Is that "ISS" or "IIS"? [NOTE: This typo was corrected.]
|
Anonymous |
Quote |
Apr 15th 2015 5 years ago |
FYI, looks like Palo Alto is already blocking the exploit as a threat. Should buy some time to patch in an orderly manner :)
|
n8sec 2 Posts |
Quote |
Apr 15th 2015 5 years ago |
If the POC is converted to use HTTPS, won't the headers be encrypted? Then, unless you decrypt the packets before or as they go thru the Palo Alto device, won't the exploit packets get thru to the target server?
|
Dean 135 Posts |
Quote |
Apr 16th 2015 5 years ago |
Correct, in this case if any protective device is not doing SSL inspection this one will likely be missed.
~Richard |
Richard 168 Posts ISC Handler |
Quote |
Apr 16th 2015 5 years ago |
Are we referring to this as the deRANGEd vulnerability?
|
Anonymous |
Quote |
Apr 16th 2015 5 years ago |
Is there a way to block this on the IIS server itself, using tools such as Request Filtering http://www.iis.net/configreference/system.webserver/security/requestfiltering
My thinking is that this would allow filtering even if you are not inspecting https on the network IPS? On second thought, at this point it is probably too late as request filtering might be through HTTP.sys - it is simply filtering what requests to forward, not which requests HTTP.sys processes?? [Edit to note that this is a question, I can't confirm this myself.] |
dotBATman 64 Posts |
Quote |
Apr 16th 2015 5 years ago |
I found Python SSL Version enabled version of the checker if you guys need it with alterable host headers.
Here... http://www.borderhawk.com/uncategorized/http-sys-ssl-enabled-check-for-vulnerability/ |
dotBATman 1 Posts |
Quote |
Apr 16th 2015 5 years ago |
Traffic for WSman alias "Windows Remote Management" (see <https://msdn.microsoft.com/library/aa384291.aspx>) and PowerShell remoting may reach HTTP.sys too!
|
Anonymous |
Quote |
Apr 16th 2015 5 years ago |
And dont forget SQL Server Reporting Services, SSTP and the MANY other components which use HTTP.sys: check its configuration per
NetSh.exe HTTP Show ServiceState The registered URLs tell which components use HTTP.sys. |
Anonymous |
Quote |
Apr 16th 2015 5 years ago |
Cisco IPS signature S862 includes definitions for this exploit. It is already blocking traffic targeting for our webservers
|
Anonymous |
Quote |
Apr 16th 2015 5 years ago |
Your powershell script is not working since AddRange() method of HTTPWebrequest accept Int64 and number supplied is bigger then Int64 and hence will fail to work. Was this script tested? Firstly it needs [long] to identify it as Int64 and not Int32 and secondly it'll still fail
$httprequest.AddRange('bytes',$inc,[long]18446744073709551615) Cannot convert value "18446744073709551615" to type "System.Int64". Error: "Value was either too large or too small for an Int64." |
GregorySuvalian 9 Posts |
Quote |
Apr 16th 2015 5 years ago |
Saw activity from the 171.13.14.0/24 range last night into this morning, but using the test version only.
GET / HTTP/1.1 Host: stuff Range: bytes=0-18446744073709551615 |
JeffSoh 31 Posts |
Quote |
Apr 16th 2015 5 years ago |
I got this confirmed via Twitter resources, Request Filtering happens "too late".
And I agree, MS would have had this listed as workaround if it was that easy.. :) |
dotBATman 64 Posts |
Quote |
Apr 16th 2015 5 years ago |
When i run the powershell cmd in ISE i get the below error any help?
powershell : Cannot convert argument "to", with value: "18446744073709551615", for "AddRange" to type "System.Int32": "Cannot convert value "18446744073709551615" to type "System.Int32". Error: "Value was either too large or too small for an Int32."" |
dotBATman 1 Posts |
Quote |
Apr 16th 2015 5 years ago |
Curl test worked for me, but the powershell test has an error
PS C:\> $wr=[Net.WebRequest]::Create( 'http://[ip address]/iisstart.htm') PS C:\> $wr.AddRange('bytes' ,0,18446744073709551615) Cannot convert argument "to", with value: "18446744073709551615", for "AddRange" to type "System.Int32": "Cannot convert value "18446744073709551615" to type "System.Int32". Error: "Value was either too large or too small for an Int32."" At line:1 char:1 + $wr.AddRange('bytes' ,0,18446744073709551615) + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [], MethodException + FullyQualifiedErrorId : MethodArgumentConversionInvalidCastArgument PS C:\> |
John 88 Posts |
Quote |
Apr 16th 2015 5 years ago |
yes, powershell script is wrong. It's impossible to do that since AddRange accepts Int64 at most and this value is bigger then Int64
|
GregorySuvalian 9 Posts |
Quote |
Apr 16th 2015 5 years ago |
There is some serious issue going on with Int64 max value and values specified in this bulletin. Max Int64 value in .NET is 0x7FFFFFFFFFFFFFFF and that's what AddRange accepts. Unsigned Int64 on the other hand will be 0xFFFFFFFFFFFFFFFF which AddRange will not accept
So all .NET code implementations will either have to use Raw Sockets or override AddRange method using Reflection and Protected method |
GregorySuvalian 9 Posts |
Quote |
Apr 16th 2015 5 years ago |
What do I look for in the output of the curl script to prove that I am NOT affected by this?
|
PW 63 Posts |
Quote |
Apr 16th 2015 5 years ago |
So can someone correct me if I'm wrong, being a Windows admin and a pretty fair powershell programmer. If powershell uses winrm to remote manage over http and https, and running the following on a server without iis installed
netsh http show servicestate |Select-String "://" |ForEach-Object {if($_ -ne ""){([string]$_).trim()}} HTTP://+:5985/WSMAN/ HTTP://+:47001/WSMAN/ returns a result, that appears to me as though ANY windows server has this potential vuln regardless of IIS or no. Is that a fair statement? |
JeffPatton 2 Posts |
Quote |
Apr 16th 2015 5 years ago |
Yes, all those affected. HTTP moved in kernel and now activation happened by WAS which means bunch of stuff can use HTTP now and not only IIS
Bulletin has ways to test it below netsh http show servicestate |
GregorySuvalian 9 Posts |
Quote |
Apr 16th 2015 5 years ago |
Sign Up for Free or Log In to start participating in the conversation!