Introduction to Computer Crime
by M. E. Kabay, PhD, CISSP-ISSMP-ISSMP
Program Director, MSIA
School of Graduate Studies
Much of the following material was
originally published in the 1996 textbook,
NCSA Guide to Enterprise Security (McGraw Hill) and was most recently
updated with newer references
for use in Norwich University programs in July 2006.
Introduction to Computer Crime.
1 Sabotage: Albert the Saboteur.
6 Scavenging: Garbage Out, Data In.
7.2 1993-1994: Internet monitoring attacks.
7.3 Cases from the INFOSEC Year in Review Database.
8.3 Easter Eggs and the Trusted Computing Base.
8.5 Back Doors: Testing Source Code.
11.2 Renewable software licenses.
11.3 Circumventing logic bombs.
12.1 Some cases of data leakage:
12.6 Plugging covert channels.
One of the most interesting cases of computer sabotage
occurred at the National Farmers Union Service Corporation of
The next morning, management confronted Albert with the film of his actions and asked for an explanation. Albert broke down in mingled shame and relief. He confessed to an overpowering urge to shut the computer down. Psychological investigation determined that Albert, who had been allowed to work night shifts for years without a change, had simply become lonely. He arrived just as everyone else was leaving; he left as everyone else was arriving. Hours and days would go by without the slightest human interaction. He never took courses, never participated in committees, never felt involved with others in his company. When the first head crashes occurred–spontaneously – he had been surprised and excited by the arrival of the repair crew. He had felt useful, bustling about, telling them what had happened. When the crashes had become less frequent, he had involuntarily, and almost unconsciously, re‑created the friendly atmosphere of a crisis team. He had destroyed disk drives because he needed company.
In this case, I blame not Albert but the managers who relegated an employee to a dead‑end job and failed to think about his career and his morale. Preventing internal sabotage depends on proper employee relations. If Albert the Saboteur had been offered a rotation in his night shift, his employer might have saved a great deal of money.
Managers should provide careful and sensitive supervision of employees’ state of mind. Be aware of unusual personal problems such as serious illness in the family; be concerned about evidence of financial strains. If an employee speaks bitterly about the computer system, his or her job conditions, or conflicts with other employees and with management, TALK to them. Try to solve the problems before they blow up into physical attack.
Another crucial element in preventing internal and external sabotage is thorough surveillance. Perhaps your installation should have CCTV cameras in the computer room; if properly monitored by round‑the‑clock security personnel or perhaps even an external agency, such devices can either deter the attack in the first place or allow the malefactors to be caught and successfully prosecuted.
One of my favourite BC cartoons (drawn by Johnny Hart) shows two cavemen talking about a third: “Peter has a mole on his back,” says one. The other admonishes, “Don’t make personal remarks.” The final frame shows Peter walking by–with a grinning furry critter riding piggyback.
For readers whose native language is not English, “piggybacking” (origins unknown, according to various dictionaries) is the act of being carried on someone’s back and shoulders. It’s also known as pick‑a‑back. Kids like it.
So do criminals.
Now, if you are imagining masked marauders riding around on innocent victims’ backs, you must learn that in the world of information security, piggybacking refers to unauthorized entry to a system (physically or logically) by using an authorized person’s access code.
In a sense, piggybacking is a special case of impersonation–pretending to be someone else, at least from the point of view of the access-control system and its log files.
To interfere with physical piggybacking, we have to avoid making security a nuisance that employees will come to ignore out of contempt for ham-handed restrictions. For example, it is wise to control access to the areas that should be secure but not to unimportant areas.
The other crucial dimension of piggybacking is employee training. Everyone has to understand the risks of allowing normal politeness (e.g., letting in a colleague) to overcome security rules. Letting even authorized people into a secured area without registering their security IDs with the access-control system damages the audit trail but it also puts their safety at risk: in an emergency, the logs will incorrectly fail to indicate their presence in the secured area.
Using someone’s logged-on workstation is a favorite method used by penetration testers or criminals who have gained physical access to devices connected to a network. Such people can wear appropriate clothing and assume a casual, relaxed air to convince passers-by that they are authorized to use someone else’s workstation. Sometimes they pose as technicians and display toolkits while they are busily stealing information or inserting back doors into a target system.
Unattended workstations that are logged on are the principle portal for logical piggybacking. Even a workstation that is not logged on can be a vulnerability, since uncontrolled access to the operating system may allow an intruder to install keystroke-capture software that will log user IDs and passwords for later use.
A simple but non‑automatic method is to lock the keyboard by physical removal of a key when one leaves one’s desk. Because this method requires a positive action by the user, it is not likely to be fool‑proof – not because people are fools, but because we are not machines and so sometimes we forget things. In addition, any behavior that has no reinforcement tends to be extinguished; in the absence of dramatic security incidents, the perceived value of security measures inevitably falls.
There are two software solutions currently in use to prevent unauthorized use of a logged‑on workstation or PC when the rightful session‑owner is away:
· Automatic logoff after a period of inactivity
· Branch to a security screen after a timeout
One approach to preventing access at unattended logged‑on workstations is at the operating system level. The operating system or a background logoff program can monitor activity and abort a session that is inactive. These programs usually allow different groups to have different definitions of “inactive” to adapt to different usage patterns. For example, users in the accounting group might be assigned a 10‑minute limit on inactivity whereas users in the engineering group might get 30 minutes.
When using such utilities, it is critically important to measure the right things when defining inactivity. For instance, if a monitor program were to use only elapsed time, it could abort someone in the middle of a long transaction that requires no user intervention. On the other hand, if the monitor were to use only CPU activity, it might abort a process which was impeded by a database lock through no fault of its own.
Currently, PCs can be protected with the timeout features of widely‑available and inexpensive screen‑saver programs. They allow users to set a count‑down timer that starts after keyboard‑input; the screen saver then requests a password before wiping out the images of flying toasters, swans and whatnot. The critical question to ask before relying on such screen savers is whether they can be bypassed; for example, early versions of several Windows 3.11 and Windows 95 screensavers failed to block access to the CTL-ALT-DEL key combination and therefore allowed intruders to access the Task Manager window where the screensaver process could easily be aborted. Today’s screensavers are largely free of this defect.
A few suggestions for secure screen savers, timeout and shutdown utilities (these references are not endorsements):
Such utilities are relatively crude; application‑level timeouts are preferable to the blunt object approach of operating system‑level logoff utilities or generic screen-lock programs. Using application timeouts, a program can periodically branch to a security screen for re‑authentication. A security screen can ask for a password or for other authentication information such as questions from a personal profile. Best of all, such application-level functions, being programmed in by the development team that knows how the program will be used or is being used in practice. To identify inactivity, one uses a timed terminal read. A function can monitor the length of time since the last user interaction with the system and set a limit on this inactivity. At the end of the timed read, the program can branch to a special reauthentication screen. Filling in the right answer to a reauthentication question then allows the program to return to the original screen display. Since programmers can configure reauthentication to occur only after a reasonable period of inactivity, most people would not be inconvenienced.
A really smart program would actually measure response time for a particular entry screen for a particular user and would branch to the security screen only if the delay were much longer than usual; e.g., if 99% of all the cases where the John accessed the customer-information screen were completed within 5 minutes, the program would branch to the security screen after 5 minutes of inactivity. In contrast, if Jane took at most 10 minutes to complete 99% of her accesses to the employee-information screen, the program would not demand reauthentication until more than 10 minutes had gone by.
In summary, an ideal timeout facility would be written into application program to provide
· A configurable time‑out function with awareness of individual user usage patterns;
· Automatic branching to a security screen for sophisticated reauthentication;
· Integration with a security database, if available;
· Automatic return to the previous (interrupted) state to minimize disruption of work.
Short of programming your own, sophisticated user-monitoring system in home-grown programs, is there any hope for spotting the user that leaves a workstation logged on to the network?
In general, there are problems with any system that simply reads a single data entry from a token which can be removed or uses input that does not require repeated data transfer. If the authentication data don’t have to be supplied all the time, then the workstation and the program that is monitoring it cannot know that the user has left until a timeout occurs, just like any other software-based solution. For example, a single fingerprint entry, a single retinal scan, or a single swipe of a smart card are inadequate for detecting the departure of an authorized user because there is no change of state when the user leaves the area.
One approach to detecting the departure of an authorized user depends on access to a continuous stream of data or presence of a physical device; e.g., a system can be locked instantly when a user removes a smart card from a reader (or a USB token from the USB port) and then can be reactivated when the token is returned. Unfortunately, the presence of the physical device need not imply that the human being who uses it is still at the workstation. The problem might be reduced if the device were like an EZ-Pass proximity card that naturally got carried around by all users – perhaps as part of a general-purpose, required ID badge that could serve to open secured doors as well as grant access to workstations and specific programs.
Another approach to program‑based re‑authentication would prevent piggybacking by means of biometric devices such as facial- or iris-recognition systems and fingerprint recognition units. For example, a non-invasive facial- or iris-recognition system could be used programmatically to shut down access the moment the user leaves the workstation and reactivate access when the user returns. Similarly, a touchpad or mouse with a fingerprint-recognition device could continually reauthenticate a user silently and with no trouble at all whenever the user moves the cursor.
Another tool that might be used for programmatic verification of continuous presence at a keyboard is keyboard typing dynamics. Such systems learn how a user types a particular phrase as a method of authentication. However, with today’s increased processor speeds and sophisticated pattern-recognition algorithms, it ought to be possible to have a security module in a program learn how a user usually types – and then force reauthentication if the pattern doesn’t match the baseline. True, this system might produce false alarms after a three-martini lunch – but maybe that’s not such a bad idea after all.
Such sophisticated methods are still not readily available
in the workplace despite steadily falling costs and steadily rising reliability.
It will be interesting to see how the field evolves in coming years as
In 1970, Jerry Neal Schneider used “dumpster diving” to retrieve printouts
from the Pacific Telephone and Telegraph (PT&T) company in
In discussions of impersonation in an online forum, one contributor noted that with overalls and a tool kit, you can get in almost anywhere. You just produce your piece of paper and say, “Sorry, it says here that the XYZ unit must be removed for repair.”
In one of my courses some years ago, a participant recounted the following astonishing story:
A well‑dressed business man appeared at the offices of a large firm one day and appropriated an unused cubicle. He seemed to know his way around and quickly obtained a terminal to the host, pencils, pads, and so on. Soon, he was being invited out to join the other employees for lunch; at one point he was invited to an office party. During all this time, he never wore an employee badge and never told anyone exactly what he was doing. “Special research project,” he would answer with a secretive air. Two months into his tenure, my course participant, a feisty information security officer, noticed this man as she was walking through his area of the office. She asked others who he was and learned that no one knew. She asked the man for his employee ID, but he excused himself and hurried off. At this point, the security officer decided to call for the physical security guards. She even prevented the mystery man’s precipitous departure by running to the only elevator on the floor and diving into it before he could use it to escape.
It turned out that the man was a fired employee who was under indictment for fraud. He had been allowed into the building every morning by a confederate, a manager who was also eventually indicted for fraud. The manager had intimidated the security guards into allowing the “consultant” into the building despite official rules requiring everyone to have and wear valid employee passes. The more amazing observation is that in two months of unauthorized computer and office use, this man was never once stopped or reported by the staff working in his area.
This case illustrates the crucial importance of a sound corporate culture in ensuring that security rules are enforced.
Because so many people are hesitant to get involved in enforcing security rules, I recommend that security training include practice simulations of how to deal with unidentified people; anyone spotting such a person should call facilities security at once. One can even run drills by letting people know that there will be deliberate violations of the badge rule and that the first person to report the unbadged “intruder” will win a prize. Naturally, one should not terminate such practice drill – just keep it going indefinitely. Sooner or later, someone will report a real intruder.
This method of spotting intruders will fail, however, if authorized employees consistently fail to wear visible identification at all times on the organization’s property. The most common reason for such delinquency is that upper managers take off their badges as an unfortunate sign of high social status; naturally, eventually all employees end up taking off their badges. And then, since all it takes to look like one of the gang is not wearing an ID, the street door may as well be kept unlocked with a large sign pointing into the building reading, “Come steal stuff here.”
One of the most common forms of computer crime is data diddling – illegal or unauthorized data alteration. These changes can occur before and during data input or before output. Data diddling cases have included banks, payrolls, inventory, credit records, school transcripts, and virtually all other forms of data processing known.
One of the classic data diddling frauds was the Equity Funding
case, which began with computer problems at the Equity Funding Corporation of
The computer problems occurred just before the close of the financial year in 1964. An annual report was about to be printed, yet the final figures simply could not be extracted from the mainframe. In despair, the head of data processing told the president the bad news; the report would have to be delayed. Nonsense, said the president expansively (in the movie, anyway); simply make up the bottom line to show about $10,000,000.00 in profits and calculate the other figures so it would come out that way. With trepidation, the DP chief obliged. He seemed to rationalize it with the thought that it was just a temporary expedient, and could be put to rights later anyway in the real financial books.
The expected profit didn’t materialize, and some months later, it occurred to the executives at Equity that they could keep the stock price high by manufacturing false insurance policies which would make the company look good to investors. They therefore began inserting false information about nonexistent policy holders into the computerized records used to calculate the financial health of Equity.
In time, Equity’s corporate staff got even greedier. Not content with jacking up the price of their stock, they decided to sell the policies to other insurance companies via the redistribution system known as re‑insurance. Re‑insurance companies pay money for policies they buy and spread the risk by selling parts of the liability to other insurance companies. At the end of the first year, the issuing insurance companies have to pay the re‑insurers part of the premiums paid in by the policy holders. So in the first year, selling imaginary policies to the re‑insurers brought in large amounts of real cash. However, when it the premiums came due, the Equity crew “killed” imaginary policy holders with heart attacks, car accidents, and, in one memorable case, cancer of the uterus – in a male imaginary policy-holder.
By late 1972, the head of DP calculated that by the end of the decade, at this rate, Equity Funding would have insured the entire population of the world. Its assets would surpass the gross national product of the planet. The president merely insisted that this showed how well the company was doing.
The scheme fell apart when an angry operator who had to work overtime told the authorities about shenanigans at Equity. Rumors spread throughout Wall Street and the insurance industry. Within days, the Securities and Exchange Commission had informed the California Insurance Department that they’d received information about the ultimate form of data diddling: tapes were being erased. The officers of the company were arrested, tried, and condemned to prison terms.
What can we learn from Equity Funding scandal? Here are some thoughts for discussion:
As managers, make it clear in writing and behaviour that no illegality will be tolerated in your organization. Provide employees with information on what to do if their complaints of malfeasance are not taken seriously by their superiors. You may demonstrate the seriousness of your commitment to honesty by including instructions on how to reach legal or regulatory authorities.
As employees, be suspicious of any demands that you break documented rules, unspoken norms of data processing, or the law. For example, if you are asked to fake a delay in running a program–for any ostensible reason whatsoever–write down the time and date of the request and who asked you to do it. I know that it’s easy to give advice when one doesn’t bear the consequences, but at least see if it’s possible to determine why you are being asked to dissimulate. If you’re braver than most people, you can try seeing what happens if you flatly refuse to lie. Who knows, you might be the pin that bursts whatever bubble your superiors are involved in.
If you notice an irregularity–e.g., a high‑placed official apparently doing extensive data entry–see if you can discreetly find out what’s happening. See what kind of response you get if you politely inquire about it. If a high‑placed employee tries to enter the computer room without authorization, refuse access until your own supervisor authorizes entry–preferably in writing.
If you do come to the conclusion that a crime is being committed, inform your supervisor–if (s)he seems to be honest. Otherwise, inform the appropriate civic or other authorities when you have evidence and your doubts are gone. At least you can escape being arrested yourself as a co‑conspirator.
“Superzap” was an IBM utility that bypassed normal operating system controls. The term eventually became a generic word; with such a program, a user with the appropriate access and privileges could read, modify, or destroy any data on the system, whether in memory or on disk. Such tools can sometimes allow the user to avoid leaving an audit trail. Worse, normal application controls may be ignored; e.g., requirements for referential integrity in databases, respect for business rules, and authorization restrictions limiting access to specific people or roles.
What kinds of utilities qualify as superzaps?
In my own experience, I was told by one customer, a service bureau, that one of its customers regularly used a superzap program to modify production data. Other than warning the managers that such a procedure is inherently risky, there was nothing the bureau could do about it.
When I was running operations at a service bureau in the 1980s, I discovered that a programmer made changes directly in spoolfiles (spooled print files) on a monthly basis to correct a persistent error that had never been fixed in the source code. If such shenanigans were going on in a mere report, what might be happening in, say, print runs of checks?
So why tolerate superzaps at all?
Superzap programs serve us well in emergencies. No matter how well planned and well documented, any system can fail. If a production system error has to be circumvented NOW, patching a program, fixing a database pointer, or repairing an incorrect check-run spoolfile may be the very best solution as long as the changes are authorized, documented, and correct. However, repeated use of such utilities to fix the same problems indicates a problem of priorities. Fix the problem now, yes; but find out what caused the problem and solve the root causes as well.
Powerful system utilities that bypass normal controls can be used to damage data and code. Network managers can control such “superzap” programs by limiting access to them; software designers can help network managers by enforcing capability checking at run-time.
Security systems using menus can restrict users to specific tasks; the usual security matrix can prevent unauthorized access to powerful utility programs. Some programs themselves can check to see that prospective users actually have appropriate capabilities (e.g., root access). Ad hoc query programs can sometimes be restricted to read-only in any given database.
On some systems, access control lists (ACLs) permit explicit inclusion of user sets which may access a file (including superzap programs) for read and write operations.
Aside from using normal operating system security, one can also disable programs temporarily in ways which interfere with (they don’t preclude) unauthorized access; e.g., a system manager can reversibly remove the capabilities allowing interactive or batch execution from dangerous programs.
It may be desirable to eliminate certain tools altogether from general availability. For example, special diagnostic utilities which replace the operating system should routinely be inaccessible to unauthorized personnel. Such diagnostic tools could be kept in a safe, for example, with written authorization required for access. In an emergency, the combination to the safe might be obtained from a sealed, signed envelope which would betray its having been opened. I can even imagine a cartoon showing a sealed glass box containing such an envelope on the computer room wall with the words, “IN CASE OF EMERGENCY, BREAK GLASS” to be sure that the emergency crew could get the disk or cartridge if it had to.
When printing important files such a runs of checks, it may be wise to print “hot” instead of spooling the output. That is, have the program generating the check images control a secured printer directly rather than passing through the usual buffers. Make sure that the printer is in a locked room. Arrange to have at least two employees watching the print run. If a paper jam requires the run to be started again, arrange for appropriate parameters to be passed to prevent printing duplicates of checks already produced.
Regardless of all the access-control methods described above, if an authorized user wishes to misuse a superzap program, there is only one way to prevent it: teamwork. By insisting that all use of superzaps be done with at least two members of the staff present, one can reduce the likelihood of abuse. Reduce, not eliminate: there is always the possibility of collusion. Nonetheless, if only a few percent (say, two percent for the sake of the argument) of all employees are potential crooks, then the probability of getting two crooks on the same assignment by chance alone is about 0.04%. True, the crooks may cluster together preferentially, but in any case, having two people using privileged-mode DEBUG to fix data in a database seems better than having just one.
One method that will certainly NOT work is the ignorance-is-bliss approach. I have personally heard many network managers dismiss security concerns by saying, “Oh, no one here knows enough to do that.” This is a short-sighted attitude, since almost everything described above is fully documented in vendor and contributed software library publications. Recalling that managers are liable for failures to protect corporate assets, I urge all network managers to think seriously about these and other security issues rather than leaving them to chance and the supposed ignorance of a user and programmer population.
Sometimes it’s the little details that destroy the effectiveness of network security. Firewalls, intrusion-detection systems, token-based and biometric identification and authentication – all of these modern protective systems can be circumvented by criminals who take advantage of what few people ever think about: garbage.
Computer crime specialists have described unauthorized access to information left on discarded media as scavenging, browsing, and Dumpster‑diving (from the trademarked name of metal bins often used to collect garbage outside office buildings).
Discarded garbage is not considered private
property under the law in the
“The Fourth Amendment does not prohibit the warrantless search and seizure of garbage left for collection outside the curtilage of a home.... Since respondents voluntarily left their trash for collection in an area particularly suited for public inspection, their claimed expectation of privacy in the inculpatory items they discarded was not objectively reasonable. It is common knowledge that plastic garbage bags left along a public street are readily accessible to animals, children, scavengers, snoops, and other members of the public. Moreover, respondents placed their refuse at the curb for the express purpose of conveying it to a third party, the trash collector, who might himself have sorted through it or permitted others, such as the police, to do so. The police cannot reasonably be expected to avert their eyes from evidence of criminal activity that could have been observed by any member of the public.....”
In other words, anything we throw out is fair
game, at least in the
NewsScan authors John Gehl and Suzanne Douglas summarized the rest of the story as follows: In mid-2000,
Microsoft . . . [complained] that various organizations
allied to it have been victimized by industrial espionage agents who attempted
to steal documents from trash bins. The organizations include the Association
for Competitive Technology in
Saying he was exercising a “civic duty,” Oracle
chairman and founder Lawrence J. Ellison defended his company of suggestions
that Oracle’s behavior was “Nixonian” when it hired private detectives to scrutinize
organizations that supported Microsoft’s side in the antitrust suit brought
against it by the government. The investigators went through trash from those
organizations in attempts to find information that would show that the organizations
were controlled by Microsoft. Ellison, who, like his nemesis Bill Gates at Microsoft,
is a billionaire, said, “All we did was to try to take information that was
hidden and bring it into the light,” and added: “We will ship our garbage to
[Microsoft], and they can go through it. We believe in full disclosure.” “The
only thing more disturbing than Oracle’s behavior is their ongoing attempt to
justify these actions,” Microsoft said in a statement. “Mr. Ellison now appears
to acknowledge that he was personally aware of and personally authorized the
broad overall strategy of a covert operation against a variety of trade associations.”
(New York Times
Discarded information can reside on paper, magnetic disks and tapes, and even electronic media such as PC-card ram disks. All of them have special methods for obliterating the unwanted information. I don’t want to spend much time on paper, carbon papers, and printer ribbons; the obvious methods for disposing of these media are so simple they need little explanation. One should ensure that sensitive paper documents are shredded; the particular style of shredding depends on the degree of sensitivity and the volume of sensitive papers. Cross-cut shredders, locked recycling boxes and secure shredding services that reliably take care of such problems are well established in industry.
At this point, I suggest that readers take a look around their own operations and find out how discarded paper, electronic and magnetic media containing confidential information are currently handled. With this information in hand, you’ll be able to read the upcoming articles with your own situation well in mind.
The first area to look at is the least obvious: electronic storage. Data are stored in the main random-access memory (RAM, as in “This computer has 128 MB of RAM) in computers whenever the data are in use. Until the system is powered off, data can be captured through memory dumps and stored on non-volatile media such as CD-ROM. Forensic specialists use this approach as one of the most important steps in seizing evidence from systems under investigation. However, criminals with physical access to a PC or other computer may be able to do the same if there is inadequate logging enabled on the system. Furthermore, even if the system is powered off and rebooted, thus destroying the contents of main memory, most systems use virtual memory (VM) which extends main memory by swapping data to and from a reserved area of a hard disk. Examining the hard disk (usually with special forensic software) allows a specialist to locate a great deal of information from RAM such as keyboard, screen and file buffers and process stacks (containing the global variables used by a program plus the data in use by subroutines at the time the swap occurred). Although there is never a guarantee of what will be found in the swap file, rummaging around with text-search tools can reveal logon IDs, passwords, and fragments of recently active and possibly confidential documents. The most alarming aspect of swap files is that they may contain cleartext versions of encrypted files; any decryption algorithm necessarily has to put a decrypted version of the ciphertext somewhere in memory to make it accessible by the authorized user of the decryption key.
Physical protection of a workstation to preclude access to the hardware is the most cost-effective mechanism for preventing scavenging via the swap files as well as to reduce scavenging of disk-resident data. Tools such as secure cabinets, anti-theft cables, movement-sensitive alarms, locks for diskette drives, and special screws to make it more difficult to enter the processor card cage all make illicit or undetected access more difficult.
While we’re on the topic of RAM, most handheld computers use RAM for storage. What happens when you have to return such a system for repairs? Users can set passwords to hide information on some systems (e.g., Palm Pilots) but there are lots of programs for cracking the passwords of these devices. If it is possible to overwrite memory completely, I recommend that the user do so before having the device repaired or exchanged. If the system is nonfunctional, administrators should decide whether the relatively low cost of replacing the unit is justified to maintain security. Old handheld computers make excellent and original coasters for hot or cold drinks; they can also be used as very short-lived Frisbees.
One issue worth mentioning in connection with disks is that some documents may contain more information than the sender intends to release. MS-Office documents, for example, have a PROPERTIES sheet that some people never seem to check before sending their documents to others. I have noticed Properties sheets with detailed Comments or Keywords fields that reveal far too much about the motives underlying specific documents; others include detailed or out-dated information about reporting structures such as the name of the sender’s manager (a real treat for social engineering adepts). Users of MS-Word should turn off the FAST SAVE “feature” that was useful when saving to slow media such as floppy disks but that is now completely useless and even dangerous: FAST SAVE allows deleted materials to remain in the MS-Word document. Worse yet is the danger of turning on “TOOLS | TRACK CHANGES” but turning off the options to “Highlight changes on screen” and “Highlight changes in printed document.” In this configuration, Word maintains a meticulous record of exactly who made which changes – including deletions – in the document but does not display the audit trail. Someone receiving such a document can restore the display functions at the click of a mouse and read potentially damaging information about corporate intentions, background information and bargaining positions. All documents destined for export should be checked for properties and track changes. My own preference when exchanging documents is to create a PDF (Portable Document Format) file using Adobe Acrobat – and to check the output to see that it conforms to my expectations.
What should network administrators do about sensitive information on hard disks that are being sent out to third parties as part of workstations that need repairs, in exchange programs or as charitable donations?
In general, the most important method for protecting sensitive data on disk is encryption. If you routinely encrypt all sensitive data then only the swap file will be of concern (see the previous column in this series). However, many organizations do not require encryption on desktop systems even if laptop systems must use encrypting drivers. If you decide that the hard disk be “wiped” before sending it out, be sure that you use adequate tools for such wiping.
As many readers know, deleting a file under most operating systems usually means removing the pointer to the first part (extent, cluster) of the file from the disk directory (file allocation table or FAT under the Windows operating systems). The first character of the file name may be obliterated, but otherwise, the data remain unchanged in the now-discarded file. Unless the disk sectors are allocated to another file and overwritten by new data, the original data will remain accessible to utilities that can reconstruct the file by searching the unallocated clusters all over the disk and offering a menu of potentially recoverable data. With the size of today’s hard disks, free space can be in the gigabytes, the clusters containing discarded data may not be overwritten for a long time.
Quick formatting a disk drive reinitializes file system structures such as the file allocation table but leaves the raw file data untouched. Full formatting using the operating system is a high-level format that leaves data in a recoverable state. Low-level formatting is normally carried out at the factory and establishes sectors, cylinders and address information for accessing the drive. Low-level formatting may render all data previously stored on a disk inaccessible to the operating system but not necessarily to specialized recovery programs.
One inadequate method for obliterating data that I have heard people recommend is regular defragmentation. Moving existing files around on disk to ensure that each file uses the minimum number of contiguous blocks of disk space will likely overwrite blocks of recently liberated file clusters. However, there is no guarantee that existing free space containing data residues will be overwritten.
It is best to obliterate sensitive hard disk data at the time you discard the files. File shredder programs (use any search engine with keywords “file shredder program review” for plenty of suggestions) can substitute for the normal delete function or wastebasket. These tools overwrite the contents of a file to be discarded before deleting it with the operating system. However, a single-pass shredder may allow data to be recovered using special equipment; to make data recovery impossible, use military-grade obliteration that uses seven passes of random data.
Unfortunately, even shredder programs may not solve the problem for ultra-high sensitivity data. Because file systems generally allocate space in whole number of clusters, an end-of-file (EOF) that falls anywhere short of the end of a cluster leaves slack space between the EOF and the end of the cluster. Slack space does not normally get overwritten by the file system, so it is extremely difficult to get rid of these fragments unless you use shredder programs that specifically take this problem into account.
One tool that is used by the US Department of Defense for wiping disks is WipeDrive
< http://www.whitecanyon.com/wipedrive.php
>. The documentation specifies that the product genuinely wipes all data
from a hard drive, regardless of operating system and format. The tool can
even be run from a boot disk. It is licensed to individual technicians rather
than to specific PCs, thus making it ideal for corporate use. [I have no involvement
with CleanDrive or its makers and this reference does not constitute an endorsement.]
File shredder programs are a double-edged sword. They allow honest employees to obliterate company-confidential data from disks but they also allow dishonest employees to obliterate incriminating information from disks. One program review includes the words, “The program’s even got a trial copy you can download for free. So try it out and get those... ummm... errr... personal files off your work PC before the boss sends his computer gurus out to check your machine.” This advice is clearly not directed at system administrators or to honest employees.
Telling the difference between the good guys and the bad guys is a management issue and has been discussed in previous articles published in this newsletter. However, as a precaution, I recommend that corporate policies specifically forbid the installation of file-shredder programs on corporate systems without authorization.
One quick note about magnetic tapes: beware the scratch tape. In older environments where batch processing still uses tapes as intermediate storage space during jobs, it is customary to have a rack of “scratch” tapes that can be used on demand by any application or job. There have been documented cases in which data thieves regularly read scratch tapes to scavenge left-over data from competitors or for industrial espionage. Scratch tapes should be erased before being re-used.
As for broken or obsolete magnetic media such as worn-out diskettes, used-up magnetic tapes and dead disk drives, the worst thing to do is just to throw this stuff into the regular garbage.
Security experts recommend physical destruction of such media using band saws, industrial incineration services capable of handling potentially toxic emissions and even sledge hammers.
In conclusion, all of us need to think about the data residues that are exposed to scavengers. Whether you work in a mainframe shop or a PC environment, whether your organization is a university or a vulture capitalist firm, it’s hard to, ah, carrion when data scavengers steal our secrets.
Some of my younger students have expressed bewilderment over the term Trojan “horse.” They associate “Trojan” with condoms and with evil programs. Here’s the original story:
...But
[The Horse is then dragged into the walled city of
...In the night, the armed men who were enclosed in
the body of the horse...opened the gates of the city to their friends, who had
returned under cover of the night. The city was set on fire; the people, overcome
with feasting and sleep, put to the sword, and
Bullfinch’s Mythology thus describes the original Trojan Horse. See < http://homepage.mac.com/cparada/GML/WOODENHORSE.html > for extensive information about the story. Today’s electronic Trojan is a program which conceals dangerous functions behind an outwardly innocuous form.
One of the nastiest tricks played on the shell‑shocked world of microcomputer users was the FLU‑SHOT‑4 incident of March 1988. With the publicity given to damage caused by destructive, self‑replicating virus programs distributed through electronic bulletin board systems (BBS), it seemed natural that public‑spirited programmers would rise to the challenge and provide protective screening.
He reported the incident immediately to his superior
officers. Panic ensued until
Some of the first PC Trojans included
Trojan attacks on the Internet were discovered in late
1993. Full information about all such attacks is available on the World Wide
Web site run by CIAC, the Computer Incident Advisory Capability of the
CIAC and other response teams have observed many compromised systems surreptitiously monitoring network traffic, obtaining username, password, host‑name combinations (and potentially other sensitive information) as users connect to remote systems using telnet, rlogin, and ftp. This is for both local and wide area network connections. The intruders may (and presumably do) use this information to compromise new hosts and expand the scope of the attacks. Once system administrators discover a compromised host, they must presume monitoring of all network transactions from or to any host “visible” on the network for the duration of the compromise, and that intruders potentially possess any of the information so exposed. The attacks proceed as follows. The intruders gain unauthorized, privileged access to a host that supports a network interface capable of monitoring the network in “promiscuous mode,” reading every packet on the network whether addressed to the host or not. They accomplish this by exploiting unpatched vulnerabilities or learning a username, password, host‑name combination from the monitoring log of another compromised host. The intruders then install a network monitoring tool that captures and records the initial portion of all network traffic for ftp, telnet, and rlogin sessions. They typically also install “Trojan” programs for login, ps, and telnetd to support their unauthorized access and other clandestine activities.
System administrators must begin by determining if
intruders have compromised their systems. The
CIAC works closely with CERT-CC, the
A few weeks later, CIAC issued Bulletin E-12, which warned ominously,
The number of Internet sites compromised by the ongoing series of network monitoring (sniffing) attacks continues to increase. The number of accounts compromised world‑wide is now estimated to exceed 100,000. This series of attacks represents the most serious Internet threat in its history.
IMPORTANT: THESE NETWORK MONITORS DO NOT SPECIFICALLY TARGET INFORMATION FROM UNIX SYSTEMS; ALL SYSTEMS SUPPORTING NETWORK LOGINS ARE POTENTIALLY VULNERABLE. IT IS IMPERATIVE THAT SITES ACT TO SECURE THEIR SYSTEMS.
Attack Description
The attacks are based on network monitoring software, known as a “sniffer”, installed surreptitiously by intruders. The sniffer records the initial 128 bytes of each login, telnet, and FTP session seen on the local network segment, compromising ALL traffic to or from any machine on the segment as well as traffic passing through the segment being monitored. The captured data includes the name of the destination host, the username, and the password used. This information is written to a file and is later used by the intruders to gain access to other machines.
Finally, another CIAC alert (E-20, May 6, 1994) warned of “A Trojan‑horse program, CD‑IT.ZIP, masquerading as an improved driver for Chinon CD‑ROM drives, [which] corrupts system files and the hard disk.” This program affects any MS-DOS system where it is executed.
1997.04.29 The Department of Energy’s Computer Incident Advisory Capability (CIAC) warned users not to fall prey to the AOL4FREE.COM Trojan, which tries to erase files on hard drives when it is run. A couple of months later, the NCSA worked with AOL technical staff to issue a press release listing the many names of additional Trojans; these run as TSRs (Terminate - Stay Resident programs) and capture user IDs and passwords, then send them by e-mail to Bad People. Reminder: do NOT open binary attachments at all from people you don’t know; scan all attachments from people you do know with anti-virus and anti-Trojan programs before opening. (EDUPAGE)
1997-11-06 Viewers of pornographic pictures on the sexygirls.com
site were in for a surprise when they got their next phone bills.
1998-01-05 Jared Sandberg, writing in the Wall Street Journal, reported on widespread fraud directed against naïve AOL users using widely-distributed Trojan Horse programs (“proggies”) that allow them to steal passwords. Another favorite trick that fools gullible users is the old “We need your password” popup that claims to be from AOL administrators. AOL reminds everyone that no one from AOL will ever ask users for their passwords.
1999-01-29 Peter Neumann summarized a serious case of software
contamination in RISKS 20.18: At least 52 computer systems downloaded a TCP
wrapper program directly from a distribution site after the program had been
contaminated with a Trojan horse early in the morning of
1999-05-28 Network Associates Inc. anti-virus labs warned of a
new Trojan called BackDoor-G being sent around the Net as spam in May. Users
were tricked into installing “screen savers” that were nothing of the sort.
The Trojan resembled the previous year’s Back Orifice program in providing remote
administration — and back doors for criminals to infiltrate a system. A variant
called “Armageddon” appeared within days in
1999-06-11 The Worm.Explore.Zip (aka “Trojan Explore.Zip) worm
appeared in June as an attachment to e-mail masquerading as an innocuous compressed
WinZIP file. The executable file used the icon from WinZIP to fool people into
double-clicking it, at which time it began destroying files on disk. Within
a week of its discovery in
1999-09-20 A couple of new Y2K-related virus/worms packaged as Trojan Horses were discovered in September. One e-mail Trojan called “Y2Kcount.exe” claimed that its attachment was a Y2K-countdown clock; actually it also sent user IDs and passwords out into the Net by e-mail. Microsoft reported finding eight different versions of the e-mail in circulation on the Net. The other, named “W32/Fix2001” came as an attachment ostensibly from the system administrator and urged the victims to install the “fix” to prevent Internet problems around the Y2K transition. Actually, the virus/worm would replicate through attachments to all outbound e-mail messages from the infected system. [These malicious programs are called “virus/worms” because they integrate into the operating system (i.e., they are virus-like) but also replicate through networks via e-mail (i.e., they are worm-like).]
2000-01-03 Finjan Software Blocks Win32.Crypto the First Time: Finjan Software, Inc. announced that its proactive first-strike security solution, SurfinShield Corporate, blocks the new Win32.Crypto malicious code attack. Win32.Crypto, a Trojan executable program released in the wild today, is unique in that infected computers become dependant on the Trojan as a “middle-man” in the operating system. Any attempt to disinfect it will result in the collapse of the operating system itself. It is a new kind of attack with particularly damaging consequences because attempting to remove the infection may render the computer useless and force a user to rebuild their system from scratch.
2000-08-29 Software companies . . . reported that the first . .
. [malware] to target the Palm operating system has been discovered. The bug,
which uses a “Trojan horse” strategy to infect its victims, comes disguised
as pirated software purported to emulate a Nintendo Gameboy on Palm PDAs and
then proceeds to delete applications on the device. The . . . [malware] does
not pose a significant threat to most users, says Gene Hodges, president of
Network Associates’ McAfee division, but signals a new era in technological
vulnerability: “This is the beginning of yet another phase in the war against
hackers and virus writers. In fact, the real significance of this latest Trojan
discovery is the proof of concept that it represents.” (Agence
2000-10-27 Microsoft’s internal computer network was invaded by
the QAZ “Trojan horse” software that caused company passwords to be sent to
an e-mail address in
However, within a few days, Microsoft . . . [said] that network vandals were
able to invade the company’s internal network for only 12 days (rather than
5 weeks, as it had originally reported), and that no major corporate secrets
were stolen. Microsoft executive Rick Miller said: “We started seeing these
new accounts being created, but that could be an anomaly of the system. After
a day, we realized it was someone hacking into the system.” At that point Microsoft
began monitoring the illegal break-in, and reported it to the FBI. Miller said
that, because of the immense size of the source code files, it was unlikely
that the invaders would have been able to copy them. (AP/Washington Post
2002-01-19 A patch for a vulnerability in the AOL Instant Messenger (AIM) program was converted into a Trojan horse that initiated unauthorized click-throughs on advertising icons, divulged system information to third parties and browsed to porn sites.
2002-03-11 The “Gibe” worm was circulated in March 2002 as a 160KB
EXE file attached to a cover message pretending to be a Microsoft alert explaining
that the file was a “cumulative patch” and pointing vaguely to a Microsoft security
site. Going to the site showed no sign of any such patch, nor was there a digital
signature for the file. However, naive recipients were susceptible to the trick.
[MORAL: keep warning recipients not to open unsolicited attachments in e-mail.]
2002-04-03 Nicholas C. Weaver warned in RISKS that the company Brilliant Digital (BD) formally announced distribution of Trojan software via the Kazaa peer-to-peer network software. The BD software would create a P2P server network to be used for distributed storage, computation and communication -- all of which would pose serious security risks to everyone concerned. Weaver pointed out that today’s naïve users appear to be ready to agree to anything at all that is included in a license agreement, whether it is in their interests or not.
2003-02-14 E-mail purporting to offer revealing photos of Catherine
Zeta-Jones, Britney Spears, and other celebrities is actually offering something
quite different: the secret installation of Trojan horse software that can be
used by intruders to take over your computer. Users of the Kazaa file-sharing
service and IRC instant messaging are at risk. (Reuters/USA Today
2003-05-22 Data security software developer Kaspersky Labs reports that a new Trojan program, StartPage, is exploiting an Internet Explorer vulnerability for which there is no patch. If a patch is not released soon, other viruses could exploit the vulnerability. StartPage is sent to victim addresses directly from the author and does not have an automatic send function. The program is a Zip-archive that contains an HTML file. Upon opening the HTML file, an embedded Java-script is launched that exploits the “Exploit.SelfExecHtml” vulnerability and clandestinely executes an embedded EXE file carrying the Trojan program.
2003-07-14 Close to 2,000 Windows-based PCs with high-speed Internet
connections have been hijacked by a stealth program and are being used to send
ads for pornography, computer security experts warned. It is unknown exactly
how the trojan (dubbed “Migmaf” for “migrant Mafia”) is spreading to victim
computers around the world, whose owners most likely have no idea what is happening,
said Richard M. Smith, a security consultant in
2004-01-08 BackDoor-AWQ.b is a remote access Trojan written in Borland Delphi, according to McAfee, which issued an alert Tuesday, January 6. An email message constructed to download and execute the Trojan is known to have been spammed to users. The spammed message is constructed in HTML format. It is likely to have a random subject line, and its body is likely to bear a head portrait of a lady (loaded from a remote server upon viewing the message). The body contains HTML tags to load a second file from a remote server. This file is MIME, and contains the remote access Trojan (base64 encoded). Upon execution, the Trojan installs itself into the %SysDir% directory as GRAYPIGEON.EXE. A DLL file is extracted and also copied to this directory (where %Sysdir% is the Windows System directory, for example C:\WINNT\SYSTEM32) The following Registry key is added to hook system startup: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion \RunOnce “ScanRegedit” = “%SysDir%\GRAYPIGEON.EXE” The DLL file (which contains the backdoor functionality) is injected into the EXPLORER.EXE process on the victim machine. More information, including removal instructions, can be found at: http://us.mcafee.com/virusInfo/default.asp?id=description &virus_k=100938
2004-01-09 A Trojan horse program that appears to be a Microsoft
Corp. security update can download malicious code from a remote Web site and
install a back door on the compromised computer, leaving it vulnerable to remote
control. Idefense Inc., a Reston,