Last Update: July 28, 2020
Since the beginning of 2016, the Information Security Early Warning Partnership has received many reports of incidents regarding the insecure loading of Dynamic Link Libraries that involve the application-directory type. An application-directory type DLL loading is an issue in which, at the time an application is launched, a DLL file stored in the same directory as the application is prioritized and loaded instead of the DLL files in the system directory. HIRT-PUB17011 introduces an overview of the application-directory type issues related to the insecure loading of Dynamic Link Libraries, as well as corresponding countermeasures.
The insecure loading of Dynamic Link Libraries is caused by situations in which the application loads DLL or executable files that should not be loaded. Two types of exploits have been reported: those involving the current-directory type and those involving the application-directory type (Table 1).
Table 1: Types of problems related to the insecure loading of Dynamic Link Libraries
| Type | Overview | Countermeasures |
| Insecure loading of Dynamic Link Libraries in 2010 [Current-directory type] |
A (fake) DLL file stored in the same directory as the data file is prioritized and loaded instead of the (existing) DLL files in the system directory. | Implement controls that do not allow a (fake) DLL file in the current directory to be loaded. |
| Insecure loading of Dynamic Link Libraries in 2016 [Application-directory type] |
When an application is launched, a (fake) DLL file that is placed in the same directory as the application is prioritized and loaded instead of the (existing) DLL files in the system directory | Implement controls that do not allow the (fake) DLL file in the same directory as the application to be loaded. Note, however, that in some cases, the application alone cannot control this exploit, and users must also take action. |
Clicking on a document file (document.xxx) placed in a directory such as a file-share directory causes the executable file associated with the filename extension .xxx to start. When this occurs, the DLL file placed in the same directory as the file document.xxx (in the current directory) is prioritized and loaded instead of the (existing) DLL files in the system directory.
Diffusion activities
NotPetya attempts to propagate itself. In the process of propagating itself, this malware spreads by exploiting a vulnerability in Windows SMBv1 (vulnerability CVE-2017-0145, addressed by security update MS17-010) and by stealing the user's Windows credentials.
Figure 1: Current-directory type exploits
When the user clicks an executable file and starts the installation or actual functionality provided by the executable file, a DLL file placed in the same directory as the application is prioritized and loaded instead of the (existing) DLL files in the system directory.
The following type of attack is possible: An attacker places an executable file and a (fake) DLL file in a directory such as a file sharing directory (Figure 2 top). Similar problems might also occur after the operation to download the executable file (including the fake DLL file) is performed (Figure 2 bottom).
One example of a problem that might occur is that, if certain conditions are met, the user might decide to click on the executable file. For example, if the executable file and the (fake) DLL file are included in a .zip file, or if the (fake) DLL file is added to a web browser's download directory, where it is injected in among other files, the user might decide to click on the executable file.
Figure 2: Application-directory type
As a countermeasure, controls must be implemented that do not allow the (fake) DLL file placed in the same directory as the application to be loaded. At HIRT, we further classified the application-directory type issues of the insecure loading of Dynamic Link Libraries vulnerability into seven types, and investigated the possibility of countermeasures. As a result, we found that in some cases the application alone cannot control the issues associated with the insecure loading of Dynamic Link Libraries (Table 1).
Table 2: Further classification of application-directory type issue
| Type | Overview | Countermeasure#1 | Countermeasure#2 | Countermeasure#3 | ||
| Measures to be taken in the application | Measures to be taken by the user | |||||
| Use variables such as the SetDefaultDllDirectories variable and the LoadLibraryEx variable to delay loading of the DLL file when the application starts. | When starting the application, copy the executable file to a newly-created folder, and then run the file. | Run the executable file in a safe manner. For example, run the file after it has been moved to a folder newly created by the user. Confirm that the folder does not contain any suspicious DLL files or other suspicious files, and then run the file. | ||||
| Install type[*1] | Other[*2] | Install type[*1] | Other[*2] | |||
| #1 [*a] | Loading of a DLL file that is directly linked to the applicable path | app | app [*3] | app | N/A [**] | user |
| #2 [*a] | Loading of a DLL file that is indirectly linked to the applicable path | app | app [*3] | app | ||
| #3 | Loading of a DLL file via DLL forwarding | appx [*c] | ||||
| #4 | Loading of a DLL file in a proprietary format | no [*b] | ||||
| #5 [*a] | Loading of a DLL file via compatibility functions of the application | app [*d] | ||||
| #6 | Loading of a DLL file via monitoring software | no [*b] | ||||
| #7 | Loading of a DLL file via compatibility functions of the OS | no [*b][*e] | ||||
user: Can be handled by the user
app: Can be handled by the application
appx: Can sometimes be handled by the application
no: Cannot be handled by the application alone
N/A: Not applicable
*1: This applies to applications, such as installers, that install applications into Windows systems.
*2: This applies to applications in self-extracting formats (self-extracting files) that do not need to be installed in a Windows system. These applications are also called portable applications.
*3: For self-extracting files that are used for purposes such as the distribution of materials, this excludes already-distributed self-extracting formats (self-extracting files) for which countermeasures have not been implemented.
*a: It is especially important to take note of these issues, and to take countermeasures in the application.
*b: The application alone might be able to control the loading of DLL files.
*c: Depending on the OS version, it might not be possible to implement controls or countermeasures for certain applications.
*d: These issues can be addressed by changing the filename of the executable file.
*e: This applies when the OS compatibility functionality is enabled in the repository settings.
Note: "N/A" is listed for applications for which installation is not required, because it is not typical to copy these executable files to a newly created folder when running the applications.
Followings are updates of Hitachi products and OEM products (indicated by an asterisk (*)).
Added NOTE (Countermeasures to be performed by the user) on download pages.
Software - Hitachi Digital Media GroupPublished Security Advisory HIRT-PUB17011.
Published Security Advisory HIRT-PUB17011 [Japanese].
Insecure Loading of Dynamic Link Libraries issue for Hibun Importance: AA [Japanese]
hitachi-sec-2017-124: Insecure Loading of Dynamic Link Libraries issue for JP1/Hibun self-extracting file [Japanese]
HIRT is the Product Security Incident Response Team (acting as part of a developer of products related to information and control systems). As such, HIRT is promoting measures that can be taken on the application side. At the same time, HIRT is also the incident response team of an SI vendor (acting as part of a provider of services and builder of systems that utilize said products) and the incident response team for internal users (engaging in incident response activities related to internet users who operate and manage corporate information systems themselves). As such, HIRT is also promoting measures to be taken by the user.
If you run (Figure 3, top left) a file or click [Open] (Figure 3, top right) from software such as a web browser, the applicable files are stored in the download directory (Figure 3, bottom right image). Let's think about the operations needed to execute the file test3.exe directly from a dialog box in the browser.
The first time [Run] is clicked, the file test3.exe is stored in the download directory (Figure 3, OP#1). The second time [Run] is clicked, the file test3.exe, which was previously stored in the download directory, is launched (Figure 3, OP#2). Under these conditions, a DLL file that the user unwittingly downloaded is also loaded. (For the purpose of this explanation, the dummy DLL file bcrypt.dll, which we prepared in advance, is loaded.) In other words, a DLL file that should not have been loaded is loaded unintentionally (Figure 4).
Figure 3: The (fake) DLL file is stored with other files in the download directory
Figure 4: When test3.exe is executed, the DLL file is loaded unintentionally
Even users who do not directly execute [Run] or [Open] operations from a web browser can find it difficult to determine whether an executable file requires installation, and whether the appropriate countermeasures have been taken for the executable file. We recommend that users take the following countermeasures.
The file test3.exe loads a DLL file that should not be loaded.
Figure 5 shows the process from when the file test3.exe, which is stored in the download directory, loads the file bcrypt.dll, which is in the same directory, to when an error message appears in a dialog box.
Figure 5: Loading of an inappropriate DLL file by the file test3.exe
Masato Terada (HIRT) and Naoko Ohnishi (HIRT)
