Notes

Outline

Using Independent  Auditors for Intrusion Detection Systems Jesus Molina University of Maryland

Introduction Problem: Integrity Verification Systems rely in the OS to function The OS can be corrupted Solution: Create a Integrity Verification Systems that does not rely on the Operating System Use a embedded processor as an independent auditor

Introduction (II) What is an Integrity Verification System Why we need Integrity Verification Systems Why we can not rely on actual Integrity Verification Systems Solution: Using an embedded Processor

Integrity Verification Systems Type of Intrusion detection System Intrusion Detection Systems aim to detect intruder in your machine (Burglar alarm) Integrity Verification Systems detect unapproved changes to your data

Need of Integrity Verification Systems Intrusion appear even in extremely secure machine New threats Users misusing resources Bugs not patched on time Without using an Integrity Verification System, the intrusion will not be noticed

Why the Integrity Verification System Works The intruder will try to change sensitive data of the machine after the penetration Replace application with Trojan hoses Place sniffer Inject other type of Malicious code (virus, etc)

Integrity checking using database Mode

Integrity Checking Using File Signing

Integrity Verification Systems In the Market Tripwire: uses the database approach CryptoMark: Using file signing Both rely on the integrity of the operating system

Introduction (II) What is an Integrity Verification System Why we need Integrity Verification Systems Why we can not rely on actual Integrity Verification Systems Solution: Using an embedded Processor

Attacks in Kernel Space An attacker can corrupt the operating system itself All the applications that rely on the operating system will no longer be trusted That includes current implementations of Integrity Verification Systems Any operating system is suitable to this attacks: Linux, Windows, etc

Example: Attacks in Kernel Space in Linux Two modes of operation: Kernel space and user space Application are executed in User Space Access to the hardware performed in Kernel Space The User Space program request action in Kernel Space using System Calls

Linux Operating System

Attacks in Kernel Space (II) Straightforward attack: redirect system calls Example: A user trying to read the hard disk Read system call will be requested Read system call redirected to a rogue system call The attacker is able to change the output

Redirecting system calls

Attacks in Kernel Space (III) In Linux, the Kernel could be changed “On the fly” using Loadable Kernel Modules Evil application available on the web exploiting redirection of system calls Similar attacks in other operating systems Solutions to this problem: vigilant modules, integrity checking in the kernel

Introduction (II) What is an Integrity Verification System? Why we need Integrity Verification Systems? Why we can not rely on the Operating System? How your solution is implemented?

Using Independent auditors The Integrity Verification Systems should not rely on a compromised operating system Use an independent auditor to perform the integrity checks What is an independent auditor?

Properties of independent auditors Unrestricted access Secure transactions Inaccessibility Continuity Transparency Verifiable software Non-volatile Memory Physically secure

Integrity checking using database Mode (II)

Integrity checking using file signing (II)

Using the EBSA-285 Board as an Independent auditor The EBSA-285 board is a microcomputer in the shape of a PCI card SA-110 ARM Processor 4 Mb Flash ROM 16 MB RAM memory full PCI local Bus Specification, Revision 2.1 Objective: Check the integrity of a file-system resident in a IDE hard disk

Scheme of the EBSA-285

Software in the EBSA-285: Bootloader Set up Initialization registers Set up RAM memory Copy Kernel Image and Ramdisk from Flash Rom memory to RAM Boot Kernel Image

Software in the EBSA-285: Kernel Use an ARM port of Linux as the embedded Kernel Patched to be used with the EBSA-285 as an add-in card IDE drivers changed to be used in polled mode (The EBSA-285 can not “listen” the interrupts in the PCI bus)

Properties of independent auditors for the EBSA-285 Unrestricted access Secure transactions Inaccessibility Continuity Transparency Verifiable software Non-volatile Memory Physically secure

Performance of the EBSA-285 Access timings using the hdparm utility, mounting an IDE hard disk with an ext2 file-sytem Timing buffer-cache reads:   128 MB in  3.05 seconds =41.97 MB/sec  Timing buffered disk: 26.72 seconds = 2.40 MB/sec This numbers are taken when no contention appears between the host processor and the EBSA-285

Performance of the EBSA-285 (II) Locking problems: If both the EBSA-285 and the host processor access to the IDE hard disk at the same time, race condition arises This race conditions can be solved using locking. However, this involves changing the host operating system if the BUS used is a PCI bus Other BUSES could possibly allow this locking without changing the host OS

Conclusion The EBSA-285 can be used as an independent auditor Using the EBSA-285 as an independent auditor will provide a true Integrity Verification System The performance of the EBSA-285 should be tested in other architectures, including Buses, hard disk (SCSI) and file systems.