▶ 3.2 Executable Files and Malware
When we look in our directories at the files, we distinguish between two file types:
Data files, like a word-processing file containing an essay, a spreadsheet, or a configuration file used by a program or the operating system.
Executable files that contain application programs or other programs.
An executable file contains instructions to be executed by the CPU. When we load those instructions into a control section in RAM, the CPU runs that program. This was described in Section 2.1.2. The program’s instructions must be organized and formatted in a special “executable” file format. Although the format varies with different operating systems, they are all similar to what we see in FIGURE 3.5.
FIGURE 3.5 Executable file format.
Every executable file begins with a “file header” that describes the structure and format of the program. The header contains these fields:
■ Magic number—a standard data value that appears in the first location of the executable file. Different operating systems and different CPUs typically use different magic numbers so that the system won’t accidentally run a program that can only run correctly on a different type of system.
■ Program size—indications of the size of the block of machine instructions that make up the program itself.
■ Layout information—addresses and offsets to be used to lay out variables and stack locations in the program’s data section.
Following the header, the rest of the file consists primarily of machine instructions. When we execute the program in a file, the operating system loads those instructions directly into a control section. When starting the program, the operating system sets the program counter to the starting address of the control section.
3.2.1 Execution Access Rights
FIGURE 3.6 shows what happens when Bob runs the word-processor program to edit his essay. The square boxes on the top left and right represent files. The box with the tab in the left corner is a data file, owned by Bob, that contains his essay. The plain box on the right is an executable file owned by the system that contains the word-processor program.
FIGURE 3.6 Bob executes the word processor to edit his essay.
When Bob starts the word processor, the system reads the executable file into the word-processor control section (lower right corner). As the process executes the program, it uses the data section (lower left corner) to contain working variables and to store the parts of the essay file being edited.
Bob has full ownership of his essay file and full read/write access to his data section. The file containing the word-processor program is owned by the operating system. Bob has read-only access to the file and to its control section. When Bob starts the program, the operating system itself copies the file’s instructions into the control section.
As before, we represent access rights with labeled arrows. Note that executable files and control sections may have an “X” permission. In the case of the file, this indicates the execute right. When present, a user may execute the file. Most modern systems provide this right. This helps implement Least Privilege; it allows a user to run a program, but it does not imply the right to copy it or visually examine the executable instructions. In practice, however, most systems provide both Read and Execute permissions, because parts of the system might not respond well if they can’t actually read the program file. The programmer who creates a program has all three rights—read, write, and execute—which yields “RWX.”
Types of Executable Files
Application programs aren’t the only executable files on a typical operating system. The first and most important executable file is the “kernel” of the operating system itself. When we boot the system, the BIOS reads this file from the hard drive and loads it into RAM. From there, the rest of the operating system starts up. Any part of the operating system that may be added while the system is running must reside in its own executable file.
Here is a list of common types of executable files:
■ Application programs—the files we execute to run useful applications. Some “system utility” programs, like those for managing and formatting hard drives, are application programs.
■ Operating system kernel—the file the BIOS reads into RAM during the bootstrap process. This contains the machine instructions that make up the operating system’s main procedures.
■ Device drivers—custom procedures for using I/O devices.
■ Shared libraries—useful functions that may be shared among multiple programs (dynamic link libraries in Windows).
These files, like typical executable files, contain machine instructions. To run the program, we load it into RAM and direct the CPU to execute the instructions. Some systems, however, notably those derived from Unix, also treat some text files as executable files. These are files written in a scripting language. These include programming languages like Perl, Python, PHP, or Lisp. The CPU can’t execute these programs directly, but instead must execute the language’s interpreter program. This is also true of programs written in versions of the Basic language, including Visual Basic. We discuss scripting languages further when we discuss macro viruses in Section 3.2.3.
A system’s security depends on protecting executable files, especially operating system files. An attacker can break our Chain of Control by modifying an executable file, especially if it is a critical operating system file.
3.2.2 Computer Viruses
By 1981, the Apple II had become an incredibly popular desktop computer. Introduced at the West Coast Computer Faire in 1977, the Apple received a huge boost in sales with the introduction of “Visicalc” in 1979, the first spreadsheet program. Visicalc justified buying an Apple II for the office. Back then, hard drives were too expensive for small computers. Most computers used removable diskettes. The operating system and one or two applications could fit on a single diskette.
The computer software industry was in its infancy. People often borrowed software from one another and often copied each others’ application programs. This behavior was especially rampant with computer games. Bill Gates, then the young cofounder of the tiny Microsoft Corporation, published articles urging computer users to pay for their software and shun unauthorized copies, but the sharing (called piracy today) persisted.
There was little to discourage computer users from sharing software until a few of them noticed something odd: Their application programs grew larger and started more slowly. Closer investigation revealed that a small program attached itself to each of their application program files. When such a program was executed, it would attach a similar program to any other program files it found.
In 1983, researcher Fred Cohen performed a series of studies in which he constructed programs that replicated themselves. He used the term computer virus to describe them. At first, other researchers saw little relevance in this work, but soon viruses emerged as the first widespread form of computer malware.
Virus Infection
When a virus “infected” an application program, it added its own machine instructions to the end of the program’s file (FIGURE 3.7). By adjusting the file headers, the virus ensured that its instructions were loaded into RAM along with the application program. The virus also modified the application itself so that the virus program would run first.
FIGURE 3.7 A virus infection in an executable program file.
When the user started up an infected application, the operating system loaded the program into RAM, including the virus. The system jumped to the start of the application, which had been modified to make the virus program run first. Here is what a typical virus did:
The virus searched the operating system’s file directory to locate every file containing an application program. It would then inspect each application program file.
If the program file had already been infected by the virus, the virus skipped to the next file.
If the file was not infected, the virus copied its executable instructions to the end of the file, “appending” to it. This reduced the risk of accidentally damaging the application.
Next, the virus modified the first instruction in the application to “Jump” to the start of the virus program. The virus also saved that first instruction, so that it would be the last instruction the virus executed itself before jumping back to resume the application. Now the file was fully “infected” and would run the virus the next time the application started.
Once the virus had checked every application program on the system, it executed the instruction from the start of the application and jumped back to the application program.
It is much simpler to run malware on a modern operating system. The attacker just repackages a legitimate application with a “wrapper” that includes the malware. The wrapper contains software that executes first: It starts the legitimate application in one process and the malware in another. The legitimate application executes normally, and the malware runs invisibly in the background unless it takes a visible action. Modern malware doesn’t usually infect other applications; it uses other techniques to propagate.
Biological viruses rely on particular techniques to infect other victims; some are airborne, some travel in food, and so on. In the case of computer viruses, infection only occurs if the victim executes the virus code. The virus subverts the Chain of Control to cause itself to be executed. There are many ways this can happen. In the early days, viruses most often spread by running an infected application.
Originally, viruses seemed benign. Early virus authors sought persistence and replication. They found their viruses spread more effectively if they were innocuous and hard to detect. Even so, viruses made assumptions about executable files, and they could damage a file if the assumptions were incorrect.
Malicious Viruses
By the late 1980s, however, some virus writers were inclined toward destruction. The Jerusalem virus, which appeared in 1987 in the city of Jerusalem, contained a “destructive payload” that would delete all executable files on the system on Friday the 13th, starting in 1988. This type of trigger was typical of destructive viruses: They would spread for some period of time, and then a calendar date would trigger a destructive action. The Michelangelo virus (1991) was a famous example of this; it was programmed to reformat hard drives on March 6, Michelangelo’s birthday.
Michelangelo, like several later viruses, did not directly infect applications. Instead, it infected the Master Boot Record (MBR) of diskettes and hard drives (FIGURE 3.8). Whenever a computer bootstrapped from a particular disk, the BIOS would first read in and execute the instructions stored on the MBR.
FIGURE 3.8 A diskette infected with a virus, circa 1991.
Courtesy of Dr. Richard Smith.
By that time, low-cost disk drives were common on desktop computers. The Michelangelo virus code ran whenever the system was booted from an infected disk, whether a hard drive or diskette. The virus would then modify the bootstrap data on every disk on the system so that it would execute the virus code before it bootstrapped the operating system.
Applications and bootstraps were not the only techniques used to spread viruses. Any time the virus writer can trick a victim into executing a program, the virus writer will use it to spread a virus. There are several ways to automatically execute a program when inserting a flash drive into a computer; several viruses use such techniques to spread between computers.
3.2.3 Macro Viruses
Whenever we write a computer program, we write it in a programming language. For us to use a particular language, we need a program that translates what we wrote into actions performed by the CPU. These “programming language programs” fall into two categories:
Compiler—a program that converts our program into machine language. The CPU executes the machine language. C, Java, Fortran, and Cobol are examples of compilers.
Interpreter—a program that “interprets” the text of our program a word at a time, and performs the actions specified in the text. Python, Visual Basic, Javascript, PHP, Lisp, and keyboard command processors are examples of interpreters.
We called interpreted languages scripting languages earlier. A program in a scripting language sometimes is called a script. For example, a file containing Unix shell commands or MSDOS commands is often called a shell script. Today’s languages may even straddle the line between compiling and interpreting. For example, Java usually compiles the program into “bytecodes,” which are then run by a highly optimized interpreter that is customized to specific CPUs and operating systems.
Sometimes we call scripts macros, especially when we embed them in other documents. For example, many Microsoft Office applications will allow us to create a macro by recording a sequence of operations. The Office application typically translates the sequence into a Visual Basic program and saves it with the file. We can tell the application to perform the macro when particular events occur.
While these programming capabilities provide some interesting features, they also increase the attack surface. Most scripting languages can create files or modify other files and execute other programs. A script-oriented or macro virus uses these features as an attack vector.
In the early 1990s, a rumored macro virus infected Microsoft Word documents. When executed, the virus copied itself to other Word files it could find and also posted the document to the Usenet News system. This published the document worldwide for viewing by everyone who used the Usenet News system.
While macro viruses posed a serious risk for some systems, vendors largely ignored the problem until such viruses were widely distributed by email (see Chapter 15). Defensive measures often take two forms:
Authentication: the application software only runs the macro program if it can authenticate the file’s source, and the user trusts that source. Authentication usually relies on digital signatures (see Chapter 8).
Sandboxing: the application software runs the macro program with heavy restrictions on what it can do. This restricted environment is called a sandbox.
Modern mobile devices rely heavily on sandboxing to resist malware. Both Apple’s iOS and Google’s Android run apps separately in highly restricted security zones. Most app files reside in a file system restricted exclusively to that app. The only way to share a file or other data is if the app provides a sharing feature. To further protect the mobile system and its apps, each app must request permission to use shared resources or devices (e.g., the camera). The owner must grant permission to the app.
3.2.4 Modern Malware: A Rogue’s Gallery
Since the 1980s, antivirus researchers and vendors have identified thousands of viruses and other forms of malware. In 2008, vendor Symantec announced that the total number passed one million. Here is a selection of malware packages:
■ Waledac
■ Conficker, also called Downadup
■ Pushdo/Cutwail
■ ZeuS/Gameover
■ Cryptolocker/CryptoWall/WannaCry
■ Stuxnet/Flame
Many of these packages propagate like viruses while others propagate across networks. Here is a summary of common attack vectors used in modern malware:
■ Infect flash drives—The malware copies itself to any plugged-in flash drives. The malware then configures the drive to execute the malware automatically when the drive is inserted in a computer.
■ Drive-by downloads—This is a network-based attack in which a user visits a web page, or clicks on a pop-up window, and unintentionally downloads the malware.
■ Worm propagation—The malware exploits a desktop or server vulnerability that it can reach via a network connection. The vulnerability allows the malware to install itself on the vulnerable computer. (See Section 10.1.3.)
■ Trojan infection—A Trojan is a program that appears benign but in fact contains malware. In a Trojan infection, the malware arrives on the computer and the user is tricked into executing it. The term Trojan is derived from the story of the Trojan horse. (See Section 4.4.3.)
■ Email infection—Trojan malware arrives on the desktop via email, and the user executes it, causing the infection. (See Section 14.3.3.)
In Section 1.3, we briefly examined types of cyber criminal teams that play different roles and exploit different types of information to make money. Different malware packages often represent different parts of the process in a cybercrime enterprise. Many malware packages construct botnets, and the botnet’s herder uses the network for a variety of malicious or illegal purposes.
Waledac
Waledac constructs and manages a sophisticated and hard-to-trace botnet. The malware then provides several ways to make money from the network. Waledac is a Trojan that originally propagated primarily through email and drive-by downloads. An existing botnet operator may also download Waledac into the network of bots.
Once the network is in place, the controller may use it to do any of the following:
■ Deliver spam email. (See Section 14.3.1.)
■ Create pop-up windows that harass the computer’s owner. Waledac’s pop-ups usually warn of a virus infection and offers the sale of special antivirus software. The software is sold by the botnet operator, and it contains additional malware.
■ Harvest authentication credentials from the PC. (See Section 6.2.2.)
■ Perform distributed denial of service attacks. (See Section 10.1.3.)
The Waledac bot software relied on a set of predefined “domain names” to identify the computers in command of the botnet. The software used those names to keep in contact with the botnet herder. Security experts monitored bot software and eventually identified more than 270 domain names it used. In early 2010, Microsoft was granted a court order to block those domain names, taking the botnet offline.
Conficker, Also Called Downadup
The name “Conficker” is the popular name given to a worm often called “Downadup” in the security community. Conficker propagated through millions of Windows computers in 2009; infections subsided after that. Conficker constructed a botnet, but it did not itself contain software to exploit the network. On one occasion, the botnet briefly hosted Waledac software to distribute spam.
Pushdo/Cutwail
Starting in 2007, a malware organization constructed a botnet using Pushdo and Cutwail malware. Pushdo implements a botnet and supports downloading of additional malware. Cutwail implements email spam campaigns. In early 2009, Symantec’s MessageLabs estimated that this botnet contained at least 1 million bots and averaged more than 7 million spam messages per day.
Over the next 18 months, however, work by regulators and security researchers closed down most of the network computers used by the botnet operators to operate the botnet. This yielded a dramatic decrease in worldwide spam traffic.
ZeuS/Gameover
ZeuS is a malware “product” in that its developers offer it for sale on the black market. Criminal groups purchase the software as an easy-to-use package to create a botnet focused on financial fraud.
ZeuS generally propagates via email or drive-by downloads. Email may often use social engineering techniques that direct victims to spoofed versions of popular social networking sites, like Myspace, Facebook, or LinkedIn.
When ZeuS infects a computer, it installs its “Zbot” malware, which connects the infected machine to the botnet. Zbot then steals financial credentials from the infected machine and transmits them to the botnet operator. Zbot also can use the victim’s computer to perform financial transactions using the victim’s credentials.
To complete the fraud, the botnet operator recruits money mules to visit banks and withdraw cash from looted accounts. After withdrawal, the mules forwarded the money to the controllers. In late 2010, the Federal Bureau of Investigation announced over 100 arrests related to a ZeuS botnet, including dozens of money mules. In 2014, the U.S. Justice Department filed a criminal complaint alleging that Evgeniy Bogachev, a Russian national, was the author of the ZeuS botnet.
Gameover was a botnet based on the ZeuS software that was apparently operated after October 2011 by herders in Russia and Ukraine. The botnet was constructed using Cutwail spam emails. By 2014 the net was estimated to contain up to one million infected bots and alleged to have stolen more than $100 million from businesses and individuals. “Operation Tovar,” a global effort by law enforcement, tech vendors, and security experts, took down Gameover in mid-2014.
Cryptolocker/CryptoWall/WannaCry
Cryptolocker is a form of “ransomware” that uses encryption to hold a computer hostage. Infection usually arrives via spam email, although it has also been reported via drive-by downloads. While this type of extortion has happened before, Cryptolocker achieved enough distribution in late 2013 to be covered by noncomputing news outlets. The Gameover botnet was one of the distribution channels for Cryptolocker. A variant named CryptoWall appeared in 2014. WannaCry ransomware appeared in 2017 and infested hundreds of thousands of computers worldwide.
Following an infection, the malware runs for several hours on the targeted computer, encrypting user application files. Cryptolocker uses very high-quality encryption that is not practical to break without the encryption key. Once the files are all encrypted, the malware displays a window demanding ransom. If the victim pays the ransom using the correct online links, the software uploads the encryption key and decrypts the files. If the victim fails to pay before a given deadline, the encryption key is discarded and can’t be retrieved.
Stuxnet/Flame
In November 2010, the president of Iran announced that a cyberattack had caused “minor problems” with centrifuges used in its nuclear facilities for processing uranium. Press reports and malware researchers tied those problems to Stuxnet, a sophisticated malware package that first appeared in 2009.
Stuxnet was a worm that targeted programmable logic controllers or PLCs. Factories, refineries, oil pipelines, and the electrical power grid use PLCs to automate industrial and utility systems. These devices are often connected to Windows computers on a network, and Stuxnet propagated by attacking the Windows computers.
Stuxnet used infected flash drives to enter factory networks even when not connected to the internet. The worm used several previously unknown Windows vulnerabilities to propagate on the network. Stuxnet sought specific PLC models that performed specific tasks related to centrifuge operation and ignored all others. Stuxnet modified the PLC software to operate the centrifuge at dangerous speeds but to report safe speeds to the operator.
Press reports suggest that Stuxnet was a “cyber weapon” developed by the United States and Israel to target the Iranian nuclear program. The malware required sophisticated technical knowledge of both centrifuge equipment and of Windows vulnerabilities. It contained no mechanisms to make money, yet required significant resources to develop. No government official has formally claimed responsibility.
Further study of Stuxnet and similar malware uncovered “Flame,” an older variant that focuses on eavesdropping. Like Stuxnet, Flame has no obvious mechanism for making money, except perhaps by harvesting login credentials. Unlike most botnet software, Flame is remarkably stealthy. It scans the computer’s hard drive slowly, taking care not to use too many resources. It constructs summaries of the drive’s contents and transmits them in short, hard-to-detect messages to a remote destination. Flame can also exchange data with wireless devices.