关于个人防火墙的真相
原文作者:MaD?
原文標(biāo)題:The truth aboutpersonal firewalls
電子郵件:mad-factor@mail.ru
作者國籍:俄羅斯
聲明:1、本人翻譯水平有限,有不當(dāng)之請大家理解。如部分看不懂可以和原文對照。
??? ???? ?? 2、歡迎轉(zhuǎn)載,但請不要漏掉原文作者和翻譯者的信息。
??? ???? ?? 3、歡迎大家指出我翻譯中的錯(cuò)誤,我好改正。
內(nèi)容:
??? ????有多種方式來保護(hù)你的計(jì)算機(jī)免受惡意軟件的侵害,比如軟件防火墻,病毒和Rootkit檢 測軟件等。所有這些防護(hù)軟件都基于一些眾所周知而幾乎沒有改進(jìn)的技術(shù),而且這些技術(shù)你也許已經(jīng)知道,繼承這些技術(shù)的安全產(chǎn)品也是不完善的。這樣的后果通常 是可怕的。然而這些安全公司卻天真的認(rèn)為他們的產(chǎn)品是最先進(jìn)的,包含了最新的特性,是用戶必備的。但是只要你透過他們的華麗的外衣就會看到,他們的Bug和錯(cuò)誤甚至比你在學(xué)校的設(shè)計(jì)還要多。雖說生產(chǎn)一款產(chǎn)品首要的是好而強(qiáng)有力的廣告。但沉重的廣告和糟糕的測試結(jié)合在一起能向用戶展示一些產(chǎn)品所謂的強(qiáng)大嗎,能使其產(chǎn)生一種強(qiáng)烈的購買欲望嗎?當(dāng)然不行。
??? ????保護(hù)你的個(gè)人電腦免受外部的和內(nèi)部的第三者的攻擊是一個(gè)好主意。一些保護(hù)你的PC遠(yuǎn)離木馬和間諜軟件“啟發(fā)式”的方法好像真在工作。如果他們工作的話,付30到50美元就能獲得實(shí)時(shí)的保護(hù)和更新的確是個(gè)非常好的想法??上?#xff0c;他們不能。
??? ????首先我想為我糟糕的英語道歉。我們的討論將會涉及以下產(chǎn)品:
??? ?????? ZoneAlarm Firewall 6.x
??? ?????? Outpost Firewall 3.x and 4.x
?? ?? ???? Look'n'Stop Firewall 2.0
??? ?????? Kerio Firewall 4.3
??? ?????? Sygate Firewall 5.6
??? ?????? Jetico Firewall 1.0
??? ?????? PortsLock Firewall 1.9
?? ?? ???? Tiny Firewall 6.5
??? ?????? Norton Internet Security 8.0
??? ?????? Comodo Firewall 2.4
??? ?????? OnlineArmor Firewall 2.1
??? ????個(gè)人軟件防火墻的保護(hù)有2種基本級別:NDIS(網(wǎng)絡(luò)驅(qū)動(dòng)接口規(guī)范)和TDI(傳輸數(shù)據(jù)接口)。NDIS級是建立在TCP/IP棧的基礎(chǔ)上的,在這個(gè)級別上的保護(hù)能阻止基于TCP/IP棧BUG的攻擊,甚至你不用更新你的棧;他也能防御許多電子欺騙,洪水攻擊和分布式拒絕服務(wù)攻擊。沒有使用NDIS技術(shù)的防火墻自然變成了局外人。失敗者有PortsLock防火墻, Norton Internet Security, Comodo防火墻?等。你真的愿意為PortsLock防火墻付35歐元嗎,他甚至不能抵御低級別的TCP/IP攻擊。或者為Comodo付79美元?為你的系統(tǒng)感到悲哀。真正的防火墻是基于NDIS級的。基于NDIS有兩種不同的保護(hù)方法。第一種是NDIS-hooking保護(hù)。主要方法是HooksNdisRegisterProtocol()/NdisOpenAdapter()。當(dāng)NDIS協(xié)議試圖被注冊時(shí)或是正要綁定某個(gè)適配器時(shí),防火墻將接到通知。在防火墻正在HOOK NDIS_PROTOCOL_BLOCK andNDIS_OPEN_BLOCK的句柄的這個(gè)關(guān)鍵時(shí)刻,并且當(dāng)系統(tǒng)想要發(fā)送或接收數(shù)據(jù)包時(shí),防火墻將會被通知當(dāng)這些發(fā)生的時(shí)候。防火墻正試圖安裝他們的鉤子時(shí)是有趣的時(shí)候,幾乎每個(gè)防火墻都是hook NDIS_PROTOCOL_BLOCK的句柄,但是Sygate, Kerio?和Jetico等除外,他們是HOOK NDIS_PROTOCOL_CHARACTERISTICS的句柄,而不是調(diào)用真正的NdisRegisterProtocol(),在那之后他們又移動(dòng)到原來的句柄。更安全嗎?對嗎?正是,防火墻應(yīng)該獨(dú)立工作,與多少協(xié)議被注冊和多少被綁定無關(guān)。是的,每個(gè)防火墻都支持這個(gè)。例如,當(dāng)ZoneAlarm正在hook一個(gè)句柄時(shí),他是分配一個(gè)無分頁的內(nèi)存并且放入以下幾條指令。
pop????????eax????????;?58
push????????HookData????;?68?XX?XX?XX?XX
push????????eax????????;?50
jmp????????HookedHandler????;?E9?XX?XX?XX?XX
??? ????然后,他寫一些重要的信息在其他內(nèi)存片,調(diào)用HookData和所有在NDIS_PROTOCOL_BLOCK中被hook的句柄:
??? ???
OpenAdapterCompleteHandler
CloseAdapterCompleteHandler
BindAdapterHandler
UnbindAdapterHandler
??? ????在NDIS_OPEN_BLOCK中的:
??? ???
??? SendHandler
??? ReceiveHandler
??? ReceivePacketHandler
??? SendPacketsHandler
??? ????對NDIS_PROTOCOL_BLOCK象下面這樣:
??? ???
??? VOID HookedOpenAdapterComplete(
??? ???PVOID HookData,
??? ??? INNDIS_HANDLE? ProtocolBindingContext,
??? ??? INNDIS_STATUS? Status,
?? ?? ? INNDIS_STATUS? OpenErrorStatus
??? );
??? ???真正的OpenAdapterComplete()?句柄被放在這:[HookData + 0x770]
??? ???
??? VOID HookedCloseAdapterComplete(
??? ???PVOID HookData,
??? ??? INNDIS_HANDLE? ProtocolBindingContext,
??? ??? INNDIS_STATUS? Status
??? );
??? ???真正的CloseAdapterComplete()?句柄被放在這:[HookData + 0x774]
???????
??? VOID HookedBindAdapter(
??? ???PVOID HookData,
??? ???OUT PNDIS_STATUS Status,
??? ??? INNDIS_HANDLE? BindContext,
??? ??? INPNDIS_STRING? DeviceName,
?? ?? ? INPVOID? SystemSpecific1,
??? ??? INPVOID? SystemSpecific2
??? );
??? ???真正的BindAdapter()?句柄被放在這:[HookData + 0x764]
? ???
?? VOID HookedUnbindAdapter(
??? ???PVOID HookData,
??? ???OUT PNDIS_STATUS? Status,
??? ??? INNDIS_HANDLE? ProtocolBindingContext,
??? ??? INNDIS_HANDLE? UnbindContext
??? );
??? ????真正的UnbindAdapter()??句柄被放在這:?[HookData + 0x768]
??? ??? For NDIS_OPEN_BLOCK:
?? VOIDHookedSend(
??? ???PVOID HookData,
??? ??? INNDIS_HANDLE? NdisBindingHandle,
??? ???IN? PNDIS_PACKET? Packet
??? );
??? ???真正的Send()??句柄被放在這:?[HookData + 0x1A4]
????
?VOID? HookedReceive(
??? ???PVOID HookData,
??? ???IN? NDIS_HANDLE????????????ProtocolBindingContext,
??? ???IN?NDIS_HANDLE????????????MacReceiveContext,
??? ???IN?PVOID??????????????????HeaderBuffer,
??? ???IN?UINT???????????????????HeaderBufferSize,
?? ?? ?IN?PVOID??????????????????LookAheadBuffer,
??? ???IN?UINT???????????????????LookaheadBufferSize,
??? ???IN?UINT???????????????????PacketSize
??? );
??? ???真正的Receive()?句柄被放在這:?[HookData + 0x4D0]
?VOID HookedReceivePacket(
??? ???PVOID HookData,
??? ???IN?NDIS_HANDLE????????????ProtocolBindingContext,
??? ???IN?PNDIS_PACKET???????????Packet
);
??? ???真正的ReceivePacket()?句柄被放在這:?[HookData + 0x570]
VOID HookedSendPackets(
??? ???PVOID HookData,
?? ?? ? INNDIS_HANDLE?????????????MiniportAdapterContext,
??? ??? INPPNDIS_PACKET???????????PacketArray,
?? ?? ? INUINT????????????????????NumberOfPackets
);
??? ???真正的SendPackets()??句柄被放在這:? [HookData+2E4h]
??? ????可憐的ZoneAlarm,這是如此的簡單對于獲取真實(shí)的句柄并恢復(fù)他。
??? ????我說過,每個(gè)防火墻都支持多數(shù)的注冊協(xié)議。事實(shí)上,并不是每個(gè)。Sygate認(rèn)為,保持關(guān)于協(xié)議和公開包的所有信息在他的.data段中已經(jīng)足夠了。不幸是個(gè)壞主意。他的句柄HOOK方式比ZoneAlarm簡單,但是說明哪些內(nèi)存將被分配的指令被?放在Sygate的驅(qū)動(dòng)Teefer.sys中:
???pop???????eax??????? ; 58
???push??????? HookData??? ; 68XX XX XX XX
???push???????eax??????? ; 50
???jmp??????? FakeHandler??? ;E9 XX XX XX XX
??? ??? HookData也是放在.data中的。Sygate總共能HOOK576個(gè)句柄(包括協(xié)議和開放塊句柄)。于是,大約有40-50個(gè)NDIS_PROTOCOL_BLOCK和NDIS_OPEN_BLOCK能被Hook(不要忘記幾個(gè)開放塊能被附加到一個(gè)協(xié)議塊)。大概40-50塊已經(jīng)足夠了,但那樣的代碼實(shí)在是個(gè)糟糕的設(shè)計(jì),給緩沖區(qū)溢出打了個(gè)招呼。
??? ????我有另外一個(gè)好例子,是關(guān)于關(guān)于多么有必要知道怎樣Hook和hook多少。那些來自Kerio防火墻小組的家伙不知道這些。作為一個(gè)好的防火墻,設(shè)置HOOK在?NdisRegisterProtocol(), NdisDeregisterProtocol(), NdisOpenAdapter(),NdisCloseAdapter()?等函數(shù)并且HOOK句柄。就像我說的,Kerio只是hook NDIS_PROTOCOL_CHARACTERISTICS的句柄并且僅僅調(diào)用NdisRegisterProtocol()函數(shù),但他不將句柄移回NDIS_PROTOCOL_CHARACTERISTICS。這會怎樣?未公開的特性?我不這樣認(rèn)為,恰恰是粗心的編碼和對內(nèi)核標(biāo)準(zhǔn)和架構(gòu)的誤解。另一個(gè)好的例子是,Kerio團(tuán)隊(duì)不知道任何關(guān)于NDIS的開發(fā),事實(shí)就是這樣,他們甚至不知道怎樣去HOOK。Kerio防火墻HOOK在NDIS_PROTOCOL_CHARACTERISTICS里:
??? OpenAdapterCompleteHandler
???CloseAdapterCompleteHandler
????并這樣hook NDIS_OPEN_BLOCK:
??? SendHandler
??? SendPacketsHandler
??? ????不是太多?剛好。他能被用來繞過他的NDIS保護(hù),并發(fā)送一個(gè)包給TCP/IP棧。你雖然已經(jīng)按了“阻止所有”按鈕,但仍然能在本地嗅探器下看到進(jìn)來的數(shù)據(jù)包。我可不喜歡像Kerio防火墻假裝的那樣假裝自己受保護(hù)的時(shí)候,再去嗅探器下看數(shù)據(jù)包。從另一個(gè)方面來說,Outpost防火墻,喜歡在NDIS_PROTOCOL_BLOCK中hook更多的句柄:
??? OpenAdapterCompleteHandler
??? SendCompleteHandler
???TransferDataCompleteHandler
??? RequestCompleteHandler
??? ReceiveHandler
??? StatusHandler
??? ReceivePacketHandler
??? BindAdapterHandler
??? UnbindAdapterHandler
??? ????在?NDIS_OPEN_BLOCK中:
??? ??? Outpost4.0:
??? SendCompleteHandler
???TransferDataCompleteHandler
??? ReceiveHandler
??? ReceivePacketHandler
??? StatusHandler
??? ?? Outpost 3.x:
??? SendHandler
??? TransferDataHandler
??? SendCompleteHandler
???TransferDataCompleteHandler
??? ReceiveHandler
???RequestCompleteHandler
??? ReceivePacketHandler
??? SendPacketsHandler
??? StatusHandler
??? ???他的句柄調(diào)用和防火墻之間的代碼是非常有趣的:
??? call???ImCode??????? ; E8 XX XX XX XX
????
???? For Outpost3.x:
???pop???????eax??????? ; 58
???push???????[eax]??????? ; FF30??????? Pushing the real handler
???pushad???????????????; 60
???push???????[eax+4]??????? ; FF 70 04
???push??????? [esp+28h]??? ; FF74 24 28??? Pushing return address
???jmp???????[eax+8]??????? ; FF 60 08
??? For Outpost 4.0:
???pop???????eax??????? ; 58
???add??????? eax,3??????? ; 83 C0 03???Missing three zero bytes after call
???push???????[eax]??????? ; FF30??????? Pushing the real handler
???pushad???????????????; 60
???push???????[eax+4]??????? ; FF 70 04
???push??????? [esp+28h]??? ; FF74 24 28??? Pushing return address
???jmp???????[eax+8]??????? ; FF 60 08
??? ???像我們看到的那樣,那不是一個(gè)問題對于卸載所有的HOOK并立即獲取系統(tǒng)控制權(quán)。如果你厭煩了這中間的匯編代碼,他們通常是能夠轉(zhuǎn)換成普通C代碼的,我能向你展示一些來自Tiny防火墻團(tuán)隊(duì)有趣的東西,他假裝是真正的安全,并且向我們展示了很多的hook:
??? NdisOpenAdapter
??? NdisCloseAdapter
??? NdisInitializeWrapper
??? NdisTerminateWrapper
??? NdisMRegisterMiniport
???NdisIMRegisterLayeredMiniport
??? NdisRegisterProtocol
??? NdisMSetAttributesEx
??? NdisRegisterMac
???NdisIMAssociateMiniport
???NdisClOpenAddressFamily
???NdisCmRegisterAddressFamily
???NdisMCmRegisterAddressFamily
??? NdisMCoSendComplete
??? ???哦,看起來很優(yōu)秀,也真是很優(yōu)秀的樣子,他們試圖對這些函數(shù)做一個(gè)結(jié)合HOOK通過設(shè)置跳轉(zhuǎn)到他們的句柄。我不喜歡“結(jié)合”,知道為什么嗎?那不是因?yàn)樗y以實(shí)現(xiàn)或是有些指令很難“結(jié)合”(理論上可行,實(shí)踐上未必,我不認(rèn)為在真正函數(shù)的開端那樣做可行)。主要的原因是那樣不安全。Rootkit開發(fā)者使用他是因?yàn)槟鞘且环N獲取控制權(quán)的簡單的方式,但不要試圖把他用作安全軟件中,就像用恐怖份子的方法對付恐怖分子一樣。還有要說的是,我沒有發(fā)現(xiàn)任何線程安全和多處理器安全的代碼。再一次失敗。當(dāng)你在“結(jié)合”某些代碼的時(shí)候,你需要確信沒有一個(gè)線程、沒有一個(gè)CPU在運(yùn)行這些代碼。
??? ??? Tiny防火墻為每個(gè)HOOK句柄申請內(nèi)存,并拷貝這些C函數(shù)在開端和結(jié)尾:
???push???????ebp???????????????????; 55
???mov??????? ebp,esp???????????????; 8B EC
???sub??????? esp,XXh???????????????; 83 EC XX
???mov??????? byte ptr [ebp-1],XXh??????????? ; C6 45FF XX
???mov??????? dword ptr [ebp-8],HookedHandler??? ; C7 45 F8 XX XX XX XX
??? <...>
???push??????? RealHandler
???call??????? [ebp-8]
???mov??????? esp, ebp
???pop??????? ebp
???ret??????? XXh
??? ???于是這就變的相當(dāng)簡單,對于從新句柄偏移0xD去獲得真的句柄。對所有的句柄,Tiny都是拷貝上面的代碼。
??? hook在NDIS_PROTOCOL_BLOCK中:
??? SendCompleteHandler
??? StatusHandler
??? Hooked?在?NDIS_OPEN_BLOCK中:
??? TransferDataHandler
??? SendCompleteHandler
???TransferDataCompleteHandler
??? ReceiveHandler
??? ReceivePacketHandler
??? StatusHandler
??? ???需要說的是,有些防火墻變聰明了,如果他們被別人hook的時(shí)候,他們會試圖恢復(fù)他們的hook。例如,Outpost防火墻就檢測這個(gè)并監(jiān)視他們的hook,但僅僅像指針的安全那樣。也許他們不認(rèn)為會有剪接戲法?Outpost小組不知道,白帽子Sygate防火墻也能恢復(fù)他們的hook,但他恢復(fù)的僅僅是NDIS_OPEN_BLOCK.SendHandler和?NDIS_OPEN_BLOCK.SendPacketsHandler。那是奇怪的,因?yàn)橐驗(yàn)樗麄僪ook了很多NDIS_PROTOCOL_BLOCK中的句柄:
??? OpenAdapterCompleteHandler
???CloseAdapterCompleteHandler
???TransferDataCompleteHandler
??? ReceiveHandler
??? StatusHandler
????和?NDIS_OPEN_BLOCK?的hook:
??? SendHandler
??? TransferDataHandler
???TransferDataCompleteHandler
??? ReceiveHandler
??? ReceivePacketHandler
??? SendPacketsHandler
??? StatusHandler
??? ???只有幾種防火墻用中間層NDIS驅(qū)動(dòng)來做NDIS級的保護(hù)。這是一個(gè)聰明的解決方案。例如,Look’n’Stop?和?Outpost 2008?防火墻用IM NDIS驅(qū)動(dòng)。Outpost好的改進(jìn)是在去年。但是現(xiàn)在繞過防火墻變的容易使因?yàn)闆]有HOOK,沒有伎倆和沒有任何未公布的特性被使用。現(xiàn)在你能粉碎所有的IM NDIS防火墻只是繞過他們。不需要擾亂防火墻接受和發(fā)送包的句柄,你也不用向他們發(fā)送包??傊?#xff0c;使用IM NDIS驅(qū)動(dòng)是好的,眾所周知的,已公布的,一個(gè)正確的保護(hù)系統(tǒng)不受外部攻擊的方法。
??? ????像你可能看到的那樣,技術(shù)各個(gè)防火墻的技術(shù)是相似的,思路甚至能被盜用并且沒有人會說你盜用了一個(gè)想法。好的方式是透過表面創(chuàng)新你的產(chǎn)品。不需去思考,不用產(chǎn)生想法,去反匯編、調(diào)試并且對它感興趣。第二種主級別的防火墻基于TDI,傳輸數(shù)據(jù)接口能為內(nèi)核傳輸協(xié)議棧提供更高級別的訪問。Afd.sys,能解析winsock,經(jīng)由tdi.sys(TDI層,上面層說過)與Windows TCP/IP棧(tcpip.sys)通信。于是,又幾種方式和地方去安裝hook并監(jiān)視你的程序和網(wǎng)絡(luò)通信。設(shè)置你的保護(hù)最好的地方正是在tcpip.sys設(shè)備,它能在協(xié)議棧的最上層解釋執(zhí)行:
??? ??? DeviceIp
??? ??? DeviceTcp
??? ??? DeviceUdp
??? ???DeviceIPMULTICAST
??? ???DeviceRawIp
??? ????好的,你甚至能通過/Device/RawIp來戲弄一些人。對于阻止程序的一個(gè)訪問網(wǎng)絡(luò)的請求最好的方式(公開
的方式,也是重要的),是附加到這些設(shè)備上并監(jiān)視他們。幾乎所有的防火墻都這樣做了,因?yàn)檫@是通知用戶陌生程序要訪問網(wǎng)絡(luò)的好方法。例如,Look’n’Stop附加他的設(shè)備到tcpip.sys設(shè)備:
??? ???DevicePcaTcpFilter -> DeviceTcp
??? ???DevicePcaUdpFilter -> DeviceUdp
??? ???DevicePcaRawIpFilter -> DeviceRawIp
??? ??? /Device/Ip在那里?不是足夠的,我們需要確信,所有種類的連接需要被監(jiān)視,或是他們恰恰通過了這個(gè)假冒的保護(hù)。
??? ????你的看見這些設(shè)備在你的WinObj工具里:
??? ???DeviceComodoRawIpFilter
??? ???DeviceComodoUdpFilter
??? ???DeviceComodoTcpFilter
??? ???DeviceComodoIpFilter
??? ????我希望你能猜到,Comodo防火墻是附加設(shè)備到相同名字的tcpip.sys設(shè)備。
??? ??? Outpost、Kerio、Jetico?防火墻, Norton InternetSecurity僅僅附加一個(gè)無名的設(shè)備到Tcp,Udp,Ip,RawIp,沒有感興趣的事。了解設(shè)備棧結(jié)構(gòu)的人應(yīng)該知道拋開這些附加設(shè)備使防火墻不再提示是相當(dāng)容易的。你只需要找到tcpip.sys的DRIVER_OBJECT的指針,遍歷DeviceObject列表,清空所有DEVICE_OBJECT的附加項(xiàng)。相當(dāng)容易吧?但對對抗防火墻很有效,他們的防護(hù)程序就是在那附近。另一個(gè)脆弱防火墻的錯(cuò)誤和夸大的廣告。除了附加技術(shù)外,還有另一種有趣而復(fù)雜的的技術(shù),但對惡意軟件更有效,這就是MajorTable hook。大家都知道,當(dāng)用戶態(tài)程序想與驅(qū)動(dòng)交互的時(shí)候,他通知要交互驅(qū)動(dòng)的I/O管理器。I/O管理器產(chǎn)生一個(gè)IRP,并調(diào)用DRIVER_OBJECT.MajorTable[IRP_MJ_XXX]的句柄。就在tcpip.sys這,一些防火墻僅僅hook一個(gè)IRP_MJ_XXX句柄并監(jiān)視所有調(diào)用,通過允許請求和拒絕禁止。找到一個(gè)真的句柄不是很容易,哈?幾乎每個(gè)人都認(rèn)為那不可能。尋找一些被hook的句柄的主要方法是,他必須被調(diào)用然后會被發(fā)現(xiàn)。通過hook Int 0x01,設(shè)置TF,防火墻句柄的所有調(diào)用,我們能發(fā)現(xiàn)一個(gè)防火墻要調(diào)用的真的句柄。簡單,MajorTable-hooking技術(shù)被像ZoneAlarm這樣的防火墻青睞,他是這樣HOOK的:
??? IRP_MJ_CREATE
??? IRP_MJ_CLOSE
??? IRP_MJ_DEVICE_CONTROL
???IRP_MJ_INTERNAL_DEVICE_CONTROL
??? IRP_MJ_CLEANUP
??? ????另一個(gè)局部hook的失敗是,tcpip.sys僅有TCPDispatch()?和TCPDispatchInternalDeviceControl()2個(gè)IRP句柄,第一個(gè)被所有?MajorTable填充,把它從另一個(gè)句柄上移出時(shí)容易的。TCPDispatchInternalDeviceControl()你能通過使用另一個(gè)方法?(例如前面說的追蹤方法和反匯編方法)來發(fā)現(xiàn)。Sygate防火墻喜歡HOOK這些句柄:
??? ???IRP_MJ_CREATE
??? ??? IRP_MJ_CLOSE
??? ???IRP_MJ_DEVICE_CONTROL
??? ???IRP_MJ_INTERNAL_DEVICE_CONTROL
??? ??? PortsLock防火墻,hook所有MajorTable句柄。好主要,既不將TCPDispatch()也不將TCPDispatchInternalDeviceControl()給敵人。Tiny防火墻是hook下面的句柄。
??? ???IRP_MJ_CREATE
??? ???IRP_MJ_CLOSE
??? ??? IRP_MJ_DEVICE_CONTROL
??? ???IRP_MJ_INTERNAL_DEVICE_CONTROL
??? ???IRP_MJ_CLEANUP
??? ????對于在一個(gè)防火墻中僅有這種類型的保護(hù)是不嚴(yán)重的,你不這樣認(rèn)為嗎?我認(rèn)為像PortsLock防火墻,Norton Internet Security,Comodo防火墻和其他有“防火墻”這個(gè)錯(cuò)誤稱號的,就像一些有著很漂亮界面的保護(hù)系統(tǒng)。惡意軟件正在變的越來越猖獗,每天都有大量的ROOTKIT杯注冊,更多老練的,先進(jìn)的,比防火墻更底層的正在不斷涌現(xiàn)。他們試圖影響其他進(jìn)程并隱匿其中。就像一個(gè)披著羊皮的狼。我談到,injection, OpenProcess()/WriteProcessMemory()/CreateRemoteThread()和一個(gè)好的shellcode或一個(gè)self-mapped模塊等都能透過防護(hù)與外部通信,而且工作的很好,也很容易編寫,所有需要好的保護(hù)而不受其侵害。系統(tǒng)服務(wù)標(biāo)提供內(nèi)核函數(shù)的訪問通道,他是通過調(diào)_KiSystemService,那是用用戶模式和驅(qū)動(dòng)來實(shí)現(xiàn)的。防火墻為了阻止這些動(dòng)作使系統(tǒng)保持健壯,成功地hook了打開進(jìn)程、寫進(jìn)程內(nèi)存、創(chuàng)建遠(yuǎn)線程、進(jìn)程、文件、文件編輯等函數(shù)。防火墻喜歡做這些,例如,ZoneAlarm防火墻hook以下系統(tǒng)服務(wù):
???? ZwConnectPort
??? ZwCreateFile
??? ZwCreateKey
??? ZwCreatePort
??? ZwCreateProcess
??? ZwCreateProcessEx
??? ZwCreateSection
??? ZwCreateWaitablePort
??? ZwDeleteFile
??? ZwDeleteKey
??? ZwDeleteValueKey
??? ZwDuplicateObject
??? ZwLoadKey
??? ZwMapViewOfSection
??? ZwOpenFile
??? ZwOpenProcess
??? ZwOpenThread
??? ZwReplaceKey
???ZwRequestWaitReplyPort
??? ZwRestoreKey
??? ZwSecureConnectPort
??? ZwSetInformationFile
??? ZwSetSystemInformation
??? ZwSetValueKey
??? ZwTerminateProcess
??? ???他監(jiān)視對注冊表,進(jìn)程,驅(qū)動(dòng),文件的訪問,并阻止自己被關(guān)閉。Outpost Firewall 4 hook更多的服務(wù):
??? ZwAssignProcessToJobObject
??? ZwClose
??? ZwCreateFile
??? ZwCreateKey
??? ZwCreateProcess
??? ZwCreateProcessEx
??? ZwCreateSymbolicLinkObject
??? ZwCreateThread
??? ZwDeleteFile
??? ZwDeleteKey
??? ZwDeleteValueKey
??? ZwLoadDriver
??? ZwMakeTemporaryObject
??? ZwOpenFile
??? ZwOpenKey
??? ZwOpenProcess
???ZwProtectVirtualMemory
??? ZwQueryDirectoryFile
??? ZwQueryKey
??? ZwQueryValueKey
??? ZwReplaceKey
??? ZwRestoreKey
??? ZwSaveKey
??? ZwSaveKeyEx
??? ZwSetInformationFile
??? ZwSetValueKey
??? ZwTerminateProcess
??? ZwTerminateThread
??? ZwUnloadDriver
??? ZwWriteVirtualMemory
??? ???但事實(shí)上他僅用了他們的一半。他不關(guān)心驅(qū)動(dòng),你能加載任何你想要的,但他hook了ZwLoadDriver。更多的hook就更好嗎?啊哈,對漏洞挖掘者來說更好。不是每個(gè)人都知道代碼的質(zhì)量怎樣,它將要運(yùn)行當(dāng)我們調(diào)用ZwOpenKey時(shí)。我的系統(tǒng)將要藍(lán)屏嗎?另一個(gè)關(guān)于hook的例子是Kerio防火墻:
??? ZwClose
??? ZwCreateFile
??? ZwCreateKey
??? ZwCreateProcess
??? ZwCreateProcessEx
??? ZwCreateThread
??? ZwDeleteFile
??? ZwDeleteKey
??? ZwDeleteValueKey
??? ZwLoadDriver
??? ZwMapViewOfSection
??? ZwOpenFile
??? ZwOpenKey
??? ZwResumeThread
??? ZwSetInformationFile
??? ZwSetValueKey
??? ZwTerminateProcess
??? ZwWriteFile
??? ???沒看見ZwOpenProcess/ZwWriteVirtualMemory的hook。使用Kerio你能插入你想要的每個(gè)進(jìn)程,包括允許的進(jìn)程。Sygate所用的hook比其他的少:
??? ZwTerminateProcess
??? ZwMapViewOfSection
???ZwAllocateVirtualMemory
??? ZwCreateThread
???ZwProtectVirtualMemory
??? ZwWriteVirtualMemory
??? ???他們認(rèn)為能通過hookZwWriteVirtualMemory來保護(hù)系統(tǒng)。那是有BUG的:你能打開進(jìn)程,并改變一些線程的context,幾乎與?Jetico做的相同:
??? ZwConnectPort
??? ZwCreatePort
??? ZwCreateThread
??? ZwTerminateProcess
??? ZwWriteVirtualMemory
??? ???
??? ????不是很有趣。Tiny防火墻做的最有趣:
??? ZwCreateKey
??? ZwCreateSection
??? ZwOpenKey
??? ZwSetInformationProcess
??? ZwTerminateProcess
??? ???你能這樣說嗎?:這是容易的對于通過ZwWriteVirtualMemory來插入一些東西。當(dāng)然,但當(dāng)此惡意行為發(fā)生時(shí),用戶將被通知。這是個(gè)愚蠢的小玩笑,對于在用戶模式下來保護(hù),Tiny防火墻載入他的UmxSbxExw.dll?到每個(gè)進(jìn)程并hook許多進(jìn)程通過安裝每個(gè)函數(shù)開始的跳轉(zhuǎn):
kernel32.dll:
CreateProcessA
CreateProcessW
CreateRemoteThread
DebugActiveProcess
FreeLibrary
GetProcAddress
LoadLibraryExW
OpenThread
TerminateProcess
TerminateThread
WriteProcessMemory
user32.dll:
BroadcastSystemMessage
BroadcastSystemMessageA
BroadcastSystemMessageExA
BroadcastSystemMessageExW
BroadcastSystemMessageW
EndTask
ExitWindowsEx
OpenClipboard
PostMessageA
PostMessageW
PostThreadMessageA
PostThreadMessageW
SendDlgItemMessageA
SendDlgItemMessageW
SendMessageA
SendMessageCallbackA
SendMessageCallbackW
SendMessageTimeoutA
SendMessageTimeoutW
SendMessageW
SendNotifyMessageA
SendNotifyMessageW
SetUserObjectSecurity
SetWindowsHookA
SetWindowsHookExA
SetWindowsHookExW
SetWindowsHookW
advapi32.dll:
AbortSystemShutdownW
AdjustTokenPrivileges
ChangeServiceConfig2A
ChangeServiceConfig2W
ChangeServiceConfigA
ChangeServiceConfigW
ControlService
CreateProcessAsUserA
CreateProcessAsUserW
CreateProcessWithLogonW
CreateServiceA
CreateServiceW
DeleteService
EnumDependentServicesA
EnumDependentServicesW
EnumServicesStatusA
EnumServicesStatusExA
EnumServicesStatusExW
EnumServicesStatusW
InitiateSystemShutdownExW
InitiateSystemShutdownW
OpenSCManagerA
OpenSCManagerW
OpenServiceA
OpenServiceW
QueryServiceConfig2A
QueryServiceConfig2W
QueryServiceConfigA
QueryServiceConfigW
QueryServiceStatus
QueryServiceStatusEx
SetFileSecurityW
SetKernelObjectSecurity
SetNamedSecurityInfoW
SetSecurityInfo
SetServiceObjectSecurity
StartServiceA
StartServiceW
??? ???哦,Tiny是個(gè)hook怪物。你能看見在kernel32.dll上的hook!WriteProcessMemory在他們的保護(hù)之下以防止被插入。Tiny防火墻團(tuán)隊(duì)認(rèn)為那是一個(gè)很酷的保護(hù)方式,在一些不穩(wěn)定的程序中他可能會掛掉。從那些進(jìn)程中卸載掉他的Dll也不是件難事,恢復(fù)所有的函數(shù)入口就可以享受生活了。Outpost也喜歡這樣做,他加載他的wl_hook.dll到應(yīng)該被保護(hù)以防止惡意軟件的每個(gè)進(jìn)程。那是龐大的hook隊(duì)列:
kernel32.dll:
CreateProcessA
CreateProcessW
CreateRemoteThread
DebugActiveProcess
WinExec
ntdll.dll:
LdrLoadDll
LdrUnloadDll
NtCreateThread
NtResumeProcess
NtResumeThread
NtSetContextThread
NtSetValueKey
NtSuspendProcess
NtSuspendThread
NtTerminateProcess
NtWriteVirtualMemory
ZwCreateThread
ZwResumeProcess
ZwResumeThread
ZwSetContextThread
ZwSetValueKey
ZwSuspendProcess
ZwSuspendThread
ZwTerminateProcess
ZwWriteVirtualMemory
user32.dll:
CallNextHookEx
ChangeDisplaySettingsExA
ChangeDisplaySettingsExW
DdeConnect
DdeConnectList
DdeInitializeA
DdeInitializeW
EndTask
ExitWindowsEx
FindWindowExA
FindWindowExW
PostMessageA
PostMessageW
SendInput
SendMessageA
SendMessageCallbackA
SendMessageCallbackW
SendMessageTimeoutA
SendMessageTimeoutW
SendMessageW
SendNotifyMessageA
SendNotifyMessageW
SetForegroundWindow
SetWindowPos
SetWindowsHookExA
SetWindowsHookExW
??? ????那不是一個(gè)保護(hù),是沒有必要的代碼。是的,他能抵制一些稀有惡意代碼,但沒有更多。一些防火墻不僅想被作為一個(gè)防火墻來使用,他們包含了一些有趣的特性像間諜軟件或rootkit的檢測程序。是的,他們工作了?,這就產(chǎn)生了一個(gè)印象。在遇到調(diào)試之前的幾分鐘。一些防火墻試圖監(jiān)視模塊的加載通過設(shè)置經(jīng)由PsSetLoadImageNotiryRoutine()的例行檢查。Jetico Firewall, Look’n’Stop Firewall, Tiny Firewall,ZoneAlarm Firewall, Outpost Firewall是這樣做的。例如,當(dāng)Outpost加載時(shí),監(jiān)視dnsapi.dll的加載,他通知用戶一些程序試圖使用DNS服務(wù)。這將會發(fā)生,當(dāng)你將要調(diào)用gethostbyname()時(shí),dnsapi.dll?會自動(dòng)加載。不是很酷。重命名dnsapi.dll到xxx.dll,加載它,找到DnsQuery_A的指針,并使用它來解析,OutPost將會關(guān)閉。這是個(gè)糟糕的方式對于在這兒的保護(hù)。幾乎在每個(gè)防火墻中,你都能發(fā)現(xiàn)很多無用的,無效的東西。有時(shí),它幫助理解部分代碼或給出一個(gè)例子函數(shù)命名,甚至你能發(fā)現(xiàn)一些調(diào)式信息。Look’n’Stop防火墻團(tuán)隊(duì)沒有區(qū)分發(fā)布版和調(diào)試版,可能那就是他們?yōu)槭裁戳粝逻@些東西在這:
??? push??? offsetasc_187DC ; "f://dev//lns//2.05.cur//tdisys//w32api.c"
???push??? offset aKegetcurren_23 ; "KeGetCurrentIrql() ==PASSIVE_LEVEL"
???call??? ds:RtlAssert
??? ????斷言在調(diào)試構(gòu)建時(shí)是有用的,但不是在發(fā)布版中。Tiny防火墻有很多奇怪的格式串日志:
?.text:00011608 aNbh0x08xMac0x0 db9,'nbh:0xX mac:0xX mah:0xX ??? ???pbc:0xX',0Dh,0Ah
.text:00011608 ; DATA XREF:HookedNdisOpenAdapter+273 o
.text:00011608 db9,'med:"%s"',0Dh,0Ah
.text:00011608 db9,'drv:"%s"',0Dh,0Ah
.text:00011608 db9,'dev:"%s"',0Dh,0Ah
.text:00011608 db9,'ada:"%s"',0
.text:00011661 align 4
我認(rèn)為沒人想因?yàn)檫@些奇怪的記錄而看見藍(lán)屏。ZoneAlarm也喜歡記錄:
.text:0001A610 aUPacketSProtoS db '%uPacket %s: Proto: %s Flags: 0xlx Src: %2u.%2u.%2u.%2u '
.text:0001A610 ; DATA XREF:sub_1A693+119 o
.text:0001A610 db 'Dest: %2u.%2u.%2u.%2u',0
他尤其喜歡記錄在發(fā)布版本中,當(dāng)然。
.text:00025A84 aSFragTLxHLxPfl db '%sfrag: t=%lx h=%lx pflg=%lx subp=%lx sip=%d.%d.%d.%d dip=%'
.text:00025A84 ; DATA XREF:sub_25BAA+2D1 o
.text:00025A84 db 'd.%d.%d.%d id=%xf=%s%s%s off=%hu act=%lx',0Ah,0
我喜歡?ZoneAlarm,他給我一些函數(shù)的名字:
.text:00050250 aVsdatantVstdic db'VSDATANT:vsTdiClientRequestReceivePreProc(): FO=%p SE=%p RE#'
.text:00050250 ; DATA XREF: sub_502A6+D3o
.text:00050250 db '=%d IRP=%p :TIMEOUT(%u)',0Ah,0
Kerio防火墻團(tuán)隊(duì)不包含路徑就不能生成他們的驅(qū)動(dòng):
.rdata:00433704aCProjectsNetsecuritytoolsFire db 'C:/Projects/netsecuritytools/FirewallSDK/Build.Release/4.3.'
.rdata:00433704 db'x/bin/Release/fwdrv.pdb',0
他們也這樣記錄:
.data:00434020 aFwdrvApicopyas db'FWDRV: ApiCopyAssociatedEndpoint: Local: %u.%u.%u.%u:%u Remo'
.data:00434020 ; DATA XREF:sub_401150+3B4 o
.data:00434020 db 'te:%u.%u.%u.%u:%u,SpeedIn: %u, SpeedOut: %u, PID: 0xX, A'
.data:00434020 db 'pp: [%s], Service:[%s]',0
并且真是有大量這樣的記錄:
.data:0043B1D4 aSPagedCodeCa_7 db '%s():Paged code called on IRQL %d',0
??? ???我想說的是:不要緊,你喜歡記錄多少,你應(yīng)該移走這樣的垃圾記錄和垃圾代碼在發(fā)布版中。越少的代碼,越少的bug。也學(xué)下次藍(lán)屏?xí)偤迷谀切┰愀鉁y試并綁定調(diào)試信息的代碼中。今年的首次揭幕是OnlineArmor防火墻?!癘nline Armor有一個(gè)非常好的機(jī)會,調(diào)者華爾茲就竊取了蘇格蘭時(shí)事通訊2008最佳軟件防火墻的榮譽(yù)稱號”?是的,在DriverVerifier下的首次測試就給我了一個(gè)藍(lán)屏。真是很有趣,他在標(biāo)準(zhǔn)檢查工具下掛掉了。?在里面你能發(fā)現(xiàn)IRP_MJ_DEVICE_CONTROL?句柄,那是處理所有與METHOD_NEITHER有關(guān)的IOCTLs。
??? ????你知道ProbeForRead()/ProbeForWrite()?他們甚至不檢查指針是否為空,這真是可笑,所有Windows用戶的最好保護(hù)軟件有如此多的問題。猜猜它能怎么樣?一部分16進(jìn)制的代碼如下所示:
?int __stdcall DispatchDeviceControl(intDeviceObject, PIRP Irp)
{
? struct_IRP::$::$::$::$A02EC6A2CE86544F716F4825015773AC::_IO_STACK_LOCATION *Stack; //eax@1
? unsigned int Status; // edi@1
? PIRP _Irp; // esi@1
? void *InBuffer; // ecx@2
? int InBufferSize; // edi@2
? PVOID OutBuffer; // edx@2
? int OutBufferSize; // ebx@2
? int Length; // eax@3
? int ReturnLength; // [sp+8h][bp-4h]@1
? ReturnLength = 0;
? _Irp = Irp;
? Stack =Irp->Tail.Overlay.CurrentStackLocation;
? Status = 0xC00000BBu;
? if ( *(_BYTE *)Stack == 14 )
? {
??? InBuffer = (void*)*((_DWORD *)Stack + 4);
??? InBufferSize =*((_DWORD *)Stack + 2);
??? OutBuffer =Irp->UserBuffer;
??? OutBufferSize =*((_DWORD *)Stack + 1);
??? Irp = (PIRP)*((_DWORD*)Stack + 3);
??? Status =HandleRequest((int)Irp, InBuffer, InBufferSize, OutBuffer, OutBufferSize,&ReturnLength);
? }
? Length = ReturnLength;
? _Irp->IoStatus.Status =Status;
? _Irp->IoStatus.Information =Length;
? IofCompleteRequest(_Irp, 0);
? return Status;
}
int __stdcall HandleRequest(int Ioctl,void *InBuffer, int InBufferSize, void *OutBuffer, int OutBufferSize, int*ReturnLength)
{
? …
? if ( Ioctl == 0x830020EB )
? {
???sub_1484A((int)OutBuffer);
??? *v6 = 28;
??? return 0;
? }
在sub_1484A()里什么是如此的有趣?看看這里:
int __stdcall sub_1484A(int a1)
{
? int result; // eax@3
? CPPEH_RECORD ms_exc; // [sp+Ch][bp-18h]@1
? ms_exc.disabled = 0;
? if ( dword_16168 )
? {
??? memcpy((void *)a1,(const void *)dword_161A8, 0x1Cu);
? }
? else
? {
??? result = 0;
??? memset((void *)a1, 0,0x1Cu);
? }
? return result;
}
??? ???酷,在內(nèi)核空間寫些東西已經(jīng)沒有任何困難了,我們能制造一個(gè)DOS,甚至可以執(zhí)行代碼。我只是不想進(jìn)一步發(fā)掘了,希望剩下的將被同道之一完成。如果我說的是真的話,似乎每個(gè)防火墻都能被繞過,沒有東西能做到100%的保護(hù)。Rootkit,木馬,蠕蟲和其他惡意軟件變的更加隱蔽、復(fù)雜,而且很難被發(fā)現(xiàn)。我不想給出任何關(guān)于選擇哪款防火墻的建議,只是要確信,你用了一個(gè)功能強(qiáng)大的防火墻。
轉(zhuǎn)載于:https://www.cnblogs.com/airoot/p/4131855.html
總結(jié)
以上是生活随笔為你收集整理的关于个人防火墙的真相的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 用户体验设计的五个原则(转)
- 下一篇: css斜角覆盖阴影