DLL Hijacking should be P2 or P3

DLL Hijacking (also called DLL Side Loading and DLL search order hijacking) is currently classified under executable planting at a P4 or P5. As the title says, the I suggest this vulnerability be rated at a P2 or P3, because the originally assessed requirements were too narrowly scoped and the in the wild exploitation is akin to stealing an entities code-signing certificate.

This vulnerability was first proposed to the VRT in #16 and added in #28 . @jhaddix proposed this be rated at the current level based on access needed to conduct the attack. The attack scenario that I suspect this was based on is:

1. attacker adds malicious DLL to same folder as target exe.
2. user executes program (running the malware)

While this scenario is used in some cases, the usage in the wild is often different. As noted by: http://blog.acrossecurity.com/2011/09/more-misconceptions-about-binary.html:

We still occasionally come across this misconception that in a binary planting attack, the user has to willfully download a DLL or EXE and place it in some particular location on his computer, from where it will subsequently be launched. If this were true, binary planting would certainly be a ridiculous concept.

Actually though, in a typical binary planting attack the user doesn't have to download anything to his computer. He **opens a file from a remote (attacker-controlled) shared folder and the vulnerable application on his computer automatically, silently executes a DLL or EXE from that same remote folder**. 

In submissions of mine related to DLL Hijacking, I’ve pointed out the following posts to highlight the above quote from AcrossSecurity and illustrate in the wild exploitation:

• https://researchcenter.paloaltonetworks.com/2015/05/plugx-uses-legitimate-samsung-application-for-dll-side-loading/
• https://www.fireeye.com/blog/threat-research/2014/04/dll-side-loading-another-blind-spot-for-anti-virus.html

This vulnerability is also classified by others as: HIGH - https://www.symantec.com/security_response/attacksignatures/detail.jsp?asid=24370 HIGH - (For Skype) https://nvd.nist.gov/vuln/detail/CVE-2016-5720 10 - https://www.rapid7.com/db/vulnerabilities/windows-dll-hijacking-vuln

[ryancblack]

Great discussion here from you both and very much appreciated. Our team is spinning back up during the holidays and end of year. Please expect further commentary and engagement by mid next week.

[silascutler]

So, I’m going to close this because I think we have stalemated on this issue.

@subrosaassociates has nailed the need to reassess the weight of thick vs. web client vulns several times because we are comparing apples and potatoes here. There are different requirements to exploit a web vs. client vulnerabilities and different levels of risk to those capable of exploitation.

I want to caution the line of thinking:

That being said if the attacker convinces the victim to download and execute a malware package, that is game over

When looking at binary exploitation, there are vulnerabilities that go beyond delivery that allow attackers to persist or exploit additional areas.

---

The reason I have pushed on DLL side-loading is that it is an attack that can be exploited without the knowledge of the vendor. In the PlugX cases, unless it is reported, an attacker can abuse the trust in a company’s code-signing certificate for as long as the certificate is valid. (So, even if you patch the in next version, if the code signing cert is still valid, I can continue to exploit this until the certificate expires. )