WithSecureLabs
[Bug] Chainsaw Accidentally Attempts to Parse Non-MFT Files when Signature Matches
When running chainsaw over whole triage packages the error handling is mostly correct. I.e.
[!] failed to load file 'C:\Triage\C\ProgramData\Microsoft\Windows Defender\Support\MpWppTracing-20241201-170000-00000000-fffffffeffffffff.bin' - Bad signature: [0, 10, 0, 0], expected one of [b"FILE", b"BAAD", b"0000"]
The issue occurs when it matches this signature. It then attempts to parse the file believing it is a valid MFT. An example of this is the Urlblock file located here C:\Triage\C\Users\User\AppData\Local\Microsoft\Internet Explorer\UrlBlock\urlblock_637519735737636150.bin. When the signature "0000" passes it attempts to parse the file and fails due to it not actually being an MFT file.
thread 'main' panicked at C:\Users\Administrator.cargo\registry\src\index.crates.io-6f17d22bba15001f\mft-0.6.1\src\mft.rs:67:9: attempt to divide by zero
There needs to be tighter error handling on this part so that .bin files that are not MFTs will be skipped. Maybe checking more of the file rather than just the first set of bytes to ensure the structure matches that of an MFT? Either that or gate the .bin file names when in hunt mode on directories to just look for files containing mft in the name?
Easy way to reproduce this is to get a bin file with all 0s as a test file. I reproduced it with this file as well as an easy test case for you. https://nbg1-speed.hetzner.com/100MB.bin
Agreed, the lack of magic is really starting to bite now.
We might be able to use Google's Magika once the rust library is out as this requires no external files unlike libmagic. But in the short term I will make sure that we don't panic cause that is a problem.
