1. Data Capture in Encrypted Environments with Sebek

2. Speakers  Edward Balas  Researcher at Indiana University  Member of the Honeynet Project

3.  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.

5. Motivation  Observe intruders even in encrypted environments  Do so without being noticed.  Monitor all attacker activity, not just keystrokes

6. Historical techniques  Serial line monitoring  Packet sniffing  Ethereal  Snort  Trojaned binaries  Bash  SSH

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

8. Next step in the arms race  Data Capture needs to circumvent encryption.  Application trojaning is insufficient.  Time to head for the Kernel Space.

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

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

11. Typical deployment

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

13. What the read hijack looks like

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

15. What the data export looks like

16. Capabilities  Keystroke monitoring  SCP file transfer recovery  Burneye password recovery  Monitor network inactive processes

17. Anti-Sebek Foo The weak points in Sebek’s Armor

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

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

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

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

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

23. The Sebek Server.  Operates as a packet sniffer.  Uploads data into mysql database  Outputs keystroke logs  Web Interface allows one to browse all data

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

25. 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?

26. Main Page: All hosts summary

27. Looking at Keystrokes

28. Closer look at “scp” process

29. Using the SCP decode option

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

31. Lets take a closer look at malware’s activity

32. I wonder what the password is?

33. Hmm... this looks bad

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

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

36. The Future...  Develop IDS that is based on Sebek Data.  Merging this IDS with Systrace to protect systems  Using this IDS to support Honeytokens

37. Where Can I learn more?  http://www.honeynet.org/papers/sebek.pdf

38. Where Can I get Sebek www.honeynet.org/tools/sebek  For questions or comments contact Edward Balas  ebalas at iu.edu