Hacked Workstations

[Guest]

I work at a school where students have been booting off Linux CDs and
deleting the SAM and booting off NT password reset floppies to delete the
admin password.

For reasons beyond my control we have to give the students the ability to
boot off of floppies and CDs.

My question is how can we stop this from happening?

 

[Dave]

I work at a school where students have been booting off Linux CDs and
deleting the SAM and booting off NT password reset floppies to delete the
admin password.

For reasons beyond my control we have to give the students the ability to
boot off of floppies and CDs.

My question is how can we stop this from happening?

you have a couple options. the hardest one to get implimented is to
discipline anyone caught bypassing security... kick a few of them out of
school and maybe the others will get the idea. or you could live with the
fact that its going to happen and make sure that you have a quick way to
restore the proper image to a hacked machine. maybe even boot from a
network instead of the local hard drive. if you go this way you also
probably want to segregate the student machines so they don't have access to
anything important. basically if you are in a situation where you can't
control physical access to the machines you can't stop anyone from doing
basically anything they want.

 

[Guest]

It is a private school. The school makes tens of thousands of dollars for
every student that attends. So unless a student is causing the school to lose
money (causing tens of thousands of dollars in damage would make them
unprofitable for the school, but that kind of damage is unlikely) then there
is no way in hell that they will kick them out.

These students are not very smart. A few skript kiddiots showed everyone
else the few tricks mentioned to get the local admin password. So I was
thinking that maybe if I could somehow encrypt the System32 folder using EFS
or something then they at least wouldn't be able to boot off a Linux CD and
delete the SAM as the wouldn't be able to find the SAM on the encrypted drive.

Would that even work though? I don't know much about EFS.

 

[Herb Martin]

It is a private school. The school makes tens of thousands of dollars for
every student that attends. So unless a student is causing the school to lose
money (causing tens of thousands of dollars in damage would make them
unprofitable for the school, but that kind of damage is unlikely) then there
is no way in hell that they will kick them out.

These students are not very smart. A few skript kiddiots showed everyone
else the few tricks mentioned to get the local admin password. So I was
thinking that maybe if I could somehow encrypt the System32 folder using EFS
or something then they at least wouldn't be able to boot off a Linux CD and
delete the SAM as the wouldn't be able to find the SAM on the encrypted drive.

Would that even work though? I don't know much about EFS.

All NT-type security (with very few exceptions)
require PHYSICAL security of the machines.

If you give them the ability to boot the machine
then all bets are off.

EFS can protect data files (and even some exe etc.)
but it cannot protect many/most system files since
they must be readable immediately.

THey would ALWAYS be able to "Find" the SAM
since EFS protects ONLY files (not the directory
structure.)

[Despite common misperception and even the way
the prompts in the tools are worded there are no
"encrypted directories" -- encrypting directories
means setting the defaults for files created there.]

 

[John John]

Use Server 2003 with AD and the Knoppix kiddies will be lost. There
will be no SAM to hack at the WORKSTATIONS in class. Does that make
sense? Or am I right off the rails?

John

 

[Herb Martin]

Use Server 2003 with AD and the Knoppix kiddies will be lost. There
will be no SAM to hack at the WORKSTATIONS in class. Does that make
sense? Or am I right off the rails?

Well, there is a SAM on all Win2000+ DCs
but it only holds the emergency admin account.

 

[Steven L Umbach]

Domain computers still have a local sam and the user will be allowed to gain
access as a local administrator and still have full control of the computer
enabling them to unjoin from the domain if they wish or do whatever
lse. --- Steve

 

[Steven L Umbach]

There is nothing you can do as long as they are allowed to boot from these
devices. Now depending on what they are doing you still may have ways to
control them, particularly if this is an Active Directory domain and you can
upgrade to XP Pro which allows the use of Software Restriction Policies
which can also restrict a local administrator as long as the computer
remains a member of the domain. A local administrator could always unjoin a
computer from the domain, but you could make sure they can not rejoin it to
the domain which could deny them to domain resources they may need and show
them how smart they really are. If the school is making over ten thousand
dollar profit per student I am sure they could afford the upgrade to XP
ro. --- Steve

 

[John John]

Hummm.... yes. But my idea is to open the whole darn workstations
anyway. Make them (the workstations... or the students!) dummy
terminals. So what if they have admin privileges. After a few days
they will know that the exercise is pointless, there will be nothing but
Windows on the workstation. SAM won't bother, AD on the server will
rule. Some sort of image or network push could restore the workstation
to the default state in a hurry. Or not... let the ones who break it
learn how to restore an image. They should quickly find out that
without the dummy terminals they can't do anything, tell them that their
pc's are broken for 24 hours and get then to read Shakespeare. The days
of broken terminals will over. Then they will set their sight on the
server... another gate to hack.

John

 

[John John]

We'll have to figure a way around the domain disjoins. No terminals!
Now time to listen to opera while the techs fix the terminals... The
kids will go nuts waiting. These are just "unthought" of ideas,
brainstorms can lead to other solutions... or fizzle into brain farts!

John

 

[Steven L Umbach]

You did not say if you are in a domain or not but here is something that may
help, particularly if you are in a domain. You can use Group Policy to
configure startup and shutdown scripts. These scripts run in system context.
You could create a startup script that uses the command [ net user
administrator newpassword ] which would assign the built in administrator a
new password at startup to the operating system. On a non domain computer
they may eventually catch on but for domain computers you could put the
script in the proper sysvol folder for the policy machine configuration and
remove users from the script permissions and add domain computers with
read/execute permissions. That would prevent users from navigating to the
sysvol share to read the password you put in the script. This of course
assumes that the administrator account has not been renamed and that they
are not resetting passwords for another user that has administrator group
membership. FYI users may try to bypass startup scripts by pulling the
network cable before startup so be sure to disable logging onto the domain
with cached credentials in the appropriate security policy which can help
reduce success of such.

http://support.microsoft.com/default.aspx?scid=kb;en-us;198642
http://support.microsoft.com/default.aspx?scid=kb;en-us;322241

Also if these are domain computers you can use Restricted Groups to force
membership in the administrators group that you specify and I suggest that
you do this at the OU level and make sure that just domain admins is in the
administrators group, though that will still leave the built in
administrator account for the domain computer also. If you can do such I
suggest that you also shorten the Group Policy refresh interval for
computers to around five minutes and configure security policy processing to
process even if Group Policy objects have not changed to force Restricted
Groups to enforce group membership more often than the default 90 minutes.
Again assuming that you are using an Active Directory domain, there are
tools such as PsPasswd that allow you to change the local administrator
password on domain computers from the command line using a batch file or
running the command against a file list that included fully qualified domain
names of the domain computers. Other tools such as PsShutdown can remotely
force users to loggoff or reboot the computer to force a new password to be
used. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;320045
http://www.sysinternals.com/ntw2k/freeware/pspasswd.shtml
http://www.sysinternals.com/ntw2k/freeware/psshutdown.shtml

 

[Jeff Cochran]

I work at a school where students have been booting off Linux CDs and
deleting the SAM and booting off NT password reset floppies to delete the
admin password.

For reasons beyond my control we have to give the students the ability to
boot off of floppies and CDs.

My question is how can we stop this from happening?

Use a product such as Hard Drive Sheriff or others that have the OS on
a ROM. They can do whatever they want, reboot and it's all back.

Jeff

 

[Andrew Sword [MVP]]

Asking who ever runs the school to take action against those caught will
assist.

 

[Kevin D. Quitt]

I would use removable drives and re-write the drives each evening. Or
have a drive assigned for each student, and start it off fresh whenever
they check it out.

 

[Guest]

We do reimage the workstations whenever they get "hacked." We also reimage
them on a regular basis as just part of our routine system upkeep. Because
there are students who save files on these workstations we try not to reimage
than willy nilly because students lose their work and the IT dept gets blamed.

Yes we supply the students with CD-Rs to save their work on but many of them
do not do this, they just save their work to the local hard drive.

 

[Guest]

That is one of the problems. The administration does not view this as a
serious problem.

 

[Guest]

I have no real budget. Seeing as how the administration refuses to beieve
that there is a problem going on they are not going to give me money for
something like this.

 

[Guest]

One of the problems is that they do this to a computer off in a corner. Then
load a packet sniffer on it and just let it run all night. Or they will do it
to an often used workstation and put a keystroke logger on it.

They don't seem to mess with the computers that they do their work on.
Instead they mess with other computers that either nobody uses or that other
people use. So if it is denied access to domain resources they don't care,
they already put their keylogger or sniffer on it.

 

[Guest]

I guess the problem is that once they have changed the local admin password
then they could have put a rootkit on the machine or anything else. Changing
the password back to something secure isn't really an option because at that
point the machine is no longer trustworthy so we just reimage it.

You did not say if you are in a domain or not but here is something that may
help, particularly if you are in a domain. You can use Group Policy to
configure startup and shutdown scripts. These scripts run in system context.
You could create a startup script that uses the command [ net user
administrator newpassword ] which would assign the built in administrator a
new password at startup to the operating system. On a non domain computer
they may eventually catch on but for domain computers you could put the
script in the proper sysvol folder for the policy machine configuration and
remove users from the script permissions and add domain computers with
read/execute permissions. That would prevent users from navigating to the
sysvol share to read the password you put in the script. This of course
assumes that the administrator account has not been renamed and that they
are not resetting passwords for another user that has administrator group
membership. FYI users may try to bypass startup scripts by pulling the
network cable before startup so be sure to disable logging onto the domain
with cached credentials in the appropriate security policy which can help
reduce success of such.

http://support.microsoft.com/default.aspx?scid=kb;en-us;198642
http://support.microsoft.com/default.aspx?scid=kb;en-us;322241

Also if these are domain computers you can use Restricted Groups to force
membership in the administrators group that you specify and I suggest that
you do this at the OU level and make sure that just domain admins is in the
administrators group, though that will still leave the built in
administrator account for the domain computer also. If you can do such I
suggest that you also shorten the Group Policy refresh interval for
computers to around five minutes and configure security policy processing to
process even if Group Policy objects have not changed to force Restricted
Groups to enforce group membership more often than the default 90 minutes.
Again assuming that you are using an Active Directory domain, there are
tools such as PsPasswd that allow you to change the local administrator
password on domain computers from the command line using a batch file or
running the command against a file list that included fully qualified domain
names of the domain computers. Other tools such as PsShutdown can remotely
force users to loggoff or reboot the computer to force a new password to be
used. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;320045
http://www.sysinternals.com/ntw2k/freeware/pspasswd.shtml
http://www.sysinternals.com/ntw2k/freeware/psshutdown.shtml

Use Server 2003 with AD and the Knoppix kiddies will be lost. There will
be no SAM to hack at the WORKSTATIONS in class. Does that make sense? Or
am I right off the rails?

John

 

[Guest]

Oh, I forgot to mention. We run Windows NT Server on our servers. Yeah, I
know. Please don't look at me like that. So none of that fancy Active
Directory stuff I'm afraid.

I guess the problem is that once they have changed the local admin password
then they could have put a rootkit on the machine or anything else. Changing
the password back to something secure isn't really an option because at that
point the machine is no longer trustworthy so we just reimage it.

You did not say if you are in a domain or not but here is something that may
help, particularly if you are in a domain. You can use Group Policy to
configure startup and shutdown scripts. These scripts run in system context.
You could create a startup script that uses the command [ net user
administrator newpassword ] which would assign the built in administrator a
new password at startup to the operating system. On a non domain computer
they may eventually catch on but for domain computers you could put the
script in the proper sysvol folder for the policy machine configuration and
remove users from the script permissions and add domain computers with
read/execute permissions. That would prevent users from navigating to the
sysvol share to read the password you put in the script. This of course
assumes that the administrator account has not been renamed and that they
are not resetting passwords for another user that has administrator group
membership. FYI users may try to bypass startup scripts by pulling the
network cable before startup so be sure to disable logging onto the domain
with cached credentials in the appropriate security policy which can help
reduce success of such.

http://support.microsoft.com/default.aspx?scid=kb;en-us;198642
http://support.microsoft.com/default.aspx?scid=kb;en-us;322241

Also if these are domain computers you can use Restricted Groups to force
membership in the administrators group that you specify and I suggest that
you do this at the OU level and make sure that just domain admins is in the
administrators group, though that will still leave the built in
administrator account for the domain computer also. If you can do such I
suggest that you also shorten the Group Policy refresh interval for
computers to around five minutes and configure security policy processing to
process even if Group Policy objects have not changed to force Restricted
Groups to enforce group membership more often than the default 90 minutes.
Again assuming that you are using an Active Directory domain, there are
tools such as PsPasswd that allow you to change the local administrator
password on domain computers from the command line using a batch file or
running the command against a file list that included fully qualified domain
names of the domain computers. Other tools such as PsShutdown can remotely
force users to loggoff or reboot the computer to force a new password to be
used. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;320045
http://www.sysinternals.com/ntw2k/freeware/pspasswd.shtml
http://www.sysinternals.com/ntw2k/freeware/psshutdown.shtml

Use Server 2003 with AD and the Knoppix kiddies will be lost. There will
be no SAM to hack at the WORKSTATIONS in class. Does that make sense? Or
am I right off the rails?

John

megascout29 wrote:

I work at a school where students have been booting off Linux CDs and
deleting the SAM and booting off NT password reset floppies to delete the
admin password.

For reasons beyond my control we have to give the students the ability to
boot off of floppies and CDs. My question is how can we stop this from
happening?