3:07 p.m.
Hi Michael,
first of all, thanks for your support:)
My measurements using the same buffer sizes (when applicable, I cannot
use arbitrary buffer length for all tools) show that the difference is
around 5% , which I agree is not noticable and definitely not a
significant performance gain.
What makes a bigger difference is the size of the buffer itself. Many
tools are using PAGE_SIZE as the buffer size, win32dd and winpmem are
one of the rare tools that are using big buffers by default (and I
think that's a good thing). Difference can then be even up to 100%.
I have not proved this assumption, because some other variables could
influence the speed of the acquisition and I didn't reverse engineer
every single driver to see which transfer methods and acquisition
methods are being used.
I agree, but as I said, to an attacker who "owns" the acquisition tool
in user space (via binary planting or some other methods), access to
kernel space might be much harder.
I agree with you completely regarding reliability and simplicity, but
I'm still not so convinced about the security. At least you make it
one bit harder for an attacker (who also has the same reliability and
simplicity issues in his driver:) ).
For example, I have done a workshop at the open
source
digital forensic conference demonstrating among other things how
Volatility can be easily defeated on a live system. For educational
purposes, I have added write support to the winpmem memory acquisition
tool which allows volatility itself to write to arbitrary physical
memory. Since Volatility is really good at finding the artifacts,
turns out its also really good at manipulating these artifacts :-).
https://volatility.googlecode.com/svn/branches/scudette/docs/references.html
http://bit.ly/OSDFC_Memory_Workshop
Very cool, I already saw that some time ago and it's a very nice intro
and walkthrough for Volatility.
On 7 January 2013 20:52, Luka Milkovic
<milkovic.luka(a)gmail.com> wrote:
The only thing that currently really puts both paradigms in more or
less equal positions from an attacker's perspective is that you need
admin privileges for UM injection/hooking, because the acquisition app
itself needs admin privs.
But there are other techniques available in UM that could subvert the
correctness of the process and attack acquisition applications from a
less privileged account.
For example, I made some quick test for binary planting
vulnerabilities and almost all acquisition tools that I tested are
vulnerable to binary planting. Winpmem is actually the only tested
tool which is not vulnerable to binary planting, while Memoryze and
OSForensics have large number of such vulnerabilities.
I don't consider BP such a big issue here (although it is not
something that should be completely ignored), but it further supports
"KM is better" theory I'm advocating.
Of course KM is not a complete solution, but the attack surface is
somewhat lowered.
As a side note - Volatility on Windows is also searching for DLLs and
Python code in the current directory first. I wonder if someone made a
pyc planting:)
KM/KM paradigm used ONLY by win32dd is better in
many ways:
1. Buffer never leaves the kernel space - attacker cannot attack it
from the user-mode
It is true that the image is written from kernel mode, but a kernel
mode rootkit can easily intercept the kernel functions just like in
usermode. Usermode hooking can still be used to intercept the IO
control which triggers acquisition (for example some acquisition modes
are easier to subvert and a user mode tool can still force these to be
used by hooking the io control command). 2. Buffer never leaves the kernel space - no
performance overhead of
communicating with the driver, copying the memory back to user-space
(or not, depending on the method used, but then you have additional
probes of UM buffer etc.)
Our measurements show that buffering between kernel and user space
does not have a very significant impact. In particular, the linux pmem
driver does support direct mmap implementation (bascially its an mmap
into physical memory), but in practice there is no measurable
performance difference. I believe that on windows it is also possible
to set up direct MDL mappings into userspace which simply avoid any
copying between kernel and user space. I never spent the time to
investigate this since I am not seeing significant performance gains
when comparing winpmem to win32dd. 3. Logging and/or encryption methods done in
KM-only are again much
safer than doing it in user-mode (you mention it later in your answer)
That depends on your frame of reference. Safer is only a relative
term. To an attacker which already owns kernel space it is the same
amount of work to hook a kernel module or a user space program. It does not solve the problem, as I have
demonstrated, but I think it
is simply unnecessary and worse approach to transfer the buffer back
to user-mode and then write it to dump.
I disagree. Passing the buffer back to userspace makes user mode
processing much simpler and more reliable since you do not need to do
much processing in kernel space. For example, it is possible to run
Volatility directly on the live system without taking an image first,
for a quick triage of the system - this is faster and more efficient
than taking a full image if all we want is to search for specific
sigs.
In practice it is trivial to encrypt/obfuscate the data between kernel
and user space which makes manipulating these buffers from userspace
by Dementia more difficult without intimate knowledge of how the
specific acquisition tool works.
I agree.
The real challenge for Dementia the way I see it is to be able to
identify the DFIR tool in order to interfere with it.
Exactly!
It worries me that many infosec specialists (not necessarily forensic
experts) use acquisition tools without even minimal precautions - they
download the tool, put it on the USB stick and run the tool as-is,
without even renaming it. Detecting the acquisition application by its
name is one of the first filters used by Dementia and it is as dumb as
it gets:)
There are plenty of ways to detect DFIR tool, you mentioned some of
them and George gave a link on Peter Kleissner's whitepaper. I'm
thinking about implementing some of them, but don't have the time at
the moment...
It's heuristics in the end, and you're dead right that some commercial
applications are much less flexible here.
For example, by breaking the
system in such a way that any acquisition tool fails to work at all -
this can get the responder to be pretty sure the system is owned, but
they still can not acquire the image or evidence. Coupled with a
really good persistence mechanism (so its hard to locate the malware
on disk) and most responders will just rebuild the box and move on.
:) When I was thinking about writing tool like Dementia, a friend of
mine told me it's completely useless to create such tool:) His opinion
is that a tool which detects an installation of DFIR app driver or
launch of DFIR application and immediately crashes the machine or
reboots it (via HalReturnToFirmware or smth) is even more effective
then Dementia-like tools:)
This should not be suspicious to analyst, because he would think that
the application itself is causing the reboot.
We must consider the possibility that our own tools and techniques are
used against us - those artifacts that you are finding using
Volatility (and other tools) can also be found by the bad guys and
cleaned up just as easily. It is an arms race :-).
Actually, I was thinking about utilizing Volatility to work for me in
Dementia's hiding job - Volatility would detect the artifacts and I
would just need to remove them from the dump.
I abandoned this idea since I would need to sanitize the buffers on
the fly and would need to hack Volatility significantly. I'm not a
good Pyhton developer, so that would take some time:)
Anyway, thanks Luka for an interesting talk and a nice discussion.
Michael.
Thanks to you also Michael, it was an interesting discussion:)
Cheers,
Luka