Malicious Logic

1. Malicious Logic Trojan Horses Viruses Worms CS 334: Computer Security

2. Introduction • Malicious Logic: a set of instructions that cause violation of security policy • Idea taken from Troy: to breach an impenetrable perimeter, have someone from the inside unknowingly bring you inside • Example: Name the following script ls and place in a directory Set UID of /tmp.xxsh to UID of person executing this script Remove this script and run ls CS 334: Computer Security

3. Trojan Horses • Trojan Horse: A program with an overt (documented or known) effect and a covert (undocumented or unexpected) effect • In example, overt action is to list files, covert is to create shell that is setuid to user executing script • There is a key notion here of ``tricked’’ • In the example script, if user root executed this unintentionally by typing ls in a directory, then we have a security policy violation. • If root types out these lines and runs them intentionally, no violation • Key problem: system does not know whether user really intends to run specific set of instructions CS 334: Computer Security

4. Example: NetBus • Program that allows attacker to control Windows NT workstation remotely • Can download and upload files, intercept mouse or key strokes, generally be sysadmin • Requires small NetBus server on target machine • Placed in several small game programs and other ``fun’’ stuff, then distributed to web sites where unsuspecting users would likely download them CS 334: Computer Security

5. Propogating Trojan Horse • Propogating Trojan Horse: (also replicating Trojan Horse) is a Trojan Horse that creates a copy of itself. • Ex. Ken Thompson’s compiler • Added Trojan horse to login program so it accepted a specific password in addition to user’s password • Placed code that does this into compiler, so it would add it whenever it saw a login call. (So not visible in login code) • Placed the Trojan horse for compiler into compiler binary, so if compiler was recompiled it would always include the trojan horse for login. • Replaced source for compiler with clean source for compiler. CS 334: Computer Security

6. Computer Virus • Computer Virus: A program that inserts itself into one or more files and then performs some (possibly null) action • Insertion Phase: virus inserts itself into file • Execution Phase: the action is performed CS 334: Computer Security

7. Virus Pseudocode CS 334: Computer Security

8. Virus A Trojan Horse? • Some say YES: Purpose of infected program is overt action, injections and execution phase is the covert action • Some say NO: Virus has no covert purpose. Its overt purpose is to infect and execute. • Who cares. Bottom line is that defenses against Trojan horses inhibit viruses. CS 334: Computer Security

9. Some History • 1983: Fred Cohen (at time grad student at USC) designed virus to acquire privileges on VAX-11/750 running Unix. • Obtained all system rights within half hour on average • Because virus didn’t degrade response time, most users never knew system under attack • 1984: Experiment on UNIVAC 1108 showed virus could infect that system • UNIVAC partially implemented Bell-LaPadula Model, using mandatory protection mechanisms • Showed that if a system does not prohibit writing using mandatory access controls, then system does little, if anything, to prohibit virus propagation CS 334: Computer Security

10. More History • 1986-87: Brain (Pakistani) virus infects IBM PCs • Alters boot sectors of floppy disks, possibly corrupting files. • Spreads to any uninfected floppy inserted into system. • Numerous variations have been reported • 1987: MacMag Peace virus • Infect Mac, Amiga, among others • Prints ``universal message of peace’’ on March 2, 198, then deletes itself. • Infected copies of Aldus FreeHand program, which were subsequently recalled by manufacturer CS 334: Computer Security

11. Still More History • 1987: Tom Duff experiments on Unix with small virus that copies itself into executable files. • Not virulent, but when placed in 48 programs on heavily used machine, spread to 46 different systems and 466 files in 8 days. • Duff did not violate security mechanism by seeding files • Wrote another virus in Bourne shell script. It could attach itself to any Unix program • Demonstrated that viruses are not intrinsically machine-dependent and can spread to systems of varying architectures CS 334: Computer Security

12. Ok, Even More History • 1989: Harold Highland develops Lotus 1-2-3 virus • Virus stored as set of commands for spreadsheet • Loads automatically when file opened • Was for demo only, so it changed the value in specific row and column then spread to other files. • Demonstrated that macros for office programs on PCs could contain viruses. CS 334: Computer Security

13. Virus Types • Boot Sector Infectors • Executable Infectors • Multipartite Viruses • TSR Viruses • Stealth Viruses • Encrypted Viruses • Polymorphic Viruses • Macro Viruses CS 334: Computer Security

14. Boot Sector Viruses • Boot sector is the part of a disk used to bootstrap the system or mount a disk • Code in boot sector is executed when system sees disk for first time • Boot sector virus is one that inserts itself into the boot sector of a disk • When system or disk boots, virus is executed • Original boot sector code is moved CS 334: Computer Security

15. Example: Brain Virus • When system boots from infected disk, virus is in boot sector and is loaded. • Moves disk interrupt vector (location 0x13) to location 0x6d and sets disk interrupt location to invoke Brain virus. • Brain virus then loads original boot sector and continues the boot • When user reads another floppy, interrupt at 0x13 is invoked, calling Brain virus • If value 0x1234 in word at location 0x4 of new disk, boot continues normally. If not, disk is infected • Infection sometimes overwrite some sectors, thus the sometimes destructive nature of the Brain virus CS 334: Computer Security

16. Executable Infectors • Executable infector: virus that infects executable programs • On PC these are COM or EXE viruses because of the file types they infect • Viruses prepends or appends itself to executable CS 334: Computer Security

17. Example: Jerusalem Virus • Triggered when infected program is executed • Virus puts value 0x0e0 into ax register and invokes DOS service interrupt (0x21) • If on return the high eight bits of ax contain 0x3, virus is already on system and original program is invoked • If not, virus sets itself up to respond to traps to DOS service interrupt vector CS 334: Computer Security

18. Example: Jerusalem Virus • Virus checks date • if a Friday the 13th and year is not 1987, virus sets flag in memory to delete files instead of infecting them • In memory, virus checks all calls to DOS service interrupt, looking for files to be executed (service call 0x4b00) • Virus checks file name, and deletes file if destruct bit set (except for COMMAND.COM file) • Virus checks last five bytes of file. • If string MsDos, file is infected • If not, virus checks whether name of file ends in E or M, in which case virus infects it (assuming its a COM or EXE file) CS 334: Computer Security

19. Multipartite Viruses • Virus that can infect either boot sectors or applications • Virus typically has two parts, one for each type. Appropriate part is invoked depending on circumstances CS 334: Computer Security

20. TSR Viruses • Terminate and Stay Resident (TSR) virus is one that stays active (resident) in memory after application (or bootstrapping or disk mounting) has terminated. • Can be boot sector or executable infectors • Brain and Jerusalem are both TSR viruses • Non TSR viruses execute only when host application is executed (or infected disk mounted, etc) CS 334: Computer Security

21. Stealth Viruses • Stealth viruses are those that conceal the infection of files • Intercept calls to the OS that access files • If call is for file attributes, original (uninfected) file attributes returned • If call is to read file, uninfected version is returned • If call is to execute file, infected file is executed CS 334: Computer Security

22. Example: The Stealth Virus • Also called IDF virus or 4096 virus • Modifies DOS service interrupt handler • Not interrupt vector. This way inspection of interrupt vectors does not reveal presence of virus • If call is for length of file, length of uninfected file returned • If request to open file, file is temporarily disinfected, then reinfected when file is closed • Changes last modification time for file to indicate the file is not infected CS 334: Computer Security

23. Encrypted Viruses • Virus that enciphers all of the virus code except for a small decryption routine • Anti-virus software looks for known sequences of code • To fight this, some viruses encipher most of code, leaving only small decryption routine and random cryptographic key in clear CS 334: Computer Security

24. Example: 1260 Virus • Uses two keys stored in k1 and k2 • Virus code begins at location sov and ends at location eov • Dual keys and shifting of first key prevent simple xor from uncovering deciphered virus CS 334: Computer Security

25. Polymorphic Viruses • A virus that changes its form each time it inserts itself into another program • Considered an encrypted virus • With straight encrypted virus, decryption portion can be detected! • Polymorphic viruses designed to defeat this. • They change instructions in virus to something equivalent but different. Technique is used to hide decryption code. All do same thing! CS 334: Computer Security

26. Example CS 334: Computer Security

27. Polymorphic Viruses • Production of polymorphic viruses has been automated • Mutation Engine (ME) • Trident Polymorphic Engine (TPE) • Polymorphism can occur at different levels • A deciphering algorithm may have two different implementations • Two different algorithms may produce same result (much harder to detect) CS 334: Computer Security

28. Macro Viruses • A virus that it composed of a sequence of instructions that is interpreted rather than executed directly • Conceptually no different from ordinary computer viruses • Can execute on any system that can interpret the instructions • Can infect executables or data files (data virus) CS 334: Computer Security

29. Macro Virus • If infecting executable, must arrange to be interpreted at some point • Ex. Duff’s experiments wrapped executables with shell scripts. Resulting executables invoked Bourne shell which interpreted virus code before invoking usual executable • Macro viruses not bound by machine architecture – use specific programs • Any system that runs this program can be affected, though effects may differ • Ex. MS Word virus will work on PC, Mac, CS 334: Computer Security

30. Example: Melissa Virus • Infected Word 97 and 98 documents on Windows and Mac systems (written in Visual Basic) • Installs itself as the ``open’’ macro and copies itself into the Normal template so that any files that are opened are infected • Then invokes mail program and sends copies to names in address book • On PC spread was through mail • On Mac, most user didn’t use mail program that Melissa invokes, so spread was not via email. CS 334: Computer Security

31. Computer Worms • A computer worm is a program that copies itself from one computer to another (as opposed to hitching a ride) • Research on worms began in mid-1970s • Schopp and Hupp developed distributed programs to do various tasks. These probed workstations, to find idle machines on which they installed code segments do do work. When other work on machine started, segments shut down. CS 334: Computer Security

32. The Internet Worm • Nov. 2, 1988: program targeted Berkeley and Sun Unix based machines. • Within hours of introduction to Internet it had rendered thousands of computers unusable • Worm inserted instructions into a running process on target machine and arranged for instructions to be executed CS 334: Computer Security

33. The Internet Worm • Recovery required disconnection from network and reboot • Several critical programs had to be changed and recompiled to prevent re-infection • Worse, program disassembly required to determine whether other malicious effects present • Fortunately only purpose of worm was self propagation (could have been much worse!) CS 334: Computer Security

34. Internet Worm • Worm took advantage of flaws in some standard software installed on Unix systems • fingerd is a utility that allows users to obtain information about other users • gets is a routine that takes input into a buffer without performing a bounds check • sendmail is a program that routes mail in heterogeneous networks CS 334: Computer Security

35. fingerd • Program runs as a daemon (background process) • Allows connections from remote programs • Reads single line of input, sends back appropriate output • Code used call to gets routine to get input. Worm smashed the stack using this call • Unfortunately, several routines remain with such buffer overflow vulnerabilities CS 334: Computer Security

36. sendmail • Operates in several modes: worm exploited debug mode operation • Sendmail listens on TCP port 25 for attempts to deliver mail using simple mail transfer protocol (SMTP) • When contacted, sendmail enters into dialog to determine sender, etc. CS 334: Computer Security

37. sendmail • Worm used DEBUG command to specify the recipient of the message as a set of commands instead of a user address • This is not allowed in normal mode • In debug mode, allows testers to verify mail is arriving without having to invoke address resolution routines • That is, testers can run programs to show state of mail system without separate login connection or having to send mail CS 334: Computer Security

38. Aside: Unix Passwords • Passwords encrypted with premuted version of DES and ciphertext stored in world-readable accounting file • Worm used dictionary attack to break passwords (sometimes as many as 50% of the passwords on a system) • Unix now stores passwords in shadow password file that can only be accessed by sysadmin • And encryption is done using a privileged routine that delays return for a second or so (prevents online testing) CS 334: Computer Security

39. Aside: Trusted Logins • BSD Unix has nice support for login from remote machines • One can specify a list of host/login name pairs that are assumed to be trusted. Login with these pairs does not require a password • hosts.equiv and .rhosts files • Worm exploited this by trying to locate machines that might trust the current machine • How do you think it did this? • When one found, worm placed itself on the target machine CS 334: Computer Security

40. Internet Worm (High level description) • Main program: collect info on other machines on network to which current machine could connect • Read config files • Run system utilities to get info about current state of network connections • Used previously mentioned flaws to attempt to establish bootstrap on these machines. CS 334: Computer Security

41. Internet Worm (High Level Description) • Bootstrap program: • 99 lines of C code that would be compiled and run on remote machine • Once transferred to target machine, it was compiled and invoked with three command line arguments • Network address of infecting machine • Number of network port to connect to on machine to get copies of the main worm files • Magic number that acted as one-time challenge password • If worm on remote host and port didn’t receive magic number back, it would immediately disconnect from bootstrap program • Possibly to prevent someone from capturing a copy of the worm by spoofing a Worm server CS 334: Computer Security

42. Internet Worm (High Level Description) • Bootstrap program: • Connect back with worm that originated it and transfer a set of precompiled code (binaries) to local machine • These binaries represented versions of the main program for various OS versions and machine architectures. • Once binaries transferred, loaded and linked with standard library routines on host machine, then one by one run. CS 334: Computer Security

43. Father Christmas Worm • Electronic Christmas Card passed around IBM-base networks • Card was letter instructing recipient to save letter and run as a program. • Program drew Christmas Tree (with blinking lights!) and printed Merry Christmas • Program checked recipients list of previously received mail as well as address book, then sent itself to all these addresses • Overwhelmed network and forced shutdown • Macro worm written in high-level job control language CS 334: Computer Security

44. Rabbits and Bacteria • Program that absorbs all of some class of resource • Program copies multiply so fast that resources exhausted. A class of denial of service attack. • Ex. (Dennis Ritchie) This will exhaust disk space or inode tables on a Unix Version 7 system CS 334: Computer Security

45. Examples • Internet worm: • During infection, opened a port on target machine. • When another worm tried to infect machine, it checked port. If opened it assumed machine infected. • But apparently to thwart sysadmins opening a small program on that port, every sixth attack it ignored the check. • Lead to many copies of the worm on single machine. These consumed the CPU. • Father Christmas: • Created so much network traffic that network became unusable and had to be shut down CS 334: Computer Security

46. Question: Is there an algorithm that can determine if an arbitrary program contains replicating code? CS 334: Computer Security

47. Answer (Cohen): No such algorithm can exist. It is provably undecidable whether an arbitrary program contains a computer virus. CS 334: Computer Security

48. Logic Bomb • Logic bomb is a program that executes malicious logic when some external event occurs • E.g. program attacks on specific date • Disaffected employees who plant Trojan horses in systems often use logic bombs • E.g. delete entire payroll roster when employee’s name is deleted CS 334: Computer Security

49. Example • Early 1980s: program posted to USENET promised to make administering systems easier • Directions: • Unpack shar archive containing program • Compile program and install as root • Midway down the shar archive: CS 334: Computer Security

50. A More Modern Perspective on Malicious Logic We’ve talked a bit about classification and seen an important theoretical result. Now we consider more recent developments. As always thanks to my Berkeley Colleagues for providing much of the slides on this modern perspective. CS 334: Computer Security