Re: nmap potentially vulnerable to Windows DLL Hijacking

[David Fifield <david () bamsoftware com>]

On Tue, Aug 31, 2010 at 09:21:17PM +0100, Rob Nicholls wrote:
> On Wed, 1 Sep 2010 00:40:13 +0530 (IST), Nikhil Mittal
> <nikhil_uitrgpv () yahoo co in> wrote:
> > I was just checking nmap 5.21 for Windows DLL hijacking and it seems
> > that nmap is searching for airpcap.dll in "insufficient qualified
> > path". If I force nmap to open a file from a network share it do try
> > to load dll from that share, it means it is vulnerable? correct me if
> > wrong. I am unable to exploit the vulnerability because while
> > accessing airpcap.dll from network share I can see FAST IO Disallowed
> > in procmon. I have no idea that whether this is something deliberately
> > done for some reason for nmap. To sum up: It seems that nmap latest is
> > vulnerable to Windows DLL Hijacking flaw.
>
> This is presumably similar to the Wireshark issue:
>
> http://www.exploit-db.com/exploits/14721/
> http://www.nessus.org/plugins/index.php?view=single&id=48943
>
> I must admit I was surprised to hear that Nmap tries to load this file
> as it's not one that's usually distributed with WinPcap (it's related to
> AirPcap, a separate project from CACE Technologies). I presume we can do
> something in Nmap to fix/workaround this issue (perhaps copy whatever
> the Wireshark developers have done in 1.2.11?).

The vulnerability doesn't affect Nmap by default because Nmap does not
register any file name extensions for itself. You are right, though,
that airpcap.dll is insufficiently qualified and is being searched for
in the current directory, among other places. I verified this using
procmon.exe and the instructions at
http://msdn.microsoft.com/en-us/library/ff919712(VS.85).aspx
("Dynamic-Link Library Security").

If you manually create a file name extension association, the
vulnerability does affect Nmap with airpcap.dll. I checked this using
the great test tool from
http://blog.metasploit.com/2010/08/better-faster-stronger.html. I
followed these steps:

Create a file name extension association by opening My Computer, Tools,
Folder Options, File Types, and clicking New. I chose the extension
"NMP". Click Advanced, then New, and enter "open" for Action. For
"Application used to perform action", enter

"C:\Program Files\Nmap\nmap.exe" -iL "%1"

In the DLLHijackAuditKit directory, delete DLLAudit if it exists (if you
have run the tool before), then make this change to audit.js to save
time:

--- audit.js.orig       2010-09-03 16:52:49.000000000 -0700
+++ audit.js    2010-09-03 16:53:05.000000000 -0700
@@ -41,3 +41,4 @@
 var oOutParam = oReg.ExecMethod_(oMethod.Name, oInParam);
-var aNames = oOutParam.sNames.toArray();
+// var aNames = oOutParam.sNames.toArray();
+var aNames = [ ".nmp" ];

Run 01_StartAudit.bat and save Logfile.CSV as instructed. Run
02_Analyze.bat, and you will see

[*] Successfully exploited nmap.exe with .nmp using airpcap.dll.

Then if you enter DLLHijackAuditKit/nmap.exe_nmp_airpcap.dll and
double-click exploit.nmp, you will see a calculator appear. Don't forget
to remove the file name extension association when you are done.

I repeated the test with zenmap.exe and it can be exploited with
intl.dll, part of GTK+. This is also not a vulnerability by default
because Zenmap doesn't create file name extension associations either.

In trying to fix this I was guided strongly by
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5133. Their approach
was to remove the current directory from the DLL search path using a
function that is only available in XP SP1 or later, and on earlier
systems to change the current directory to the directory containing the
executable instead of whatever directory contains the file to be opened
(the NMP file in our case). This is what I've committed for Nmap and
Nping in r20083.

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5133#c5
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5133#c18
svn diff -c 33915:33917 http://anonsvn.wireshark.org/wireshark/trunk
svn diff -c 33958 http://anonsvn.wireshark.org/wireshark/trunk

As far as I can tell, we don't call LoadLibrary directly. It happens
indirectly through a call to __HrLoadAllImportsForDll("wpcap.dll") in
winfix.cc. The change above appears to be enough to stop WinPcap from
trying to load airpcap.dll from the current directory.

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5133#c20 alludes to
the possibility of another library like WinPcap calling LoadLibrary in
an unsafe way, despite this new protection. I guess this has to be
solved in each third-party library, and it sounds like it is already in
progress for WinPcap.

I would appreciate independent confirmation that this fixes the problem
(i.e., makes the calculator not pop up when following the instructions
above), especially on Windows XP with no service pack.

I haven't yet solved the issue with zenmap.exe and intl.dll. This file
exists in the installation directory but it's not being found because
it's in the py2exe subdirectory.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/