Firstly, to reiterate here, this is pointless in the case where Fiddler/EnableLoopback itself is in a writable location (as it is by default) because the attacker can simply strip out the verification logic.
Secondly, the proposed solution of checking the hash of the binary suffers from a time-of-check/time-of-use (TOCTOU) vulnerability, as the attacker can replace the DLL between the time of the check and the time of the use by the loader.
Posted on:16 Sep 2019 16:26
Thanks for your response. There is some remediation step to prevent dll Hijacking attack.
The hash of the DLL has to be encrypted with a private key
In the application, the public key, "encrypted hash" and salt must be embedded
Upon application start, decrypt the "encrypted hash" with your public key.
Generate the Hash again at runtime with the same salt, and compare with the hash decrypted using the public key.
I'm converting this thread to our support system in order to continue the conversation in private.
We can acknowledge this issue and you can feel free to ask for a CVE. In order to fix this, is it possible to send us sample code that reproduces this issue.
Your contribution is highly appreciated.
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Telerik Feedback Portal
and vote to affect the priority of the items
Posted on:12 Sep 2019 01:50
can you acknowledge or approve this bug ?. can i request CVE ID for this issue ?