Forum Replies Created
-
Posts
-
You can do about anything if the malware includes kernel-mode component. The majority of users are usually logged on as user with Administrator rights which has the priviledge to install and load drivers. So there is no actual problem for the malware to install such a component (it can be even the primary component of the malware).
Since such kernel-mode component can bypass firewall by many different ways, such as:
1) Execution in the context of priviledged process (even simply create thread in the context of System process),.
2) Blocking/cheating firewall components.
3) Using it’s own protocol module and working with network directly.
4) Working with TCPIP.SYS devices directly bypassing any possible upper level TDI filters.
5) and so on…I am very curious how does popular personal firewall like ZoneAlarm work. When they discover outgoing packets, how do they know what program is sending them?
Usually they utilize NDIS level filter and TDI one.
Do all such firewalls work similarily?
From the general point of view the answer is YES, but concrete realization and set of features can be very different.
I was thinking if any malware application could fake returned command line so the firewall would think it’s the other process. Is it possible?
Yes, this is possible.
Hmm, it is difficult to say what actually happens because I don’t know how you’ve created the code for the DLL. The original sample (console application) had not such problems, so probably it is somehow relative to moving the code into the DLL…
Uninstall process should remove all NeT Firewall components; however I don’t exclude the collision. Please check the registry key below, if it exists then just remove it and reboot (this is kernel component registry key). If it is not then probably your problems are caused by something else.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesipfrwl
Hope it helps…
P.S. I would be gratefull if you could explain the problems you’d expirienced with NeT Firewall.
Hi,
I have it running on the web server (Windows Server 2003 Web Edition) for about 3 months (up to this day) without reboot. So probably it should fit your requirements…
Etherbridge is an expiremental driver and it was not updated for a long time. In some configurations it works, but in others don’t. In your case driver looks to overload system with packets duplications…
There is no proof and easy way to get full process path. This topic was discussed (in russian) in Windows Internals forum. Two ways were proposed (first is easier but second is more reliable):
I)
ZwQueryInformationProcess ( NtCurrentProcess(), ProcessBasicInformation, &ProcInfo, sizeof(ProcInfo), 0);ProcInfo.PebBaseAddress->ProcessParameters->ApplicationName
II)
1. Get EPROCESS using IoGetCurrentProcess().
2. For NT 4.0 and 5.0 get SectionHandle using ObReferenceObjectByHandle() get SectionObject; for NT 5.1 just get SectionObject from EPROCESS.
3. From SectionObject get SegmentObject.
4. From SegmentObject get ControlArea.
5. From ControlArea get FilePointer (FileObjec pointert).
6. Using ObQueryNameString() get full path for the process.This value is filled using KeQuerySystemTime (equal to user-mode NtQuerySystemTime). Here is the short description:
“System time is a count of 100-nanosecond intervals since January 1, 1601. System time is typically updated approximately every ten milliseconds. This value is computed for the GMT time zone.” (Windows DDK help)
In order to convert the m_SystemTime to SYSTEMTIME structure do the following:
1) Copy m_SystemTime to FILETIME structure (don’t use simple typecast, because alignment can be different).
2) Call FileTimeToSystemTime.If you control DeviceTcp, DeviceUdp, DeviceIp, DeviceRawIp and DeviceMULTICAST then you have complete control over application’s (IE, ICQ, Outlook and etc…) access to the MS TCP/IP network stack. Under control I mean ability to block any network activity (create socket, listen port, connect remote host and et…). Is that your question?
But this does not mean that you control all network activity of the system, because it may have another network protocols installed (IPv6 an example). But even without installing additional protocols, control over TDI is not the same as control over network. If you try to block the network with your TDI filter then MS TCP/IP still continue packet routing, it still replies ICMP ping, network file and folder sharing still works and etc… This is because mentioned network activities never reach TDI level.
I hope I’ve answered your question…
I don’t understand what actually you mean under “control control the network of the system”. Please clarify if you need the correct answer…
I have not code for WinpkFilter, but the routines below demonstrate how I did it in Ethernet Bridge. Doing this using WinpkFilter is very similar. Please note, that you should also set NDIS flags NDIS_FLAGS_SKIP_LOOPBACK | NDIS_FLAGS_DONT_LOOPBACK before sending the packet over the network in order to avoid it to indicated back (in the code below it is done inside UF_SendPacketToAdapter but I did not provided it).
VOID FLT_FilterReceivedPacket (
NDIS_HANDLE NdisBindingHandle,
PINTERMEDIATE_BUFFER pBuffer
)
{
// Processing relative declarations
PUSHORT pEtherType;
//Adapter and protocol relative structures
PPROTOCOL_ENTRY pProto;
PADAPTER_ENTRY pAdapter, pReceivedAdapter;
DbgPrint ( "FLT_FilterReceivedPacket pBuffer->m_Lengh = %d...n", pBuffer->m_Length );
// DbgPrint ( "FLT_FilterReceivedPacket entered...n" );
// .... process packet here....
// We dump packet content here
//DbgPrint ("nRCV:n");
//DbgPrint ("MACS: DEST %.2X%.2X%.2X%.2X%.2X%.2X SOURCE: %.2X%.2X%.2X%.2X%.2X%.2Xn",
// pBuffer->m_IBuffer[0],
// pBuffer->m_IBuffer[1],
// pBuffer->m_IBuffer[2],
// pBuffer->m_IBuffer[3],
// pBuffer->m_IBuffer[4],
// pBuffer->m_IBuffer[5],
// pBuffer->m_IBuffer[6],
// pBuffer->m_IBuffer[7],
// pBuffer->m_IBuffer[8],
// pBuffer->m_IBuffer[9],
// pBuffer->m_IBuffer[10],
// pBuffer->m_IBuffer[11]
// );
pEtherType = (PUSHORT) pBuffer->m_IBuffer;
pEtherType += ETH_LENGTH_OF_ADDRESS;
/* switch( htons( *pEtherType ) )
{
case ETHERTYPE_IP:
DbgPrint ("IP packet: ");
ipHdr = ( PIP_HEADER ) &pBuffer->m_IBuffer[MHdrSize];
DbgPrint ( " %u.%u.%u.%u ---> %u.%u.%u.%un",
(ipHdr->ip_src.S_un.S_un_b.s_b1),
(ipHdr->ip_src.S_un.S_un_b.s_b2),
(ipHdr->ip_src.S_un.S_un_b.s_b3),
(ipHdr->ip_src.S_un.S_un_b.s_b4),
(ipHdr->ip_dst.S_un.S_un_b.s_b1),
(ipHdr->ip_dst.S_un.S_un_b.s_b2),
(ipHdr->ip_dst.S_un.S_un_b.s_b3),
(ipHdr->ip_dst.S_un.S_un_b.s_b4)
);
break;
case ETHERTYPE_ARP:
DbgPrint ("ARP packet:");
arpPkt = ( PARP_PACKET ) pBuffer->m_IBuffer;
DbgPrint ( " %u.%u.%u.%u ---> %u.%u.%u.%u ?n",
(arpPkt->ea.arp_spa[0]),
(arpPkt->ea.arp_spa[1]),
(arpPkt->ea.arp_spa[2]),
(arpPkt->ea.arp_spa[3]),
(arpPkt->ea.arp_tpa[0]),
(arpPkt->ea.arp_tpa[1]),
(arpPkt->ea.arp_tpa[2]),
(arpPkt->ea.arp_tpa[3])
);
break;
case ETHERTYPE_REVARP:
DbgPrint ("REVARP packet:n");
break;
default:
DbgPrint ("Uknown type n");
}*/
// Simply indicate packet to protocol
UF_SendPacketToProtocol (
NdisBindingHandle,
pBuffer->m_IBuffer,
pBuffer->m_Length
);
// Send packet to all other network interfaces if bridging enabled
if ( g_BridgingStatus )
{
// Locate adapter and protocol entryes associated with operation
pReceivedAdapter = MF_FindAdapterByBindingHandle( NdisBindingHandle, &pProto);
pAdapter = ( PADAPTER_ENTRY ) pProto -> m_AdaptersList.Flink;
// Walk the list of binded adapters
while ( pAdapter != ( PADAPTER_ENTRY ) &pProto -> m_AdaptersList )
{
if ( pAdapter != pReceivedAdapter)
{
// Packet was receved not from this adapter
// Simply send packet onto this interface
// DbgPrint ("Duplicating packet on the another interface...n");
if (osMajorVersion == 5 && osMinorVersion > 0)
UF_SendPacketToAdapter ( &pAdapter->m_XPOpenBlock, pBuffer );
else
UF_SendPacketToAdapter ( &pAdapter->m_W2kOpenBlock, pBuffer );
// Also indicate packet to TCPIP from the name of this interface
if (osMajorVersion == 5 && osMinorVersion > 0)
UF_SendPacketToProtocol (
&pAdapter->m_XPOpenBlock,
pBuffer->m_IBuffer,
pBuffer->m_Length
);
else
UF_SendPacketToProtocol (
&pAdapter->m_W2kOpenBlock,
pBuffer->m_IBuffer,
pBuffer->m_Length
);
}
pAdapter = (PADAPTER_ENTRY) pAdapter->m_qLink.Flink;
}
}
// Free intermediate buffer
IB_FreeIntermediateBuffer ( pBuffer );
}
//***********************************************************************************
// Name: FLT_FilterSendPacket
//
// Description: Routine for filtering outgoing packets, place packet processing code
// here
//
// Return value: None
//
// Parameters:
// NdisBindingHandle - network interface binding handle
// pBuffer - pointer to intermediate buffer
//
// NOTE: None
// **********************************************************************************
VOID FLT_FilterSendPacket (
NDIS_HANDLE NdisBindingHandle,
PINTERMEDIATE_BUFFER pBuffer
)
{
// Processing relative declarations
PUSHORT pEtherType;
//Adapter and protocol relative structures
PPROTOCOL_ENTRY pProto;
PADAPTER_ENTRY pAdapter, pSentAdapter;
DbgPrint ( "FLT_FilterSendPacket pBuffer->m_Lengh = %d...n", pBuffer->m_Length );
// DbgPrint ( "FLT_FilterSendPacket entered...n" );
// .... process packet here....
// We dump packet content here
// DbgPrint ("nSEND:n");
// DbgPrint ("MACS: DEST %.2X%.2X%.2X%.2X%.2X%.2X SOURCE: %.2X%.2X%.2X%.2X%.2X%.2Xn",
// pBuffer->m_IBuffer[0],
// pBuffer->m_IBuffer[1],
// pBuffer->m_IBuffer[2],
// pBuffer->m_IBuffer[3],
// pBuffer->m_IBuffer[4],
// pBuffer->m_IBuffer[5],
// pBuffer->m_IBuffer[6],
// pBuffer->m_IBuffer[7],
// pBuffer->m_IBuffer[8],
// pBuffer->m_IBuffer[9],
// pBuffer->m_IBuffer[10],
// pBuffer->m_IBuffer[11]
// );
pEtherType = (PUSHORT) pBuffer->m_IBuffer;
pEtherType += ETH_LENGTH_OF_ADDRESS;
/* switch( htons( *pEtherType ) )
{
case ETHERTYPE_IP:
DbgPrint ("IP packet: ");
ipHdr = ( PIP_HEADER ) &pBuffer->m_IBuffer[MHdrSize];
DbgPrint ( " %u.%u.%u.%u ---> %u.%u.%u.%un",
(ipHdr->ip_src.S_un.S_un_b.s_b1),
(ipHdr->ip_src.S_un.S_un_b.s_b2),
(ipHdr->ip_src.S_un.S_un_b.s_b3),
(ipHdr->ip_src.S_un.S_un_b.s_b4),
(ipHdr->ip_dst.S_un.S_un_b.s_b1),
(ipHdr->ip_dst.S_un.S_un_b.s_b2),
(ipHdr->ip_dst.S_un.S_un_b.s_b3),
(ipHdr->ip_dst.S_un.S_un_b.s_b4)
);
break;
case ETHERTYPE_ARP:
DbgPrint ("ARP packet:");
arpPkt = ( PARP_PACKET ) pBuffer->m_IBuffer;
DbgPrint ( " %u.%u.%u.%u ---> %u.%u.%u.%u ?n",
(arpPkt->ea.arp_spa[0]),
(arpPkt->ea.arp_spa[1]),
(arpPkt->ea.arp_spa[2]),
(arpPkt->ea.arp_spa[3]),
(arpPkt->ea.arp_tpa[0]),
(arpPkt->ea.arp_tpa[1]),
(arpPkt->ea.arp_tpa[2]),
(arpPkt->ea.arp_tpa[3])
);
break;
case ETHERTYPE_REVARP:
DbgPrint ("REVARP packet:n");
break;
default:
DbgPrint ("Uknown type n");
}*/
// Simply send packet onto network
UF_SendPacketToAdapter (
NdisBindingHandle,
pBuffer
);
// Send packet to all other network interfaces if bridging enabled
if ( g_BridgingStatus )
{
// Locate adapter and protocol entryes associated with operation
pSentAdapter = MF_FindAdapterByBindingHandle( NdisBindingHandle, &pProto);
pAdapter = ( PADAPTER_ENTRY ) pProto -> m_AdaptersList.Flink;
// Walk the list of binded adapters
while ( pAdapter != ( PADAPTER_ENTRY ) &pProto -> m_AdaptersList )
{
if ( pAdapter != pSentAdapter)
{
// Packet was sent not to this adapter
// Simply send packet onto this interface
// DbgPrint ("Duplicating packet on the another interface...n");
if (osMajorVersion == 5 && osMinorVersion > 0)
UF_SendPacketToAdapter (
&pAdapter->m_XPOpenBlock,
pBuffer
);
else
UF_SendPacketToAdapter (
&pAdapter->m_W2kOpenBlock,
pBuffer
);
}
pAdapter = (PADAPTER_ENTRY) pAdapter->m_qLink.Flink;
}
}
// Free intermediate buffer
IB_FreeIntermediateBuffer ( pBuffer );
}The code above do the following:
1) Release event for packet indication.
2) Set adapter into passthru mode (the state it was before you set TUNNEL mode).
3) Flush packet queue associated with the adapter.For temporary stop filtering: 1 – is not necessary, 2 – should be be done, otherwise (if you exited the loop) the network will be forzen after all WinpkFilter internal buffers are used, 3 – should be done because if you have existed packet reading loop, to that moment you can have internal buffer pool exosted and the network frozen.
So, in addition to exiting the loop you should set the default mode over the interface and flush its packet queue. If you want to restore filtering, then set tunnel mode and enter the loop again.
Please pay attention to the routine below (it is available in PassThru and PacketSniffer samples), which actually stops WinpkFillter operations over the network interface and releases resources:
void ReleaseInterface()
{
// This function releases packets in the adapter queue and stops listening the interface
ADAPTER_MODE Mode;
Mode.dwFlags = 0;
Mode.hAdapterHandle = (HANDLE)AdList.m_nAdapterHandle[iIndex];
// Set NULL event to release previously set event object
api.SetPacketEvent(AdList.m_nAdapterHandle[iIndex], NULL);
// Close Event
if (hEvent)
CloseHandle ( hEvent );
// Set default adapter mode
api.SetAdapterMode(&Mode);
// Empty adapter packets queue
api.FlushAdapterPacketQueue (AdList.m_nAdapterHandle[iIndex]);
}1) First issue with direct NDIS_OPEN_BLOCK modification works just like you have described. The only fix is hooking internal NDIS-routines and repatching the NDIS_OPEN_BLOCK each time when handlers are changed,
2) The second approach with substitution on NDIS_OPEN_BLOCK works fine, and in your case problem is somethere else, lines you have provided look OK.
In general NDIS hooking driver is relatively complicated and it is difficult to design such a driver from the scratch. So I would recommend to use one of the documented approaches (intermediate, filter hook or etc…) or license ready NDIS hooking solution instead of trying to create the new one.
