Making output of malfind a little more informative

[GoogleCodeExporter]

To make the names of the dumped files by malfind a little more informative 
I´ve applied a small change at line 407ff.

Changed version is attached.

Greetings to all especially MHL for that great plugin!

Original issue reported on code.google.com by MichaelF...@gmx.net on 26 Jun 2012 at 7:10

Attachments:

• malfind.py

[GoogleCodeExporter]

Sorry, I was to fast. This is no defect it's an enhancement only with priority 
low

Original comment by MichaelF...@gmx.net on 26 Jun 2012 at 7:12

[GoogleCodeExporter]

Michael, 

What would happen if EPROCESS.ImageFileName contained "../../etc/passwd" and 
you ran the plugin with your proposed patch? Not only would the file be written 
outside of your intended output directory, but it could possibly corrupt other 
files on your analysis system. If your analysis system is Windows, it could be 
even more dangerous. For example:

1) An attacker starts a copy of cmd.exe and then overwrites 
EPROCESS.ImageFileName with "../bad.mic"
2) The attacker allocates memory in the cmd.exe process using 
VirtualAlloc(PAGE_EXECUTE) so it will be detected by malfind and writes a 
malicious document that exploits CVE-2010-3970 to the memory 
3) You run malfind with the patch, it extracts the malicious document outside 
of your desired output directory. 
4) Some arbitrary time in the future, you browse to the directory with explorer 
and it renders a thumbnail of the malicious document, leading to remote code 
execution

I'm being slightly dramatic, but the attack is possible and we'd rather not 
introduce possible ways to attack analysis systems. This is why we try not to 
take strings from untrusted sources (the memory dump) and use them when 
constructing file paths. 

You're welcome to use the patch on your systems (after all, that's what open 
source is for), but its not something we're going to commit for the public 
branch. Admittedly there are probably a few areas in the source code that 
already does this, but they should be changed, or we need to design a safe 
character filter to prevent things like "../" and "..\" being used in path 
names. 

Original comment by michael.hale@gmail.com on 26 Jun 2012 at 4:11

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 26 Jun 2012 at 5:52

• Changed state: WontFix
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Hello Michael, hello all,

wow, that's a thrilling scenario I did not consider while trying to get the 
malfind output in the way of older versions. I felt quite secure using the 
*.dmp-extension for the dump files. According 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3970 that bad things 
will need a *.mic (my nickname... ;-)) or *.<office> extension to happen, won't 
they. According your idea to infect my system (may I trust your code in future 
;-)) it was not my best idea to use the _EPROCESS.ImageFileName as the first 
part of the dumpfiles name, you're right. It should be a little more safe using 
something like "Process" (as you did) followed by the rest, shouldn't it?
Because IMHO it is more informative the see from which process injected code 
origins I would like to suggest to use the Imagefilename in further versions 
anyway, rid of special characters of course.
Regards mic 

Original comment by MichaelF...@gmx.net on 27 Jun 2012 at 7:12

[GoogleCodeExporter]

No problem. Your feedback is useful and we definitely want to make it easy to 
use. You're not the only one who desires the process name to be included in 
dumped files, so I wanted to explain once and for all why we don't currently do 
it that way. Most likely we can filter characters sometime soon (in the 
meantime feel free to alter your copies however you please ;-))

Original comment by michael.hale@gmail.com on 27 Jun 2012 at 3:23