PE CounterSignatures not parsed correctly in Microsoft signed drivers #16
Comments
metthal
added a commit
that referenced
this issue
Jan 13, 2024
It seems that some (maybe newer) MS countersignatures are not PKCS7 per RFC2315 but rather CMS structures defined by RFC5652. Unfortunately, PKCS7_* family of OpenSSL functions is not able to handle it, but there are CMS_* functions which are. They however do not provide same set of functions to do the same things as with PKCS7 structures. This PR adds possibility to fall back to CMS if PKCS7 fails. Some functions had to be simulated and therefore might not be *that* accurate but just from testing on a few files, it seems to validate them correctly. But it might need a tuning in the future if we test it on a more extensive set of samples.
|
Hi. Sorry for the late response. The first working version has been implemented in PR #17. It might need a little bit more extensive testing before merging though. Let me know if you run into any issues with the PR revision if you have a chance to test it out. |
|
@metthal tested your fix and works well with all MS drivers i was able to test. Well done! 👍 |
metthal
added a commit
that referenced
this issue
Jan 29, 2024
* Added support for RFC5652 types of MS countersignatures (#16) It seems that some (maybe newer) MS countersignatures are not PKCS7 per RFC2315 but rather CMS structures defined by RFC5652. Unfortunately, PKCS7_* family of OpenSSL functions is not able to handle it, but there are CMS_* functions which are. They however do not provide same set of functions to do the same things as with PKCS7 structures. This PR adds possibility to fall back to CMS if PKCS7 fails. Some functions had to be simulated and therefore might not be *that* accurate but just from testing on a few files, it seems to validate them correctly. But it might need a tuning in the future if we test it on a more extensive set of samples. * Removed debug prints * CMake adjustments in hopes to fix Windows build * Debugging GitHub Workflow issue * Revert "CMake adjustments in hopes to fix Windows build" This reverts commit b6b9bf3. * Revert "Debugging GitHub Workflow issue" This reverts commit f644da4. * Include opensslv.h for OPENSSL_VERSION_NUMBER * Format changes using clang-formatter * Remove and move openssl to correct folder on Windows build * Add python scripts for test dev purposes * Add program name to authenticode dumper * Add tests for new MS countersignature feature * Update CI to use expected OpenSSL versions --------- Co-authored-by: Karel Hájek <[email protected]>
|
Fixed with #17 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
it seems there is a bug in the library when parsing the countersignatures on Microsoft signed drivers.
If you try to run the authenticode_dumper code from your examples on a Microsoft signed driver, e.g. procexp.sys, you will get the following output:
As you can see the Verify Flags is set to
COUNTERSIGNATURE_VFY_CANT_PARSEin the parsed countersignature.BTW this bug happens with any drivers signed by Microsoft, you can pick any drivers with a signature in the C:\Windows\System32\drivers directory and the same unwanted behavior happens.
When using the "Digital Signatures" tab from explorer in Windows, you can see that it correctly parses the countersignature from Microsoft-signed drivers. Below example for the procexp.sys driver:
Instead, the parsing of countersignatures from drivers non-Microsoft signed works properly, e.g. kprocesshacker.sys:
I debugged a bit the issue and it seems the failure is here --> https://github.com/avast/authenticode-parser/blob/master/src/countersignature.c#L187
It seems that the openssl function
d2i_PKCS7is not able to parse the data from the unauthenticated attribute.Also, i have a suspect that this bug is causing an issue in the parsing of countersignature in the "pe" module of yara in which i opened already an issue here --> VirusTotal/yara#2012
Thanks,
Antonio Cocomazzi
The text was updated successfully, but these errors were encountered: