Results 1 to 5 of 5

Thread: IIS vulnerability in SYSTEM impersonation token...

  1. #1
    Senior Member
    Join Date
    Aug 2002
    Posts
    651

    IIS vulnerability in SYSTEM impersonation token...

    This one is hot off the press (m$ list) for today. Those of you that don't subscribe (mainly for newbies, I guess) should definitely take a look at some of them. You can subscribe fromt he Security Focus website . You'll find tons of helpful updates and advice for all flavors of security.
    *** A3 Security Consulting: CR@K Vulnerability Research ***


    Title : MS IIS out of process privilege elevation
    vulnerability(A3CR@K-Vul-2002-06-002)
    Reporter : li0n (li0n@a3sc.co.kr)
    Affected software : IIS 4.0, 5.0, 5.1
    Risk : High
    Local/Remote : Local
    Category : Windows - IIS - Privilege elevation
    Date : June, 25, 2002

    Advisory URL : http://www.li0n.pe.kr/eng/advisory/m...ersonation.txt



    [1] Summary

    An impersonation vulnerability of dllhost.exe allows a local user to gain the SYSTEM privilege.

    This vulnerability arises from the fact that the process of dllhost.exe harbors an impersonation token of SYSTEM account while processing user's request. Because a process of dllhost.exe is executed with IWAM_machinename privilege, an attacker can manipulate the process's memory space and steal the SYSTEM privilege when the process has the impersonation token of SYSTEM account. In other words, an attacker can execute arbitrary codes with SYSTEM privilege through this impersonation.



    [2] Affected software

    Internet Information Services 4.0
    Internet Information Services 5.0
    Internet Information Services 5.1



    [3] Patch

    http://www.microsoft.com/technet/tre...n/MS02-062.asp



    [4] Testing environments

    Microsoft Windows 2000 advanced server with
    Service pack2
    Security rollup1
    Cumulative Patch for Internet Information Services (Q319733)



    [5] Required Knowledge

    Architecture of Microsoft IIS
    Impersonation



    [6] Technical Details

    Microsoft IIS provides two protection modes, in-process mode and out-of-process mode. If IIS is set to in-process mode, .asp request and ISAPI dlls are executed within inetinfo.exe process that is running with SYSTEM privilege. So, an attacker can obtain SYSTEM privilege easily with some effort to control the process to serve his purpose.

    On the other hand, if IIS is set to out-of-process mode, .asp request and ISAPI dlls are executed within dllhost.exe process which is running with IWAM_machinename account. In this case, an attacker can only obtain IWAM_machinename account even if he or she is successful with the attack. For reference, the default setting for IIS4 is in-process and the default setting for IIS5 is out-of-process.

    dllhost.exe process calls ole32!CoImpersonateClient function to process user's request. If CoImpersonateClient function returns successfully, the process becomes to harbor an impersonation token of SYSTEM account for a moment. Later on, dllhost.exe process finishes up its impersonated SYSTEM privilege by calling RevertToSelf function to destroy SYSTEM privilege and returns to IWAM_machinename privilege.

    Because a process of dllhost.exe is executed with IWAM_machinename privilege, an attacker can manipulate the process's memory space and steal the SYSTEM privilege when the process has the impersonation token of SYSTEM account.

    For an example, an attacker can make dllhost.exe process call MyCoImpersonateClient function instead of ole32!CoImpersonateClient function using API hooking technique. An attacker can forge a MyCoImpersonateClient function and he or she can execute malicious code using SYSTEM privilege.

    Another method to execute malicious code is to attach the dllhost.exe process to a debugger and modify dllhost.exe process's memory contents.

    An attacker can create and assign an arbitrary account to the local administrator group exploiting this vulnerability and execute programs with administrator privilege.



    [7] Exploit Code

    Not included in this advisory on purpose



    [8] Informations

    ** Vendor status **
    Patch Released (MS02-062)


    ** Credit **
    Discovery and exploitation Research : li0n@a3sc.co.kr
    Advisor : CR@K TEAM


    ** Copyright (c) 1999-2002 A3 Security Consulting ** Permission is hereby granted for the redistribution of this alertelectronically. It is not to be edited in any way without express consent of A3 Security Consulting. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail li0n@a3sc.co.kr for permission.


    ** Disclaimer **
    The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author or an entity where he belongs be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.


    ** Feedback **
    Please send suggestions, updates, and comments to:

    A3 Security Consulting Co., Ltd.
    http://www.a3sc.co.kr/
    Official : li0n@a3sc.co.kr , Private : li0n@li0n.pe.kr
    Opinions are like holes - everybody\'s got\'em.

    Smile

  2. #2
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    It's not clear exactly what this vulerability allows people to do ...

    I assume because it says "Local/Remote : Local", it allows local users to gain SYSTEM privileges.

    This is actually not too serious because of the huge number of already documented ways of gaining localsystem rights in WinNT/2k

    Plus also, it's very usual to give untrusted users local access accounts on web server boxes.

  3. #3
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    SYSTEM account is equally (sometimes MORE) powerfull than the administrator account so while their might be many other ways to gain localsystem rights, a serious admin that keeps up with patches and has fixed the "other ways" already will want to know about this one! Besides, even if you have untrested user accounts on the box (which should be pretty much limited to web services), you don't want them getting "rooting" the box...

    Ammo
    Credit travels up, blame travels down -- The Boss

  4. #4
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    Sorry - typo in my previous post

    it's very usual to give untrusted users local access accounts on web server boxes.
    should read:

    It's very unusual to give untrusted users local access accounts on web server boxes.

    In order to exploit this bug, you need to be able to run arbritary code locally as an unprivileged user, then apparently you can gain localsystem access. This is something which you should never allow untrusted people to do on a web server

    Sorry for the confusion.

  5. #5
    Senior Member
    Join Date
    Aug 2002
    Posts
    651
    It would be great if we could just assume that companies follow that sort of policy - "unusual to give untrusted users local access accounts..."; however, you and I both know that people don't follow the "cardinal" rules. If they did, many of us would be without a job, and hackers would have a little bit more trouble hacking into systems based on mistakes made by Admins. If only...
    Opinions are like holes - everybody\'s got\'em.

    Smile

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •