My family is installing DSL and wireless networking, which will expose us to substantially more security problems than in the past. Wireless networking is likely to appear soon at the UCLA Mathematics Department as well. My goal is, therefore, to assess what the threats are and how they might be mitigated. It is generally believed that a determined attacker with plenty of time and large but achievable resources is likely to successfully perpetrate any exploit he pleases, just as a determined burglar or embezzler is likely to be able to steal any of your resources. Nonetheless, most people who are careful about physical security do not get burgled, and I believe that the threat of hacking can be similarly reduced to an acceptable level.
First, some nomenclature. The ``hacker'' is the person perpetrating the attack, but since this essay is about computer threats, the ``hacker'' will often mean the computer operated by the meat person. The ``victim'' is the one being attacked. The ``exploit'' is whatever the hacker does. Frequently exploits are nested, e.g. the hacker first gains root access (a root exploit) and then uses that access to obtain encrypted material which he then cracks. It's a fact of life that most attacks involve a ``dupe'', a computer, and an account on that computer, which the hacker uses as a transfer point, so if the attack is caught in progress or if traces are found, the trail leads back to the dupe, and is frequently lost at that point. Nonetheless I will generally ignore the dupe and discuss as if the hacker and the victim were interacting directly.
Threats can be targeted or random. As an example of a targeted threat, the hacker may decide that the victim specifically has money worth stealing, and may hack to discover what institution holds the money, and what are the authentication codes needed to disburse it to the hacker. In the academic setting occasional undergraduates concoct elaborate schemes to steal examinations or to tamper with grades. They may also retaliate against unfavorable outcomes by embarrassing the department or specific professors in it.
In random threats, on the other hand, the only relation between the hacker and the victim is that the victim is vulnerable. Nowadays we can expect blanket attacks in which an automated script attacks every address in a range, and does the exploit on all vulnerable machines. Dupes are generally selected at random. Random threats can become targeted, if the exploit is to scan for resources that the hacker considers valuable; the hacker would then return in a targeted attack to collect the resource.
Another dimension distinguishing threats is the purpose of the attack. Vandalism is common, in which the victim's disc is wiped. Targeted vandalism more often takes the form of putting embarrassing material in a public place such as the victim's web pages. A particularly insidious form of targeted vandalism is to introduce subtle corruption, for example by adding a nickel here and a dime there to financial records, that is likely not to be noticed until an audit (internal, the victim hopes). Recent months have seen targeted denial of service attacks, in which vast numbers of dupes are caused to bombard the victim with traffic which is legitimate as to form.
Another purpose variant is a virus attack, in which the purpose of the virus is to reproduce. Except possibly for the initial infection, viruses appear randomly. Generally the virus has some kind of payload, which is more or less subtle vandalism.
The next variant on this dimension is stealing or falsifying data. Sometimes the data itself is valuable, such as an examination before it is administered, or the data may simply give the hacker access to the real object of value.
Finally the hacker may be interested in impersonating the victim. For example a professor (impersonated by a student hacker) might notify the members of his class that an exam had been postponed. In this kind of attack the message is accepted as authoritative by the recipient, even though the sender did not actually authorize it. Another serious threat is for the hacker to impersonate the victim at a financial institution.
Stealing and impersonation pretty much have to be targeted attacks, unless there is a piece of software, such as a home banking interface, that is vulnerable and that is common enough that a blanket attack will turn up numerous instances before the hole is plugged.
In the family DSL scenario, targeted attacks are unlikely, and the major threat will be random and blanket attacks. On the other hand, at any one time there may be one or two students who are motivated and technically able to mount a targeted attack on the department, given a vulnerability; and (unsuccessful) random attacks are seen daily.
It's a fact of life that desktop computers, and particularly laptops, are stolen, or are sold when obsolete without proper precautions (wiping the disc). In a targeted attack the hacker may also gain physical access to the computer but decline to steal it. In these cases it is trivial to gain root access to the machine, for example by booting it off a repair disc. Sometimes non-root application programs can be exploited directly, but virtually all serious attacks will involve root access at some point.
However, most attacks are done over the network. Dialup (PPP) connections are intermittent and slow, limiting exposure, but DSL is always active. With a wireless network, a hacker can position himself unobtrusively within range, and from there can contact the internal network.
When computers are kept up to date with the latest security patches, most exploits fail, but new exploits appear a few times per year, and there is an interval before they are recognized and the hole is patched. It is generally believed that a determined targeted attacker can eventually gain access to any machine. I wish I had a good feel for the amount of effort required. Would the attacker have to research a whole new exploit? Or is the statement made because most machines aren't up to the minute on security patches? Or do kernels have non-publicized inherent flaws that cannot be plugged? Experience in the Math Department is that exploits do occur, but rarely. Perhaps there is a continual background of undetected exploits with invisible consequences, possibly using our machines as dupes. But hackers want credit for their work; not for long are they satisfied to hack into some machines and then leave silently. Thus, if we're dupes we should receive complaints, and if we're victims we should see damage. We don't, usually, and other departments do, occasionally, particularly when they aren't careful about security. Thus I conclude that the level of effort we're using at the Math Department is adequate.
There are only so many network services, and by now the ways to exploit them are well known, and (one hopes) most of the holes have been plugged. Thus successful attacks against network services are rare. Generally when the Math Department has been attacked successfully, the hacker was able to impersonate one of our users and then execute code on our machine, called a ``root kit'', that exploited some flaw in the kernel.
When the hacker has physical possession of the computer to be hacked, there are a few defenses that are worth taking. Public terminals should be set up to not boot from removeable media (CDROM or floppy provided by the hacker), and there should be a password on the BIOS setup program so this setting cannot be changed. There is always a physical way to clear such a password, but typically it requires opening the computer and removing the backup battery, which would be suspicious activity in a public lab. UNIX machines should require a password to enter single-user mode (as root). Linux can bypass single-user configuration scripts for booting a damaged system; this feature should be sabotaged. These steps (except Linux) are in fact taken in the Math Department public labs. But of course in a non-public setting they only slow down the hacker for five minutes at most.
As set up in the Math Department, root on two master machines (Malibu and Julia) has a host-based privilege (/.rhosts) to execute on other machines, whereas root on other machines has no privilege elsewhere. Only certain staff members are allowed to login to the master machines. In this way, when a hacker impersonates a general user and uses a root kit, he cannot execute on the master machine either as root or as the user. He can, however, execute as the user on various non-master machines, and re-do the exploit there, so the restriction is not as onerous as it might seem. It would be a good idea at the Math Department to kick all users off the master machines except the programming staff, particularly on Malibu, where lab assistants and TA's are allowed.
It's important to keep our users' passwords out of the hands of hackers. We use shadow passwords, so a hacker on the master site can't just copy (and then laboriously crack) the password file, but we use NIS, which makes this information available to any machine on the local networks. Soon we will use NIS+, which is more secure. Linux on the home system uses shadow passwords and doesn't use NIS. Several times we've discovered that the entire password file from the Math Department has ended up on a hacker's site, and some of the passwords have been cracked. In that situation we make everyone change his or her password.
Frequently when the Math Department has been hacked, it's found that a user's account elsewhere was compromised, and the outside account had the privilege (granted by the user) to execute on our machine without authentication. We would very much like to limit our trust of outside authentication.
To the system administrator the main issue is that the hacker can get root access. But what does the hacker then do to individual users?
Clearly vandalism to the user's files can be very annoying. In the home situation we need to make backups much more aggressively: daily, and really do it, and we need a fractal scheme so we can go back to historical versions in case of selective or subtle corruption. For example, the backup discs are labelled 1, 2, 4, 8... and tape j is overwritten on (astronomical Julian) days divisble by j but not by 2j. The copy kept in the safe deposit box is in addition to this. During (or just before) the backup, the program's binary compare feature should be used, reporting altered files. We should humanly judge whether we were the ones who altered those files.
Being root, the hacker can read any file and ``su'' to become any user. The user's identification keys should be protected cryptographically by a good pass phrase. Both pgp and ssh do this. The privilege of logging onto another system without authentication should depend on the protected identification keys.
Unfortunately, it is difficult to use ssh effectively if you have to type a 35-byte pass phrase on every remote login. The whole point of .rhosts files is to obviate typing the password, so remote executions appear to be a seamless extension of the local session. Similarly, pgp runs on mail (or other) files individually and the pass phrase must be typed for each message to be signed, encrypted or decrypted. Unless the users are very serious about security, as at a bank or in military service, and sometimes not even then, they will avoid using the high security tools if the pass phrase has to be typed in more than a few times per day. Ssh includes a key agent which swallows the secret key of the user. The user's processes, such as ssh and slogin, can contact the agent and get a judgment that an encrypted challenge string actually decrypts to a provided value, implying that the user or host on the other end possesses the true authentication keys for the local user. Its socket is owned by the user and cannot be read by other ordinary users. Pgp has no such feature, but in theory it could be programmed to use the ssh key agent. [Update: pgp does now have a key agent, and it works.]
If the hacker does the root exploit while the user is logged in, he can open the key agent's socket and can do repeated challenges with carefully crafted data that (in theory) can reveal the secret key before the Sun turns into a cinder. In theory the key agent can use technological means to distinguish its session from the hacker's session. In theory the hacker can fake the session indicia, and in fact the hacker, as root, can root through memory, locate the key agent's data space, and (maybe) steal the key. With the present sophistication of hackers an attack on a key agent is unlikely, but as ssh becomes more common, we'll likely see exploit scripts which will locate any running key agents and perpetrate whatever exploit is feasible.
If we want users to routinely sign all mail, they should have three keys: a routine key, loaded in the key agent, which if stolen can be revoked and replaced with little loss; a secure signing key, for which the pass phrase must be typed each time it is used, and a secure encryption key, which can be surrendered in the (unlikely) event of a subpoena without compromising the signing key.