Isapi.dll Failed To Load

0 views

Skip to first unread message

Germain Aguilera

unread,

Aug 3, 2024, 5:07:26 PM8/3/24

to loyfilroze

I try to reproduce the issue but failed. Can you show the following images about this issue: the list of sub items under Application Development in Server Manager, the location of dll file, complete 404 error page, the binding of site and web.config.

I compiled a blank 64bit isapi dll and placed it in the same folder as the 32bit dll. Changed the Enable 32bit applications to false, and the 64bit dll works fine. When enable 32bit is true, the 64bit gives an error 500 as expected.

The AppWiz.dll file is a legacy dll file developed by my company, so it isn't a native Windows dll. It was developed in C++Builder 6. The file uses a SQL database to produce HTML pages based on the data and structure set up within the database, basically like what ASP.net would do, but completely custom logic.

Does this file involve your personal security information or your company's security information? Can you make a similar sample file (do not include any privacy information involving security content) and share it with me, I can use it to test. If you don't want share file, another method is you can create a support ticket from here. You will get remote support from Microsoft engineers without share files.

And the policy does not allow the use of third-party tools to obtain your files. Please go to the support ticket, Microsoft remote engineers will provide you with a tool to upload the dll file and solve your problem.

Thank you for all your assistance. Unfortunately I am unable to log a ticket using the Small Business support channel (seems to be the only way to log a Windows 2019 ticket) because I do not have a support subscription with Microsoft. Is there another way to log a ticket and receive the support I need?

Some required IIS components are NOT loading properly. e.g. (The Module DLL failed to load. The data is the error.). This can happen when that feature is not installed properly on the server.

Please check if system is referring failed to load DLL in "C:\Windows\System32\inetsrv\config\applicationHost.config" file. If yes, identify the associated Role/Service and install it on server. In this case "WebDAV Publishing" IIS Module. Please find below screen shot for your reference.

The DLL files are in my executable directory (libeay32.dll and ssleay32.dll). As far as I know, it is the correct version, though finding what OpenSSL version fits my installed Indy version does not seem easy and I may be wrong.

When that error happens, you can then call Indy's WhichFailedToLoad() function in the IdSSLOpenSSLHeaders unit to find out WHY it failed. Either the DLLs themselves could not be loaded into memory, or else they are missing exports that Indy requires.

I don't belive the DLLs were corrupted, but just in case I downloaded the latest versions of the DLLs (v1.0.2.21) and no more errors on my local Win10 machine, but the Win2019 server is still triggering the same exceptions.

I just had to do a windows 10 upgrade in place because my windows update was stuck in January and wouldn't update. Now I'm getting eidosslcouldnotloadssllibrary could not load ssl. I'm assuming the ssleay.dll and libeay.dll were in the windows directory and got deleted with the upgrade? I'm working on an android app that indy was working just fine in but now it goes poof! Where should the files reside on windows development system? i put the copies in the embarcadero programs folder (C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\subversion) into Windows\SysWOW and Windows\System32 but it doesn't help. Delphi 11.2

Nevermind! I told rad studio to ignore the error as it was spurious in the android environment and everything works just fine. Reinstall of windows must have erased my previous instruction to ignore the error. Thanks Remy for the heads up on .dll locations, I'll remove them from Windows\SysWOW and Windows\System32

OpenSSL website also links to Win32OpenSSL website providing another build of Win32 DLL binaries. Note note that unlike the builds above builds on that site may have dependencies on Visual C++ 2008 Redistributables (to keep dll files smaller) so make sure you include all the required (and correct) redistributable files in your software installation. You probably don't have to care about that if you use binaries above at the cost of slightly larger DLLs. Also note that site does not keep archives of older versions so you may want to watch their page if you prefer their binaries.

I just upgraded to Windows 10 from 7. Cool so far, but when I try to go to any of my applications the app pool crashes and I get a 503. I can restart the app pool but it continues to crash. So I checked the event log to see what was happening. I then got the error "The Module DLL C:\WINDOWS\system32\inetsrv\rewrite.dll failed to load". The problem most people had was that the dll was not there. However that is not my problem. Because it is there. After some googling I have not been able to find a solution. Can anyone please help me out? Accoding to my registry I am running IIS 10.0?

I had the same issue and reinstalling was not enough. Turns out my VM was way behind on windows update (probably a vanilla install without any updates...) and getting it up to then then reinstalling IIS URL Rewrite Module 2.0 fixed the issue.

FactoryTalk View SE exposes several REST endpoints on Microsoft IIS that are accessible remotely. One of these endpoints is at /rsviewse/hmi_isapi.dll, which is an ISAPI DLL handler that performs several actions that deal with FactoryTalk project management.

The ISAPI DLL was loaded and briefly analyzed in Ghidra to understand its basic functionality. However, this turned out to be unnecessary, as all the steps described in this advisory were discovered with a pure black-box penetration testing approach.

-- refers to the server running FactoryTalk View SE.
-- must be an existing project on the server.
-- can be any random string as the name implies,
-- is the IP address of the attacker's host.

The will then proceed to write to \_bak\, perform some actions on it (these actions were not determined since it did not matter for exploitation purposes), and finally delete . All of these actions all occur in less than a second.

Once the first vulnerability was identified, the next objective was to obtain remote code execution. At this point, the data in the file and the filename were completely controllable, but this did not mean it was possible to execute arbitrary code.

The easiest way to achieve RCE is to write a file with ASP or ASPX code to the IIS directory.This was easily achieved by abusing a directory traversal vulnerability in the provided in Snippet 3 (above). If responds as in Snippet 3 with set to:

The will then write (taken from Snippet 5) to \\SE\\HMI Projects\\shell.asp. Since this directory is configured as a virtual directory in IIS, the ASP file will be immediately executed once it is accessed.

As described previously, is only written and accessed for less than one second, and then immediately deleted. To be able to execute the ASP code, the file will need to be accessed as soon as it is written.

To achieve reliable exploitation, it is necessary to know and its path on the FactoryTalk View SE server. These steps are not necessary for a demonstration proof of concept, but a real, weaponized exploit would certainly need them. The provided Metasploit module does implement these steps.

I'm having difficulty getting the "Hello" example to work with IIS 7.5. I've followed the documentation at _on_Microsoft_IIS multiple times. I've used depends to verify that HttpExtensionProc, GetExtensionVersion, TerminateExtension are being exported by hello.wt.dll. I also have "Allow Unspecified ISAPI Modules" checked on the "Edit ASAPI and CGI Restrictions Settings" for the machine.

What's happening is that I can use my browser to navigate to the directory where the Hello.wt.dll exists, but when clicking on it, it simply wants to download Hello.wt.dll instead of executing it. I think the problem has something to do with "Handler Mappings" in the IIS configuration. Please see the attached image. Note that I do have "Read, Script, Execute" all checked in the "Edit Feature Permissions" settings for the machine. But I think the problem might be that there is nothing "ISAPI" related in the list of "Handler Mappings". Should something more be there? If so, what should it be?

Wim - Hi, thanks for the quick response! I've manually added this "ISAPI-dll" entry and am now getting a little farther in that it actually appears to try and use the Hello.wt.dll DLL in execution rather than just download the file, however, it's not yet fully working. A few questions:

Thanks Wim for the DLL. However, despite another few hours of tinkering, it's still not working. Specifically, I think it must have something to do with the Module Mapping for the Isapi Handler. In a previous post you said this:

However, IIS Manager is not allowing me to do this. Please see the attached screenshot. Despite it saying that the executable field is optional it insists I should have one. It won't allow me to leave the executable field empty and still create a module mapping. Any ideas?

Wim - Hi, I'm still stuck on this. A quick question: Can you provide the web.config file for when you successfully tested this hello world isapi dll? It should be in the same directory you have your hello world DLL in. I'd like to compare it to what I have.