Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
WHITE OAK LABS2 DEFCON XI 8/3/2003
Acknowledgements
• Niels Provos – OpenBSD’s systrace
• DT – suggested this thread last year
• Greg Hoglund – insights
• md5 at da ghettohackers – reviews
WHITE OAK LABS3 DEFCON XI 8/3/2003
What is Intrusion Prevention?
• To a netsec person it looks like a
firewall.
Messages Rules Messages (Packets)
WHITE OAK LABS4 DEFCON XI 8/3/2003
What is Intrusion Prevention?
• To a AV person it looks like an AV.
Messages Signatures Messages (File IO)
WHITE OAK LABS5 DEFCON XI 8/3/2003
What is Intrusion Prevention?
Network-based
Host-based Packets Signatures
API() Signatures
WHITE OAK LABS6 DEFCON XI 8/3/2003
What is Intrusion Prevention?
Packets Signatures
Socket() Signatures
Consider personal
firewalls that
combine host and
network based
filtering.
WHITE OAK LABS7 DEFCON XI 8/3/2003
How is IP different?
• Rather than rules, it uses signatures.
• But these aren’t the same signatures you might run in an Intrusion Detection Systems (IDS)
• Signatures as access controls.
API() Signatures
WHITE OAK LABS8 DEFCON XI 8/3/2003
How is it different?
• Consider SNORT/Hogwash..
• Signature-based Firewall
• IDS vendors call this
“Gateway IDS”
Packets Signatures
WHITE OAK LABS9 DEFCON XI 8/3/2003
What is Intrusion Prevention?
• It's complementary to AV & Firewall
• Filters messages between
applications and the kernel.
• Uses signatures to recognize payload
behavior or injection mechanisms.
API() Signatures
WHITE OAK LABS10 DEFCON XI 8/3/2003
Why the heck should we care?
• Encryption, fragmentation and re-
encoding, can prevent application
layer filtering on the wire.
• Data resides in the clear in the
application layer. So do exploits.
WHITE OAK LABS11 DEFCON XI 8/3/2003
Why the heck should we care?
• Visibility into the application layer
provides capability for better
contextual discrimination.
= Stops certain kinds of exploits.
WHITE OAK LABS12 DEFCON XI 8/3/2003
So, why do we need another tool?
• Network security
• App level Firewalls
• Attack through services/daemons.
• crunchy on the outside?
• Application state is complex.
• State of memory, disk, clients…
WHITE OAK LABS13 DEFCON XI 8/3/2003
IP Signatures
For signatures that:
• Are application state specific
• Are system state specific
• Use contextual clues
• Block from the inside
WHITE OAK LABS14 DEFCON XI 8/3/2003
Well, OK, so how does it work?
Consider architectural layers in the OS.
Let’s take a look at:
• Layers in Windows architecture
• Layers in UNIX
WHITE OAK LABS15 DEFCON XI 8/3/2003
Win2K System ArchitectureOS/2 AppWin32 App Posix App
OS/2
Subsystem
Win32
Subsystem
Posix
Subsystem
Executive Services Interface
Security
Reference
Monitor
IPC
Manager
Virtual
Memory
Manager
Process
Manager
GDI
Window
Manager
Window
Manager
Device Drivers
Hardware
Hardware Abstraction Layer (HAL)
Micro Kernel
Object Manager
Graphics
Device
Drivers
IO
Manager
File
Systems
Ntdll.dll
WHITE OAK LABS16 DEFCON XI 8/3/2003
Win2K System Architecture
OS/2 AppWin32 App Posix App
OS/2
Subsystem
Win32
Subsystem
Posix
Subsystem
Executive Services Interface
Security
Ref.
Monitor
IPC
Mgr.
Virtual
Memory
Mgr.
Process
Mgr.
GDI
Window
Mgr.
Window
Mgr.
Device Drivers
Hardware
Hardware Abstraction Layer
Micro Kernel
Object Manager
Graphics
Device
Drivers
IO
Mgr.
File
Sys.
Ntdll.dll
Two distinct user-land layers:
• Binary compatible app layer
• OS specific, native layer
Three distinct kernel layers:
• Executive services
• Object Manager
• Hardware Abstration Layer
WHITE OAK LABS17 DEFCON XI 8/3/2003
Linux System Architecture
Linux App
Win32 App Mac App
Wine or
Win4LinBasilisk
System call interface
SchedulerVirtual
Memory
Manager
Process
Manager
Socket
Manager
Hardware
File
SystemsMemory
Allocator
Network
Protocols
Network
Drivers
Character
Devices
Block
Devices
Libc.so
MAME
Games
VFS Interface
WHITE OAK LABS18 DEFCON XI 8/3/2003
Linux System Architecture
Linux App
Win32 App Mac App
Wine or
Win4LinBasilisk
System call interface
SchedulerVirtual
Memory
Manager
Process
Manager
Socket
Manager
Hardware
File
SystemsMemory
Allocator
Network
Protocols
Network
Drivers
Character
Devices
Block
Devices
Libc.so
MAME
Games
VFS Interface
• One common abstraction
layer for kernel.
• One common abstraction
layer for user-land.
Is fewer layers bad?
WHITE OAK LABS19 DEFCON XI 8/3/2003
Linux System Architecture
Linux App
Win32 App Mac App
Wine or
Win4LinBasilisk
System call interface
SchedulerVirtual
Memory
Manager
Process
Manager
Socket
Manager
Hardware
File
SystemsMemory
Allocator
Network
Protocols
Network
Drivers
Character
Devices
Block
Devices
Libc.so
MAME
Games
VFS Interface
Each layer provides context
info.
• What can that information
provide?
• Given this information,
what can we distinguish?
• How is this different than
other forms of filtering?
WHITE OAK LABS20 DEFCON XI 8/3/2003
Architecture Comparison
OS/2 AppWin32 App Posix App
OS/2
Subsystem
Win32
Subsystem
Posix
Subsystem
Executive Services Interface
Security
Ref.
Monitor
IPC
Mgr.
Virtual
Memory
Mgr.
Process
Mgr.
GDI
Window
Mgr.
Window
Mgr.
Device Drivers
Hardware
Hardware Abstraction Layer
Micro Kernel
Object Manager
Graphics
Device
Drivers
IO
Mgr.
File
Sys.
Ntdll.dll
Linux App
Win32 App Mac App
Wine or
Win4LinBasilisk
System call interface
SchedulerVirtual
Memory
Manager
Process
Manager
Socket
Manager
Hardware
File
SystemsMemory
Allocator
Network
Protocols
Network
Drivers
Character
Devices
Block
Devices
Libc.so
MAME
Games
VFS Interface
WHITE OAK LABS21 DEFCON XI 8/3/2003
Linux System Architecture
Even considering the app. as
a “black box” we can
observe at multiple layers:
• API calls
• System calls
• Instruction level
Linux App
Win32 App Mac App
Wine or
Win4LinBasilisk
System call interface
SchedulerVirtual
Memory
Manager
Process
Manager
Socket
Manager
Hardware
File
SystemsMemory
Allocator
Network
Protocols
Network
Drivers
Character
Devices
Block
Devices
Libc.so
MAME
Games
VFS Interface
WHITE OAK LABS22 DEFCON XI 8/3/2003
Linux System Architecture
Exploits:
• focus on escaping IDS
• often cause exceptional
behavior.
Rather than fix IDS, let’s
take an entirely different
approach.
Linux App
Win32 App Mac App
Wine or
Win4LinBasilisk
System call interface
SchedulerVirtual
Memory
Manager
Process
Manager
Socket
Manager
Hardware
File
SystemsMemory
Allocator
Network
Protocols
Network
Drivers
Character
Devices
Block
Devices
Libc.so
MAME
Games
VFS Interface
WHITE OAK LABS23 DEFCON XI 8/3/2003
Linux System Architecture
Because it acts at these
layers it is independent of:
• Method of transport
• Method of injection.
It is specific to:
• App state or behavior
• Payload behavior
Linux App
Win32 App Mac App
Wine or
Win4LinBasilisk
System call interface
SchedulerVirtual
Memory
Manager
Process
Manager
Socket
Manager
Hardware
File
SystemsMemory
Allocator
Network
Protocols
Network
Drivers
Character
Devices
Block
Devices
Libc.so
MAME
Games
VFS Interface
WHITE OAK LABS24 DEFCON XI 8/3/2003
Examples…
• Yes, let's consider a specific payload
(and exploit for that matter) on
FreeBSD.
• How does it get in and how do we
distinguish it's behavior.
• Why is this important...
WHITE OAK LABS25 DEFCON XI 8/3/2003
Demo of IP on FreeBSD
• Background of exploit: release date,
authors, impact, subsequent
variations.
• firewall coverage
• anti-virus coverage
• IDS and AV coverage
WHITE OAK LABS27 DEFCON XI 8/3/2003
Review of injection and payload
Code excerpts:
• Vulnerability
• Injection
• Payload
WHITE OAK LABS28 DEFCON XI 8/3/2003
How can we prevent it?
• Unique aspects of payload?
• How we can recognize it..
• Unique aspects of injection?
• How we can recognize it..
WHITE OAK LABS30 DEFCON XI 8/3/2003
Review of contextual information
• network identity
• user identity
• application state
• authentication
• workflow
• orthogonally to other methods
WHITE OAK LABS31 DEFCON XI 8/3/2003
What’s the state of the industry?
• Leading products in the market?
• What differentiates them?
• How do the integrate with others?
• Success stories?
WHITE OAK LABS32 DEFCON XI 8/3/2003
The End
• Updated slides and tools will be
available at:
www.defcon.org
www.murphey.org/dc-11/
• I can be contacted at: