病毒|PLC|工業(yè)網(wǎng)絡(luò)-Stuxnet病毒是如何進(jìn)入和感染PLC
1. 如何選擇需要感染的PLC。 Stuxnet會(huì)根據(jù)目標(biāo)系統(tǒng)的特點(diǎn),使用不同的代碼來(lái)感染PLC。 一個(gè)感染的序列包括了許多PLC 模塊(代碼模塊和數(shù)據(jù)模塊),用以注入PLC來(lái)改變目標(biāo)PLC 的行為。這個(gè)威脅包括了三個(gè)感染序列。其中兩個(gè)非常相似,功能也相同,我們將其命名為序列A和B。第三個(gè)序列我們命名為序列C。Stuxnet通過(guò)驗(yàn)證“指紋”來(lái)判斷系統(tǒng)是否為計(jì)劃攻擊的目標(biāo)。它會(huì)檢查: PLC種類/家族:只有CPU 6ES7-417 和6ES7-315-2 會(huì)被感染。系統(tǒng)數(shù)據(jù)模塊:SDB 會(huì)被解析;根據(jù)他們包含的數(shù)據(jù),感染進(jìn)程會(huì)選擇A,B或其它感染方式開始行動(dòng)。當(dāng)解析SDB 時(shí),代碼會(huì)搜索這兩個(gè)值是否存在-- 7050h and 9500h;然后根據(jù)這兩個(gè)數(shù)值的出現(xiàn)次數(shù),選擇序列A 或B 中的一種來(lái)感染PLC。 代碼還會(huì)在SDB 模塊的50h 子集中搜索字節(jié)序2C CB 00 01, 這個(gè)字節(jié)序反映了通信處理器CP 342-5 (用作Profibus-DP) 是否存在。 而選擇序列C進(jìn)行感染的條件則由其他因素構(gòu)成。
2. 感染方法 Stuxnet使用“代碼插入”的感染方式。當(dāng)Stuxnet 感染OB1時(shí),它會(huì)執(zhí)行以下行為: 增加原始模塊的大??; 在模塊開頭寫入惡意代碼; 在惡意代碼后插入原始的OB1 代碼。Stuxnet也會(huì)用類似于感染OB1的方式感染OB35。它會(huì)用自身來(lái)取代標(biāo)準(zhǔn)的協(xié)同處理器DP_RECV 代碼塊,然后在Profibus (一個(gè)標(biāo)準(zhǔn)的用作分布式I/O的工業(yè)網(wǎng)絡(luò)總線) 中掛鉤網(wǎng)絡(luò)通信。 利用A/B方法的感染步驟如下: 檢查PLC 類型; 該類型必須為S7/315-2; 檢查SDB 模塊,判斷應(yīng)該寫入序列A 或B 中的哪一個(gè); 找到DP_RECV,將其復(fù)制到FC1869,并用Stuxnet嵌入的一個(gè)惡意拷貝將其取代; 在序列中寫入惡意模塊(總共20個(gè)),由Stuxnet 嵌入; 感染OB1,令惡意代碼可以在新的周期開始時(shí)執(zhí)行; 感染OB35, 它將扮演“看門狗”的角色。
3. 感染代碼 被注入OB1 功能的代碼是用來(lái)感染序列A 和B的。這些序列包含了以下模塊: 代碼塊:FC1865 至FC1874, FC1876 至FC1880 (注意:FC1869并非Stuxnet的一部分,而是PLC的DP_RECV模塊的一個(gè)拷貝); 數(shù)據(jù)模塊:DB888 至DB891。 序列A 和B 用DP_RECV 掛鉤模塊來(lái)攔截Profibus 中的數(shù)據(jù)包,并根據(jù)在這些模塊中找到的數(shù)值,來(lái)構(gòu)造其他的數(shù)據(jù)包并發(fā)送出去。這由一個(gè)復(fù)雜的狀態(tài)機(jī)控制(狀態(tài)機(jī)被建立在上面提到的FC 模塊中)。這個(gè)狀態(tài)機(jī)可部分受控于數(shù)據(jù)塊DB890 中的DLL。 在某些條件下,序列C會(huì)被寫入一個(gè)PLC。這個(gè)序列比A和B包含更多的模塊: FC6055 至FC6084;DB8062, DB8063;DB8061, DB8064 至DB8070 (在運(yùn)行中產(chǎn)生)。 序列C主要為了將I/O信息讀寫入PLC的內(nèi)存文件映射的I/O 區(qū)域,以及外圍設(shè)備的I/O。 程序A/B 的控制流如下圖所示,在之前的Step7 編輯器的截圖中也有部分顯示(數(shù)據(jù)模塊FC1873)
4. Rootkit Stuxnet PLC rootkit代碼全部藏身于假冒的s7otbxdx.dll中。為了不被PLC所檢測(cè)到,它至少需要應(yīng)付以下情況: 對(duì)自己的惡意數(shù)據(jù)模塊的讀請(qǐng)求;對(duì)受感染模塊(OB1 , OB35, DP_RECV) 的讀請(qǐng)求;可能覆蓋Stuxnet自身代碼的寫請(qǐng)求。 Stuxnet包含了監(jiān)測(cè)和攔截這些請(qǐng)求的代碼,它會(huì)修改這些請(qǐng)求以保證Stuxnet 的PLC 代碼不會(huì)被發(fā)現(xiàn)或被破壞。下面列出了幾個(gè)Stuxnet用被掛鉤的導(dǎo)出命令來(lái)應(yīng)付這些情況的例子: s7blk_read: 監(jiān)測(cè)讀請(qǐng)求,而后Stuxnet 會(huì)返回:真實(shí)請(qǐng)求的DP_RECV (保存為FV1869);錯(cuò)誤信息,如果讀請(qǐng)求會(huì)涉及到它的惡意模塊;OB1或OB35的干凈版本的拷貝s7blk_write: 監(jiān)測(cè)關(guān)于OB1/OB35的寫請(qǐng)求,以保證他們的新版本也會(huì)被感染。s7blk_findfirst / s7blk_findnext: 這些例程被用于枚舉PLC中的模塊。惡意模塊會(huì)被自動(dòng)跳過(guò)。s7blk_delete: 監(jiān)測(cè)對(duì)模塊的“刪除”操作。 如上文所述,Stuxnet 是一個(gè)非常復(fù)雜的威脅,而其中的PLC 感染代碼令問(wèn)題更加難以解決。僅僅關(guān)于注入的MC7代碼(我們于幾個(gè)月前通過(guò)逆向工程獲得)就可以討論很久。若想了解更多關(guān)于PLC 感染例程和Stuxnet的總體情況,請(qǐng)務(wù)必關(guān)注我們即將于Virus Bulletin會(huì)議中發(fā)布的白皮書。
評(píng)論排行