Data Capture in Encrypted Environments with Sebek

Speakers

Edward Balas Researcher at Indiana University Member of the Honeynet Project

This material is based on research sponsored by the Air Force Research Laboratory under agreement number F30602-02-2-0221. The U.S. Government is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright notation thereon.

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

Motivation

Observe intruders even in encrypted environments

Do so without being noticed.

Monitor all attacker activity, not just keystrokes

Historical techniques

Serial line monitoring

Packet sniffing Ethereal Snort

Trojaned binaries Bash SSH

Limits of existing techniques

Network based capture limit you to black box system analysis. Unable to monitor encrypted sessions

presuming no key escrow

Trojaned binaries Easy to detect Easier to avoid

Next step in the arms race

Data Capture needs to circumvent encryption.

Application trojaning is insufficient.

Time to head for the Kernel Space .

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

A kernel based Data Capture tool

How do we gain access to the data of interest?

How do we get this data to a server without the attacker detecting it?

Can we make the system impossible to detect?

Sebek

Uses kernel space “privilege” to gain access to all data read by intruder.

Exports this data to remote server in covert manner.

It can be detected and disabled, but it is a step in the right direction.

Typical deployment

Getting access to the data

Replace the read() system call in the kernel

Have new syscall record interesting data

Just change the function pointer in the system call table.

What the read hijack looks like

Getting the data to the server

We don’t want data export slowing down the host. UDP works well in this situation

We don’t want a hacker to see or block these packets. Using the standard socket interface wont work Sebek generates packet itself and interacts

directly with ethernet driver.

What the data export looks like

Capabilities

Keystroke monitoring

SCP file transfer recovery

Burneye password recovery

Monitor network inactive processes

Anti-Sebek Foo

The weak points in

Sebek’s Armor

Detecting Sebek

Static Fingerprinting via kernel memory /proc/kcore kernel space via insmode find data structures, symbols etc. a true wealth of data

Dynamic performance profiling Cause sebek to export packets if sebek is running 1,000,000 reads will take longer

than if it is not running check to see if network latency increases as a result

of Packets Per Second TX

Evading Sebek

One way to evade sebek is to not use the read call.

Dornseif, Holz and klien outline how to access files with the mmap call

not so useful in traditional shell and pipe environments

would work for custom malware etc.

Disabling Sebek

J. Cory outlined a method to disable Sebek by rewriting syscall table. works for kernel module w/ syscall jacking wont for a kernel patch

Dornseif, Holz and Klien simply called the cleanup_module() call. also fails in a kernel patch

Anti-Sebek Bibliography

M. Dornseif, T. Holz, C. Klien, “NoSEBrEak - Attacking Honeypots”, Proceedings of the 2004 IEEE Workshop on Information Assurance and Security.

J. Corey, “Advanced Honeypot Identification” Sept 2003, http://www.phrack.org/fakes/p62-0x07.txt

J. Corey, “Advanced Honeypot Identification and Exploitation” Jan 2004, http://www.phrack.org/fakes/p63/p63-0x09.txt

What can we do about this?

rollout a patch based Sebek. monitor the mmap call / associated page

faults? futher obfuscate contents of sebek

memory Trojan the /proc/kcore device and the

insmod related syscalls?

The Sebek Server.

Operates as a packet sniffer.

Uploads data into mysql database

Outputs keystroke logs

Web Interface allows one to browse all data

Data Analysis

Example shows a non-root user copying a file to his home directory.

The file is a Burneye protected copy of a ptrace exploit.

The user runs the binary and gains root access.

Analysis Questions

1. Can we recover the SCPed file using the web interface?

2. Can we determine the password used to run the Burneye binary?

3. Can we determine exactly when the user gained root access?

Main Page: All hosts summary

Looking at Keystrokes

Closer look at “scp” process

Using the SCP decode option

Looking at the SCPed file

We have now recovered a file named malware from PID 1264 FD 0.

After downloading, we examined the file with strings.

“TEEE burneye - TESO ELF Encryption Engine”

This is a burneye binary

Lets take a closer look at malware’s activity

I wonder what the password is?

Hmm... this looks bad

Back to the Questions

We were able to recover the file named malware, which was transfered using SCP.

The password used to run malware was “secret” The blackhat user gained root access

Timestamp 2003-7-23 20:04:01 Process ID 1318 File Descriptor 0

The Future

Ability to compile directly into kernel Make harder to disable anti-anti-Sebek techniques provide a better facility for users to

express what data they want to collect. improved data analysis.

The Future...

Develop IDS that is based on Sebek Data. Merging this IDS with Systrace to protect

systems Using this IDS to support Honeytokens

Where Can I learn more?

http://www.honeynet.org/papers/sebek.pdf

Where Can I get Sebek

www.honeynet.org/tools/sebek

For questions or comments contact Edward Balas ebalas at iu.edu