Presentation is loading. Please wait.

Presentation is loading. Please wait.

Course 1 Learning Plan  Security overview and patching  Public vulnerability databases and resources  Secure software engineering  Security assessment.

Similar presentations


Presentation on theme: "Course 1 Learning Plan  Security overview and patching  Public vulnerability databases and resources  Secure software engineering  Security assessment."— Presentation transcript:

1 Course 1 Learning Plan  Security overview and patching  Public vulnerability databases and resources  Secure software engineering  Security assessment and testing  Resource management  Trust management

2 Learning objectives  Be able to identify resources at risk  Understand how resources become at risk from denial-of-service attacks  Be able to decide which resources need to be exposed  Understand how to mitigate resource exhaustion risks

3 Resource Management: Outline  Motivation  Resource identification  Resource exhaustion CPU exhaustion Network applications and protocols vulnerabilities Generous Protocols and Algorithms Other asymmetric attacks  Memory Management

4 How Important is Availability?  How important is it to have resources available at some specific times or all the time?  Market for 99.99% availability systems or even "5 nines" (99.999%) Worth a lot of money for some businesses Redundant hardware, fault-resistant software  Problem: Infrastructure, hardware, software usually designed for functionality and performance in normal situations, not robustness vs. worst-case scenarios Malicious people can engineer worst-case scenarios to come true

5 Availability Through Software  Monitoring software that relaunches an application whenever it crashes or quits  Redundant software installations on different partitions  Disk images (e.g., Ghost)  Virtual machines that reload running images (VMWare)  The above are just mitigating setups that don't fix the original problem and can still cause interruptions Perfect software is not possible, but better software is

6 Denial of Service  The unavailability of a needed resource, most often due to a malicious entity.  Sometimes not the primary goal Side effect of another attack Failure to achieve worse results  Perhaps used to evade traceability, law enforcement or accountability disable logging mechanisms disable detection and alert systems  submerge human with messages, human may disable the attacked defense mechanism!

7 Resource Identification  Shared resources are exposed to resource exhaustion attacks Memory Hard Drive space Bandwidth CPU Entropy (for random number generation) Database engines Servers Analysts Wireless Mice, Keyboards Wireless NICs

8 Question  Which one of these resources is susceptible to a resource exhaustion attack?  a) Electric power  b) Chair  c) Trackpad

9 Resource Exhaustion  May happen whenever there are: A finite number of resources A finite rate (e.g., processing)  Hard to defend against some variants Sometimes a balancing act Analogy: By staying home, the risk of meeting unpleasant people is removed, but the cure may be worse than the risk.

10 How Resource Exhaustion Happens  Spend time processing requests from illegitimate (but possibly legitimate) users  Allow legitimate users to hog resources  Improperly free resources no longer needed  Sometimes design errors, sometimes implementation

11 Resource Exhaustion Enablers  Expensive Tasks Algorithms Encryption, Compression and Encoding  e.g., DVDs are expensive to compress  Generous Protocols and Algorithms Anonymous or unauthenticated allocation of computer resources Amplifiers (broadcasts, subscriptions, distributed systems)  Coding errors turned into vulnerabilities Memory Leaks and other memory management errors  Design errors Absence of policies, restrictions, access control, partitions or compartments, backups, failover or redundant systems

12 Example: Disk  Risk: Disk or partition is unavailable because it is completely filled  Threat: one user can rob all others of disk space (including the use of a partition)  Resource managed by the operating system  Enabling factors Missing or no quotas specified by OS for users and processes  /tmp directory  fill up the disk (or partition) with temp files  /var directory  use up the disk (or partition) with logs

13 Question  Identify the correct resource exhaustion enablers: a) Memory failures b) Generous protocols and algorithms c) Expensive hardware

14 Question  Identify the correct resource exhaustion enablers: a) Memory failures b) Generous protocols and algorithms c) Expensive hardware

15 CPU Exhaustion Attacks  Uninterruptible tasks  Unwise operational order Perform a series of complex operations first, before checking the request's validity  Asymmetric attacks Cost for attacker is much smaller than for defender Algorithmic complexity attacks

16 Uninterruptible Tasks  CAN Linux and earlier allows local users to cause a denial of service (resource exhaustion) by reading a large buffer from a random device (e.g. /dev/urandom), which cannot be interrupted until the read has completed.  CPU not available until random numbers have all been calculated

17 Unwise Operational Order  A firewall’s job is to block traffic Don’t perform expensive operations on traffic you’re blocking anyway!  CAN IBM SecureWay Firewall before performs extra processing before determining that a packet is invalid and dropping it, which allows remote attackers to cause a denial of service (resource exhaustion) via a flood of malformed TCP packets without any flags set.

18 Asymmetric CPU Attacks  Cryptographic algorithms are typically expensive Initiate communications so server generates keys, etc...  Don’t know if message is good until decrypted Send random messages  IPSEC design vulnerability

19 Algorithmic Complexity Attacks  Exploit worst-case scenario of algorithms Hash algorithms (Crosby and Wallach 2003)  Data structure pollution  Bro IDS (Intrusion Detection System) dropping 70% packets  Normally O(N), becomes O(N 2 ) with malicious input  if N is 1000, cost is 1000 times higher than expected! Quicksort: O(N 2 ) instead of O(NlogN) Python regular expression engine  Exponential blowout with malicious input Fix: use algorithms that are not vulnerable  "universal hash algorithms" designed to avoid the vulnerability  Please see

20 Question  Algorithmic complexity attacks work because: a) they attack complex algorithms b) they exploit the worst-case behavior of algorithms c) there were errors in the implementation of the algorithms

21 Question  Algorithmic complexity attacks work because: a) they attack complex algorithms b) they exploit the worst-case behavior of algorithms c) there were errors in the implementation of the algorithms

22 Discussion  How would you prevent or defend against: Uninterruptible tasks Unwise operational order Asymmetric attacks

23 Discussion Sample Answers  How would you prevent or defend against: Uninterruptible tasks  Limit CPU slices per user  move part of algorithm out of kernel space Unwise operational order  Do not invest in something that may be worthless until you know for sure you have to (may not be initially obvious) Asymmetric attacks  Limit the rate of the expensive events/origin

24 Network Application and Protocol Vulnerabilities  Can produce: Memory exhaustion Numbered resource (e.g., ports) exhaustion Bandwidth exhaustion...

25 Ports and Thread Exhaustion  In TCP/IP, an application uses a ”port”, a positive number less than Example: port 80 for web servers.  Passive FTP: FTP server reserves a random port (above 1024) for use by a client and waits for the client to connect there.  What if client doesn’t connect ever?

26 Ports example  CAN Etype Eserv 2.97 allows remote attackers to cause a denial of service (resource exhaustion) via a large number of PASV commands that consume ports 1024 through 5000, which prevents the server from accepting valid PASV.

27 Threads Example  Microsoft NT architecture: FTP and Web services on the same computer share a common thread pool Exhausting the FTP thread pool will cause failed connection requests for the Web service.  CVE IIS processes passive FTP connection requests by assigning a thread to each port waiting for a client to connect

28 Sockets  Socket: Data structure to record which application talks to what  Internet sockets ( AF_INET ): Which application reserved which port One IP address, one port = one socket you can listen to Incoming connections are recorded with additional sockets Number of sockets -1 = number of clients

29 Sockets example  CVE tunnel 0.08 and earlier does not properly close sockets that were initiated by a client, which allows remote attackers to cause a denial of service (resource exhaustion) by repeatedly connecting to and disconnecting from the server.

30 Generous Protocols and Algorithms  A Protocol or Algorithm that allocates resources based on (perhaps initially) anonymous or unauthenticated requests  Can you name one?

31 TCP/IP Generosity  The TCP/IP protocol allocates memory at the beginning stage of a communication, upon reception of a packet with the “SYN” flag, to keep track of communications (e.g., socket).  Early TCP/IP implementations kept the memory allocated for a very long time...  SYN flood attack: The sending of numerous SYN packets until all the memory available for keeping track of new connections has been consumed.

32 Generosity in Stateful Protocols  Protocols that maintain state information are necessarily more vulnerable to DoS attacks. Above a certain treshold, quality of service breaks down  Connectionless protocols show progressive degradation with load  Conversion of stateful into stateless protocols Not easy in all cases, but can solve SYN flood Idea: encrypt the state data, and return it to client  No memory usage  Increased CPU and bandwidth usage trade-off Reference: Aura and Nikander 1997

33 Amplification  Form of generosity  Example: ICMP ping Request-response protocol Unauthenticated Can send request to a broadcast address  All computers respond!  To who? A spoofed IP address == Smurf attack  Bandwidth can be completely consumed by the response  Overwhelm victim destination computer  Other victims  hosts on affected networks  networks in between broadcast and destination

34 Question  Can you name another amplification mechanism used by attackers? a) Challenge-response mechanism b) Encryption c) Distributed Denial-of-Service attacks

35 Question  Can you name another amplification mechanism used by attackers? a) Challenge-response mechanism b) Encryption c) Distributed Denial-of-Service attacks  In DDoS attacks, amplification is provided by numerous "zombie" (compromised) computers obeying remote commands.

36 Work-Around for Generosity  Quickly expire transactions (connections, etc...) that block while waiting on input especially anonymous users

37 Exercise  Name the vulnerability in this pseudo-code, and explain why it is vulnerable: 1 Wait for client connection 2 Validate input 3 Create user object 4 Match user against potential dates 5 Prepare report 6 Verify that user paid subscription; if so send back report, if not send bill 7 Repeat (i.e. go to line 1)

38 Exercise  Name the vulnerability in this pseudo-code, and explain why it is vulnerable:  That is an unwise operational ordering. It can result in a resource exhaustion because expensive operations are performed before a request validity check.

39 Memory Management Problems  Memory leaks (very common) Memory that is never freed, for every request CAN Memory leak in libmcrypt before allows attackers to cause a denial of service (memory exhaustion)  Double free CVE The decompression algorithm in zlib and earlier, as used in many different utilities and packages, causes inflateEnd to release certain memory more than once (a "double free"), which may allow local and remote attackers to execute arbitrary code via a block of malformed compression data.

40 Memory Management Problems (cont.)  Use of freed memory CAN NetBSD 1.4 through 1.6 beta allows local users to cause a denial of service (kernel panic) via a series of calls to the TIOCSCTTY ioctl, which causes an integer overflow in a structure counter and sets the counter to zero, which frees memory that is still in use by other processes.  Freeing wrong memory CAN The getCanonicalPath function in Windows NT 4.0 may free memory that it does not own and cause heap corruption, which allows attackers to cause a denial of service (crash) via requests that cause a long file name to be passed to getCanonicalPath, as demonstrated on the IBM JVM...

41 Memory Management Problems (cont.)  Information leakage CAN PuTTY 0.53b and earlier did not clear logon credentials from memory, including plaintext passwords, which could allow attackers with access to memory to steal the SSH credentials. CAN SSH2 clients for VanDyke (1) SecureCRT and 3.4.7, (2) SecureFX and 2.0.4, and (3) Entunnel and earlier, do not clear logon credentials from memory, including plaintext passwords... CAN Multiple ethernet Network Interface Card (NIC) device drivers do not pad frames with null bytes...

42 Notes About Information Leakage  Overwrite sensitive memory to prevent leakage  Compilers may remove calls to bzero and memset during optimization Use SecureZeroMemory in Windows Use spc_memset from Secure Programming Cookbook  Use memory locking to prevent passwords and keys from being saved to disk (virtual memory, swap space) mlock AllocateUserPhysicalPages and VirtualLock  Disable crash dumps (core files) setrlimit(RLIMIT_CORE, …)

43 Memory Management Problems (cont.)  Invalid memory references CAN The Microsoft Java implementation, as used in Internet Explorer, can provide HTML object references to applets via Javascript, which allows remote attackers to cause a denial of service (crash due to illegal memory accesses)... CAN The Microsoft Java implementation, as used in Internet Explorer, allows remote attackers to read restricted process memory, cause a denial of service (crash), and possibly execute arbitrary code via the getNativeServices function, which creates an instance of the com.ms.awt.peer.INativeServices (INativeServices) class, whose methods do not verify the memory addresses that are passed as parameters.

44 Memory Management Problems (cont.)  Memory exposures CAN FreeBSD port programs that use libkvm for FreeBSD RELEASE and earlier, including (1) asmon, (2) ascpu, (3) bubblemon, (4) wmmon, and (5) wmnet2, leave open file descriptors for /dev/mem and /dev/kmem, which allows local users to read kernel memory. CAN Integer signedness error in several system calls for FreeBSD RELEASE-p10 and earlier may allow attackers to access sensitive kernel memory via large negative values to the (1) accept, (2) getsockname, and (3) getpeername system calls, and the (4) vesa FBIO_GETPALETTE ioctl.

45 Exhausting Memory for Data Structures  Process and other tables  Buffer pools  File descriptors  Sockets  Etc...

46 Human Resource Exhaustion  Typical street scenario: Some people distract the person guarding assets while others steal things or otherwise violate policies  Information security: Create many alerts and warnings so that an analyst or user is overwhelmed and can't identify the dangerous ones.  IDS flooding tools available  "Stick" (Giovanni 2001) Attack against online support and services  Chat bots (Gabriolovich and Gontmahker 2003)  Defense: Reverse Turing Tests  Recognizing distorted letters in an image  Riddles

47 Discussion  Discuss the similarities between SPAM and human resource exhaustion attacks.

48 True or False?  Denial of service attacks are all caused by resource exhaustion  All shared resources risk being exhausted  Lower resource cost to the attacker than the defender is indicative of a resource exhaustion vulnerability

49 Questions?

50 About These Slides  You are free to copy, distribute, display, and perform the work; and to make derivative works, under the following conditions. You must give the original author and other contributors credit The work will be used for personal or non-commercial educational uses only, and not for commercial activities and purposes For any reuse or distribution, you must make clear to others the terms of use for this work Derivative works must retain and be subject to the same conditions, and contain a note identifying the new contributor(s) and date of modification For other uses please contact the Purdue Office of Technology Commercialization.  Developed thanks to the support of Symantec Corporation

51 Pascal Meunier  Contributors:  Jared Robinson, Alan Krassowski, Craig Ozancin, Tim Brown, Wes Higaki, Melissa Dark, Chris Clifton, Gustavo Rodriguez- Rivera


Download ppt "Course 1 Learning Plan  Security overview and patching  Public vulnerability databases and resources  Secure software engineering  Security assessment."

Similar presentations


Ads by Google