SEC835

1. SEC835 Audit Trail

2. 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”

3. Security Audit Architecture

4. Event Definition • must define what are auditable events • Common Criteria suggests: • introduction of objects • deletion of objects • distribution or revocation of access rights or capabilities • changes to subject or object security attributes • policy checks performed by the security software • use of access rights to bypass a policy check • use of identification and authentication functions; • security-related actions taken by an operator/user • import/export of data from/to removable media

5. 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

6. Audit Trail Types • System level • Syslogs (Windows log, Unix log) • Application level • Security related activities towards application • User level • Activities performed by individuals • Physical level • Generated by physical access control systems

7. User-Level Audit Trails • trace 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 capture • user interactions with system • e.g. commands issued • identification and authentication attempts • files and resources accessed. • may also log use of applications

8. Audit Trail Storage Alternatives • read/write file on server • easy, 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

9. 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

10. Audit trail content • Mandatory Fields:- • User ID and Name • Activity Date/Timestamp • Activity Code, Type and Description • Terminal IP address and Location

11. 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

12. Types of Audit Trail Analysis • audit 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

13. Audit Review • audit 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

14. Approaches to Data Analysis • Audit 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

15. Logging • Logging integrity • Logs 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

16. Attacks on Logs • Use the following website • http://cve.mitre.org/ • Denial of service using chaff (junk; noise) • Goal – incapacitate audit facilities to avoid being caught

17. 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.

18. Attacks on Logs • Semantic 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

19. 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.

20. Attacks on Logs • Log 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

21. Attacks on Logs • Log 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

22. 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

23. Attacks on Logs • Log 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

24. 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

25. Log deficiencies • Logging second-hand or uncertain information • Spoofed identities • Data that does not bring any value • Missed valuable data

26. 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

27. 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

28. Logging vulnerabilities create new attack vectors • CVE-2006-0202 • Dave 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.

29. PCI Logging Requirements • PCI 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.

30. 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.

31. Exercise – Access Control and Audit • Secure design patterns: • Access control

32. Strong Access Control Mechanism Pattern Communicate to the auditor

33. SEC835 Error Handling

34. What is the problem? • Non-secure error handling technique is one of major security issues caused by applications • It affects all three security characteristics of the system: confidentiality, integrity, availability • It opens the door for different attacks, such as DoS, malicious code planting and executing • The 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

35. 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.

36. Users and Errors:What Not to Tell Them

37. 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.

38. A Classic Example, Continued • Eventually, the appropriate standard became a generic “Authentication Failed. Please try again.” message.

39. 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

40. What is Wrong Here? Continued • Warning: 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.

41. 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.)

42. 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.

43. 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.)

44. Error Message Mapping (Diagram)

45. 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.

46. 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)

47. 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)

48. 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.

49. 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.

50. 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