New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DLL Hijacking should be P2 or P3 #118

Closed
silascutler opened this Issue Dec 10, 2017 · 19 comments

Comments

5 participants
@silascutler

silascutler commented Dec 10, 2017

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:

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

This comment has been minimized.

Member

ryancblack commented Dec 15, 2017

@silascutler - Thank you for raising this question! Upon discussion we see value in potentially including a variant that has a default higher priority.

The impetus behind a lower default priority on context-dependent categories is balance default expectations with technical reasons to elevate criticality.

As this issue is dependent on several factors, including the ability to write the assembly to the program installation location which often requires higher privileges, do you have a suggested distinction between a poor practice in context? One example, as you have already provided, would be the execution of a trusted application from an attacker-controlled location.

If these may be grouped distinctly in a clear manner we can title these variants in a way that best conveys the issue for researchers and the consumers of vulnerability reports.

@silascutler

This comment has been minimized.

silascutler commented Dec 23, 2017

Exploitation of this technique against an existing installation I think is the misconstruing this issue and I'd like feedback from others ways they've seen this vulnerability exploited. I suspect there are some ways from the game modding community.

From my experience, exploitation of this is common by replaying the executable against targets - like with PlugX. In these instances, the software isn't running on systems targeted, the vulnerability simply allows the attacker the ability to leverage the associated code-signing cert to legitimize payload deployment.

In the aforementioned PlugX blog from Palo Alto, attackers dropped a file named 7.tmp. This file contained:

  • %TEMP%\RunHelp.exe [This file is key]
  • %TEMP%\ssMUIDLL.dll
  • %TEMP%\ssMUIDLL.dll.conf

These files are extracted and RunHelp.exe is executed; this file is vulnerable to DLL side loading (using ssMUIDLL.dll). In this attack, the full installation of RunHelp's software is not on the targeted systems. The ability to write to the installation directory is not a factor in exploiting this vulnerability.

From the above attack scenario, In order for a higher classification, the vulnerable executable must be either

  • Signed
  • Critical component (ie: Installer, Updates, service components) [There are potentially other attacks here]

Without a signed file, the attack is a lower risk.

The problem with the 'Binary Planting' category is that it too heavily groups this vulnerability into one type of exploitation scenario. Usage of this vulnerability in the wild may be more accurately described as a broken access control.

So, for classification, it could go like this:
Priority | Category | Vulnerability Name | Function

  • P2: [High] : Broken Access Control (BAC) | DLL Hijacking | Incorrect DLL Security Controls
    • Signed executable, possible use in replay attacks
  • P3: [Medium] : Client-Side Injection | DLL Hijacking | Incorrect DLL Security Controls
    • Unsigned, but something like an installer, update or service component
  • P5: [Low]: Client-Side Injection | DLL Hijacking | Incorrect DLL Security Controls
    • Unsigned, Low risk
@subrosaassociates

This comment has been minimized.

subrosaassociates commented Dec 26, 2017

@silascutler this is great to see this discussion happening here, i've had a few dll attacks bounced

From my experience there is a disconnect between web bugs and thick client bugs, imo if you allow thick clients in scope you are considering a threat model that differs from a web interface i think that's getting overlooked

obviously the VRT to-date has been hugely successful for web bugs, but it would be nice if it was a little more clear to bugcrowds clients and for the hunters that if they allow thick clients into the scope 'it aint web (most of the time)

I'd like to see thick client issues expanded and measured appropriately to the environmental context to where those apps exist (LAN/PAN/*not a webpage)

@subrosaassociates

This comment has been minimized.

subrosaassociates commented Dec 26, 2017

Some video examples for some DLL stuff (might as-well)

Good questions for those that have thick client apps in scope:

  • Am I interested in hardening my thick client app
  • Do I want to be the app seen running malicious code relatively easy
  • have I caveated dll attacks from scope, because if we havent ... and we havent hardened there is probably opportunities
@ryancblack

This comment has been minimized.

Member

ryancblack commented Dec 29, 2017

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.

@plr0man

This comment has been minimized.

Contributor

plr0man commented Jan 4, 2018

@silascutler to your original post. As far as I understand the user has to use Internet Explorer and visit an untrustworthy remote file system location or a WebDAV share and open a document from these locations. On systems running Protected Mode, Internet Explorer will require user consent to launch Windows Explorer, using a security warning. These are some significant prerequisites for a successful attack. I would be happy to see this kind of PoCs in our reports though, as we might be able to push for higher priority as opposed to the local vector which we usually see. Any other advanced method reports are of course welcome and the default priority may be upgraded based on context. However our general experience evaluating binary planting reports has resulted in baseline P5/P4 priorities.

@silascutler

This comment has been minimized.

silascutler commented Jan 4, 2018

Let me put together a PoC to demonstrate. The vulnerability I'm describing does not rely upon IE, WebDAV or shares. Stand by

@silascutler

This comment has been minimized.

silascutler commented Jan 4, 2018

@plr0man, Yeah, if it was required to have that many conditions, it'd be highly unlikely that actual real-world execution would be possible.

I have prepared an example use-case for this exploit in malshare.com/users/~p1nk/sploit.exe.

The file is a SFX-archive that when executed, will unpack two files: DbgView.exe (Vulnerable to DLL Hijacking) and a DLL file (the malicious attacker file I created). When run, the SFX will execute DbgView, which will run the malicious DLL opening calc.exe

This is the most common use-case. Attacker sends phishing email that results in users opening said SFX archive.

@subrosaassociates

This comment has been minimized.

subrosaassociates commented Jan 4, 2018

I think water gets muddy when you have to provide explicit scenario's and equally 'On systems running Protected Mode' type language

something can be improved, the customer has asked to be provided with exploitable routes

it's the XSS of thick client work

I'd add that from a mentality perspective i've been paid out a fair few times on convoluted xss, because it was xss not because it was unlikely or how the attack position my theoretically be attained

https://attack.mitre.org/wiki/Technique/T1038 it's on the list for many things

@silascutler

This comment has been minimized.

silascutler commented Jan 4, 2018

@subrosaassociates Absolutely. There are times in which this vulnerability can be chained with additional things and that could get into IE/ Protected mode stuff.

I absolutely agree with that statement. It's XSS of applications [thick clients].

Another thing that makes this (in my view) arguably more valuable to an attacker the XSS is that attacks can occur abusing this exploit without the associated company knowing. With XSS, an attacker has to bounce traffic off of a companies web-server, whereas with this, they only need copies of the vulnerable files.

@subrosaassociates

This comment has been minimized.

subrosaassociates commented Jan 4, 2018

there needs to be a level of maturity from the customers that want to receive thick client bugs

I'd suggest that thick client work yields a different metric all together instead of leaning on the web

the separation between server side data and endpoint compromise needs to be measured in how much you care about each

i.e. :

  • Do we want to look like we care - fix the website
  • Do we actually care, fix the software we sell.

and those two gravities should be equal in concern as long as the client is concerned.

@truemongo

This comment has been minimized.

truemongo commented Jan 5, 2018

@silascutler,

I'm curious, in your SFX example (which I assume you're presenting as a real world use case) what is the gain for an attacker to use DbgView.exe, and DLL sideloading as part of the attack? If you can get the user to run a SFX through phishing (an executable itself, and unsigned) then you've already won.

The PlugX usage of a 3rd party .exe to sideload a DLL also seems more about obfuscation than actual value to the attacker.

@silascutler

This comment has been minimized.

silascutler commented Jan 6, 2018

Yes. Real world case. Fully functional.

@truemongo, Solid question about the user running the WinRAR SFX file. While these files are unsigned, they are used for legitimate applications and as some installers. As such, they aren't always flagged. When the SFX executes the vulnerable application, it is not run under WinRAR, but as a stand-alone process. This is the opposite (and crux of the issue) to the vulnerable application when vulnerable to sideloading. In the following screenshot, you can see the result of the PoC being executed.
screenshot from 2018-01-05 18-42-14

To the host system, calc.exe is run at the same permission level as the signed executable and to A/V and logging systems, what is see is "User ran WinRAR and then started signed application" - "Not user ran this unknown program".

@plr0man

This comment has been minimized.

Contributor

plr0man commented Jan 26, 2018

Looks like there are no further comments on this issue. So just to sum it up, current severity rating reflects the local nature of the attack vector. In the reference you provide @silascutler we can read that this is not always the case. I clarified our position on that aspect in my previous comment.

Regarding PlugX or the SFX example you give above, I don't believe we're on the same page. The fact that there are techniques that utilize DLL sideloading as the means to tricking the victim's system into NOT FLAGGING the execution of such malware doesn't seem to have much in common with how DLLs are planted in local applications. Neither does this technique change the attack vector from local to remote.

That being said if the attacker convinces the victim to download and execute a malware package, that is game over, it is a prerequisite which for the most part is beyond the software manufacturer's responsibility, unless we are talking about an A/V vendor being the client or public relations concerns. Hope this makes sense.

@silascutler

This comment has been minimized.

silascutler commented Jan 26, 2018

Then before closing this, let me add a point and two follow up questions. In your last statement, there is a distinct potential for a public relations problem if a vendor's software is used in the same manor as with PlugX. In these cases, the vendor's only way to stop exploitation would be to revoke their code-signing certificate, re-acquire and update across their platform.

Two broad questions:

  • What would a locally exploitable buffer overflow, without a privilege escalation component be rated?
  • Are there any vulnerabilities in the taxonomy that are related to post-exploitation? Equating initial access to /game-over/ seems short sighted as it precludes a wealth of potential attack surface.
@subrosaassociates

This comment has been minimized.

subrosaassociates commented Jan 26, 2018

Yeah, I havent had any responses to my points, i'll like to hear some feedback too :)

@plr0man

This comment has been minimized.

Contributor

plr0man commented Jan 29, 2018

Apologies @subrosaassociates I was hoping that your concerns have been addressed in #121. Would you mind reiterating any of your remaining questions?

@silascutler sure, you could revoke the certificate, but in most cases that would be a radical move. Anyway we are getting off track:)
To your questions:

  • Allow me to answer with a question: what differences in security risk do you see between locally exploitable buffer overflow and binary planting?
  • P5 as used in the VRT means "accepted risk", "best practice" or as we call it "Informational", note that does not mean Not Applicable. It is up to the customer to decide if they are interested in fixing this type of issues.
@subrosaassociates

This comment has been minimized.

subrosaassociates commented Jan 30, 2018

hey @plr0man, I replied to the permissions issue in it's own thread, i was referring to my questions notes in here

but similarly...

my goals for joining in on the conversation was to influence the separation of web interface and desktop interface issues

for example, getting $100 for a nice little attack doesn't seem worth it, when a blogpost and a CVE might do my public exposure more benefit - amongst peers and perspective employers, you wont get that on a private bounty, and as long as the attack surfaces are considered as they currently are, thick client bugs will continue to go underrated

@silascutler

This comment has been minimized.

silascutler commented Jan 30, 2018

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. )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment