Re: local admin account password

From: Jimi Thompson (jimit_at_myrealbox.com)
Date: 11/28/03

  • Next message: Jimi Thompson: "Re: local admin account password" 
    Date: Thu, 27 Nov 2003 23:23:23 -0600
To: Peterson Ellis <peterson_ellis@bah.com>

    Physical security is the basis of all security. but with the merging of
    the physical with the digital, it most certianly doesn't end there. I
    agree that if I can get my hands on a box, it's approximiately 10
    minutes away from being mine. However, walking up to the box isn't the
    only way to get it to boot of my media and/or power cycle the server
    these days. My latest worry in this area are the KVM's that allow the
    machine to boot off a "virtual" (i.e. remotely producted and managed
    disk image) floppy. Now I don't have to walk up to the box to get it to
    boot off my nefarious floppy disk, I can do it over the wire. For
    anyone who doesn't think that's a serious concern, you need to look at
    the number of linux utilities that exist solely to rest the local admin
    password and/or user name to known value(s).

    Just because admin's use them for a harmeless purpose doesn't mean that
    the black hats aren't using them for their own ends as well.

    2 cents,

    Jimi

    Peterson Ellis wrote:

    >What do you mean when you say that "physical security negates the need
    >to worry about boot floppy/cds"? Are you saying that the users do not
    >have physical access to their boxes or that they can be observed by a
    >guard/other workers/management?
    >
    >Ellis
    >
    >Eli Allen wrote:
    >
    >
    >>Thanks, I've used that tool before (seems to have a bug as it didn't work
    >>with a particular password I was trying to use one while "net user" worked
    >>fine at changing the password but thats a different story)
    >>
    >>some other consideration that I probably should have mentioned:
    >>- Some users are admins of some boxes but should have no access to others.
    >>i.e. they can do lophtcrack on their own box but don't wnat that to help
    >>them get into another box
    >>
    >>- physical security negates the need to worry about boot floppy/cds
    >>
    >>Thanks
    >>Eli Allen
    >>
    >>----- Original Message -----
    >>From: "David Cameron" <david@uberconcept.com>
    >>To: "Eli Allen" <eallen@bcpl.net>
    >>Cc: <focus-ms@securityfocus.com>
    >>Sent: Wednesday, November 26, 2003 3:25 AM
    >>Subject: Re: local admin account password
    >>
    >>
    >>
    >>>You might want to consider a solution using something like this:
    >>>
    >>>
    >>>
    >>http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q272/5/30.ASP&NoWebContent=1
    >>
    >>
    >>>using the above, you could write a script that would change the
    >>>passwords of the servers on a regular basis (say weekly).
    >>>
    >>>regards
    >>>David Cameron
    >>>
    >>>Eli Allen wrote:
    >>>
    >>>
    >>>>Say you have more then 1000 systems, how do you handle the local admin
    >>>>account password on the machines? (assuming it needs to be available for
    >>>>extreme cases to get into the machine as you'd normally just use a
    >>>>
    >>>>
    >>domain
    >>
    >>
    >>>>login)
    >>>>
    >>>>A few ways I can think of (in order from what I think is worst to best):
    >>>>1) use the same password on all boxes. Obviously insecure
    >>>>
    >>>>2) Use a different password on all boxes and a big filling cabinet to
    >>>>
    >>>>
    >>secure
    >>
    >>
    >>>>it (as its impossible to memorize). Don't think this would work in the
    >>>>
    >>>>
    >>real
    >>
    >>
    >>>>world so not worth using.
    >>>>
    >>>>3) Use a password scheme where the password is basically the same on all
    >>>>
    >>>>
    >>box
    >>
    >>
    >>>>except its based on something specific about the server. This means if
    >>>>someone figures out the scheme (cracking a single box and figuring it
    >>>>
    >>>>
    >>out or
    >>
    >>
    >>>>just gets told) they basically made this as good as the first idea I
    >>>>
    >>>>
    >>list.
    >>
    >>
    >>>>4) Only use domain accounts so delete the local ones. But this means no
    >>>>more recovery console and don't think cached logins will work. With so
    >>>>
    >>>>
    >>many
    >>
    >>
    >>>>boxes and hence lots of admins you may not have logged onto the box and
    >>>>
    >>>>
    >>so
    >>
    >>
    >>>>not have cached login in the cache even if you increased the logins that
    >>>>
    >>>>
    >>can
    >>
    >>
    >>>>be cached.
    >>>>
    >>>>5)My main idea/plan is to store all the passwords on a central SQL
    >>>>
    >>>>
    >>server.
    >>
    >>
    >>>>This way you can easily have a different random passwords for the admin
    >>>>accounts on all the boxes.
    >>>>
    >>>>The DB file would be encrypted with EFS so only the limited user SQL
    >>>>
    >>>>
    >>runs
    >>
    >>
    >>>>under has access to the file and another user just used for doing
    >>>>
    >>>>
    >>backups of
    >>
    >>
    >>>>this file. This means an attacker can't use an OS break-in to get to
    >>>>
    >>>>
    >>the
    >>
    >>
    >>>>data and needs to compromise SQL or one of those two user accounts. SQL
    >>>>would be set to integrated auth and only allow the domain groups who are
    >>>>allowed access to the admin password in. (i.e. using the access rights
    >>>>already existing)
    >>>>
    >>>>For data recovery (this DB is very important not to lose) there are two
    >>>>
    >>>>
    >>main
    >>
    >>
    >>>>considerations, one the file is small as the DB has very little info in
    >>>>
    >>>>
    >>it
    >>
    >>
    >>>>and two it doesn't get updated very often. The backup user can make a
    >>>>
    >>>>
    >>zip
    >>
    >>
    >>>>backup of the DB whenever it gets changed and then encrypt the file (PGP
    >>>>
    >>>>
    >>or
    >>
    >>
    >>>>something like it with the private key stored on a/multiple CD-R(s)
    >>>>somewhere safe) Then this file could be copied to lots of employee's
    >>>>desktops. Its encrypted so they can't read it and with lots of people
    >>>>having the file the likelihood of everyone's copy being damaged from HDD
    >>>>failure is low. (Yes will use tape backup of the file too including off
    >>>>
    >>>>
    >>site
    >>
    >>
    >>>>storage but tape is slow and should only be used if necessary) If there
    >>>>
    >>>>
    >>is
    >>
    >>
    >>>>an emergency the managers could easily allow the file to be decrypted
    >>>>
    >>>>
    >>and
    >>
    >>
    >>>>then attached to any SQL server available relatively quickly.
    >>>>
    >>>>Access to this file can be made by any utility that can make use of
    >>>>
    >>>>
    >>stored
    >>
    >>
    >>>>procedures. There would be basically two stored procs, one to get a
    >>>>password from the DB and one to set the password in the DB both would
    >>>>
    >>>>
    >>have 3
    >>
    >>
    >>>>values (machine name, username, and password) passed in and out
    >>>>
    >>>>
    >>(obviously
    >>
    >>
    >>>>depending on which you use). This way if a person decides to try and
    >>>>
    >>>>
    >>dump
    >>
    >>
    >>>>the DB and get all the passwords the stored proc can do something about
    >>>>
    >>>>
    >>it
    >>
    >>
    >>>>(alert management, stop it from happening, or something like that) This
    >>>>
    >>>>
    >>way
    >>
    >>
    >>>>its easy to write whatever interface you want to be able to do access
    >>>>
    >>>>
    >>the DB
    >>
    >>
    >>>>and the app itself doesn't really need to be secure as the
    >>>>
    >>>>
    >>authentication is
    >>
    >>
    >>>>based on the user that app is run by.
    >>>>
    >>>>Yes I realize it has a central point of attack at the DB but I think
    >>>>
    >>>>
    >>that
    >>
    >>
    >>>>can be secured well enough and the design is secure that its still
    >>>>
    >>>>
    >>better
    >>
    >>
    >>>>then the other methods.
    >>>>
    >>>>Any comments? Thanks
    >>>>
    >>>>Eli Allen
    >>>>eallen@bcpl.net
    >>>>
    >>>>
    >>>>
    >>>>
    >>>--------------------------------------------------------------------------
    >>>
    >>>
    >>-
    >>
    >>
    >>>--------------------------------------------------------------------------
    >>>
    >>>
    >>-
    >>
    >>
    >>>>
    >>>>
    >>>
    >>>
    >>>
    >>---------------------------------------------------------------------------
    >>---------------------------------------------------------------------------
    >>
    >>
    >
    >---------------------------------------------------------------------------
    >---------------------------------------------------------------------------
    >
    >
    >
    >
    >

    ---------------------------------------------------------------------------
    ---------------------------------------------------------------------------

  • Next message: Jimi Thompson: "Re: local admin account password"

    Relevant Pages

    • Re: I need to password protect my pc at startup
      ... Is there a better way to protect my machine? ... Lock your office. ... Without physical security - just about everything else ... BIOS/System Setup and once there - setting a password to boot the computer ...
      (microsoft.public.windowsxp.basics)
    • Re: I need to password protect my pc at startup
      ... Lock your office. ... Without physical security - just about everything else ... You could set a BIOS password and change the boot method so that it boots ...
      (microsoft.public.windowsxp.basics)
    • Re: No way to secure a system completely by means of software?
      ... Without physical security there is no security. ... Possibly a sturdy computer case with an alarm that ... > Second, how to avoid someone using boot diskettes or boot cd, ... Disabling boot from floppy or cd in the bios, ...
      (microsoft.public.win2000.security)
    • Re: can someone get admin password with physical access?
      ... >Hi, I help out the admin at my school with security, and we have very poor ... >physical security of computers. ... The way round this is to set the boot order on each PC's BIOS so it will only ... The only way around the BIOS password is to open the case and start swapping ...
      (comp.os.ms-windows.nt.admin.security)