1 / 24

Week 14: Chapter 3

Week 14: Chapter 3. Program Security. Week 14: 3.1 Secure Programs. Different people have different perspective on secure software (programmers, managers, users). Tracking faults (from developers): Requirements Design Code inspections Note fixing might cause more faults

zena-smith
Download Presentation

Week 14: Chapter 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Week 14: Chapter 3 Program Security

  2. Week 14: 3.1 Secure Programs • Different people have different perspective on secure software (programmers, managers, users). • Tracking faults (from developers): • Requirements • Design • Code inspectionsNote fixing might cause more faults • Failures - are effects of faults • Vulnerability and flaws do not map to faults and failures • "Bugs" means different things, depending on context. • IEEE says "fault" is inside view from the developer “failure” - outside view from user • Types of Flaws: • validation error • domain error • serialization and aliasing • inadequate identification and authentication • boundary condition violation • other exploitable logic errors

  3. Week 14: 3.2 Nonmalicious Program Errors • Buffer Overflows • Accidental not checking array bounds Example C program (handout #1) • User Data --> User data • User Data --> User program code • User Data --> System data • User Data --> System program code • Exploit Shell Code Example C program (handout #2) • Incomplete Mediation - data exposed or uncontrolled • Synchronization or race conditions Perl race example (handout #3) • Mutex, File Lock or Semaphore Perl File Lock example (handout #4)

  4. Week 14: 3.3 Viruses and Other Malicious Code • Programs work on data and users usually don't see the raw data. • Malicious users can make programs that access data and other programs other than what was intended. • Malicious code can do harm. • Malicious code has been around for a long long time (70's). • Malicious code can also be accidental.

  5. Week 14: Kinds of Malicious Code • Virus - a program that can pass code onto other nonmalicious programs by modifying them. • Transient - only executes when the program that it is attached to runs. • Resident - once the program executes the virus stays in memory until it gets triggered again. Terminate and Stay Resident (TSR). • Trojan horse - program appears to execute normal, but does something else. Example • Logic bomb - only gets activated when specific condition occurs. • Trapdoor- Vendor supplies systems with maintenance account and password. (hosts.equiv + +) Or programmers write program with special access for later use (sendmail - wizzard administrator) • Worm - like virus but stand alone program that only purpose is to replicate itself and uses the network to spread to other systems. Virus attaches itself to another program. • Rabbit - Replicates itself without limit to exhaust resource (I disagree with author)

  6. Week 14: Table 3-1 Types of Malicious Code

  7. Week 14: Added New • Spyware-This is new. Can be non-malicious or malicious. • Can steal your information (Identity Theft). This is done with a keystroke logger and even though you use encryption on connections the damage is already done before it can be encrypted. • Can steal your email addresses • Can see what Web sites you visit • Can see contents of files • PopUp ads • Slow down your computer • Crash your computer • Today's top SpywareI-Look UpCoolWebSearchN-CaseGATORDoubleClick • Two programs to fight Spyware:Ad-Aware (Lavasoft)Spybot - Search & Destroy

  8. Week 14: Added New Last year: April 23, 2004 ECS Student Account Hacked. • One student in ECS has learned a lesson the hard way. On April 16th he noticed some strange files in his html directory that he had not put there. He noticed a README file and when he examined the contents it mentioned "IRC". So he erased the files and did not report it or think anything serious about it. On Friday April 23rd the ECS Security Staff noticed his account being used by two or more users from Amsterdam Netherlands. The staff changed his password to lock them out and then killed their processes. When the student whose account was being used was contacted it was determined his password was non-crackable. But here's the serious part, he has a home computer and does not have a firewall nor until recently a anti-virus software. The recent purchase of anti-virus software identified several viruses, worms, Trojans and hacker programs. It is the belief of ECS Security Staff that his computer contained a SPYWARE program that captured his keystrokes and sent them to hackers in Europe.

  9. Week 14: Simple Virus Pseudo Code Program V := {goto main; 1234567; subroutine infect-executable := {loop: file := get-random-executable-file; if (first-line-of-file = 1234567) then goto loop else prepend V to file;} subroutine do-damage := {whatever damage is to be done} subroutine trigger-pulled := {return true if some condition holds} main: main-program := {infect-executable; if trigger-pulled then do-damage; goto next;} next: }

  10. Week 14: How Viruses Attach • Append viruses - execute first then transfers control to original program. • Surround virus -has control before and after regular program. • Integrated viruses - replace some of the target program or all of the target and give the effect that the target program worked.

  11. Week 14: How Viruses Gain Control • The virus needs to have the CPU execute it to be in control. • One way is to overwrite the program on the disk. • Another is to move the original program and then after the CPU executes it then transfer control to the program. • Another is to install itself in memory and change the pointers of the operating system or interrupt table to point to it.

  12. Week 14: Homes for Viruses • Install itself in the boot sector (MBR) master boot record. • Memory resident virus - (TSR) terminate and stay resident. • Other homes such as applications like word processors and spread sheets and even attachments to email. • Even attachments to vendor distributed programs or games.

  13. Week 14: Virus Signatures • Virus can not be completely invisible but can be very hard to detect, especially if it has self modifying code. • The code it executes can be identified and a program can scan for the tell-tail code. • Usually it is at the start of a program or maybe a test and jump to code at the bottom of the file. • If the virus writer wants to keep the program size the same to prevent detection then it has to replace some of the program code or compress the program and prepend the virus to the program. • But a good scanner with a checksum can detect the changes in the code.

  14. Week 14: The Source of Viruses • Virus program can be small so it hides very easily in a large program. • Might hide in a compiler, a data base manager or a file manager. • Macro virus so named because it’s a macro in Microsoft Word, Excel and others (visual basic program). • The number one spot is an attachment to email or some public download file. • Virus program can be part of a Trojan or Worm. • Several BAD sites have toolkits that will build a virus without the user having any technical knowledge (script kiddies).

  15. Week 14: Preventing Virus Infection • Ways to prevent Virus infections • Test all new software on an isolated computer. • Use only commercial software acquired from reliable, well established vendors. • Do not put a floppy disk in the machine unless it has been scanned first. • Do not open attachments to email unless they have been scanned. Including turn off the auto open of attachments in mail readers. • Scan any downloaded files before they are run. • At least once a week update the virus signature data files. • Make a bootable disk/CD with a virus scan program on it and write protected. • Make and retain backup copies of executable system files in the event the virus detection program can't remove the virus.

  16. Week 14: Truths and Misconceptions About Viruses • Although other computers/operating systems are vulnerable to Viruses, it seems the mentality of the programmers of Viruses is more common on PCs. • Viruses can modify hidden and read only files. True • Viruses can appear only in data files or Word docs, or in programs. False • Viruses spread only on disks or in e-mail. False • Viruses can not live in memory when the computer is shut off, but they can still be on other storage devices. Also Reboot (warm start) is vulnerable to Viruses in memory. True • Viruses cannot infect hardware. True • Viruses can be malevolent, benign, or benevolent. True

  17. Week 14: Virus Examples: • The BRAIN virus and Melissa virus (handout #5) • http://gaia.ecs.csus.edu/~dsmith/csc250/lecture_notes/wk11/wk11_12.html

  18. Week 14: Worm Examples: • The AnnaKournikova.jpg.vbs (VB Script worm Feb 2001) • http://gaia.ecs.csus.edu/~dsmith/csc250/lecture_notes/wk11/anna.vbs.html • Symanetec analysis of anna worm • http://gaia.ecs.csus.edu/~dsmith/csc250/lecture_notes/wk11/vbs.sst.html

  19. Week 14: Worm Examples: • The Mawanella.vbs (VB Script worm May 2001) • http://gaia.ecs.csus.edu/~dsmith/csc250/lecture_notes/wk11/Mawanella.vbs.html • Decoded Mawanella • http://gaia.ecs.csus.edu/~dsmith/csc250/lecture_notes/wk11/mawa.decoded.vbs.html

  20. Week 14: Other Malicious Code: Internet Worms • Famous 1988 Internet Worm Robert Morris Worm • Code Red first to spread fast 1/4 million in 9 hours. • Only effective on Microsoft IIS Servers (overflow buffer) • Recent (Aug 2003) Microsoft W32.Blaster Worm • Also W32/Welchia Worm (a.k.a. good worm!) (not) • Copycats create versions (usually lettered A, B...) • Confusion in the Internet since there are 8 companies in business of security for Virus/Worm Scanners and each gives a different name to the malicious code. (Instructors comment) e.g. W32/Welchia.worm10240 [AhnLab], W32/Nachi.worm [McAfee], WORM_MSBLAST.D [Trend], Lovsan.D [F-Secure], W32/Nachi-A [Sophos], Win32.Nachi.A [CA], Worm.Win32.Welchia [Kaspersky] • The 8 companies are:Computer AssociatesF-secureNetwork AssociatesNormanPandaSophosSymantecTrend Micro

  21. Week 14: Sec. 3.4 Targeted Malicious Code • The previous notes have dealt with anonymous code not targeted to a specific system, application or a particular purpose. • Trapdoors are often caused by programmers leaving debug routines in the code. Or failure to check array bounds which lets code overrun the array bounds and get placed on the stack. • Causes of Trapdoors: • Programmer forgets to remove them. • Programmer intentionally leaves them in for testing. • Leaves them in intentionally for maintenance of the finished product. • Leaves them in for later covert means of access. • Salami Attacks refer to the simple fact, that when dealing with real numbers the computer has a fixed size and will perform rounding or truncation. There will always be those programmers that will try to conceal the small amounts on the hope that humans will not notice a small error.

  22. Week 14: Sec. 3.5 Controls against Program Threats • Software Engineering • Modularity, Encapsulation, and Information Hiding • Peer reviews • Hazard Analysis HAZOP, FMEA, FTA • Independent Testing • Good Design • Prediction • Static Analysis • Configuration Management • Proofs of Program Correctness • Operating System Controls - trusted software, confinement, audit log • Administrative Controls - Standards of program development

  23. Week 14: Sec. 3.6 Summary of Program Threats and Controls • Malicious code gets a lot of publicity. But don't let media attention distract you from the seriousness of the threat. • No real way to measure the amount of damage that malicious code can do. All one can do is estimate, and that is only for the discovered programs, what about the ones that haven't been discovered or haven't been executed, or worst the ones that haven't been written yet. • Sites to research for Viruses, Worms, Hoaxes and other Malicious Code: • The Department of Energy's CIAC Hoax pagehttp://ciac.llnl.gov/ciac/CIACHoaxes.html • The Symantec Corporation (Norton Anti-virus Home) SARC databasehttp://www.symantec.com/avcenter/hoax.html • Network Associates (McAfee and Dr. Solomon Anti-virus) web pagehttp://vil.nai.com/villib/alpha.asp • The CERT (Computer Emergency Response Team) http://www.cert.org/ • The SANS Institute (System Administration, Networking, and Security) http://www.sans.org/newlook/home.htm

  24. Week 14: Sec. 3.6 Summary Cont • The Urban Legends Site (home of folklore)"An urban legend: appears mysteriously and spreads spontaneously in varying forms • contains elements of humor or horror (the horror often "punishes" someone who flouts society's conventions). • makes good storytelling. • does NOT have to be false, although most are. ULs often have a basis in fact, but it's their life after-the-fact (particularly in reference to the second and third points) that gives them particular interest." • http://urbanlegends.about.com/ • Recommend daily (at least once a week) visit the Internet Storm Center to find out what condition the Internet is as far as security!!! • http://isc.sans.org/

More Related