LoadDriver 2148204812

c++ / delphi package - dll injection and api hooking

LoadDriver 2148204812

Postby Baconzor » Tue Oct 01, 2019 3:48 pm

Last madcodehook I've got running on my clients are from dec 2017

Recently I've decided to update to the 2.8.8.0, went throught all the hoops, configuring the driver, resigning everything, getting the microsoft hardware signature from their partner dashboard

Tested on my machines and everything was fine, driver installation, dll injection, IPC communication, 100%, so I started updating my clients, I separated 1000 machines to deploy before putting it up to everyone, updating drivers and hooks is kinda critical so for sure a slow deploy on this one

Everything was fine for a couple weeks, then clients started reporting my software stopped working, I checked the affected machines and uppon testing, no dll injection due the driver not being loaded

The LoadDriver function returns false, getlast error returns 2148204812, sometimes it also returns -2146762484 on other machines, the message from syserrormessage is the certificate was explicitly revoked

Naturally, I went to Globalsign about the revoked thing, they assured me the certificate was not revoked, the Microsoft Dashboard also accepts my certificate, also 95% of the Windows 10 machines load the driver just fine

Globalsign advised me to reset my token and reissue and reinstall my certificates, their intermediate certificates, and their root certificates, I did all of those things, everything fresh, same result

I'm currently rollbacking the version since the past signed driver can be loaded fine

I'm wondering if it could be something on their environment, some security software blocking loading the driver, then again why would they let the previous one be loaded, and why set such error in return, when I deny a call to an API I usually return access denied

So here I am posting to see if anyone else is having the same issue and if someone can shed a light on what else I could do about this
Baconzor
 
Posts: 17
Joined: Tue Dec 01, 2009 3:15 pm

Re: LoadDriver 2148204812

Postby iconic » Tue Oct 01, 2019 4:42 pm

You might have one of the affected customer's run a separate tool which just calls WinVerifyTrust() on your signed driver and report the result back to you. If you're still getting a similar error about the issuing CA revoking your certificate then I'd pat GlobalSign on the shoulder again, possibly even ask to speak to their development team, because everything is still pointing to them according to the revocation error.

*edit*
You might also upload your driver to VirusTotal.com and see if your signed file
is reported back as something less than trusted. IIRC it should also report revoked
certificates, but likely not scan the entire chain down to the root. Worth a try
however.

--Iconic
iconic
Site Admin
 
Posts: 929
Joined: Wed Jun 08, 2005 5:08 am

Re: LoadDriver 2148204812

Postby madshi » Wed Oct 02, 2019 8:48 am

Great suggestions from iconic there.

Alternatively, you could also compile a barebones (almost empty) driver yourself, and sign it, to check if that one is also refused to load on those affected customers' PC. That would allow you to check if the problem is specific to the madCodeHook driver or not. It seems unlikely, but stranger things have happened. Of course doing this test would require one of the affected users to help you debug.
madshi
Site Admin
 
Posts: 10098
Joined: Sun Mar 21, 2004 5:25 pm

Re: LoadDriver 2148204812

Postby Baconzor » Sun Oct 13, 2019 10:08 pm

Alright, here's more info following the suggestions, I appreciate them

I made the tool that calls WinVerifyTrust, it does multiple calls using different flags:

DRIVER_ACTION_VERIFY
WINTRUST_ACTION_GENERIC_CHAIN_VERIFY
WINTRUST_ACTION_GENERIC_VERIFY_V2

*Also the WTD_REVOKE_WHOLECHAIN options to check the whole chain

As expected, on the unaffected machines all calls returns success, even the DRIVER_ACTION_VERIFY

I also tested a driver signed with my EV certificate, but before running through the Microsoft dashboard to get theirs, as expected, the generic flags for signature check return sucess, but the DRIVER_ACTION_VERIFY fails

So I got ahold of one of my clients machines that had this issue, I ran the tool there and bang, as expected, the call to WinVerifyTrust with DRIVER_ACTION_VERIFY fails to recognize the signature, this is a good way to identify machines affected by this issue, without trying to load the driver

Furthermore, I checked the msdn of WinVerifyTrust and found this info about extra padding bytes after the signature (HKLM\Software\Microsoft\Cryptography\Wintrust\Config\EnableCertPaddingCheck=1), this came into effect around 2014, but hey this could be it, the info around this issue is sometimes installers could add extra bytes there...I fiddled with the key but it didn't make any difference, in any way

So I went ahead and looked deeper about this padding info, I found this signature check tool "AnalyzePESig" that dumps out info around the PE file, including certificate info, turns out there is no padding after the PKCS7 signatures on my drivers

For good measure I also got the SigCheck from SysInternals to check, and it also trusts the signature, must simply use WinVerifyTrust generic flags

VirusTotal, good tip btw, also returned peachy, 0/69 detection

I'm currently still at a loss, but hey, got a lot more info that I'll turn to Globalsign and see what they have to say about it

One last thing, the driver is triple signed, the old sha1, sha2 and MS for both windows 7 and 10 compability, as most windows 7 machines still can't read EV signatures, not even Microsoft's. Globalsign told me to discontinue signing with Sha1, but they just don't get the clients circunstances, I deploy corporate software only, and there is plenty of machines still running windows 7, and I can't just go to them and tell them "hey man just update your OS's if you want to run my product"

So the file goes:

1 - Sha1
2 - Sha2
3 - Microsofts

It just hit me that maybe, just maybe, the Sha1 signature could be what is causing windows to not trust the driver, even though it is also Sha2 and MS signed

This is currently my last attempt, I already rolled back to the previous driver and it is getting harder to get access to a clients machine to run tests, since everything is running back as expected

I will post back in case this succeeds
Baconzor
 
Posts: 17
Joined: Tue Dec 01, 2009 3:15 pm

Re: LoadDriver 2148204812

Postby iconic » Mon Oct 14, 2019 1:45 am

I'm glad you were able to shed some light on the situation. Personally, I deploy 2 separate drivers via OS check. If the OS < Win8 I deploy the SHA-1 driver only (IIRC) and for >= Win8 I deploy the EV SHA-2 + MS co-signed drivers. I do not triple sign my drivers because Windows 7 (without the SHA-2 hotfix) will not understand SHA-2 at all on some machines and fail to verify. I'll double-check this tomorrow and post back when I have more time to ensure what I said above is accurate, but I'm fairly certain (if memory serves) this is the case. I'm currently away from my main development machine otherwise I'd simply check now.

I also agree that CA's don't care about legacy OS support and we can't simply tell a client or customer to simply upgrade their OS version. That's unrealistic and rather comical even :o

--Iconic
iconic
Site Admin
 
Posts: 929
Joined: Wed Jun 08, 2005 5:08 am


Return to madCodeHook

Who is online

Users browsing this forum: No registered users and 12 guests

cron