Please see part 1 for an introduction if you are reading this article separately.
The first technical talk I attended was presented by Mariusz Burdach, titled "Finding Digital Evidence In Physical Memory." Mariusz really needed two hours or more to give his topic justice. He started his talk buy holding up DoD and DoJ manuals which recommend pulling the plug as an incident response step (argh), and he said commercial tools all focus on inspecting hard drives. Unfortunately, modern rootkits may stay in non-swappable memory pages, and will not touch the hard drive. Therefore, traditional victim hard drive forensic practices may be useless against modern techniques.
Mariusz named three anti-forensic methods.
- Data contraception: do not create data on the hard drive; keep everything in memory
- Data hiding: keep processes from appearing in task or process lists
- Data destruction: remove suspicious information on the file system
He mentioned a few cool examples.
- The Core Security syscall proxy as a means to not write any files to disk when loading malicious programs into memory on a target system.
- The Metasploit SAM Juicer dumps Windows
password hashes from a Meterpreter shell without writing any files to disk. - Hacker Defender has commercial antidetection modules.
- Jamie Butler's FU and Shadow Walker (collaboration with Sherri Sparks) are impressive.
Marius briefly discussed software- and hardware-based means to acquire victim memory. On the hardware side he noted Tribble, a PCI card that can read system memory. On a related noted, I ate lunch on Wednesday with Jamie Butler. His new company Komoku is working on the Copilot host monitor, another PCI card mentioned by Mariusz. If you don't have a PCI card already in the victim system, you might be able to acquire or change memory via Firewire. I missed this when it was originally announced, but now I realize it's a huge issue.
The most relevant aspect of Mariusz's talk was his announcement of two tools for reviewing physical memory dumps. The first is the Windows Memory Forensic Toolkit (WMFT) and the second is Idetect, for Linux. These look very interesting, and I believe Mariusz will release new versions once he returns to Poland. Mariusz' talk and several that followed emphasized that memory absolutely must be analyzed when performing incident response.
Next I saw John Heasman from NGS Software present "Implementing and Detecting an ACPI BIOS Rootkit." John was the best speaker at BH Federal, in terms of content and delivery style. His presentation (.pdf) has already seen some coverage. The problem centers on the fact that Advanced Configuration and Power Interface can be used to read and write sensitive areas of targets, like system memory. For example, ACPI could be used to disable all access control on a Windows system by extracting ACPI Machine Language (AML) from a target BIOS, finding inititialization control methods, appending ACPI Source Language (ASL) to implement the SeAccessCheck exploit, recompiling into machine language, flashing the BIOS, and rebooting the system. Linux has a similar problem where the sys_ni_syscall exception handler could be patched.
John brought up very interesting points about rootkits. He asked whether they always need to be active, or if they could simply activate at random times to frustrate detection. He said the bootable CDs that use ACPI would be as vulnerable as the OS installed on a hard drive, making life tougher for incident responders. Sure, ACPI can be disabled, but that may disable some device drivers too. John said that ACPI debugging and Windows event logs may yield clues to ACPI exploitation, so stay alert. He also mentioned that ACPI could be modified such that fans never activate. Combine that with a process that starts the CPUs spinning and you have a software-based way to destroy a machine!
Keep in mind that a BIOS rootkit would not be a traditional rootkit. It would be used to infect a target, and then code on the target would open back doors and so on. The BIOS only offers "tens of KB" of space, according to John.
This reinforces my point that rootkits make NSM more relevant than ever. Now all we need is a Cisco router or switch rootkit.
0 komentar:
Posting Komentar