RE: priviledge escalation techniques

From: Roy Stapleton (roy_at_stapleton.biz)
Date: 01/23/05

  • Next message: BSK: "RE: priviledge escalation techniques" 
    Date: Sun, 23 Jan 2005 18:06:55 -0000
To: "Thor" <thor@hammerofgod.com>, "Eyal Udassin" <eyal@swiftcoders.com>, <pen-test@securityfocus.com>, "Dan Rogers" <pentestguy@gmail.com>

    On the subject of the registry and programs that run as system, we
    should focus on the executables that reside in the

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services...

    Even though the user has no permission to change the entries here, the
    executables listed definitely run under system privileges or with the
    account specified. These executables should be the target for
    replacement or misdirection. Whilst searching this subtree for *.exe
    files I noticed that some explicit paths were listed using environmental
    variables. i.e. %systemroot%\system32\servicename.exe.

    This begs the question, does the user have the privilege to stop and
    start services? And can the user change the contents of these
    environmental variables?

    I can't test right now, but it will be fun tomorrow back at work testing
    these in our lab.

    I will also test the contents of the run key, but I also believe that
    the contents of both HKLM and HKCU will run under the users credentials.

    2 reasons, open a task manager and compare the user name running the
    processes with the entries in the run key. Note the credentials of the
    explorer.exe process.

    [Insert your favourite comment about editing the registry here, as I
    will not be held responsible if you get it wrong or can't recover]

    Add HKCU\Software\Microsoft\Windows NT\Current Version\winlogon\Shell as
    a string with cmd.exe as the contents, when you log on the only ui you
    are presented with is a command prompt. Again open the task manager and
    compare credentials, but also note that explorer.exe and the entries
    listed in the run keys of both HKLM and HKCU are not running.

    Have fun

    Roy

    -----Original Message-----
    From: Thor [mailto:thor@hammerofgod.com]
    Sent: 23 January 2005 17:01
    To: Eyal Udassin; pen-test@securityfocus.com
    Cc: Roy Stapleton
    Subject: Re: priviledge escalation techniques

    Hi Eyal-

    I understood the idea of replacing the executables -- I was just
    pointing
    out that entries in
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run don't
    specify SYSTEM-only programs/services launched at system startup- they
    also
    contain programs launched at *user* logon, even though the main hive is
    HKLM. HKCU's RUN key also specifies progs to launch at logon.

    On my system (XP2), most of my startup executables are in my HKLM hive,
    not
    KHCU, and they all run under my user account. The RUN keys are for user

    logon, even though they can be located in different hives/keys.

    This from MSDN:
    "Run and RunOnce keys are run each time a new user logs in. RunServices
    and
    RunServicesOnce are run in the background when the logon dialog box
    first
    appears or at this stage of the boot process if there is no logon. These

    keys are for background services such as remote registry service and are
    run
    only once per boot. The Setup key is run only by Setup's first-boot
    activities, or after you use the Add/Remove Programs Wizard. This key
    displays the progress dialog box as the keys are run one at a time. For
    the
    Setup key, the name of the value is the name that is displayed in the
    dialog
    box."

    These articles cover that in more detail:

    http://support.microsoft.com/?kbid=314866

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/setupap
    i/setup/run_and_runonce_registry_keys.asp

    You can also test it with WHOAMI...

    Thanks!

    T

    ----- Original Message -----
    From: "Eyal Udassin" <eyal@swiftcoders.com>
    To: "'Thor'" <thor@hammerofgod.com>; <pen-test@securityfocus.com>
    Cc: "'Roy Stapleton'" <roy@stapleton.biz>
    Sent: Saturday, January 22, 2005 10:58 PM
    Subject: RE: priviledge escalation techniques

    Hi Thor,

    I think you misunderstood my post...
    It is true that only an admin can add entries to the LM->...->Run, what
    I
    suggested is not to tamper with the registry, rather to replace one of
    the
    executables already listed there.

    All entries under the LOCAL_MACHINE's run key are executed without a
    logged
    in user (ex. services). Your last comment is valid to the CURRENT_USER
    branch, which is executed as the logged in user.

    Sorry if my previous post was unclear.

    Regards,

    Eyal Udassin - Swift Coders
    POB 1596 Ramat Hasharon, 47114
    972+547-684989
    eyal@swiftcoders.com - www.swiftcoders.com

    -----Original Message-----
    From: Thor [mailto:thor@hammerofgod.com]
    Sent: Sunday, January 23, 2005 1:25 AM
    To: pen-test@securityfocus.com
    Cc: Eyal Udassin; 'Roy Stapleton'
    Subject: Re: priviledge escalation techniques

    This is inaccurate. SYSTEM credentials for executables in the Run key
    would

    require administrative permissions at install. That is, for any current
    version of Windows.

    Every single executable (XP Pro SP2) in my RUN hive runs under the
    credentials of my user account which is, of course, a normal user.

    T

    ----- Original Message -----
    From: "Eyal Udassin" <eyal@swiftcoders.com>
    To: "'Roy Stapleton'" <roy@stapleton.biz>; <pen-test@securityfocus.com>
    Sent: Saturday, January 22, 2005 12:20 AM
    Subject: RE: priviledge escalation techniques

    Hi,

    The easiest way to perform privilege escalation on windows, whatever
    version, is to list the executables in the
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
    registry
    key. All of these executables are run under SYSTEM.

    Once you get hold of that list, see if you have write permissions to
    replace
    the original executable with your own. Don't forget to execute the
    original
    from your code, or otherwise you may cause the system to become
    unstable.

    I had a client which had such a key pointing to an old printer
    installation
    utility which no longer existed, in an unprotected directory outside of
    "program files". That was the beginning of the end of the pentest :-)

    If all the files can't be overridden, try to boot with command line only
    and
    replace them. Another approach is to remove the hard drive and perform
    the
    switch on another computer, with the victim HD as a secondary drive.

    Eyal Udassin - Swift Coders
    POB 1596 Ramat Hasharon, 47114
    972+547-684989
    eyal@swiftcoders.com - www.swiftcoders.com

    -----Original Message-----
    From: Roy Stapleton [mailto:roy@stapleton.biz]
    Sent: Friday, January 21, 2005 2:47 AM
    To: pen-test@securityfocus.com
    Subject: RE: priviledge escalation techniques

    I have tried the sethc.exe one, the 'at' command scheduler technique and
    the
    'c:\program' technique.

    The OS I used was windows XP pro sp2. I logged in as a domain user with
    no
    added rights, i.e. only local user access to the machine.

    There is no write access in the c:\ or c:\windows\system32 folder, so
    the
    sethc.exe technique fell at this hurdle, default rights on these folders
    are
    users: read & execute and list (this folder, subfolders and files),
    create
    folders (this folder and subfolders), create files (subfolders only).

    For the same reasons, the c:\program exploit failed as well.

    The domain user does not have the privilege to create schedules with the
    at
    command, so this failed as well.

    The problem seen below does exist on XP. It may be (pardon the
    fuzziness
    here) to do with caching load images of executable files and prefetch
    stores. If you look in the C:\WINDOWS\Prefetch directory you will see
    all
    the recently loaded executable files stored in a prefetch format.

    This may be why the original loaded when BSK tried the sethc.exe
    technique
    in BSK's email.

    For the below, I checked these on a machine I had local admin access on.

    XP also watches files in the system32 directory. If you browse there
    and
    rename the sethc.exe to something else and then refresh the screen, you
    will
    see XP restore the sethc.exe file after a few seconds.

    If you open a dos prompt and (make a backup of the sethc.exe file
    warning
    here) copy cmd.exe to sethc.exe, answering that yes, you do want to
    overwrite the original, you will see the new sethc.exe in an explorer
    window
    with a cmd.exe icon. Now, if you delete that, windows will restore
    sethc.exe but with a cmd.exe icon (note the file sizes). When done this
    way, pressing shift 5 times will indeed open a cmd prompt.

    This subject does interest me greatly, if you know of any techniques
    that
    will escalate privileges on an XP machine I would like to know them.

    Thanks

    Roy

    -----Original Message-----
    From: BSK [mailto:bishan4u@yahoo.co.uk]
    Sent: 20 January 2005 11:13
    To: miguel.dilaj@pharma.novartis.com; pen-test@securityfocus.com
    Subject: Re: priviledge escalation techniques

    > That's really strange. It works in WinXP.
    > Perhaps there was a change in functionality (for
    > bad!) from Win2K to XP?
    > The only possibility I can imagine is either:
    > a) something blocks launching interactive programs
    > before logon in 2K, but
    > not in XP
    > b) 2K is checking that sethc.exe is valid before
    > launching it, and XP is
    > not doing that check (I don't really think that this
    > is the case, but...)
    >
    > Do you have any XP box to test?? I'll try to get
    > hold of a 2K as well.

    I couldn't try on a XP box, but tried on a windows
    2000 server. It behaves very differently here, after
    the replacement of sethc.exe with cmd.exe:
    1. before logging in, pressing 'shift' 5 times,
    invokes sethc.exe but the original one, which in fact
    doesn't exist in system32 directory, atleast with same
    name. I think windows regenerated that file but with
    some other name.
    2. if I press 'shift' 5 times after logging in,
    nothing appears, neither original sethc.exe nor the
    replaced sethc.exe

    Any clues?

    ___________________________________________________________
    ALL-NEW Yahoo! Messenger - all new features - even more fun!
    http://uk.messenger.yahoo.com

  • Next message: BSK: "RE: priviledge escalation techniques"

    Relevant Pages

    • RE: priviledge escalation techniques
      ... executables already listed there. ... Subject: priviledge escalation techniques ... The easiest way to perform privilege escalation on windows, ... read & execute and list (this folder, subfolders and files), create ...
      (Pen-Test)
    • Re: priviledge escalation techniques
      ... SYSTEM credentials for executables in the Run key would ... Subject: priviledge escalation techniques ... The easiest way to perform privilege escalation on windows, ... read & execute and list (this folder, subfolders and files), create ...
      (Pen-Test)
    • Re: svcnxp32.exe, Part 2
      ... > There are a few more posts on this, Frank. ... >> registry, both of which were promptly deleted. ... Windows Update site, the version of wuauclt.exe that seemed to be ... svcnxp32.exe and svcnv32.exe reappeared, but not the executables. ...
      (microsoft.public.windowsupdate)
    • Re: priviledge escalation techniques
      ... On my system, most of my startup executables are in my HKLM hive, not ... Subject: priviledge escalation techniques ... The easiest way to perform privilege escalation on windows, ... > a) something blocks launching interactive programs ...
      (Pen-Test)
    • Re: priviledge escalation techniques
      ... > The easiest way to perform privilege escalation on windows, ... All of these executables are run under SYSTEM. ... Or you can use a linux live cd that supports NTFS read/write ...
      (Pen-Test)