Announcement

Collapse
No announcement yet.

Physical hacking starting place(s)?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Physical hacking starting place(s)?

    I'll admit it at the start. I'm currently a corporate goon... :P

    I am looking for some other starter references on how to 'hack' winblow$ computer from sitting at the physical machine. (My preference would be to drop a *nix distro on the desktop with Xfree... But the people who write the rules say no.)

    To explain my environment - I'm basic tech support for a CallCenter, and we're 'finally' moving to AD. I'm in-charge of recreating ALL user accounts for this site along with building a production Windows XP image. I have about 700 users that I need to lock down from playing with anything more than they're supposed to. (And from the short time that I've been here... Some of these people get REALLY ingenious when they're that bored waiting for calls to come in.)

    As I migrate these machines to WinXP Pro, I would like to look at the image/user rights that I've created from more of a black hat point of view. (I learned that access to WordPad was removed previously as that can be used to write scripts, that the users could then run with Admin rights.)

    I saw reference to 'Hacking Exposed - Windows 2000' in the forums, and plan to pick up a copy of that next week. (I'm also trying to develop my knowledge of AD to work that aspect too.)

    I know that I can't completely secure these as people have access to the boxen if they REALLY want too. (Resetting Bios password jumpers, plugging back in drive media cables, etc.)

    My Baseline that I'm working from is disabled media drives. (Floppy, CD)
    Password for Bios. (No password for boot up as I need to let them freely boot the computers.)
    All users have only 'User' access rights not higher to the WinXP Pro.
    Theoretically I should be able to disable most of the software with AD.. (The big program that I know that they'll need to be able to access is IE; As about 2/3's of the utilities that they use are IE/Java based. )

    I guess what I'm looking for like I kinda asked at the beginning is a few more ideas for where I can go to find out how to hack these from sitting in front of it. In Googling and reading here I just haven't seen much out there to actually 'cracking' the software/OS from within it.

  • #2
    Active Directory's Group Policy is your friend. You can create several groups for different classes of users, then create corosponding policy. You can get pretty brutal about it as well.

    As far as migrating goes, hit Microsoft's site for some migration tools to make recreating user accounts easier.

    Finally, as far as physically hacking the workstation goes, theres a nice bootable CD or Floppy disk mini-distro that litterally boots up and lets you edit the SAM on the windows box.

    If you are locking down your users ability to use CDROM or Floppy, Group Policy will let you do that, plus let you lock down 'removable storage devices' so your users dont get the bright idea of bringing in those USB thumb drives.

    I return whatever i wish . Its called FREEDOWM OF RANDOMNESS IN A HECK . CLUSTERED DEFEATED CORn FORUM . Welcome to me

    Comment


    • #3
      The biggest thing to do is sit down afterwards and think like someone that wants to do 'something' on the box. Whether opening a command console or paint.exe. Start by trying to find anything that the sysadmin might have forgotten about... or better yet, have someone else that knows the OS try to defeat you.

      Little things like forgetting to prevent their ability to create a scheduled task can come back to bite your ass. For example, you may set your local policy to restrict the user from executing command or cmd... but if they have the ability to create a task in task scheduler, they don't need privs to run either because they will be run outside of your policy by the Task Scheduler service.

      It all depends what the systems actually need to be able to do. If you can't trust your user with Notepad or any writing implement and some form of writing capability is necessary on the machine, then you just need to make sure that the user does not have the ability to execute the scripts the write. Make em waste their time :)

      Boot devices are your largest enemy. If they can boot from a bubble gum wrapper with leftover pixiestick dust on it, your system is owned (know-how assumed). If they have the ability to alter the hardware physically and get away with it, your efforts are near pointless, you'll be imaging the machine in no time.

      Alter the configuration of IE intensively to restrict anyone from executing scripts through the browser. This may be tricky, depending on the content you are trying to deliver and how that content is written. There are oodles of local policies that you can set specifically for IE to prevent things from right-click context menus to altering configuration. Don't let them browse the local machine, file:// support is a bad thing.
      if it gets me nowhere, I'll go there proud; and I'm gonna go there free.

      Comment


      • #4
        Originally posted by noid
        As far as migrating goes, hit Microsoft's site for some migration tools to make recreating user accounts easier.
        Also, if the company aren't total idiots and are willing to do this right, look into third-party migration tools as well. Some decent links are here. Incidentally, is this an NT4 -> 2000 migration, or just bringing 2000 into the AD world? They're *very* different in terms of what to expect.

        If you are locking down your users ability to use CDROM or Floppy, Group Policy will let you do that, plus let you lock down 'removable storage devices' so your users dont get the bright idea of bringing in those USB thumb drives.
        Pen drives and similar (don't forget USB HDDs) are the biggest pain in the ass from that standpoint. BTW, also turn off 'boot from floppy / CDROM' in the bios and be sure that the only local account on the machine is the administrator account. You do NOT want them getting into Safe Mode either if at all possible.

        Comment


        • #5
          Originally posted by converge

          Little things like forgetting to prevent their ability to create a scheduled task can come back to bite your ass. For example, you may set your local policy to restrict the user from executing command or cmd... but if they have the ability to create a task in task scheduler, they don't need privs to run either because they will be run outside of your policy by the Task Scheduler service.
          Like using 'at' to spawn a system context command shell for you.

          I return whatever i wish . Its called FREEDOWM OF RANDOMNESS IN A HECK . CLUSTERED DEFEATED CORn FORUM . Welcome to me

          Comment


          • #6
            three words typewriter
            /* NO COMMENT */

            Comment


            • #7
              oh yeah.. and an armed security guard to keep the french canadians away.
              if it gets me nowhere, I'll go there proud; and I'm gonna go there free.

              Comment

              Working...
              X