Viruses based on slides by Vitaly Shmatikov and Ninghui Li Malware - PowerPoint PPT Presentation

Viruses based on slides by Vitaly Shmatikov and Ninghui Li

Malware • Malicious code often masquerades as good software or attaches itself to good software • Some malicious programs need host programs • Trojan horses, logic bombs, viruses • Others can exist and propagate independently • Worms, automated viruses • There are many infection vectors and propagation mechanisms

Remote Vulnerabilities [Geer] New vulnerabilities Exploitable targets

Trojan Horses • A trojan horse is malicious code hidden in an apparently useful host program • When the host program is executed, trojan does something harmful or unwanted • User must be tricked into executing the host program • In 1995, a program distributed as PKZ300B.EXE looked like a new version of PKZIP… When executed, it formatted your hard drive. • Trojans do not replicate • Main difference from worms and viruses, but today many trojans are spread by virus-like mechanisms

Viruses • Virus propagates by infecting other programs • Automatically creates copies of itself, but to propagate, a human has to run an infected program – Self-propagating malicious programs are usually called worms • Many propagation methods • Insert a copy into every executable (.COM, .EXE) • Insert a copy into boot sectors of disks – “Stoned” virus infected PCs booted from infected floppies, stayed in memory and infected every floppy inserted into PC • Infect TSR (terminate-and-stay-resident) routines – By infecting a common OS routine, a virus can always stay in memory and infect all disks, executables, etc.

Virus Techniques • Macro viruses • A macro is an executable program embedded in a word processing document (MS Word) or spreadsheet (Excel) • When infected document is opened, virus copies itself into global macro file and makes itself auto-executing (e.g., gets invoked whenever any document is opened) • Stealth techniques • Infect OS so that infected files appear normal – Used by rootkits (we’ll look at them later) • Mutate, encrypt parts of code with random key

Viruses in P2P Networks [Shin, Jung, Balakrishnan] Millions of users willingly download files • KaZaA: 2.5 million users in May 2006 • Easy to insert an infected file into the network • Pretend to be an executable of a popular application • – “Adobe Photoshop 10 full.exe”, “WinZip 8.1.exe”, … – ICQ and Trillian seem to be the most popular names Infected MP3 files are rare • Malware can open backdoor, steal confidential information, spread • spam 70% of infected hosts already on DNS spam blacklists •

Prevalence of Viruses in KaZaA [Shin, Jung, Balakrishnan] 2006 study of 500,000 KaZaA files • Look for 364 patterns associated with 71 viruses • Up to 22% of all KaZaA files infected • 52 different viruses and Trojans • Another study found that 44% of all executable files on KaZaA • contain malicious code When searching for “ICQ” or “Trillian”, chances of hitting an • infected file are over 70% Some infected hosts are active for a long time • 5% of infected hosts seen in February 2006 were still active in • May 2006

Propagation via Websites [Moshchuk et al.] Websites with popular content • Games: 60% of websites contain executable content, one-third • contain at least one malicious executable Celebrities, adult content, everything except news • Most popular sites with • malicious content (Oct 2005) Large variety of malware • But most of the observed programs • are variants of the same few adware applications (e.g., WhenU)

Malicious Functionality [Moshchuk et al.] Adware • Display unwanted pop-up ads • Browser hijackers • Modify home page, search tools, redirect • URLs Trojan downloaders • Download and install • additional malware Dialer (expensive toll numbers) • Keylogging •

Drive-By Downloads Website “pushes” malicious executable to user’s browser with • inline Javascript or pop-up window Naïve user may click “Yes” in the dialog box • Can also install malicious software automatically by exploiting • bugs in the user’s browser 1.5% of URLs crawled in the Moshchuk et al. study • Constant change • Many infectious sites exist only for a short time or change • substantially from month to month Many sites behave non-deterministically •

Virus: Buffer’s overflow Used in 1988’s Morris Internet Worm, Still extremely common • today Reference (not recent but still good) • Aleph One’s “Smashing The Stack For Fun And Profit” in Phrack • Issue 49 in 1996 popularizes stack buffer overflows http://insecure.org/stf/smashstack.html Buffer overflows: Attacks and defenses for the vulnerability of • the decade, Cowan et al.

Buffer Overflow Two goals: 1. Arrange attack code in program’s address space Inject it: using a string that contains the malicious code • into some buffer (eg stack,heap, static area) It is already there: eg assume that attac code needs • execute “exec(“/bin/sh”)” and there exists code in libc that executes “exec(arg)” then only need to change “arg” with “/bin/sh” to gain shell 2. Get the program to jump to that code with suitable parameters into registers and memory Buffer overflow: change return address of procedures, • exploit function pointers - “void(* foo)()”- • Checkpointing based on setjmp/lonhjmp •

Buffer Overflow Attacker needs to know which CPU and OS are running on the • target machine. familiarity with machine code. • Know how systems calls are made. • The exec() system call. • Our examples are for x86 running Linux. • Details vary slightly between CPU’s and OS: • Stack overflow • Shell code • Return-to-libc • – Overflow sets ret-addr to address of libc function Off-by-one • Overflow function pointers & longjmp buffers • Heap overflow •

Stack Frame: When a procedure is called Parameters Return address Stack Frame Pointer Local variables Stack Growth SP

What are buffer overflows? Consider the following function: • void func(char *str) { char buf[128]; strcpy(buf, str); do-something(buf); } When the function is invoked the stack looks like: • buf sfp ret-addr str stack What if *str is 136 bytes long? After strcpy : • *str ret str

Buffer overflow: example The following example shows how to inject and jump to the attacker’s code at the same time Suppose *str is such that after strcpy stack looks like: • top of *str ret Code for P stack Program P: exec( “/bin/sh” ) (exact shell code by Aleph One) When func() exits, the user will be given a shell !! • Note: attack code runs in stack . • To determine ret guess position of stack when func() is called. •

Some unsafe C lib functions strcpy (char *dest, const char *src) strcat (char *dest, const char *src) gets (char *s) scanf ( const char *format, … ) printf (conts char *format, … )

Exploiting buffer overflows • Suppose web server calls func() with given URL. • Attacker can create a 200 byte URL to obtain shell on web server • Some complications for stack overflows: • Program P should not contain the ‘\0’ character. • Overflow should not crash program before func() exits.

Other control hijacking opportunities Stack smashing attack: • Override return address in stack activation record by overflowing a local buffer variable. • Function pointers: (used in attack on PHP 4.0.2) Heap or buf[128] FuncPtr stack • Overflowing buf will override function pointer. • Longjmp buffers: longjmp(pos) (used in attack on Perl 5.003) • Overflowing buf next to pos overrides value of pos .

return-to-libc attack • “Bypassing non-executable-stack during exploitation using return-to-libs” by contex (libc: standard C libr.) *str ret Code for P Shell code attack: Program P: exec( “/bin/sh” ) system() in libc *str ret fake_ret “/bin/sh” Return-to-libc attack:

Preventing Buffer Overflow Attacks • Static source code analysis • Use type safe languages ( Java, ML ). • Use safe library functions • Non-executable stack • Run time checking: StackGuard • Randomization • Detection deviation of program behavior • Sandboxing • Access control … (covered later in course)

Static source code analysis Statically check source code to detect buffer • overflows. • Several consulting companies. Main idea: automate the code review process. • Several tools exist: • • Coverity (Engler et al.): Test trust inconsistency. • Microsoft program analysis group: – PREfix: looks for fixed set of bugs (e.g. null ptr ref) – PREfast: local analysis to find idioms for prog errors. • Berkeley: Wagner, et al. Test constraint violations. Find lots of bugs, but not all. •

Marking stack as non-execute Basic stack exploit can be prevented by marking • stack segment as non-executable. Support in Windows SP2. Code patches exist for Linux, Solaris. • Problems: Does not defend against `return-to-libc’ exploit. • Some apps need executable stack (e.g. LISP interpreters). • Does not block more general overflow exploits: • – Overflow on heap, overflow func pointer.