12.4 The Risks of Downloaded Code

only for RuBoard - do not distribute or recompile

Fred McLain's Internet Exploder showed that an ActiveX control can turn off your computer. But it could have done far worse damage. Indeed, it is hard to exaggerate the attacks that could be written and the subsequent risks of executing code downloaded from the Internet.

12.4.1 Programs That Spend Your Money

Increasingly, programs running computers can spend the money of their owners. What happens when money is spent by a program without the owner's permission? Who is liable for the funds spent? How can owners prevent these attacks? To answer these questions, it's necessary to first understand how the money is being spent.

12.4.1.1 Telephone billing records

One of the first recorded cases of a computer program that could spend money on behalf of somebody else was the pornography viewer distributed by the Sexygirls web site (described earlier in this chapter).

In this case, what made it possible for the money to be spent was the international long distance system, which already has provisions for billing individuals for long distance telephone calls placed on telephone lines. Because a program running on the computer could place a telephone call of its choosing, and because there is a system for charging people for these calls, the program could spend money.

Although the Sexygirls pornography viewer spent money by placing international telephone calls, it could just as easily have dialed telephone numbers in the 976 exchange or the 900 area code, both of which are used for teletext services. The international nature of the telephone calls simply makes it harder for authorities to refund the money spent, because the terms of these calls are subject to international agreements.

One way to protect against these calls would be to have some sort of trusted operating system that does not allow a modem to be dialed without informing the person sitting at the computer. Another approach would be to limit the telephone's ability to place international telephone calls, in the same way that telephones can be blocked from calling 976 and 900 numbers.^[6] But ultimately, it might be more successful to use the threat of legal action as a deterrent against this form of attack.

^[6] There is a perhaps apocryphal story of a New York City janitor who got his own 976 number in the 1980s and called it from the telephone of any office that he cleaned. Blocking calls to the 976 exchange and the 900 area code prevents such attacks.

12.4.1.2 Electronic funds transfers

If you use your computer for home banking, then a hostile program can initiate a funds transfer without your knowledge. Although it sounds difficult to do, in fact it has already been demonstrated. As we mentioned earlier, in February 1997, Germany's Chaos Computer Club demonstrated an ActiveX control that would hack into a copy of Quicken running on a Windows-based PC and initiate funds transfers, all without the user entering any passwords into the program. The control worked by finding a communications buffer used by the European version of Quicken and preloading the buffer with transactions.

12.4.2 Programs That Violate Privacy and Steal Confidential Information

One of the easiest attacks for downloaded code to carry out against a networked environment is the systematic and targeted theft of private and confidential information. The reason for this ease is the network itself: besides being used to download programs to the host machine, the network can be used to upload confidential information. Unfortunately, this type of attack can also be one of the most difficult threats to detect and guard against.

A program that is downloaded to an end user's machine can scan that computer's hard disk or the network for important information. This scan can easily be masked to avoid detection. The program can then smuggle the data to the outside world using the computer's network connection.

12.4.2.1 A wealth of private data

Programs running on a modern computer can do far more than simply scan their own hard drives for confidential information; they can become eyes and ears for attackers:

Any computer that has an Ethernet interface can run a packet sniffer eavesdropping on network traffic, capturing passwords, and generally compromising a corporation's internal security.
Once a program has gained a foothold on one computer, it can use the network to spread worm-like to other computers. Robert T. Morris' Internet Worm used this sort of technique to spread to thousands of computers on the Internet in 1988. Computers running Windows 95/98/ME are considerably less secure than the Unix computers that were penetrated by the Internet Worm, and usually much less well administered. And while Windows NT, 2000, and XP do offer more advanced security controls, the simple fact is that the overwhelming number of these systems are not properly managed or maintained. Even Windows systems operated by Microsoft have been broken into, potentially compromising personal data. The CodeRed worms of late 2001 are an abject realization of these risks.
Programs that have access to audio or video devices can bug physical space. Few computers have small red lights to indicate when the microphone is on and listening or when the video camera is recording. A bugging capability can even be hidden in programs that legitimately have access to your computer's facilities: imagine a video conferencing ActiveX control that sends selected frames and an audio track to an anonymous computer somewhere in South America.
Companies developing new hardware should have even deeper worries. Imagine a chip manufacturer that decides to test a new graphic accelerator using a multiuser video game downloaded from the Internet. What the chip manufacturer doesn't realize is that as part of the game's startup procedure it benchmarks the hardware on which it is running and reports the results back to a central facility. Is this market research on the part of the game publisher or industrial espionage on the part of its parent company? It's difficult to tell.

Firewalls Offer Little Protection

In recent years, many organizations have created firewalls to prevent break-ins from the outside network. But there are many ways that information can be smuggled through even the most sophisticated firewall. Consider:

The information could be sent by electronic mail.
The information could be encrypted and sent by electronic mail.
The information could be sent via HTTP using GET or POST commands.
The information could be encoded in domain name service queries.
The information could be posted in a Usenet posting, masquerading as a binary file or image.
The information could be placed in the data payload area of IP ping packets.
An attacker program could scan for the presence of a modem and use it.

Confidential information can be hidden so that it appears innocuous. For example, it can be encrypted, compressed, and put in the message ID of mail messages. The spaces after periods can be modulated to contain information. Word choice itself can be altered to encode data. The timing of packets sent over the network can be modulated to hide still more information. Some data hiding schemes are ingenious; information that is compressed, encrypted, and hidden in this manner is mathematically indistinguishable from noise.

Computers that are left on 24 hours a day can transmit confidential information at night, when such actions are less likely to be observed. They can scan the keyboard for activity and only transmit when the screensaver is active (indicating that the computer has been left alone).

12.4.3 Signed Code Is Not Safe Code

Code signing does not provide users with a safe environment to run their programs. Instead, code signing is intended to provide users with an audit trail. If a signed program misbehaves, you should be able to interrogate the signed binary and decide who to sue. And as Fred McLain's Internet Exploder demonstrates, once the author of a malicious applet is identified, the associated software publisher's credentials can be revoked, preventing others from being harmed by the signed applet.

Unfortunately, security through code signing has many problems:

Audit trails are vulnerable

Once it is running, a signed ActiveX control might erase the audit trail that would allow you to identify the applet and its author. Or the applet might merely edit the audit trail, changing the name of the person who actually signed it to "Microsoft, Inc." The control might even erase itself, further complicating the task of finding and punishing the author. Current versions of Microsoft's Internet Explorer don't even have audit trails, although audit trails may be added to a later release.

The damage that an ActiveX control does may not be immediately visible

Audit trails are only useful if somebody looks at them. Unfortunately, there are many ways that a rogue piece of software can harm the user, each of which is virtually invisible to that person. For example, a rogue control could turn on the computer's microphone and transform it into a clandestine room bug. Or the applet could gather sensitive data from the user, for instance, by scanning the computer's hard disk for credit card numbers. All of this information could then be surreptitiously sent out over the Internet.

Authenticode does not protect the user against bugs and viruses

Signed, buggy code can do a great deal of damage. And signed controls by legitimate authors may be accidentally infected with viruses before signing and distribution.

Signed controls may be dangerous when improperly used

Consider an ActiveX control written for the express purpose of deleting files on the user's hard drive. This control might be written for a major computer company and signed with that company's key. The legitimate purpose of the control might be to delete temporary files that result from installing software. Since the name of the file that is deleted is not hardcoded into the control, but instead resides on the HTML page, an attacker could distribute the signed control as is and use it to delete files that were never intended to be deleted by the program's authors.

The Authenticode software is itself vulnerable

The validation routines used by the Authenticode system are themselves vulnerable to attack, either by signed applets with undocumented features or through other means, such as Trojan horses placed in other programs.

Ultimately, the force and power of code signing is that companies that create misbehaving applets can be challenged through the legal system. But will ActiveX audit trails hold up in a court of law? If the company that signed the control is located in another country, will it even be possible to get them into court?

Code signing does prove the integrity and authenticity of a piece of software purchased in a computer store or downloaded over the Internet. But code signing does not promote accountability because it is nearly impossible to tell if a piece of software is malicious.

12.4.4 Signed Code Can Be Hijacked

Signed ActiveX controls can be hijacked; they can be referenced by web sites that have no relationship with the site on which they reside, and can be used for purposes other than those intended by the individual or organization that signed the control.

There are several ways that an attacker could hijack another organization's ActiveX control. One way is to inline a control without the permission of the operators of the web site on which it resides, similar to the way that an image might be inlined.^[7] Alternately, an ActiveX control could simply be downloaded and republished on another site, as with a stolen GIF or JPEG image.^[8]

^[7] Inlined images are a growing problem on the Internet today. Inlining happens when an HTML file on one site references an image on another site through the use of a <IMG SRC=> tag that specifies the remote image's URL. Inlining is considered antisocial because it is used without the permission of the site that holds and downloads the image and frequently to further the commercial interests of the first site with which it has no formal relation.

^[8] Developers at Microsoft are trying to create a system for giving HTML pages digital signatures. Such a system would allow a developer to create ActiveX controls that could only be run from a specially signed page.

Once an attacker has developed a technique for running a signed ActiveX control from the web page of his or her choice, the attacker can then experiment with giving the ActiveX control different parameters from the ones with which it is normally invoked. For example, an attacker might be able to repurpose an ActiveX control that deletes a file in a temporary directory to make it delete a critical file in the \WINDOWS directory. Or the attacker might search for buffer or stack overflow errors, which could be exploited to let the attacker run arbitrary machine code.^[9]

^[9] Anecdotal reports suggest that many ActiveX controls, including controls being commercially distributed, will crash if they are run from web pages with parameters that are unexpectedly long. Programs that crash under these conditions usually have bounds-checking errors. In recent years, bounds errors have become one of the primary sources of security-related bugs. Specially tailored, excessively long input frequently ends up on the program's stack, where it can be executed.

Hijacking presents problems for both users and software publishers. It is a problem for users because there is no real way to evaluate its threat. Not only does a user need to "trust" that a particular software publisher will not harm his computer, but to be positive that there are no lurking bugs that can be exploited by evildoers, the user also needs to trust that the software publisher has followed the absolute highest standards in producing its ActiveX controls.^[10] And hijacking poses a problem for software publishers, because a hijacked ActiveX control will still be signed by the original publisher: any audit trails or logs created by the computer will point to the publisher, and not to the individual or organization that is responsible for the attack!

^[10] Companies such as Microsoft, Sun, and other firms, as well as individual programmers working on free software, have consistently demonstrated that they are not capable of producing software that is free of these kinds of bugs.

12.4.5 Reconstructing an Attack

The transitory nature of downloaded code poses an additional problem for computer security professionals: it can be difficult, if not impossible, to reconstruct an attack after it happens.

Imagine that a person in a large corporation discovers that a rogue piece of software is running on his computer. The program may be a packet sniffer; it's scanning all of the TCP/IP traffic, looking for passwords, and posting a message to Usenet once a day that contains the passwords in an encrypted message. How does the computer security team at this corporation discover who planted the rogue program, so that they can determine the damage and prevent it from happening again?

The first thing that the company should do, of course, is to immediately change all user passwords. Then, they should force all users to call the security administrator, prove their identities, and be told their new passwords.

The second thing the company should do is to install software such as ssh or a cryptographically-enabled web server so that plaintext passwords are not sent over the internal network.

Determining the venue of attack will be more difficult. If the user has been browsing the Internet using a version of Microsoft's Internet Explorer that supports ActiveX, tracking down the problem may be difficult. Internet Explorer currently doesn't keep detailed logs of the Java and ActiveX components that it has downloaded and run. The company's security team might be able to reconstruct what happened based on the browser's cache. Then again, the hostile applet has probably erased it.

It's important to note that technologies such as code signing of ActiveX and Java applets don't help this problem. Suppose that a company only accepts signed applets from 1 of 30 other companies, 3 of which are competitors. How do you determine which of the signed applets that have been downloaded to the contaminated machine is the one that planted the malicious code? The attacker has probably replaced the malicious code on the source page with an innocuous version immediately after you downloaded the problem code.

It turns out the only way for the company to actually reconstruct what has happened is if that company has previously recorded all of the programs that have been downloaded to the compromised machine. This could be done with a web proxy server that records all .class files and ActiveX components.^[11] At least then the company has a chance of reconstructing what has happened.

^[11] Turning a web proxy server into a security server was proposed by the Princeton University Secure Internet Programming group.

12.4.6 Recovering from an Attack

While to date there is no case of a malicious ActiveX control that's been signed by an Authenticode certificate being surreptitiously released into the wild, it is unrealistic to think that there will be no such controls released at some point in the future. What is harder to imagine, though, is how the victims of such an attack could seek redress against the author of the program even if that attack is commissioned with a signed control that has not been hijacked.

Consider a possible scenario for a malicious control. A group with an innocuous-sounding name but extreme political views obtains a commercial software publisher's certificate. (The group has no problem obtaining the certificate because it is, after all, a legally incorporated entity. Or perhaps it is only a single individual who has filed with his town and obtained a business license, which legally allows him to operate under a nonincorporated name.) The group creates an ActiveX control that displays a marquee animation when run on a web page and, covertly, installs a stealth virus at the same time. The group's chief hacker then signs the control and places it on several web pages that people may browse.

Afterwards, many people around the world download the control. They see the certificate notice, but they don't know how to tell whether it is safe, so they authorize the download. Or, quite possibly, many of the users have been annoyed by the alerts about signatures, so they have set the security level to "low" and the control is run without warning.

Three months later, on a day of some political significance, thousands or tens of thousands of computers are disabled.

Now, consider the obstacles to overcome in seeking redress:

The users must somehow trace the virus back to the control.
The users must trace the control back to the group that signed it.
The users must find an appropriate venue in which to bring suit. If they are in a different state in the U.S., this may mean federal court where there is a multipleyear wait for trial time. If the group has disbanded, there may be no place to bring suit.
The users will need to pay lawyer fees, court costs, filing fees, investigation costs, and other expenses.

In the end, after years of waiting, the users may not win the lawsuit. Even if they do, the group may not have any resources to pay for the losses, or it may declare bankruptcy. Thus, victims could lose several hundreds or thousands of dollars in time and lost data, and then spend hundreds of times that amount only to receive nothing.

only for RuBoard - do not distribute or recompile