ID CVE-2017-14020
Summary An Uncontrolled Search Path Element issue was discovered in AutomationDirect CLICK Programming Software (Part Number C0-PGMSW) versions 2.10 and prior, C-More Programming Software (Part Number EA9-PGMSW) versions 6.30 and prior, C-More Micro (Part Number EA-PGMSW) versions and prior, GS Drives Configuration Software (Part Number GSOFT) versions 4.0.6 and prior, and SL-SOFT SOLO Temperature Controller Configuration Software (Part Number SL-SOFT) versions and prior. An uncontrolled search path element (DLL Hijacking) vulnerability has been identified. To exploit this vulnerability, an attacker could rename a malicious DLL to meet the criteria of the application, and the application would not verify that the DLL is correct. Once loaded by the application, the DLL could run malicious code at the privilege level of the application.
Vulnerable Configurations
  • cpe:2.3:o:automationdirect:click_plc_firmware:2.10
  • cpe:2.3:h:automationdirect:click_plc
  • cpe:2.3:o:automationdirect:c-more_plc_firmware:6.30
  • cpe:2.3:h:automationdirect:c-more_plc
  • cpe:2.3:o:automationdirect:c-more_micro_firmware:
  • cpe:2.3:h:automationdirect:c-more_micro
  • cpe:2.3:o:automationdirect:gs_drives_fimware:4.0.6
  • cpe:2.3:h:automationdirect:gs_drives
  • cpe:2.3:o:automationdirect:sl-soft_solo_temperature_controller_firmware:
  • cpe:2.3:h:automationdirect:sl-soft_solo_temperature_controller
Base: 9.3
  • Leveraging/Manipulating Configuration File Search Paths
    This attack loads a malicious resource into a program's standard path used to bootstrap and/or provide contextual information for a program like a path variable or classpath. J2EE applications and other component based applications that are built from multiple binaries can have very long list of dependencies to execute. If one of these libraries and/or references is controllable by the attacker then application controls can be circumvented by the attacker. A standard UNIX path looks similar to this If the attacker modifies the path variable to point to a locale that includes malicious resources then the user unwittingly can execute commands on the attackers' behalf: This is a form of usurping control of the program and the attack can be done on the classpath, database resources, or any other resources built from compound parts. At runtime detection and blocking of this attack is nearly impossible, because the configuration allows execution.
  • DLL Search Order Hijacking
    The attacker exploits the functionality of the Windows DLL loader where the process loading the DLL searches for the DLL to be loaded first in the same directory in which the process binary resides and then in other directories (e.g., System32). Exploitation of this preferential search order can allow an attacker to make the loading process load the attackers' rogue DLL rather than the legitimate DLL. For instance, an attacker with access to the file system may place a malicious ntshrui.dll in the C:\Windows directory. This DLL normally resides in the System32 folder. Process explorer.exe which also resides in C:\Windows, upon trying to load the ntshrui.dll from the System32 folder will actually load the DLL supplied by the attacker simply because of the preferential search order. Since the attacker has placed its malicious ntshrui.dll in the same directory as the loading explorer.exe process, the DLL supplied by the attacker will be found first and thus loaded in lieu of the legitimate DLL. Since explorer.exe is loaded during the boot cycle, the attackers' malware is guaranteed to execute. This attack can be leveraged with many different DLLs and with many different loading processes. No forensic trails are left in the system's registry or file system that an incorrect DLL had been loaded.
refmap via4
bid 101780
Last major update 13-11-2017 - 15:29
Published 13-11-2017 - 15:29
Last modified 05-12-2017 - 09:40
Back to Top