SEC835

Audit Trail

Security Audit Trail

“a chronological record of system activities that is sufficient to enable the reconstruction and examination of the sequence of environments and activities surrounding or leading to an operation, procedure, or event in a security-relevant transaction from inception to final results”

Security Audit Architecture

Event Definitionmust define what are auditable eventsCommon Criteria suggests:

introduction of objects deletion of objectsdistribution or revocation of access rights or capabilitieschanges to subject or object security attributespolicy checks performed by the security software use of access rights to bypass a policy checkuse of identification and authentication functions;security-related actions taken by an operator/user import/export of data from/to removable media

Other Audit Requirements

event detection hooks in software and monitoring software to capture activity

event recording function with secure storage

event and audit trail analysis software, tools, and interfaces

security of the auditing function

minimal effect on functionality

Audit Trail Types

System levelSyslogs (Windows log, Unix log)

Application levelSecurity related activities towards application

User levelActivities performed by individuals

Physical levelGenerated by physical access control systems

User-Level Audit Trailstrace activity of individual users over time

to hold user accountable for actions taken

To use as input to an analysis program that attempts to define normal versus anomalous behavior

may captureuser interactions with system

• e.g. commands issued

identification and authentication attempts

files and resources accessed.

may also log use of applications

Audit Trail Storage Alternatives

read/write file on servereasy, least resource use, fast access

vulnerable to attack by intruder

write-once device (e.g. CD/DVD-ROM)more secure but less convenient

need media supply and have delayed access

write-only device (e.g. printer)paper-trail but impractical for analysis

Audit trail storage

Most often used store is the file on server

Ensure protection of both integrity and confidentiality

using hash, encryption, digital signatures, access controls

Audit trail content

Mandatory Fields:-

User ID and Name

Activity Date/Timestamp

Activity Code, Type and Description

Terminal IP address and Location

Implementing Logging

Foundation of security auditing facility is the initial capture of the audit data

Software must include hooks (capture points) that trigger data collection and storage as preselected events occur

Types of Audit Trail Analysisaudit trails can be used in multiple ways

this depends in part on when it happens

possibilities include:audit trail review after an event

• triggered by event to diagnose cause & remediate

periodic review of audit trail data• review bulk data to identify problems & behavior

real-time audit analysis• as part of an intrusion detection function

Audit Reviewaudit review capability provides admin with information from selected audit records

actions of one or more users

actions on a specific object or resource

all or a specified set of audited exceptions

actions on a specific system / security attribute

may be filtered by time / source / freq etc

used to provide system activity baseline

Approaches to Data AnalysisAudit Reports may provide information about

basic alerting• indicate interesting type of event has occurred

baselining• define normal vs unusual events / patterns

• compare with new data to detect changes

windowing• of events within a given set of parameters

correlation• seek relationships among events

Logging

Logging integrityLogs integrity is the primary security requirements

Logging confidentiality issues (passwords)Confidential data stored in the log should only be viewable to those who have a clear need to see the information

Avoid leaking privileged information to lower privilege users

Attacks on LogsUse the following website

http://cve.mitre.org/

Denial of service using chaff (junk; noise)Goal – incapacitate audit facilities to avoid being caught

Attacks on logs – DoS CVE-2005-3071

UFS on Solaris 8 and 9, when logging is enabled, allows local users to cause a denial of service ("soft hang") via certain write operations to UFS

CVE-2005-0775

PhotoPost PHP 5.0 RC3 . The reportpost action does not limit the logging data that is sent to the admistrator, which allows remote attackers to send large amounts of email to the admistrator.

CVE-1999-0566 IBM syslog. An attacker can write to syslog files from any location, causing a denial of service by filling up the logs, and hiding activities.

CVE-1999-0063 Cisco IOS 12.0 and other versions can be crashed by malicious UDP packets to the syslog port.

Attacks on LogsSemantic attacks (fake log entries)

Goal – destroy a log integrity so it cannot longer provide trustful information, or even to mislead a reviewer

Misleading may have different intents, e.g.• Serve as an evidence of actions which were not performed

• Destroy evidences of actions which were performed

• Redirect a reviewer to a wrong subject

Attacks on logs – Semantic attacks (fake log entries)

CVE-2006-5001

WS_FTP Server 5.05 before Hotfix 1. Unspecified vulnerability in the log analyzer prevents certain sensitive information from being displayed in the (1) Files and (2) Summary tabs.

CVE-2005-2582

Kaspersky Anti-Virus for Unix/Linux File Servers 5.0-5. Uses world-writable permissions for the (1) log and (2) license directory, which allows local users to delete log files

CVE-2006-0201

Dave Nielsen and Patrick Breitenbach PayPal Web Services (aka PHP Toolkit) 0.50, and possibly earlier versions, allows remote attackers to enter false payment entries into the log file via HTTP POST requests to ipn_success.php.

Attacks on LogsLog entries with special characters

Goal – to exploit the ability to trigger execution of an interpreter statements which normally start with a special character

See more details below

Attacks on LogsLog entries attempting to exploit vulnerabilities in the logging mechanism

Logging mechanism, in other words the software component responsible for storing log records, contains security holes that can be exploited by an attacker

This occurs the same way as with any other software component

Log entries attempting to exploit vulnerabilities in the logging mechanism

CVE-2006-3120

Brian Wotring Osiris, before 4.2.1. Format string vulnerability in the logging allows remote attacker to construct DoS, and possibly execute arbitrary code

CVE-2005-0050

Win NT, Win 2000, Win 2003 servers. The license logging service does not properly validate the length of messages, which leads to “unchecked buffer”, and allows remote attacker to construct DoS, and possibly execute arbitrary code

Attacks on LogsLog entries attempting to exploit vulnerabilities in the log viewing mechanism

Log viewing mechanism, in other words the software component responsible for viewing log records, contains security holes that can be exploited by an attacker

This occurs the same way as with any other software component

That is not necessarily refers to the reports, it can be just viewing for example through online interface

Log entries attempting to exploit vulnerabilities in the log viewing mechanism

CVE-2006-0441

Stack-based buffer overflow in Sami FTP Server 2.0.1 allows remote attackers to execute arbitrary code via a long USER command, which triggers the overflow when the log is viewed

CVE-2005-0291

Cross-site scripting (XSS) vulnerability in the log viewer in NETGEAR FVS318 running firmware 2.4, and possibly other versions, allows remote attackers to inject arbitrary web script or HTML via a blocked URL phrase

CVE-2000-1179 Netopia ISDN Router 650-ST allowed unauthenticated remote attackers to read system logs using certain control characters

Log deficiencies Logging second-hand or uncertain information

Spoofed identities

Data that does not bring any value

Missed valuable data

Logging second-hand or uncertain information

CVE-2005-3169

Microsoft Windows 2000 before Update Rollup 1 for SP4, when the "audit directory service access" policy is enabled, does not record a 565 event message for File Delete Child operations on an Active Directory object in the security event log, which could allow attackers to conduct unauthorized activities without detection

Information leakage CVE-2006-0424

BEA WebLogic Server and WebLogic Express 8.1 through SP4, 7.0 through SP6, and 6.1 through SP7 allows remote authenticated guest users to read the server log and obtain sensitive configuration information

CVE-2006-4787

AlphaMail before 1.0.16 allows local users to obtain sensitive information via the logging functionality, which displays unencrypted passwords in an error message

CVE-2006-4186

The iManager in eMBoxClient.jar in Novell eDirectory 8.7.3.8 writes passwords in plaintext to a log file, which allows local users to obtain passwords by reading the file

Logging vulnerabilities create new attack vectors

CVE-2006-0202Dave Nielsen and Patrick Breitenbach PayPal Web Services (aka PHP Toolkit) 0.50 and possibly earlier has (1) world-readable permissions for ipn/logs/ipn_success.txt, which allows local users to view sensitive information (payment data), and (2) world-writable permissions for ipn/logs, which allows local users to delete or replace payment data.

PCI Logging RequirementsPCI specifies requirements for how logging should be implemented and for the information that should be logged.

The relevant requirements include:

10.2 Implement automated audit trails for all system components to reconstruct the following events:

10.2.1 All individual user accesses to cardholder data

10.2.2 All actions taken by any individual with root or administrative privileges

10.2.3 Access to all audit trails

10.2.4 Invalid logical access attempts

10.2 5 Use of identification and authentication mechanisms

10.2.6 Initialization of the audit logs

10.2.7 Creation and deletion of system-level objects.

PCI Logging Requirements cont 10.3 Record at least the following audit trail entries for all system components for each event:

10.3.1 User identification

10.3.2 Type of event

10.3.3 Date and time

10.3.4 Success or failure indication

10.3.5 Origination of event

10.3.6 Identity or name of affected data, system component, or resource.

Exercise – Access Control and Audit

Secure design patterns:Access control

Strong Access Control Mechanism Pattern

Communicate to the auditor

SEC835

Error Handling

What is the problem?Non-secure error handling technique is one of major security issues caused by applicationsIt affects all three security characteristics of the system: confidentiality, integrity, availabilityIt opens the door for different attacks, such as DoS, malicious code planting and executingThe attacker may exploit security holes in the error-handling mechanisms, or they may use the mechanisms weaknesses to collect information required to construct the attack

What is at stake - examples System availability

Incorrect error conditions Remotely-accessible systems (i.e. any IP-connected device), with

hard-stop error conditions based on external inputs, could potentially be flooded with “garbage” designed to trigger a DoS effect.

Incorrect resource management at errors Failing to ‘clean up’ properly after an error occurs can lead to

resource depletion (i.e. open connections or memory leaks) or unintended runtime state. (i.e. heightened access levels, infinite loops, etc.)

Confidentiality and integrity Leak of sensitive information

New vectors of attack, details about the platform or environment, or sensitive bits of information could be exposed in overly verbose error messages.

Users and Errors:What Not to Tell Them

A Classic Example: Login Error Messages Early authentication mechanisms that challenged

users for a login and password would sometimes return one of the following error messages: “ID not found.” “Password is incorrect.”

An attacker could a) brute-force a guess at the ID until the first error message changed to the second, and then b) keep guessing a password until they gained entry.

A Classic Example, Continued Eventually, the appropriate standard became a

generic “Authentication Failed. Please try again.” message.

What is Wrong Here?

Warning: Access denied for user: 'root@localhost' (Using password: NO)

Warning: SQL error: [Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended , SQL state S1000 in SQLExecDirect in e:\apache_root\foo\bar.php on line 71

What is Wrong Here? ContinuedWarning: Access denied for user: 'root@localhost' (Using password: NO)

- Admin-level username exposed, along with the knowledge that no password is used to connect to an internal service

Warning: SQL error: [Oracle][ODBC][Ora]ORA-00933: SQL command not properly ended , SQL state S1000 in SQLExecDirect in e:\apache_root\foo\bar.php on line 71

- Installation path of the server and script environment, as well as a hint that input is used in crafted SQL statements, and not properly filtered (potential for SQL injection)

Even a simple “Access Denied to <Resource>” message reveals to an attacker that a particular resource is present (or recognized), which both identifies the resources and potentially fingerprints the environment.

More Recent Examples Error messages in many commercial software products

have included stack traces, SQL syntax errors, client request details, server credentials and host information, and much more.

They are often picked up by search engines from servers and technical support forum posts, which in turn have been exploited by hackers looking for easy targets – the information enables refined attacks on the target(s). (Sometimes called ‘google hacking’.)

Worse yet, some error messages introduce new vulnerabilities due to improper handling of client inputs (i.e. cross-site scripting, buffer overflows, etc.)

How to handle error messages? Users need error messages to obtain technical

support; administrators and developers need detailed error reports to diagnose faults in the system.

More often than not, users need not know why the fault happen, only that it did happen, and how it might be fixed.

How to handle error messages? Known error conditions can use error codes to map to two

tables of error messages (one, supplied with the client package, containing user-friendly but non-specific error messages, and the other held by the developers with more detailed information on the fault.)

Unfortunately, this increases maintenance requirements for the software. (Keeping the error codes and mappings up to date.)

Error Message Mapping (Diagram)

Dealing with User Input Errors Do not try and guess what the user meant with their input –

if it is not a valid value (breaks any character input rules, is malformed, exceeds bounds, references non-existent entities), deny the request and prompt them to try again.

Whenever possible, refrain from committing any values to storage until they are all valid.

More on User Input Errors If user-supplied inputs fail to pass sanity

checks/validation, it is best to simply discard the erroneous input and prompt the user to try again.

In certain situations (i.e. authentication) it may be necessary to stop a user if the user’s input is invalid over multiple iterations – repeated failure may be the result of brute force attempts against the validation mechanism(s).

Use caution if you send the erroneous input back to the client – in some cases, outputting unfiltered inputs can be exploited for user-to-user attacks. (i.e. cross-site scripting)

Use White List to validate data

Use secure data input validation technique – validate against the White List (what is allowed), not against the Black List (what is not allowed)

Test for Success!Consider the following code example:…int access = GetAccessLevel(…);If ( access == ERROR_NO_ACCESS ) {

// failure warning} else { // continue with authorized state}…

If for any reason the error flag were not set to precisely the error being checked, the “safe” code would execute anyway, resulting in an unwarranted authorized state.

Test for Success! Continued

Change to Success, also known as the White List approach

…int access = GetAccessLevel(…);If ( access == ACCESS_GRANTED ) {

// normal processing} else { // failure notification}…

The White List approach tests for successful completion, where the conditions for success are known, and all other cases are treated as failures, and managed accordingly.

Summary

Some recommendations for error handling technique Do not include technical details into the messages intended to end

users. Reject all erroneous data input from end users Use the White List approach – test for success When you have to stop the system release all the resources

allocated for the running instance Avoid hard-stops. Use them only when you really have to Write secure software for error-handling

Error handling exercise

Connect to http://www.owasp.org/index.php/Category:Error_Handling_Vulnerability

Read the articles

Make the reference sheet for your own use that will describe error-handling vulnerabilities and relevant good practice. Use your own words

Email by the end of the day today