wietze
commented
2 years ago Hey @DemanNL , thanks for opening this issue!
The first one would be in scope for this project; the problem is that there are many vulnerable programs. Perhaps if you can find one or more programs (even if they are older versions) that are vulnerable, you can populate the template as a regular Phantom DLL hijack - use e.g. wlbsctrl as an example.
The second one would currently not be in scope as it is not one of the four types we're currently tracking (side-loading, search order, phantom, environment variable). If there are enough candidates it may be worth tracking this 'input-based DLL Hijacking' as a fifth type in the future - I'll make a note of that.
Hi,
I wasn't entirely sure how to fill the template yaml for these two. But the following two libraries can be included for DLL hijacking.
QT <5.14 (https://kb.cert.org/vuls/id/411271) Uses the variable qt_prfxpath which seems to default to: C:\Qt. Causing a Phantom DLL lookup.
OpenSSL (https://www.kb.cert.org/vuls/id/567764) The variable OPENSSLDIR causes an openssl.cnf lookup which can be abused. Compiled libraries pointing OPENSSLDIR to an user write-able folder can cause a vulnerability. The openssl.cnf can point to a malicious DLL, as demonstrated here (https://www.exploit-db.com/docs/50747)
I don't really know if these two are fit for this project. Or how to fit them in the template. Please let me know if you find them suitable candidates.