Application unable to retrieve redirect data after WFP Connect Redirect with nmap or wireshark.

Application unable to retrieve redirect data after WFP Connect Redirect with nmap or wireshark.
The issue occurs when npcap is configured by nmap or wireshark data.

WFP Connect Redirect “SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT” fails to retrieve redirect data when using nmap or wireshark with npcap loopback

Steps to Reproduce using MS WFP Sampler

Get a copy of Windows Driver Kit (WDK) 8.1 Samples
https://code.msdn.microsoft.com/windowsapps/Windows-Driver-Kit-WDK-81-cf35e953/view/SourceCode
Make sure the 8.1 DDK is installed on the machine
Compile the Windows Filtering Platform Sample
Create a program "testprogram.exe"
a. Listens to 127.0.0.1:4443
b. Upon connect accept
status = WSAIoctl(originalSocket,
SIO_QUERY_WFP_CONNECTION_REDIRECT_CONTEXT,
0,
0,
(BYTE*)ppRedirectContext,
REDIRECT_CONTEXT_SIZE,
(LPDWORD)&redirectContextSize,
0,
0);
if(status != NO_ERROR)
{
status = WSAGetLastError();
print the "status
}
else
{
print the redirectContext data //you will see the IP address the browser attempts to go to.
}
Download nmap and make sure it is using npcap loopback driver
On your test system install the WFP Sample driver following the steps in
the "description.html" in the Windows Filtering Platform Sample directory.
Start your testprogram.exe, get pid of the "testprogram.exe" from task manager.
Configure the WFP Sampler to redirect to your Proxy Program.

WFPSampler.Exe -s PROXY -l FWPM_LAYER_ALE_CONNECT_REDIRECT_V4 -p TCP -pra 127.0.0.1 -prp 4443 -v -plspid
Run nmap -sV 3128 localhost

Open chrome browser and go to an address 10.10.10.1:520 for example

Expectation:
The testprogram should not receive and error and be able to retrieve redirectContext data.

Actual:
The testprogram receives an error that an invalid arguement error.

Note:
If you do net stop npcap the testprogram will retrieve the redirectContext with out error and the IP Address used in the browser will
be in the redirectContext data

Thanks for this detailed bug report! I admit I don't yet know much about the WFP loopback capture mechanism of Npcap, so it will take a lot of research to bring me up to speed. In the meantime, could you try turning on Windows Driver Verifier with standard settings for npcap.sys as well as the WFP sample driver and re-running your test? This will do introduce some further checks and may produce a BSoD crash dump that we can analyze.

Thanks Daniel, here are the Verifier results

wfp8.1>verifier /query

Time Stamp: 04/01/2019 11:36:30.359

Verifier Flags: 0x000209bb

Standard Flags:

[X] 0x00000001 Special pool.
[X] 0x00000002 Force IRQL checking.
[X] 0x00000008 Pool tracking.
[X] 0x00000010 I/O verification.
[X] 0x00000020 Deadlock detection.
[X] 0x00000080 DMA checking.
[X] 0x00000100 Security checks.
[X] 0x00000800 Miscellaneous checks.
[X] 0x00020000 DDI compliance checking.

Additional Flags:

[ ] 0x00000004 Randomized low resources simulation.
[ ] 0x00000200 Force pending I/O requests.
[ ] 0x00000400 IRP logging.
[ ] 0x00002000 Invariant MDL checking for stack.
[ ] 0x00004000 Invariant MDL checking for driver.
[ ] 0x00008000 Power framework delay fuzzing.
[ ] 0x00010000 Port/miniport interface checking.
[ ] 0x00040000 Systematic low resources simulation.
[ ] 0x00080000 DDI compliance checking (additional).
[ ] 0x00200000 NDIS/WIFI verification.
[ ] 0x00800000 Kernel synchronization delay fuzzing.
[ ] 0x01000000 VM switch verification.
[ ] 0x02000000 Code integrity checks.

[X] Indicates flag is enabled.

Verifier Statistics Summary

Raise IRQLs:                                     0
Acquire Spin Locks:                              0
Synchronize Executions:                          0
Trims:                                         929

Pool Allocations Attempted:                 747430
Pool Allocations Succeeded:                 747430
Pool Allocations Succeeded SpecialPool:     747430
Pool Allocations With No Tag:                    0
Pool Allocations Not Tracked:               742739
Pool Allocations Failed:                         0
Pool Allocations Failed Deliberately:            0

Driver Verification List

MODULE: wfpsamplercalloutdriver.sys (load: 1 / unload: 0)

  Pool Allocation Statistics: ( NonPaged / Paged )

    Current Pool Allocations:  (     2396 /        0 )
    Current Pool Bytes:        (   606368 /        0 )
    Peak Pool Allocations:     (     2399 /        0 )
    Peak Pool Bytes:           (   606760 /        0 )
    Contiguous Memory Bytes:              0
    Peak Contiguous Memory Bytes:         0

MODULE: npcap.sys (load: 1 / unload: 0)

  Pool Allocation Statistics: ( NonPaged / Paged )

    Current Pool Allocations:  (       26 /        0 )
    Current Pool Bytes:        (   241926 /        0 )
    Peak Pool Allocations:     (       35 /        2 )
    Peak Pool Bytes:           (  1879994 /      236 )
    Contiguous Memory Bytes:              0
    Peak Contiguous Memory Bytes:         0

Thanks for the update. It looks like none of the default checks produced a crash. You could add additional check flags, but we will also be doing more research and manual review to see if we can identify the problem.

Please let me know what additional checks will help you solve this.

Thanks
Keith

Hi Daniel,

In order to solve this problem the nmap needs to be modified to inject the packet back into the network.

Here is information that explains how NMap is interfering with the packet passing.

The issue with npcap is that they have WFP classify in FWPS_LAYER_INBOUND_IPPACKET_V4 layer which when simplified does something like below:

   // Make the default action.
   if (classifyOut->rights & FWPS_RIGHT_ACTION_WRITE)
          classifyOut->actionType = FWP_ACTION_CONTINUE;

……

status = FwpsAllocateCloneNetBufferList(pNetBufferList, NULL, NULL, 0, &pClonedNetBufferList);
….. // No injection here., but some packet manipulations.
FwpsFreeCloneNetBufferList(pClonedNetBufferList, 0);
…
return;
So basically it does a clone and free of the NBL without doing any packet injection and then returns the original NBL back from the classify. The clone operation removes the NBL tag from original NBL and transfers it to cloneNBL. When cloneNBL is free’ed this info is lost and hence the receiving end doesn’t see the nbl with the tag and redirect record ends up being NULL.

Upon discussion with the WFP product group when you clone nbl from a classify the expectation is that you block the original NBL and inject the cloned NBL, so the tag is transferred to the clone NBL which is by design. So for the nmap issue this needs to be reported to the nmap team to fix the driver. If they can provide a valid reason for why they need to do this (we can’t think of any reason) the product team is willing to re-visit this.

Can we get a fix for this issue in the next version of nmap?
Thanks,
Keith

Is there an update for this?

We too are being impacted and are awaiting this to be resolved.

Just a quick update:
I talked with Microsoft WFP Product Group further after trying to implement the advice given earlier.

Here is what Microsoft stated:

If you are going to do injection, depending upon the traffic direction you should be calling Receive (inbound) or Send(outbound)
The problem is in the receive path, so your send injection call is not going to help here.

Btw, the right solution here is to not clone or inject and just pass the original NBL.
If you are recommending a fix to the npcap vendor that should the right solution to suggest to them.
There is no good reason to clone and inject in this scenario here.

Or ask them to contact Microsoft with their scenario so we can recommend the best/optimal solution.

This is affecting us big time.
Thanks,
Keith

Thanks for the very detailed info on how to go about fixing this! I will look into it and see if it's something we can get done for the next Npcap release.

Inject cloned NBLs and drop the originals. See nmap/nmap#1529

We believe this issue has been addressed in Npcap 0.9982. Please let us know if it passes your tests.

Hi Daniel,

I tried this version .9982 and it does not fix the issue.

I tried to edit the loopback as you did (by injecting the clone) in the following lines

npcap/packetWin7/npf/npf/Loopback.c

Line 622 in b009a6c

    
           status = FwpsInjectNetworkSendAsync(bInnerIPv4 ? g_InjectionHandle_IPv4 : g_InjectionHandle_IPv6,

It did not work for me either.

I talked to Microsoft about it not working.
This is where the update I gave in my comment
https://github.com/nmap/nmap/issues/1529#issuecomment-515483440

Is it possible for you to contact Microsoft, they seem to have a better way to deal with this.

Thanks,
Keith

@keithdg

@keithdg Thanks for the update. Yes, if you look just above there at line 607, I have some dead code to use a different injection function based on the direction (inbound vs outbound) the NBL was coming. When I added it, there were other bugs preventing it from working, so I guarded it out (#ifdef 0), and did not re-enable it once our functional tests passed. We will try something like this for the next release. It's possible that both of the issues (not sending the clone and using the wrong injection function) were contributing to the symptoms you are seeing.

Inject inbound NBLs to the receive stack, not send stack. See nmap/nm…

We just released Npcap 0.9983 today, which includes the change above. Please let us know how this works for you.

0.9983 does not fix this issue for me.
What's worse is I can no longer unselect the loopback adapter to get things working. I am also unable to downgrade to a version that works as network adapter no longer show up.

This affects us as well. I tried 0.9983 and it does not resolve the issue.

We have seen this on a recent deployment of Windows-10 Build 1909 using npcap for a card payment application. From the dates of this thread it looks like possibly Windows-10 Build 1903 is also affected. We do not have the issue on build 1803 or 1809, or Windows-7. Win10Pcap is not supported by the vendor.

We made an extensive change to the classifyFn of Npcap which removed the clone/block/inject operation entirely for all packets except those injected by Npcap itself, which require modification to strip an extra header off. This means that Npcap should no longer be modifying any NBLs that pass through it, allowing all metadata to proceed as usual.

Please let us know how the latest Npcap 0.9988 works for you: https://npcap.org/#download

It looks like 0.9988 fixes the issue for us. Thanks!

.9988 working for me too with Wireshark and NMAP/Zenmap.

Fixed in Npcap 0.9988.

Navigation Menu

Repository navigation

Application unable to retrieve redirect data after WFP Connect Redirect with nmap or wireshark. #363

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Application unable to retrieve redirect data after WFP Connect Redirect with nmap or wireshark. #363

Description

Activity

dmiller-nmap commented on Mar 28, 2019

keithdg commented on Apr 1, 2019

dmiller-nmap commented on Apr 1, 2019

keithdg commented on Apr 1, 2019

keithdg commented on Jun 10, 2019

CBRBrad commented on Jul 26, 2019

keithdg commented on Jul 26, 2019

dmiller-nmap commented on Jul 29, 2019

dmiller-nmap commented on Aug 1, 2019

keithdg commented on Aug 1, 2019

dmiller-nmap commented on Aug 1, 2019

dmiller-nmap commented on Sep 4, 2019

timedroid commented on Sep 9, 2019

philipatl commented on Sep 30, 2019

Bill-Healthfirst commented on Feb 25, 2020

dmiller-nmap commented on Mar 5, 2020

philipatl commented on Mar 5, 2020

hiddenicon commented on Mar 5, 2020

dmiller-nmap commented on May 6, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions