|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] Linux boot disk to replace XP Admin password?
|
Fred, I am not sure you can realistically secure the public workstations
like you would a server since they are physically accessible. To clarify let
me give you this scenario...
I am a hax0r and get a job at Acme Fertilizer Co. One day I figure I should
find some neat-O info for industrial espionage resale reasons or just to
find out who that cute receptionist is always chatting with via AIM. So, do
I go after the server locked in the closet? No. The Linux utility we are
discussing does not support modification of Active Directory or Domain
accounts, only local accounts. I figure, the best option here is to;
1. Use the utility on the receptionists PC so I can later mount the
\\workstationname\c$ from some where else on the local network. "If" the
local box is doing mandatory logging (it should be) and the logs are being
read (they should be) regularly -- I can confuse the compromise by also
creating a local user account on my and the receptionist's workstation with
the same username (say "hax0r" or "helpdesk"), adding that account to the
local administrator's group, logging into that account changing my local
workstation name and mounting the share from that point. This way I find
what I want and undo what I did to my workstation by renaming my workstation
back to what it was named previously and deleting the local user account I
made. At most, the tracks I have left are one irregular mount of a share by
a local account that no longer exists from a workstation name that no longer
exists and could be anywhere on the network.
**Yes, I can here the groans now. There are holes in this plan but giving
the fact that, unless tipped off by something irregular, most people will
not be scanning logs for anything like this.
2. I "could" just compromise the MCSE's workstation at Acme and install a
sniffer, keyboard tap, etc. Later using what I find to compromise the server
and its domain accounts as well as data.
**Yes, this plan carries significantly higher risk of discovery. Yes, there
are PS2 keyboard recorders available on the net. Yes, I could just install
Back Orifice and deny being seen near the administrator's workstation.
I guess the point I want to be sure of is that "Physical security of the box
you want to stay secured is paramount to its staying secured after you
secure it." See
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/s
ecurity/essays/10imlaws.asp for Microsoft's view on this and nine other
security related concepts.
Now... having said all that rubbish, you can develop a security policy that
can ignorantly reduce the risks you may have. I am not the only one that
will tell you that you can turn off administrative shares or sharing
entirely on Windows workstations. Syskey can be employed to significantly
reduce risk to the SAM and local workstation. Encrypting File System (EFS)
can be used to secure local workstation data. There are other steps to take
as well via C2 guidelines and others, but this is not a Windows list so I
will stop here.
Thanks for reading...
011010110110000101101101
Kam Salisbury
MCSE, Linux+, CNA -- Believer in Open Source.
http://www.kamsalisbury.com
----- Original Message -----
From: "Fred K Ollinger" <follinge@sas.upenn.edu>
To: <plug@lists.phillylinux.org>
Sent: Monday, January 20, 2003 2:58 PM
Subject: Re: [PLUG] Linux boot disk to replace XP Admin password?
> > Using this utility works when trying to just blank the password for
> > Administrator. However, you cannot login as administrator (or use the
> > 'runas' service) unless you lower the workstation's overall security
policy
> > by allowing blank password length in account policies and disabling the
> > 'Limit local account use of blank passowrds to console login only'
policy in
> > Local Security Settings.
> >
> > I see this as a major threat to security of local workstations in an
> > enterprise environment. Why? Because now someone can use this utility to
> > blank out the password of the local Administrator account and quietly
access
> > the contents of the workstation's disk from somewhere else on the local
> > network.
>
> If are trusting a client accessible machine to lockdown a server, game
> over, forget about security.
>
> If have a bootable cdrom drive on a machine, game over, forget about
> security.
>
> There's really nothing you can do to lock down a client accessible
> machine. Even a bios password can usually be reset by resetting a jumper.
>
> Then one can merely boot w/ the appropriate disk to gain access.
>
> Heck, now that they have these new bootable firewire drives, any machine
> that supports that is also wide open. Mac hardware users can talk more
> about this. Can one put the macos on a iPod and use it to boot a mac? I
> don't know.
>
> Anyway, I appreciate your comment about how windows protocols mean that a
> compromised client can compromise the server. I didn't know that, and I'm
> not an expert on security. Can someone please post how to stop this? If I
> have an NT box locked down as a fileserver only, in a closet, how do I
> assure that this isn't broken into when someone knocks over the public
> terminal clients?
>
> Fred Ollinger
> _________________________________________________________________________
> Philadelphia Linux Users Group -- http://www.phillylinux.org
> Announcements - http://lists.netisland.net/mailman/listinfo/plug-announce
> General Discussion -- http://lists.netisland.net/mailman/listinfo/plug
_________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.netisland.net/mailman/listinfo/plug-announce
General Discussion -- http://lists.netisland.net/mailman/listinfo/plug
|
|