安全建議
由於Stuxnet蠕蟲病毒是首個針對工業控制系統編寫的破壞性病毒，對大型工業、企業用戶存在一定的風險，所以，冠群金辰公司病毒防護專家給企業用戶提出如下安全防護建議，以提高企業抵禦未知安全風險的能力：
在終端設備上開啟防火牆功能。
為終端設備上所有的套用系統安裝最新的補丁程式。
在終端上安裝防病毒系統，設定為實時更新病毒庫，並將病毒庫升級到最新版本。
在終端上的用戶設定最小用戶許可權。
在打開附屬檔案或通過網路接收檔案時，彈出安全警告或提示。
在打開網路連結時，發出安全警告或提示。
儘量避免下載未知的軟體或程式。
使用強口令，以保護系統免受攻擊。
兩個月前，賽門鐵克首次披露了W32.Stuxnet針對工業生產控制系統(ICS) 進行攻擊，如套用於管道和核動力工廠的控制系統。讀者可參見賽門鐵克2010年7月19日的部落格– “W32.Stuxnet 攻擊微軟零日漏洞利用USB設備大肆傳播”。
2010年9月29日，我們還將在Virus Bulletin 會議上發布一篇包含W32.Stuxnet詳盡技術細節的論文。同時我們也注意到，最近非常多的人開始對Stuxnet感染系統且不易檢測的事情表示關注。
由於Stuxnet針對某個特定的工業生產控制系統進行攻擊，而這些行為不會在測試環境中出現，因此在測試環境下觀察到的病毒行為不全面，很可能產生誤導。事實上，運行後，Stuxnet會立即嘗試進入一個可程式邏輯控制器(PLC) 的數據塊—DB890。這個數據塊其實是Stuxnet自己加的，並不屬於目標系統本身。Stuxnet 會監測並向這個模組里寫入數據，以根據情況和需求實時改變PLC的流程。
在這篇部落格里，我們會深入探討Stuxnet的PLC感染方式和Rootkit功能，特別是以下幾個方面：
它如何選擇作為攻擊目標的工業生產控制系統；感染PLC代碼塊的方法；注入PLC的惡意代碼；在被感染Windows機器中的PLC Rootkit代碼。 這四點我們會分開講，因為用來實現這些目的的代碼差異很大。
Stuxnet的目的是通過修改PLC來改變工業生產控制系統的行為，包括攔截髮送給PLC的讀/寫請求，以此判斷系統是否為潛在的攻擊目標；修改現有的PLC代碼塊，並往PLC中寫入新的代碼塊；利用Rootkit功能隱藏PLC感染，躲避PLC管理員或程式設計師的檢測。這些任務之間差別很大，比如，在被感染的Windows 機器中隱藏感染代碼使用的是標準的C/C++ 代碼，而Stuxnet 試圖在工業生產控制系統及PLC中執行的惡意代碼則是用MC7位元組碼寫的。MC7 是PLC 環境中運行的一種彙編語言，並常用STL 進行編寫。
在討論Stuxnet攻擊PLC的技術之前，讓我們先來看看PLC是如何訪問和編寫的。
Step 7 軟體使用庫檔案s7otbxdx.dll 來和PLC通信。當Step7 程式準備進入PLC時，它會調用該DLL檔案中不同的例程。例如，如果一個代碼塊需要用Step 7從PLC中讀出，那么，例程s7blk_read就會被調用到。s7otbxdx.dll中的代碼會進入PLC, 讀出其中的代碼，並把它傳回Step 7程式，如下圖所示：
為了更好的了解Stuxnet 如何進入和感染PLC，我們先來看看各種類型的數據。PLC 會處理由管理員載入到PLC的代碼和數據。這裡，我們將簡要介紹一下最常見的模組和他們的功能：
數據模組(DB)包含了程式相關的數據，比如數字，結構等。系統數據模組(SDB) 包含了PLC 的配置信息； 它們是根據連線到PLC 的硬體模組的數量/種類設立的。組織模組(OB) 是程式的入口。他們由CPU 循環執行。針對Stuxnet， 有兩個特別需要的OB:OB1 是PLC 程式的入口。它沒有特別的時間要求，總是循環執行。OB35 是一個標準的“看門狗”模組，系統會每100ms執行一次。這個功能可能包含了所有用於監控緊要輸入的邏輯，以達到立即回響，執行功能的目的。功能模組（FC）都是標準的代碼快。它們包含了會被PLC 執行的代碼。一般說來，OB1模組會引用至少一個FC 模組。下面的部分會詳細講述之前提到的威脅的四大方面。
感染原理
1. 如何選擇需要感染的PLCStuxnet會根據目標系統的特點，使用不同的代碼來感染PLC。
一個感染的序列包括了許多PLC 模組（代碼模組和數據模組），用以注入PLC來改變目標PLC 的行為。這個威脅包括了三個感染序列。其中兩個非常相似，功能也相同，我們將其命名為序列A和B。第三個序列我們命名為序列C。Stuxnet通過驗證“指紋”來判斷系統是否為計畫攻擊的目標。它會檢查：
PLC種類/家族：只有CPU 6ES7-417 和6ES7-315-2 會被感染。系統數據模組：SDB 會被解析；根據他們包含的數據，感染進程會選擇A,B或其它感染方式開始行動。當解析SDB 時，代碼會搜尋這兩個值是否存在-- 7050h and 9500h；然後根據這兩個數值的出現次數，選擇序列A 或B 中的一種來感染PLC。 代碼還會在SDB 模組的50h 子集中搜尋位元組序2C CB 00 01, 這個位元組序反映了通信處理器CP 342-5 (用作Profibus-DP) 是否存在。
而選擇序列C進行感染的條件則由其他因素構成。
Stuxnet使用“代碼插入”的感染方式。當Stuxnet 感染OB1時，它會執行以下行為：
增加原始模組的大小； 在模組開頭寫入惡意代碼；
在惡意代碼後插入原始的OB1 代碼。
利用A/B方法的感染步驟如下：
檢查PLC 類型；
該類型必須為S7/315-2；
檢查SDB 模組，判斷應該寫入序列A 或B 中的哪一個；
找到DP_RECV，將其複製到FC1869，並用Stuxnet嵌入的一個惡意拷貝將其取代；
在序列中寫入惡意模組（總共20個），由Stuxnet 嵌入；
感染OB1，令惡意代碼可以在新的周期開始時執行；
感染OB35, 它將扮演“看門狗”的角色。3. 感染代碼
被注入OB1 功能的代碼是用來感染序列A 和B的。這些序列包含了以下模組：
代碼塊：FC1865 至FC1874, FC1876 至FC1880 （注意：FC1869並非Stuxnet的一部分，而是PLC的DP_RECV模組的一個拷貝）；
數據模組：DB888 至DB891。 序列A 和B 用DP_RECV 掛鈎模組來攔截Profibus 中的數據包，並根據在這些模組中找到的數值，來構造其他的數據包並傳送出去。這由一個複雜的狀態機控制（狀態機被建立在上面提到的FC 模組中）。這個狀態機可部分受控於數據塊DB890 中的DLL。
在某些條件下，序列C會被寫入一個PLC。這個序列比A和B包含更多的模組：
FC6055 至FC6084；DB8062, DB8063；DB8061, DB8064 至DB8070 （在運行中產生）。 序列C主要為了將I/O信息讀寫入PLC的記憶體檔案映射的I/O 區域，以及外圍設備的I/O。
程式A/B 的控制流如下圖所示，在之前的Step7 編輯器的截圖中也有部分顯示（數據模組FC1873）:
Stuxnet PLC rootkit代碼全部藏身於假冒的s7otbxdx.dll中。為了不被PLC所檢測到，它至少需要應付以下情況：
對自己的惡意數據模組的讀請求；對受感染模組(OB1 , OB35, DP_RECV) 的讀請求；可能覆蓋Stuxnet自身代碼的寫請求。 Stuxnet包含了監測和攔截這些請求的代碼，它會修改這些請求以保證Stuxnet 的PLC 代碼不會被發現或被破壞。下面列出了幾個Stuxnet用被掛鈎的導出命令來應付這些情況的例子：
s7blk_read: 監測讀請求，而後Stuxnet 會返回：真實請求的DP_RECV (保存為FV1869)；錯誤信息，如果讀請求會涉及到它的惡意模組；OB1或OB35的乾淨版本的拷貝s7blk_write: 監測關於OB1/OB35的寫請求，以保證他們的新版本也會被感染。s7blk_findfirst / s7blk_findnext: 這些例程被用於枚舉PLC中的模組。惡意模組會被自動跳過。s7blk_delete: 監測對模組的“刪除”操作。 如上文所述，Stuxnet 是一個非常複雜的威脅，而其中的PLC 感染代碼令問題更加難以解決。僅僅關於注入的MC7代碼（我們於幾個月前通過逆向工程獲得）就可以討論很久。若想了解更多關於PLC 感染例程和Stuxnet的總體情況，請務必關注我們即將於Virus Bulletin會議中發布的白皮書。
卡巴斯基關於360解讀“超級工廠”的聲明
卡巴斯基實驗室於2010年7月15日向全球公布了對 “Stuxnet”病毒（國內譯成“震網”、“超級病毒”或“超級工廠”，以下稱“超級工廠”）的技術分析，並於9月24日由其創始人及CEO尤金@卡巴斯基先生公布了更為深入的行業解讀：
1、“超級工廠”病毒採用了複雜的多層攻擊技術，同時利用四種“零日漏洞”對微軟作業系統進行攻擊，利用兩種有效的數字證書（Realtek和JMicron），讓自己隱身。
2、“超級工廠”的目的不像一般的病毒，干擾電腦正常運行或盜竊用戶財產和隱私，其最終目的是入侵Simatic WinCC SCADA系統，該系統主要被用做工業控制系統，能夠監控工業生產、基礎設施或基於設施的工業流程。類似的系統在全球範圍內被廣泛地套用於輸油管道、發電廠、大型通信系統、機場、輪船甚至軍事設施中。
3、“超級工廠”已然是網路武器，被用於攻擊敵對方的有重要價值的基礎設施。它標誌著網路軍備競賽的開始。
4、“超級工廠”的幕後團隊是技術非常高超的專業人員，並且具有廣泛的資源以及強大的財力做後盾，他們應該是得到了某個國家或政府機構的支持。
對於這樣一款標誌著全球網路安全進入“基礎設施保護時代”的惡性病毒，360不但沒有做出任何得到微軟承認的實質性貢獻，卻在10月2日，即卡巴斯基公布技術分析兩個月後，發表了一份可謂“一派胡言”的官方新聞，聲稱“超級工廠”利用了“已知的”微軟漏洞，更口出狂言：“因為有360系列安全軟體的存在”，“中國已躲過‘超級工廠’病毒攻擊” 。
事實上，“超級工廠”利用的正是“未知的”微軟漏洞（國際上通常稱之為“零日漏洞”），也即它是在微軟尚沒有認識到該漏洞之前進行系統攻擊的。因此，即使用戶天天在用360打微軟補丁，也無法防禦這類攻擊。專業安全軟體廠商之所以能夠存在，就是因為它能在微軟發布漏洞補丁之前就能幫助用戶抵禦這類病毒，甚至是比微軟更早的發現這些“未知”的漏洞。卡巴斯基是全球第一個發現“超級工廠”利用了兩個最新的“零日漏洞”來進行攻擊的專業安全廠商，比微軟自身發現的還早，並在第一時間協助微軟修復此漏洞，發布漏洞補丁。
“超級工廠”之所以沒有同步在中國大爆發，最根本的原因是“超級工廠”的幕後團隊並沒有在第一時間把中國當成攻擊目標，並不是因為中國有多少人安裝了360。如360宣稱的那樣，360依靠的是幫助用戶打微軟補丁防禦“超級工廠”，這就意味著在微軟發布補丁之前，360是沒法防禦“超級工廠”的。如果“超級工廠”第一時間就攻擊中國，那么安裝了360的3億網民（360官方數據）將全部“淪陷”，無一能逃。
卡巴斯基實驗室認為，像360這樣的非專業安全廠商，沒有相應的技術和能力在第一時間截獲“超級工廠”，不能對“超級工廠”這樣的惡性病毒做出深入而合理的分析，是可以理解的。但是，360掩飾自己的不足，就“超級工廠”發表嚴重背離事實，混淆視聽的官方新聞，是完全不能接受的。360的言論很容易讓很多普通用戶認為裝了360就能抵禦類似“超級工廠”這樣的惡性病毒。如果長期容忍這種欺騙用戶、不顧事實的假宣傳在安全行業蔓延，那么整箇中國的網際網路安全形勢將進一步惡化，越來越多的最終用戶會因為得不到正確的安全知識和專業的安全保護而受到傷害，遭遇更大的損失。
卡巴斯基實驗室
2010年10月13日
360關於卡巴斯基聲明的回應
360回應：卡巴斯基對“超級工廠”的反應遲到了3個月 來源：360安全中心 發布日期：2010-10-13
最近，360隱私保護器引發了騰訊公司的激烈反應。根據以往經驗，每當360為了用戶利益而與其它廠商發生衝突的時候，總部設在俄羅斯的卡巴斯基公司總會不失時機地在背後發表攻擊360的言論，譬如發表“回頭是岸”公開信，又譬如發表所謂免費防毒的“N宗罪”。這一次也不例外，10月13日，卡巴斯基公開散布名為《360欺騙4億網民胡亂解讀“超級工廠”病毒》的文章，為了掩蓋卡巴斯基對Stuxnet超級工廠病毒防護不力、反應遲鈍的真相，故意歪曲事實，對360進行大肆攻擊。鑒於卡巴斯基的聲明與事實嚴重不符、並使用了侮辱性的語言，360公司決定正式起訴卡巴斯基（中國）。
對卡巴斯基的文章，360公司回應如下：
一、360安全衛士在7月17日就能防禦和查殺Stuxnet病毒，7月21日首家發布應急補丁，比微軟官方補丁早兩周
卡巴斯基聲稱“360依靠的是幫助用戶打微軟補丁防禦‘超級工廠’，這就意味著在微軟發布補丁之前，360是沒法防禦‘超級工廠’的。”
事實的真相是，Stuxnet超級工廠病毒最早由賽門鐵克在7月15日截獲。7月17日，360安全中心在國內率先發現Stuxnet病毒樣本，當時命名為“假面”。當天，360木馬防火牆就通過升級迅速攔截了該病毒。7月21日，360安全衛士率先針對Stuxnet攻擊的“捷徑自動執行”漏洞發布應急補丁，徹底堵死了Stuxnet病毒針對“捷徑自動執行”漏洞的攻擊，比微軟官方8月3日修復漏洞（MS10-046）的日期早兩周！
同時，360依賴自身強大的木馬防火牆（主動防禦技術），即使用戶在不打微軟補丁修復漏洞的前提下，360安全衛士和360防毒都可以完全攔截Stuxnet病毒，包括該病毒帶有Realtek和JMicron數字證書的版本。
7月17日，360橙色安全警報《微軟0DAY漏洞遭利用“假面”木馬化身捷徑》
7月21日，《微軟高危漏洞將遭大規模攻擊360提供應急補丁》
二、為什麼卡巴斯基在抵抗Stuxnet超級工廠病毒時姍姍來遲
在Stuxnet病毒剛剛出現的7月，卡巴斯基並沒有對Stuxnet做出任何反應。原因在於，Stuxnet採用了“父進程注入”的攻擊方式，直接把病毒代碼注入到卡巴斯基所有版本的進程中，能夠輕鬆繞開或破壞卡巴斯基的防護。而這類攻擊方式在國內木馬病毒中非常普遍，例如2009年感染量上百萬的“刺陵”木馬家族，而360安全衛士早已能夠完美防禦“父進程注入”攻擊。
圖：Stuxnet用“父進程注入”攻擊破壞的防毒軟體列表，其中第1、2位即為卡巴斯基
三、Stuxnet沒有在中國爆發的真實原因
在Stuxnet超級工廠病毒的傳播過程中，最主要的傳播途徑是攻擊“捷徑自動執行漏洞”（MS10-046），此外還有WindowsServer服務的遠程溢出漏洞（MS08-067）以及列印後台程式服務中的遠程代碼執行漏洞（MS10-061）。在入侵目標電腦系統後，Stuxnet會再利用Windows作業系統的兩個本地許可權提升漏洞來獲得系統控制權。
從Stuxnet病毒出現在國內第一時間算起，360安全衛士當天升級了木馬防火牆，就能夠攔截Stuxnet病毒。隨後，360又發布了徹底免疫“捷徑自動執行漏洞”的應急補丁，短短2周內，即為用戶攔截了超過30萬次相應的漏洞攻擊，阻止了漏洞危害在國內的擴散。由此可見，國內早有大批木馬病毒採用Stuxnet的漏洞攻擊技術，正因為有360的存在，在微軟發布補丁前及時防禦病毒，在微軟發布補丁後徹底修復漏洞，為阻止國內出現Stuxnet病毒疫情做出了貢獻。而卡巴斯基所謂“中國躲過Stuxnet是因為該病毒不針對中國”的說法，是完全不正確的。
反觀自命專業的卡巴斯基，被Stuxnet使用簡單的“父進程注入”技術破壞後，一直沒有修復自身存在的缺陷。目前國內外已經有大量木馬借用Stuxnet的技術攻擊卡巴斯基，使所有卡巴斯基的用戶面臨安全威脅，在此，我們鄭重建議卡巴斯基正視自身的問題，解決用戶的實際需要。
四、360多次率先發現並為高危零日漏洞提供解決方案
誠然，Stuxnet超級工廠病毒首先出現在國外，其利用的捷徑自動執行漏洞（MS10-046）、列印後台程式服務中的遠程代碼執行漏洞（MS10-061）都並非360安全中心首家發現。但是在過去3年間，360安全中心已經多次在全球率先發現高危漏洞攻擊，包括IEXML漏洞、微軟Directshow視頻開發包漏洞、Office網頁組件漏洞等。
由於360系列安全軟體覆蓋了中國80%以上的個人電腦，當這些漏洞攻擊出現在中國網際網路上時，無一例外由360率先截獲，並因此成為國內唯一受到微軟公開致謝的個人電腦安全廠商。而根據艾瑞諮詢最新數據，截至今年8月份，卡巴斯基在中國安全軟體市場覆蓋率僅為3.35%，而這個數字仍在繼續下降。可想而知，卡巴在中國能截獲的最新木馬病毒和相應的攻擊數量與360相比將如何。
我們希望卡巴斯基方面能夠尊重事實，而不是用片面的說辭攻擊同行。畢竟，一款軟體好不好用，有沒有真正保護用戶的安全，用戶說了算，360用戶量的迅猛上升和卡巴斯基的直線下跌已經說明了一切。
