Computer Security Application Security CC Issues Buffer Overflow

Computer Security Application Security

C/C++ Issues Buffer Overflow n n Writing past intended limit for variable or stack entry On stack, allows attacker to change or write over return address Forces execution flow to attacker’s code Causes vast majority of security problems with current system software, utilities Linux sendmail Oracle Many others. . .

Buffer Overflow (cont. ) Cause of problem n n Lack of bounds checking in languages at compile and/or run time On stack – this allows attacker to change data or return addresses “Smashing the stack” n Often (but not always) through use of C/C++ functions like strcpy instead of strncpy Even the “strnxxx” functions can be misused Evidence n Entries in log files (e. g. binary characters)

C# Model is more like Java n n Virtual machine Bounds checking on arrays However, code sections can be marked “unsafe” n These can contain possible buffer overflows

Java Issues No buffer overflows! n Language enforces range checking on arrays, strings Other Issues n n Can program affect user’s environment? Can program gain client information? Can program consumer indefinite amount of resources? Etc.

Java Security Features Java 2 Basic Platform n n Configurable security policy Ability to generate message digests and digital signatures Key management system Extensible infrastructure for security

Java Security Extensions (1) Java Cryptography Extension (JCE) n n Encryption Secure Key Exchange Secure Message Digests Alternate Key Management System http: //java. sun. com/products/jce/ Integrated into Java 2 SDK 1. 4 & above

Java Security Extensions (2) Java Secure Sockets Extension (JSSE) n n Provides SSL encryption facilities Supports communication with SSL server or SSL client http: //java. sun. com/products/jsse Integrated into Java 2 SDK 1. 4 and above

Java Security Extensions (3) Java Authentication and Authorization Service (JAAS) n n Main security facilities: protect client’s system from program JAAS allows developer to grant or deny access to programs based on user credentials (similar to PAM) Integrated into Java 2 SDK 1. 4 and above

Java Sandbox Basic Java Security Model Analogy n n Protect those playing within it, but also: Protect the surrounding environment from those playing Range of Sandbox n n CPU/Screen/Keyboard/Mouse/Memory Above plus web server Above plus some local resources (e. g. , limited set of local files and local machines) Open – all resources host machine has access to

Scope of Sandbox Originally just applied to applets (pre Java 1. 2) Now applied to applets and applications Security model now administered and programmed in same way Difference: n n Applets always use Java security model Applications must be told to run under Java security model

Java Security Policy Elements Bytecode verifier n Ensure class file follows rules (e. g. memory) Class loader n Can set permissions for loaded classes Access controller n Allows/prevents access to OS Security manager n Interface between core API and OS Security classes n java. security package plus extensions Key database

Security Debugging java. security. debug system property Selected Values n n all – all options access – trace calls to check. Permission() method of access controller jar – print signatures on signed jar file policy – print information about policy files as parses JSSE supports more options through javax. net. debug property

Elements of Java Sandbox Permissions – specific action a code part is allowed to perform Code Sources – location for class source plus signature Protection Domains – association of permissions with code source; e. g. code from java. sun. com can read files on my hard disk Policy Files – administrative element for sandbox control Keystores – location of certificates (used by developers as well as users)

Permissions (Core API) File permissions type: java. io. File. Permission n name: file name (system dependent) n action: read, write, delete, execute n example: permission java. io. File. Permission “<<ALL FILES>>”, “read, execute” n

Permissions (Core API) (2) Socket permissions type: java. net. Socket. Permission n name: hostname: port (wildcards available) n action: accept, listen, connect, resolve n example: permission java. net. Socket. Permission “*: 1 -”, “accept, listen, connect, resolve” n

Permissions (Core API) (3) Runtime permissions n n type: java. lang. Runtime. Permission name: varies; e. g. create. Class. Loader (allow code to instantiate a class loader) action: none (permissions are binary) example: permission java. lang. Runtime. Permission “queue. Print. Job”;

Permissions (Core API) (4) Other permissions n n n Property Net Serializable Reflection Security All

Keystores, Code Sources Keystores n handled by keytool utility Code sources n n n combination of code base and signers signer field must match alias in keystore code base is a valid URL

Policy Files Two used by default $JREHOME/lib/security/java. policy n used by all instances of JVM on a host $HOME/. java. policy n n used by user permissions are union of two files administer by policytool or by hand sample entry: grant { permission java. util. Property. Permission “java. version”, “read” }; also $JREHOME/lib/security/java. security file n further additions to base policy

Java Language Security Constructs Access levels n public, private, protected Programs cannot access arbitrary memory n no pointers Variables not used before initialized Array bounds checked Objects cannot be arbitrarily cast Enforcement n n n Compiler – e. g. no illegal casts Bytecode verifier – e. g. ensure class file has correct format, no illegal data conversion Runtime – e. g. array bounds checking, object casting

Security Patterns - Issues When data is transferred: n n n Will the systems involved validate it? Is the communication channel secure? Is the source trusted or not? When an application is accessible: n n n Who is accessing it? Is the request legitimate? Can the application process the request? If not, what should happen? Does it track attempts to access it? When data is confidential: n n n How is the data protected? Are these means sufficient? Are they warranted? Is the data backed up? Is this adequate?

Single Access Point Pattern System should have single point of entry n n n Common to all incoming requests All users must pass through it Any unauthorized requests are directed to this point J 2 EE – supports with declarative security implemented through web container

Check Point Pattern Centralizes and enforces authentication and authorization Single mechanism determines if access (or ability to grant access) to particular resource is proper Matches user with level of security allowed May be multiple check points J 2 EE supports with JAAS n PAM also supports this pattern

Role Pattern Disassociation of users and their privileges User assigned one or more roles Role assigned one or more privileges Supports easier management J 2 EE supports through declarative security model n Can specify in XML deployment descriptors

Proxy Pattern Used to provide varying degrees of access and instantiation on demand to varying clients Proxy acts as a reference to the real object Proxy controls access to object, may be responsible for creating/deleting it

Computer Security Application Testing (mostly from Writing Secure Code, 2 nd – Howard and Le. Blanc)

Scenario Need to analyze a multi-tier application n E. g. , 3 -tier application from client to application server to database server How to proceed?

Process – Derived from Threat Model Decompose the application into fundamental components Identify the component interfaces Rank the interfaces by potential vulnerability Ascertain the data structures used by each interface Find security problems by injecting mutated data

Interfaces There are many – think expansively! n n n TCP and UDP sockets Wireless Net. BIOS named pipes shared memory temporary work areas (e. g. , Windows clipboard) RPC interfaces component objects HTTP requests/responses SOAP requests (web services) console input command line arguments

Interfaces (2) n n n n n dialog boxes database access technologies (e. g. , ODBC, JDBC) database stored procedures store and forward interfaces (email, message queues) environment variables files microphone active directory sources (e. g. LDAP, Active Directory) hardware devices Infrared USB Fire. Wire (IEEE 1394) Bluetooth n etc.

Rank By Vulnerability Process running with extended privilege (e. g. , 2 pts. ) Interface written in language that has buffer overflow problems (e. g. , 2) Interface has no access control (e. g. , 1) Recipient buffer is stack based (e. g. , 2) Interface doesn’t require authentication (e. g. , 1) Feature installed/running by default (e. g. , 1 each) Feature has known security vulnerabilities (e. g. , 1)

Interfaces and Data Structures Sockets/RPC/Named Pipes/Net. BIOS => data arriving through the network Files => File contents Registry => Registry key data Active Directory => Nodes in the directory Environment => Environmental variables HTTP data => HTTP headers, form entities, query strings, MIME parts, XML payloads, SOAP data and headers Command line arguments => data in argv[] for C/C++ or String [] args for Java, C#

Attacking Techniques Spoofing identity Tampering with data Repudiation Information disclosure Denial of Service Elevation of privilege

Attacking Techniques Spoofing identity n n n Attempt to force the application to not use authentication Try forcing an authentication protocol to a less secure older version Attempt to view users’ credentials on the network or in storage Determine if security tokens (e. g. , cookies) be replayed to bypass an authentication stage Try brute-forcing a user’s credentials – do error messages give you information?

Attacking Techniques Tampering with data n n Attempt to bypass authorization or access control mechanisms Determine if it is possible to tamper with and rehash the data? Create invalid hashes, MACs and digital signatures to ensure they are checked correctly Determine whether you can force the application to go back to an insecure protocol (if using SSL)

Attacking Techniques Repudiation n Attempt to prevent logging or auditing Attempt to create a request that creates incorrect data in an event log Attempt to perform sensitive actions that might bypass security checks

Attacking Techniques Information disclosure n n n Attempt to access data that can be accessed only by more privileged users Kill the process and perform disk scavenging, looking for sensitive data that was written to disk Make the application fail in a way that discloses useful information

Attacking Techniques Denial of Service n n n Flood a process with so much data that it stops responding to valid requests Determine if malformed data crashes the process? (especially bad on servers) Determine if external influences (such as reduced disk space, memory pressure, and resource limitations) force the application to fail

Attacking Techniques Elevation of privilege n n n Test applications that run under elevated accounts, such as root on Linux or SYSTEM services on Windows Determine if you can execute data as code Determine if an elevated process can be forced to load a command shell, which in turn will execute with elevated privileges

Perturbing Data Usually valid, but test: n n n n Invalid Random Wrong data type Wrong sign Null Zero Out of bounds

Input Data - Special Characters Meta Script Escaped HTML Slashes Quotes Etc.

Summary Application security design and testing is one of the most important areas of security n Much access to systems is through applications Security analyst needs to be n n n Complete Methodical Creative