Last Updated: 14 Nov 2019 16:31 by ADMIN
Created on: 09 Sep 2019 15:59
Type: Bug Report
privilege escalation ( EnableLoopback.exe ) via dll sideloading

Hello sir, 

         I've discovered the security bug with is privilege escalation bug via DLL sideloading.

please check it for more details:



Posted on: 17 Sep 2019 00:39

Yeah, as a strategy, that doesn't really work.

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

Hello sir,

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.
With Best,
Posted on: 16 Sep 2019 14:38

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. 

Progress Telerik
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? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Posted on: 12 Sep 2019 01:50

hello sir, 


  can you acknowledge or approve this bug ?.  can i request CVE ID for this issue ?
Posted on: 11 Sep 2019 18:19
[assembly: DefaultDllImportSearchPaths(DllImportSearchPath.System32)] 

...Adding this might be useful, although again, it only really matters if this were a system-wide install where the EnableLoopback tool is not in a user-writable path.

Posted on: 11 Sep 2019 17:31

From a security POV, this is not very interesting, since anyone in a position to exploit this could also just replace EnableLoopback.exe with the malicious executable of their choosing.


Preventing DLL planting attacks in Windows and in .NET is generally pretty challenging.

Some discussion here: and

I don't know whether calling SetDefaultDllDirectories early in initialization would be possible or useful here.