Protecting Information From Exposure (Part I & II)

posted onJuly 6, 2001

by hitbsecnews

By Kurt Seifried

If you ask an administrator what they have done to protect information from being stolen or otherwise disclosed they will often respond with filesystem ACL's, strong user authentication and so forth. Unfortunately the strongest ACL's and user authentication in the world will only protect you from certain limited types of threats. It doesn't matter how strong your NT filesystem permissions are if I steal your laptop and use something like a dos boot disk with NTFS support to simply read all the files, or reset your password with NTLocksmith. Additionally information has an annoying tendency of ending up in odd places that you may not have expected, for example users may save data to a floppy disk or email it to themselves at home so they can work on it from there. Fortunately there are solutions to these problems, however without user education and support from management most will not be effective.

Limiting Access

The first step is to limit access to the services and systems that share out or contain sensitive information. Firewalling file sharing protocols such as SMB, NFS and AFS at your border gateways is a good idea, indeed, any sharing of data over other networks should probably be done via virtual private networking or other forms of encryption. Of course these types of controls have absolutely no effect on "insiders", any user with files on a file server will of course mean that they can potentially get at other user's files. This is typically where the next major defense line is, filesystem access control lists. In the Unix world we typically have three sets of permissions on a file, user, group and other as a bare minimum. In the NT/2000 and more advanced Unix world file permissions can typically be assigned arbitrarily to an almost infinite degree of complexity. If these file and directory permissions are setup correctly then a user should only have access to the files that they need access to and nothing more. Unfortunately this is often not the case as administrators and users will often assign overly permissive file permissions due to a number of reasons, the main one being if you don't have access to a file you are much more likely to notice that then if you accidentally have access to a file you shouldn't. There are a number of solutions on the market that address these problems, however they are typically add-on packages and do not come with the operating system. These file permissions of course rely on being able to accurately identify the user, which means that strong user authentication must be used otherwise the system of ACL's is largely useless. The vast majority of enterprises still rely on usernames and passwords, which are far from ideal. Users often have the same password for multiple systems (at work and home) meaning that the exposure of a password for an unrelated service is probably sufficient to gain access to some other more secure service. User's accessing POP mailboxes of FTP accounts at their ISP would transmit their password in the clear, a smart attacker would try this password against the corporate servers. To make matters worse some forms of file sharing, such as NFS, do not even rely on user authentication, instead directories are shared out with their file permissions and the remote end is trusted to report the user as being the correct one.

Protecting Network Traffic

To add insult to injury most file sharing protocols either do not support strong encryption or do not use it by default, so no matter how strong your filesystem ACL's are if a user must access data over the network chances are an attacker can view and copy it (or possibly even alter in). The best way to solve these problems is to use string encryption everywhere, thus an attacker will not be able to grab passwords from the network, or view information as it passes along. Network level encryption in the form of IPSec is growing in popularity and ease of deployment, network cards from Intel with crypto acceleration hardware built in are only $50 now and will allow a workstation or server to encrypt all network traffic with only a minimal loss in performance. Novell supports strong encryption of network traffic using it's own proprietary methods however all the Novell clients (i.e. Win32) support it making it easy to deploy. Windows file sharing (SMB/CIFS) supports the use of SSL, however a smart attacker will be able to execute a man in the middle attack using a variety of SSL tools. NFS does not support encryption however TCFS does and can be used as a replacement for NFS with most platforms if network encryption of the data traffic is needed.

Information Leakage

So once you've secured the areas that you know sensitive data resides or will travel through it is time to start looking at the areas where that data may end up unintentionally (or otherwise). When you edit a file on a computer for example that file not only exists on the harddrive in its protected location, but is also loaded into memory so it can be manipulated. This often results in the data being written to a swap file or partition without the users knowledge or consent, an attacker will be able to retrieve data from these locations with little difficulty if access is gained. OpenBSD for example now supports an encrypted swap partition, in the file /etc/sysctl.conf simply enable vm.swapencrypt.enable:

vm.swapencrypt.enable=1

In windows NT and 2000 you can force the swap file(s) to be held on certain partitions, creating a small (i.e. 200 megs for a 100 meg swap file) D: drive and placing the swap file there not only reduces the risk of it getting fragmented but makes it much easier to control access to it since controlling access to the C: drive on a windows machine tightly will often break many applications. In Linux you can encrypt partitions using a number of methods and could in theory mount a swap file (instead of a swap partition) on an encrypted partition to protect it however this is rather cumbersome. With the apparent death of the International Kernel crypto patch and several other software packages that allowed for the encryption of the entire system the future of encrypted swap files does not look good for Linux.

As well there are any number of directories a user can copy a file to in most systems, for example on Unix the /tmp directory is often world readable and writeable, it is easy for an attacker to monitor this directory and "steal" files as they are copied in. One way to help prevent this is to set a strong umask for users, i.e. the default file permissions used when a file is created, "man " will contain the necessary information, unfortunately many Unix systems still default to having world writeable umasks.

Restricting access to removable devices is required if you do not want users to be able to take information home with them, in Unix simply assigning the appropriate permissions to the /dev/* entries will do the trick. For Windows commercial software packages such as SecureNT can be used to limit access to removable media. If users have access to the Internet then it is possible that they can upload files, restricting access for outgoing protocols such as SSH, FTP, RSYNC, TFTP as well as the users ability to install additional file transfer software on their workstation can prevent them from sending out information. Of course almost every user now has access to email, meaning they can simply attach the files and hit send, to prevent this you can often block outgoing attachments in most mail server packages or buy add on software to prevent this type of activity.

Summary

There is any number of ways in which information can be exposed to an attacker, either through direct attacks or passive attacks. If you are worried about inside users accessing and sending out sensitive information then your problem is that much harder, as they often have legitimate access to the data you are trying to protect. Hopefully some of the ideas and solutions present this week will help you, as well next week is part two which will go into destruction of data and some other interesting areas. Next week I will cover filesystem level encryption, as this is a rather large and complex topic.

As mentioned before, one method to help prevent information from being exposed is to encrypt it. Unfortunately, encrypting data effectively is a lot harder than it should be; consequently it is often not done correctly, if at all due to the challenges. There are a large number of commercial products and other software packages that enable you to encrypt data on your hard drive. I will cover them by each major OS in a sort of practical guide format along with the pitfalls that may be present. No solution fits all, so it is very difficult for me to actually give any a strong recommendation over another (they all work reasonably well). The beauty of encryption is that, in theory, if it is done correctly an attacker has absolutely no way to get at the data unless they somehow steal the encryption keys. If you use a strong passphrase to protect your keys or store your keys offline, then even with physical possession of the device (i.e. a laptop) an attacker would still have to try a huge number of combination, and in theory should not be able to break it using brute force.

Key and Data Recovery

Probably one of the thorniest issues with encryption is the subject of key recovery and escrow. People encrypt data so that other people cannot get at it. Unfortunately this means that, just like the attacker, if you have a legitimate need for the data but the person who knows the key's passphrase is not available, you are out of luck. And unlike locking your keys in the car, you cannot generally call upon someone to quickly decrypt the data (if someone else could quickly decrypt the data that would negate the whole point of encrypting it in the first place). However, for many corporations there is a legitimate need for key escrow or key recovery, and what happens if Johnson gets crushed to death by a stack of old 386s? What happens if Johnson quits on bad terms with the company and refuses to give the key up (while there may be legal recourse that doesn't guarantee that you will get your data)? The problem with key escrow is that it is very "in the face" of users, i.e. when they create a key set you demand a copy, or worse yet issue them the keys. As well you must make sure that you store these copies of the keys very securely, otherwise someone that wants to get at the encrypted data may have an easy way to get it. Key recovery varies in exact implementation, but a good implementation will be configurable so that it can reflect company policies. For example, a small firm may grant their sysadmin, who they trust, the ability to recover keys, this means that the sysadmin can get at any data encrypted with recoverable keys, probably without anyone else finding out. A larger firm such as a bank may require 5 officers to each participate in the key recovery process (by using a split password or split keys, etc.) so that no individuals or small groups can get at corporate data without others knowing. If the product does not support key recovery then you will need to use key escrow. Make sure that anytime a user creates a new key they register it, otherwise if Johnson creates a new key and starts using it when the 386 crushes his brain pan, the data will be lost forever.

PGP for Windows

Probably the best all-around encryption program available currently. Sadly the source code is no longer available for auditing, which is why Phillip Zimmerman (the creator of PGP) apparently left NAI for Hushmail. PGP is primarily aimed at the Windows platform, and it contains a standard file encryption program and key management tools as the core, on to this are added filesystem encryption, network encryption (IPSec), a firewall and IDS system (for network security) and plug-ins for popular mail clients. PGP is probably the easiest third party program to use for Windows file, volume and email encryption. PGP supports split keys (i.e. multiple people are needed to access the secret key) and key recovery, to quote from the help file:

If you ever lose your private key or you forget your passphrase, there is no way to recover from it unless your administrator has set up a key reconstruction policy, which includes setting up a key reconstruction server and enabling this option in your PGP software. If this feature is enabled in your software, you would have provided recovery information—five secret questions and answers—and would have sent your key to the key reconstruction server.

So if you are willing to purchase the commercial PGP encryption products and put a bit of work into it, you can have a very flexible and robust encryption infrastructure. Unfortunately, like all Windows add on encryption products, when it comes to encrypting files you cannot easily encrypt files and directories. While you can encrypt files you must decrypt them to work with them, meaning that unencrypted copies will be floating around your hard drive. Alternatively you can create a pseudo filesystem (basically a file you mount like a network share), however you must create it a certain size so you may end up wasting space or eventually running out, as well it requires you to keep all your encrypted work on the "F:" drive, for example.

Windows 2000 EFS

EFS is built into Windows 2000 and allows you to encrypt files and directories in a relatively easy interface (windows/file explorer). The advantage of this over PGP or BestCrypt is that you can encrypt an existing file or directory (this is not advised, however, see the URL at the end on EFS best practices). You can also create a new encrypted directory (such as C:secret) and then any files created within this directory will be automatically encrypted. EFS also supports key recovery, in fact you must configure some sort of key recovery configuration before you can use EFS, and unfortunately the administrator account typically is the one with this access set up. If you do not want one person to be able to access all information you must configure the key recovery when you start installing your windows 2000 infrastructure, unfortunately for many companies they have not done this, and probably will not (so if you are currently using EFS you could check!). EFS has a number of security issues and because of its apparent ease of use, most people will not be aware of them and may inadvertently expose information. Microsoft has issued one fix so far, but you should also educate your users.

BestCrypt for Windows and Linux

BestCrypt is an add on product like PGP, however it is available for both Windows and Linux. In addition to this, the source code is available so you can audit the code if you want to do so. The file it uses to store the data (called the "container") can be mounted by the Linux version and the Windows version, adding to it's convenience, if you dual boot your laptop, for example, you can store the container on your Windows partition and access it from Windows and Linux. As far as I know BestCrypt does not support key recovery, so if you need access to the data you will need to enforce key escrow (or in this case "passphrase" escrow), which is not as reliable (the user may change the passphrase or create a new encrypted container with a different key).