Security dog: http. Sys remote code execution vulnerability Analysis (ms15-034)

"Safety Dog Safety Research team"

Written in preface:

On security Patch Day April 2015, Microsoft released 11 security updates that were fixed to include Microsoft Windows, Internet Explorer, Office,. NET Framework, Server software, office 26 security vulnerabilities in services and Web apps. This fixes a remote code execution vulnerability in HTTP. SYS, which is numbered: cve-2015-1635 (ms15-034). Currently the server security dog has updated the security patch, it is recommended to fix the security dog prompt to you the vulnerability information, so as to avoid the exploit attack.

allegedly, the usehttp. SYS Securityvulnerability, an attacker would only need to send a malicious HTTP request packet, which could remotely read the IIS server's memory data or cause the server System blue screen to crash.

According to the Bulletin, the vulnerability has a significant impact on the server system, primarily affecting Windows 7, Windows Server R2, Windows 8, Windows Server 2012, Windows 8.1, and Major server operating systems, including Windows server R2.

Safety Dog Safety Research team of small partners in the knowledge of this loophole, but also to the deep excavation research, the following will be the relevant information to share the results. If there are any ideas, and further use of the operation, also welcome to discuss the advice.

1. First binary comparison of patch files

The following are changes to HTTP. sys before and after Windows 7 repair.

The notable experience is that each function name has a ' range '. This reminds me of the previous Apache HTTPd ' Range ' header Vulnerability (see Chapter RFC2616, section 14.35).

It is no doubt that the vulnerability data is brought into the ' range ' header. The next thing to do is to delve deeper into the causes of their production. such as the http! that Ida automatically analyzes The call graph for the Ulpparserange function looks like this:

Here I used VMware to build a unpatched windows 7 SP1 as a test target, and enabled the kernel debugger to set breakpoints on all key functions and collect critical data and kernel information.

After the breakpoint is triggered, the stack information is printed out and the program continues to execute. We used the previous Apache Rangedos test sample against the target server for an offensive test, and the debugger captured the following information:

The standard Apache Rangedos script does produce an effect, so let's take a closer look at http! The implementation of the Ulpparserange function:

In debugging the old code, it was found that the function called a large integer here.

And the new version of the code calls the http! Rtlulonglongadd to check if there is an integer overflow. Note that the function in this HTTP. SYS calls 5 parameters instead of 3 parameters. Repeating the previous test script, you will find that the error code returned by the system is 0xc000000d (Status_invalid_parameter) and is no longer status_integer_overflow.

A simple POC test script after the fix is as follows (this script is only used to parse the parsing process within the Proof module for the range header parameter).

Next, let's break down the breakpoint on the unpatched module.

It's very obvious. EAX is 0x7a69 (range upper limit 31337 set in the POC), EDI is 0x539 (the range lower limit set in the POC is 1337). In the old code, if our lower limit is 0, the upper limit does not change so. When the upper limit is very large (integer threshold), we add 1 and an integer overflow occurs. The output of the hexrays is more clear:

* (_qword *) v18 = __pair__ (v22, v23) –__pair__ (v21, V20) + 1. Let's try it.

At this point you can see that the upper limit is already very large (0xFFFFFFFF). The code then executes.

We can see this EAX is predictably small now. Now, we have some indication of the Pre-patch block are doing, let's look at the patch again.

Finally, the overflow becomes 0 after adding 1. eax. Let's take a look at the patch module:

Using the same technique, we get a different error message. Interestingly, this error message can be generated in many cases (such as node depth issues, etc.). But our main goal is to decide whether to patch, so this is nothing serious. Now let's go back to whether the system is pre-contracted for patching.

One way to get the unpatched module to return the Status_invalid_parameter error message is to verify that the key of the code below fails.

dynamically changing jump conditions using the debugger , we can have the server return the following interesting page (manual memory Patch succeeded):

After the patch, when you submit an HTTP packet containing an illegal range header field, the system will report the error above.

if it's not patched , What you see is the following:

This is the key to judging whether or not to hit the patch.

Patched: http! Rtlulonglongadd returns a status_invalid_parameter error when encountering an illegal range header, and then http! Ulpparserang generates a "Invalid Header" error message to the client.

Patched: http! Ulpparserange returns 0 and then produces a "requested Range not satisfiable". Error message to the client.

2. Vulnerability Test Script:

2. #sutff. py
   

4. Import socket
   

6. Import Random
   

8. 
   

10. ipaddr = "Fill in the detection IP address here"
    

12. HEXALLFFFF = "18446744073709551615"
    

14. 
    

16. req1 = "get/http/1.0\r\n\r\n"
    

18. req = "get/http/1.1\r\nhost:stuff\r\nrange:bytes=0-" + hexallffff + "\r\n\r\n"
    

20. 
    

22. Print "[*] Audit Started"
    

24. Client_socket = Socket.socket (socket.af_inet, socket. SOCK_STREAM)
    

26. Client_socket.connect ((ipaddr, 80))
    

28. Client_socket.send (REQ1)
    

30. BORINGRESP = CLIENT_SOCKET.RECV (1024)
    

32. If "Microsoft" not in Boringresp:
    

34. Print "[*] Not IIS"
    

36. Exit (0)
    

38. Client_socket.close ()
    

40. Client_socket = Socket.socket (socket.af_inet, socket. SOCK_STREAM)
    

42. Client_socket.connect ((ipaddr, 80))
    

44. Client_socket.send (req)
    

46. GOODRESP = CLIENT_SOCKET.RECV (1024)
    

48. If ' requested Range not satisfiable ' in Goodresp:
    

50. Print "[!] Looks Vuln "
    

52. Elif "The request has a invalid header name" in Goodresp:
    

54. Print "[*] Looks patched"
    

56. Else
    

58. Print "[*] unexpected response, cannot discern patch status"

A simple method of detection:

Curl http://xxx.com/-H "host:irrelevant"-H "range:bytes=0-18446744073709551615" |grep "Range is not satisfiable"

A discovery that returns "range is not satisfiable" indicates a vulnerability.

3. Repair method

(1) Download and install the latest version of the server security dog

Select Server Optimization--system bug fix--fix the vulnerability.

(2) Turn on the website Security Dog real-time protection function, real-time Protection Server website security

Security Dog: www.safedog.cn

Microsoft reports:

https://technet.microsoft.com/en-us/library/security/MS15-034

Related connections

http://blog.beyondtrust.com/the-delicate-art-of-remote-checks-a-glance-into-ms15-034

Security dog: http. Sys remote code execution vulnerability Analysis (ms15-034)