Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 8. Copyright Pearson Prentice-Hall 2010  Some attacks inevitably get through network protections and reach individual hosts  In Chapter 7, we.

Similar presentations


Presentation on theme: "Chapter 8. Copyright Pearson Prentice-Hall 2010  Some attacks inevitably get through network protections and reach individual hosts  In Chapter 7, we."— Presentation transcript:

1 Chapter 8

2 Copyright Pearson Prentice-Hall 2010  Some attacks inevitably get through network protections and reach individual hosts  In Chapter 7, we looked at operating system and data hardening  In Chapter 8, we look at application hardening  This is the last chapter on protection. ◦ Chapter 9 focuses on response 2

3 Copyright Pearson Prentice-Hall 2010  Executing Commands with the Privileges of a Compromised Application ◦ If an attacker takes over an application, the attacker can execute commands with the privileges of that application ◦ Many applications run with super user (root) privileges ◦ In Today’s News…  CarrierIQ CarrierIQ  Hidden surveillance software, is embedded into most mobile devices, including Android, Nokia, Blackberry  With you guessed it Root Access! 3

4  One of the most important findings in cybersecurity over the past several years has been the understanding most often asserted by White House officials that "offense must inform defense." Only people who understand how attacks are carried out can be expected to be effective defenders. Copyright Pearson Prentice-Hall 2010 4

5 5 SANS Institute

6 Copyright Pearson Prentice-Hall 20096 Top 25 Application Vulnerabilities

7  But if we don’t understand these vulnerabilities  We Can’t ask the correct questions  We Can’t deploy the proper controls  We Can’t test the controls are working 7 Copyright Pearson Prentice-Hall 2009

8  mydebitcredit.com mydebitcredit.com  Reviewing one of the disabled files, this is the malicious code that wasinjected at the beginning of the file:<?php /**/eval(base64_decode("aWYoZnVuY3Rpb25f ZXhpc3RzKCdvYl9zdGFydCcpJiYhaXNzZXQo... (this continues on) 8

9  Buffer Overflows  Stack Overflows  Cross-Site Scripting (XSS)  SQL-Injection Copyright Pearson Prentice-Hall 2010 9

10  Buffer Overflow Attacks ◦ Buffers are places where data is stored temporarily ◦ A condition at an interface under which more input can be placed into a buffer or data holding area than the capacity allocated, overwriting other information. ◦ Consequences include:  Corruption of data  Unexpected transfer of control (to an unauthorized program)  Memory access violations  Program termination 10

11 Copyright Pearson Prentice-Hall 2010 11

12 12 Lets say this is computer memory running an application. The application is paused to get data So the address of where the application is before interruption is stored So we can return after getting data, but the return address is overwritten and after the pause, a new program begins processing Application Variables Return Address Application Overwrites Return Address Variables New Return Address Exploit/ShellCode

13  Identify existence of a buffer overflow vulnerability  Application must require external data that the attacker can control  Understanding of how buffer will be stored in memory 13

14  Inspect Code  Fuzzing (discussed later) 14

15  Specifically written for: ◦ A particular processor (e.g. Intel) ◦ A particular Operating System (Windows XP SP3) ◦ A particular Application ◦ Written in Machine code  Requires High level of Expertise  But Not anymore….  Metaspolit Project Metaspolit Project 15

16  Compile-Time Defenses ◦ Harden Program Code  Run-Time Defenses ◦ Detect and Abort Buffer Overflow Attacks 16

17  Choose High-Level Program Language ◦ Higher level languages better address  Data Types (text in text, integer in integer)  Better controls over data type manipulations  Perform range checks ◦ Downside Cost  Further away from underlying machine language  May not be able to access certain instructions and hardware resources may be lost  May not be possible to use these languages for  Device Drivers 17

18  Safe Coding Techniques ◦ Programmers need to inspect code for Security ◦ OpenBSD – Secure Unix Operating System ◦ Coding for Graceful Failure ◦ Any Code written to a buffer must FIRST check to ensure sufficient space is available 18

19  Stack Protection ◦ Program Entry and Exit code checks for evidence of corruption ◦ If found program is aborted ◦ Example:  Stackgaurd  Uses a “Canary” value which is inserted in memory right below the return address  This value is known  A check of this value at the known memory location before using a return address can determine if overflow changes occurred 19

20  Stack Protection ◦ Stackshield and Return Address Defender (RAD) ◦ When new function is called, return address is copied to a safe area of memory ◦ When function is finished, the Return Address in stack is compared against address in safe memory 20

21  Executable Address Space Protection ◦ Do Not allow executable code (applications) to run from the buffer  Address Space Randomization ◦ Change location of buffer in memory randomly for each process being run.  Guard Pages ◦ Gaps are placed between memory locations, thus overflow data goes into gaps and does not Overwrite data ◦ If data is written to one of these gaps, the program is aborted 21

22 Copyright Pearson Prentice-Hall 2010  Few Operating Systems but Many Applications ◦ Application hardening is more total work than operating system hardening  Understanding the Server’s Role and Threat Environment ◦ Just run minimum necessary applications on a server ◦ If Email, just run email 22

23 Copyright Pearson Prentice-Hall 2010  Basics ◦ Physical Security ◦ Backup ◦ Harden the Operating System ◦ Etc.  Minimize Applications ◦ Main applications ◦ Subsidiary applications  Wordpress Plugins (mydebitcredit.com) ◦ Be guided by security baselines 23

24 Copyright Pearson Prentice-Hall 2010  Create Secure Application Program Configurations ◦ Use baselines to go beyond default installation configurations for high-value targets ◦ Avoid blank passwords or well-known default passwords  Install Patches for All Applications  Minimize the Permissions of Applications ◦ If an attack compromises an application with low permissions, will not own the computer 24

25 Copyright Pearson Prentice-Hall 2010  Add Application Layer Authentication, Authorizations, and Auditing ◦ More specific to the needs of the application than general operating system logins ◦ Can lead to different permissions for different users  Implement Cryptographic Systems ◦ For communication with users 25

26 Copyright Pearson Prentice-Hall 2010  Custom Applications ◦ Written by a firm’s programmers ◦ Not likely to be well trained in secure coding  The Key Principle ◦ Never trust user input ◦ Filter user input for inappropriate content 26

27  Software Quality Testing ◦ Use of Structured Design Process (SAD) ◦ Testing to eliminate as many bugs as possible  Variations of likely data input to uncover bugs  Focus is on triggering bugs and fixing flaw  Secure Coding ◦ Attacker targets a known bug and exploits it ◦ Triggered by input much different than that tested for software quality, thus not likely caught during QA ◦ Increase Time and amount of Code needed  Conflicts with Business pressures for SAD 27

28  Input  Processing  Output  We’ll examine only Input… 28

29  Most common points of failure  Input is: ◦ Any data that originates from outside of the application  Keyboard  Files  Network connections  Data from operating environment  Configuration settings ◦ Data value is not known by the programmer when code is written (a variable) ◦ Data size and Data type have to be verified by code 29

30  Data Interpretation ◦ What data is being input ◦ What is the meaning of the data  Data Input can be: ◦ Textual ◦ Binary  0s and 1s are interpreted as:  Integers, floating point numbers, character strings  Must be validated  Meaning of Data ◦ Is it a URL ◦ Email Address ◦ Integer 30

31  Input data accidently or deliberately changes the operations of the program.  Happens often when input data are passed between functions of a program as parameters (variables) ◦ Input to one program is Output to another  SQL injection ◦ SQL query inserted as input or part of input  Code injection ◦ Code that is executed by the system (e.g. buffer overflow) 31

32 Copyright Pearson Prentice-Hall 2010  Buffer Overflow Attacks ◦ In some languages, specific actions are needed ◦ In other languages, not a major problem  Login Screen Bypass Attacks ◦ Website user gets to a login screen ◦ Instead of logging in, enters a URL for a page that should only be accessible to authorized users 32

33 Copyright Pearson Prentice-Hall 2010  Cross-Site Scripting (XSS) Attacks ◦ One user’s input can go to another user’s webpage ◦ Usually caused if a website sends back information sent to it without checking for data type, scripts, etc. ◦ Example, If you type your username, it may include something like, “Hello username” in the webpage it sends you 33

34 Copyright Pearson Prentice-Hall 2010  Example ◦ Attacker sends the intended victim an e-mail message with a link to a legitimate site ◦ However, the link includes a script that is not visible in the browser window because it is beyond the end of the window ◦ The intended victim clicks on the link and is taken to the legitimate webpage ◦ The URL’s script is sent to the webserver with the HTTP GET command to retrieve the legitimate webpage 34

35 Copyright Pearson Prentice-Hall 2010  Example ◦ The webserver sends back a webpage including the script ◦ The script is invisible to the user (browsers do not display scripts) ◦ But the script executes ◦ The script may exploit a vulnerability in the browser or another part of the user’s software  Comment Example ◦ Hey I really liked that blog post ◦ document.location=‘http://hacker.web.site’ 35

36  Input data should be inspected  Sounds easy, look for as part of input and block…. But  HTML character entities ◦ < = <  Input should be compared to what is wanted by the program ◦ NOT against known dangerous values ◦ See Encoding above 36

37 Copyright Pearson Prentice-Hall 2010  SQL Injection Attacks ◦ For database access ◦ Programmer expects an input value—a text string, number, etc.  May use it as part of an SQL query or operation against the database  Say to accept a last name as input and return the person’s telephone number 37

38 Copyright Pearson Prentice-Hall 2010  SQL Injection Attacks ◦ Attacker enters an unexpected string  For example: a last name followed by a full SQL query string  Bob’ drop table suppliers==  The program may execute both the telephone number lookup command and the extra SQL query  This may look up information that should not be available to the attacker  It may even delete an entire table 38

39 Copyright Pearson Prentice-Hall 2010  Must Require Strong Secure Programming Training ◦ General principles ◦ Programming-language-specific information ◦ Application-specific threats and countermeasures 39

40 Copyright Pearson Prentice-Hall 2010  Importance of WWW Service and E-Commerce Security ◦ Cost of disruptions, harm to reputation, and market capitalization ◦ Customer fraud ◦ Exposure of sensitive private information 40

41 Copyright Pearson Prentice-Hall 2010  Webservice versus E-Commerce Service ◦ WWW service provides basic user interactions  Microsoft Internet Information Server (IIS), Apache on UNIX, other webserver programs ◦ E-commerce servers add functionality: Order entry, shopping cart, payment, etc.  Links to internal corporate databases and external services (such as credit card checking)  Custom programs written for special purposes 41

42 Copyright Pearson Prentice-Hall 2010 42

43 Copyright Pearson Prentice-Hall 2010  Website Defacement  Numerous IIS buffer overflow attacks ◦ Many of which take over the computer  IIS directory traversal attacks 43

44 Copyright Pearson Prentice-Hall 2010 44 Users should only be able to reach files below the WWW root, which is below the true system root

45 Copyright Pearson Prentice-Hall 2010 45 In URLs,.. means move up one level. If allowed, user can get outside the WWW root box, into other directories In URLs,.. means move up one level. If allowed, user can get outside the WWW root box, into other directories

46 Copyright Pearson Prentice-Hall 2010  IIS directory traversal attacks (Figure 8-8) ◦ Companies filter out “..” ◦ Attackers respond with hexadecimal and UNICODE representations for “..” and “..”  Hex code for.. = 2E2E  Unicode for.. 002E002E  All three interpreted the same by webserver ◦ Typical of the constant “arms race” between attackers and defenders 46

47 Copyright Pearson Prentice-Hall 2010  Patching the WWW and E-Commerce Software and Their Components ◦ Patching the webserver software is not enough ◦ Also must patch e-commerce software ◦ E-commerce software might use third-party component software that must be patched 47

48 Copyright Pearson Prentice-Hall 2010  Other Website Protections ◦ Website vulnerability assessment tools, such as Whisker ◦ Reading website error logs ◦ Placing a webserver-specific application proxy server in front of the webserver 48

49 Copyright Pearson Prentice-Hall 2010 49

50 Copyright Pearson Prentice-Hall 2010  PCs Are Major Targets ◦ Have interesting information and can be attacked through the browser  Client-Side Scripting (Mobile Code) ◦ Java applets: Small Java programs  Usually run in a “sandbox” that limits their access to most of the system ◦ Active-X from Microsoft; highly dangerous because it can do almost everything 50

51 Copyright Pearson Prentice-Hall 2010  Client-Side Scripting (Mobile Code) ◦ Scripting languages (not full programming languages)  A script is a series of commands in a scripting language  JavaScript (not scripted form of Java)  VBScript (Visual Basic scripting from Microsoft)  A script usually is invisible to users 51

52 Copyright Pearson Prentice-Hall 2010  Malicious Links ◦ User usually must click on them to execute (but not always) ◦ Tricking users to visit attacker websites  Social engineering to persuade the victim to click on a link  Choose domain names that are common misspellings of popular domain names 52 You like beef? click here. You like beef? click here. http://www.micosoft.com

53 Copyright Pearson Prentice-Hall 2010  Other Client-Side Attacks ◦ File reading: turn the computer into an unintended file server ◦ Executing a single command  The single command may open a command shell on the user’s computer  The attacker can now enter many commands 53 C:>

54 Copyright Pearson Prentice-Hall 2010  Other Client-Side Attacks ◦ Automatic redirection to unwanted webpage  On compromised systems, the user may be automatically directed to a specific malicious website if they later make any typing error 54

55 Copyright Pearson Prentice-Hall 2010  Other Client-Side Attacks ◦ Cookies  Cookies are placed on user computer; can be retrieved by website  Can be used to track users at a website  Can contain private information  Accepting cookies is necessary to use many websites 55

56 Copyright Pearson Prentice-Hall 2010  Enhancing Browser Security ◦ Patches and updates ◦ Set strong security configuration options (Figure 8- 12) for Microsoft Internet Explorer ◦ Set strong privacy configuration options (Figure 8- 13) for Microsoft Internet Explorer 56

57 Copyright Pearson Prentice-Hall 2010 57

58 Copyright Pearson Prentice-Hall 2010 Copyright Pearson Prentice-Hall 2009 58

59 Copyright Pearson Prentice-Hall 2010  Content Filtering ◦ Malicious code in attachments and HTML bodies (scripts) ◦ Spam: Unsolicited commercial e-mail ◦ Volume is growing rapidly: Slowing PCs and annoying users (porno and fraud) ◦ Filtering for spam also rejects some legitimate messages 59

60 Copyright Pearson Prentice-Hall 2010  Inappropriate Content ◦ Companies often filter for sexually or racially harassing messages ◦ Could be sued for not doing so  Extrusion Prevention for Intellectual Property (IP)  Stopping the Transmission of Sensitive Personally Identifiable Information (PII) 60

61 Copyright Pearson Prentice-Hall 2010 61

62 Copyright Pearson Prentice-Hall 2010  Employee training ◦ E-mail is not private; company has right to read ◦ Your messages may be forwarded without permission ◦ Never put anything in a message the sender would not want to see in court, printed in the newspapers, or read by his or her boss ◦ Never forward messages without permission 62

63 Copyright Pearson Prentice-Hall 2010  E-Mail Encryption (Figure 8-17) 63

64 Copyright Pearson Prentice-Hall 2010  Benefits of Retention ◦ Major part of corporate memory ◦ Often need to retrieve old mail for current purposes  Dangers of Retention ◦ Legal discovery process ◦ Defendant must supply relevant e-mails ◦ Potentially very damaging information ◦ Always expensive ◦ Even if very expensive to retrieve, firms must pay whatever is necessary to do so 64

65 Copyright Pearson Prentice-Hall 2010  Accidental Retention ◦ Even if firms delete e-mail from mail servers, ◦ May be stored on backup tapes ◦ Users will often store copies on their own computers 65

66 Copyright Pearson Prentice-Hall 2010  Legal Archiving Requirements ◦ Many laws require retention  Securities and Exchange Commission  Many labor laws  Involuntary terminations  Public information about job openings  Medical problem complaints that may relate to toxic chemicals ◦ Laws vary in duration of storage requirements ◦ Fines or summary judgments if fail to retain and produce required e-mails 66

67 Copyright Pearson Prentice-Hall 2010  U.S. Federal Rules of Civil Procedure ◦ Specify rules for all U.S. federal civil trials ◦ Specifically address electronically stored information ◦ Initial discovery meeting  Defendant must be able to specify what information is available  Comes shortly after a civil lawsuit begins  Unless carefully thought through before hand, will fail 67

68 Copyright Pearson Prentice-Hall 2010  U.S. Federal Rules of Civil Procedure ◦ Holds on destruction  Must be put in place if it is foreseeable that a lawsuit will soon begin  Must have strong hold procedures to place holds on all electronically stored information  Archiving Policies and Processes ◦ Must have them ◦ Must reflect a firm’s legal environment ◦ Must be drawn up with the firm’s legal department 68

69 Copyright Pearson Prentice-Hall 2010  Message Authentication ◦ Spoofed messages can frame employees or the firm itself ◦ Need message authentication to prevent spoofed sender addresses 69

70 Copyright Pearson Prentice-Hall 2010 70

71 Copyright Pearson Prentice-Hall 2010 71 ConceptMeaning TransportThe carriage of voice between the two parties SignalingCommunication to manage the network. Call setup Call teardown Accounting Etc.

72 Copyright Pearson Prentice-Hall 2010  Eavesdropping  Denial-of-Service Attacks ◦ Even small increases in latency and jitter can be highly disruptive  Caller Impersonation ◦ Useful in social engineering ◦ Attacker can appear to be the president based on a falsified source address 72

73 Copyright Pearson Prentice-Hall 2010  Hacking and Malware Attacks ◦ Compromised clients can send attacks ◦ Compromised servers can do disruptive signaling  Toll Fraud ◦ Attacker uses corporate VoIP network to place free calls  Spam over IP Telephony (SPIT) ◦ Especially disruptive because it interrupts the called party in real time 73

74 Copyright Pearson Prentice-Hall 2010  Basic Corporate Security Must Be Strong  Authentication ◦ SIP Identity (RFC 4474) provides strong authentication assurance between second-level domains  Encryption for Confidentiality ◦ Can add to latency 74

75 Copyright Pearson Prentice-Hall 2010  Firewalls ◦ Many short packets ◦ Firewall must prioritize VoIP traffic ◦ Must handle ports for signaling  SIP uses Port 5060  H.323 uses Ports 1719 and 1720  Must create an exception for each conversation, which is assigned a specific port  Must close the transport port immediately after conversation ends 75

76 Copyright Pearson Prentice-Hall 2010  NAT Problems ◦ NAT firewall must handle VoIP NAT traversal ◦ NAT adds a small amount of latency  Separation: Anticonvergence ◦ The convergence goal for data and voice ◦ Virtual LANs (VLANs)  Separate voice and data traffic on different VLANs  Separate VoIP servers from VoIP phones on different VLANs 76

77 Copyright Pearson Prentice-Hall 2010  Widely Used Public VoIP Service  Uses Proprietary Protocols and Code ◦ Vulnerabilities? Backdoors? Etc. ◦ Firewalls have a difficult time even recognizing Skype traffic  Encryption for Confidentiality ◦ Skype reportedly uses strong security ◦ However, Skype keep encryption keys, allowing it to do eavesdropping 77

78 Copyright Pearson Prentice-Hall 2010  Inadequate Authentication ◦ Uncontrolled user registration; can use someone else’s name and so appear to be them  Peer-to-Peer (P2P) Service ◦ Uses this architecture and its proprietary (and rapidly changing) protocol to get through corporate firewalls ◦ Bad for corporate security control  Skype File Sharing ◦ Does not work with antivirus programs 78

79 Copyright Pearson Prentice-Hall 2010  Databases ◦ Often used in mission-critical applications ◦ Relational databases: Tables with rows (entities) and columns (attributes) ◦ As discussed earlier, avoid SQL injection attacks 79

80 Copyright Pearson Prentice-Hall 2010  Databases ◦ Restrict Access to Data  Restrict users to certain columns (attributes) in each row  For instance, deny access to salary column to most users  Limit access control to rows  For instance, only rows containing data about people in the user’s own department 80

81 Copyright Pearson Prentice-Hall 2010  Databases ◦ Restrict Granularity  Prevent access to individual data  Allow trend analysts to deal only with sums and averages for aggregates such as departments 81

82 Copyright Pearson Prentice-Hall 2010 82 Presence servers merely tell the clients that others exist and what their IP addresses are

83 Copyright Pearson Prentice-Hall 2010 83 All transmissions go through relay servers when relay servers are used.

84 Copyright Pearson Prentice-Hall 2010  Spreadsheet Security ◦ Spreadsheets are widely used and the subject of many compliance regulations ◦ Need for security testing ◦ Spreadsheet vault server to implement controls (Figure 8-25) 84

85 Copyright Pearson Prentice-Hall 2010 85 1. The vault server stores spreadsheets and strongly controls access to them. Authentication Authorizations Auditing 1. The vault server stores spreadsheets and strongly controls access to them. Authentication Authorizations Auditing 2. Spreadsheets record each change for auditing purposes 2. Spreadsheets record each change for auditing purposes

86 Copyright Pearson Prentice-Hall 2010 86 3. Cryptographic Protections for Transmissions 3. Cryptographic Protections for Transmissions 4. Strong Client Security 4. Strong Client Security

87 Copyright Pearson Prentice-Hall 2010  TCP/IP Supervisory Protocols ◦ Many supervisory protocols in TCP/IP  ARP, ICMP, DNS, DHCP, LDAP, RIP, OSPF, BGP, SNMP, etc. ◦ The targets of many attacks ◦ The IETF has a program to improve security in all (the Danvers Doctrine) 87

88 Copyright Pearson Prentice-Hall 2010  Example ◦ Simple Network Management Protocol (SNMP) ◦ Messages  GET messages to get information from a managed object  SET messages to change the configuration of a managed object  SET is often turned off because it is dangerous 88

89 Copyright Pearson Prentice-Hall 2010  Example ◦ SNMP versions and security  Version 1: No security  Version 2: Weak authentication with a community string shared by the manager and managed devices  Version 3: Pair-shared secrets, optional confidentiality, message integrity, and anti- replay protection  Still needed: public key authentication 89

90 Copyright Pearson Prentice-Hall 2010  IT Security People Must Work with the Networking Staff ◦ To ensure that appropriate security is being applied to supervisory protocols ◦ Not a traditional area for IT security in most firms 90

91 91

92 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America. Copyright © 2010 Pearson Education, Inc. Copyright © 2010 Pearson Education, Inc. Publishing as Prentice Hall


Download ppt "Chapter 8. Copyright Pearson Prentice-Hall 2010  Some attacks inevitably get through network protections and reach individual hosts  In Chapter 7, we."

Similar presentations


Ads by Google