久久久91-久久久91精品国产一区二区-久久久91精品国产一区二区三区-久久久999国产精品-久久久999久久久精品

OPC基金會(huì)于2006年開(kāi)發(fā)，用于可靠和重要的工業(yè)網(wǎng)絡(luò)中不同系統(tǒng)之間的數(shù)據(jù)安全傳輸。該標(biāo)準(zhǔn)是其前身OPC協(xié)議的改進(jìn)版本，在現(xiàn)代工業(yè)環(huán)境中幾乎“無(wú)處不在”，因其能夠?qū)崿F(xiàn)原始數(shù)據(jù)以及預(yù)處理信息的處理，并且實(shí)現(xiàn)了安全地從制造績(jī)效到生產(chǎn)計(jì)劃或者EOPC UAR層級(jí)的傳輸過(guò)程，通過(guò)該技術(shù)的應(yīng)用能夠消除空間時(shí)間的影響，任何地點(diǎn)和時(shí)間都可以授權(quán)應(yīng)用。

基于不同供應(yīng)商產(chǎn)品的監(jiān)控系統(tǒng)通常使用是互不兼容的，通常是專有的網(wǎng)絡(luò)通信協(xié)議。OPC網(wǎng)關(guān)或服務(wù)器用做不同工業(yè)控制系統(tǒng)與遙測(cè)、監(jiān)控和遙控系統(tǒng)之間的接口，統(tǒng)一工業(yè)企業(yè)的控制流程；這種功能獨(dú)立于制造廠商，屬于一種操作系統(tǒng)和編程語(yǔ)言。

OPC UA是目前已經(jīng)使用的工業(yè)標(biāo)準(zhǔn)的補(bǔ)充，更有效地對(duì)擴(kuò)展性、工業(yè)互聯(lián)網(wǎng)適應(yīng)性以及獨(dú)立性做了完善工作；研究OPC UA安全性，可以幫助工業(yè)自動(dòng)化系統(tǒng)和工業(yè)軟件的供應(yīng)商實(shí)現(xiàn)對(duì)現(xiàn)代網(wǎng)絡(luò)攻擊的更高級(jí)別的保護(hù)，此外對(duì)其安全性研究的技術(shù)細(xì)節(jié)和發(fā)現(xiàn)有助于軟件提供商控制其產(chǎn)品質(zhì)量，也有助于安全研究人員對(duì)工業(yè)通訊協(xié)議的研究工作。

1　OPC UA的二進(jìn)制安全性

OPC UA在設(shè)計(jì)之初是為支持兩種數(shù)據(jù)類型的數(shù)據(jù)傳輸而設(shè)計(jì)的，即傳統(tǒng)的二進(jìn)制格式（用于以前版本的標(biāo)準(zhǔn)）和SOAP/XML。現(xiàn)在，SOAP/XML格式的數(shù)據(jù)傳輸已被安全界認(rèn)為是過(guò)時(shí)的，在現(xiàn)代產(chǎn)品和服務(wù)中幾乎沒(méi)有再被使用。由于它在工業(yè)自動(dòng)化系統(tǒng)中被廣泛應(yīng)用的前景是模糊的，因此將研究重點(diǎn)放在二進(jìn)制格式上是明智的。

分析使用OPC UA的系統(tǒng)時(shí)發(fā)現(xiàn)，大多數(shù)執(zhí)行文件使用了名為“uastack.dll”的鏈接庫(kù)。通過(guò)搭建基于突變的fuzzing測(cè)試環(huán)境研究其安全性，算法結(jié)構(gòu)為：讀取輸入數(shù)據(jù)數(shù)列、讀取輸入數(shù)據(jù)序列、對(duì)執(zhí)行偽隨機(jī)轉(zhuǎn)換、通過(guò)網(wǎng)絡(luò)將結(jié)果序列發(fā)送到程序作為輸入、接收服務(wù)器的響應(yīng)、重復(fù)。在開(kāi)發(fā)了一組基本的突變（bitflip、byteflip、算術(shù)變異、插入幻數(shù)、重置數(shù)據(jù)序列、使用長(zhǎng)數(shù)據(jù)序列）之后，研究人員成功地識(shí)別了uastack.dll中的第一個(gè)漏洞。它是一個(gè)堆損壞的漏洞，成功地利用它可以使攻擊者執(zhí)行遠(yuǎn)程代碼執(zhí)行（RCE），在這種情況下，他們就可以使用NT權(quán)限/系統(tǒng)特權(quán)。研究人員識(shí)別的漏洞是由處理數(shù)據(jù)的函數(shù)造成的，這些數(shù)據(jù)是從一個(gè)套接字中讀取的，這些函數(shù)錯(cuò)誤地計(jì)算了數(shù)據(jù)的大小，然后將數(shù)據(jù)復(fù)制到堆上創(chuàng)建的緩沖區(qū)中。

另外，在使用UA .NET堆棧的.NET應(yīng)用程序的過(guò)程中，在分析wireshark中應(yīng)用程序的流量時(shí)，注意到一些數(shù)據(jù)包有一個(gè)is_xml位字段，其值為0。在分析應(yīng)用程序的過(guò)程中，研究人員發(fā)現(xiàn)它使用了XmlDocument函數(shù)，該函數(shù)很容易被.NET版本4.5和之前的XXE攻擊所攻擊。這意味著，如果我們將is_xml位字段的值從0更改為1，并將特制的XML數(shù)據(jù)包添加到請(qǐng)求主體（XXE攻擊），將能夠讀取遠(yuǎn)程計(jì)算機(jī)上的任何具有NT權(quán)限/系統(tǒng)特權(quán)的文件，并且在某些情況下還可以執(zhí)行遠(yuǎn)程代碼執(zhí)行（RCE）。

2　OPC UA協(xié)議分析

為了找出OPC基金會(huì)實(shí)施OPC UA協(xié)議的漏洞，研究包括：OPC UA棧（ANSI C、.NET、JAVA）、使用OPC UA棧的OPC Foundation應(yīng)用程序（例如上述的OPC UA .NET Discovery Server）、其他使用OPC UA棧應(yīng)用程序的軟件開(kāi)發(fā)人員。

2.1　將UA ANSI C棧進(jìn)行Fuzzing測(cè)試化處理

使用OPC基金會(huì)開(kāi)發(fā)者提供的標(biāo)準(zhǔn)鏈接庫(kù)，通常難以發(fā)現(xiàn)其漏洞，通過(guò)使用OPC基金會(huì)提供的源碼（包含于UA ANSI C棧的示例服務(wù)器），對(duì)其代碼進(jìn)行手工Fuzzing測(cè)試，有助于研究人員了解是否將新功能加入到UA ANSI C棧的特定實(shí)現(xiàn)中。

為加速Fuzzing測(cè)試，研究人員重載了網(wǎng)絡(luò)函數(shù)socket/sendto/recvfrom/accept/bind/select，從本地文件讀取輸入的數(shù)據(jù)，而不是連接到網(wǎng)絡(luò)。另外研究人員還使用AddressSanitizer（內(nèi)存問(wèn)題的排查工具和方法）編譯了程序。為了將剛開(kāi)始發(fā)現(xiàn)的一組示例集合在一起，我們使用了與第一個(gè)Fuzzing測(cè)試相同的技術(shù)，即使用抓包工具tcpdump從任意客戶端應(yīng)用程序中捕獲流量。另外，通過(guò)改進(jìn)Fuzzing測(cè)試技術(shù)，專門(mén)為OPC UA和特殊突變創(chuàng)建了字典。

從OPC UA中的二進(jìn)制數(shù)據(jù)傳輸格式的規(guī)范可以看出，對(duì)于AFL來(lái)說(shuō)，從OPC UA（\xff\xff\xff）中的一個(gè)空字符串的二進(jìn)制轉(zhuǎn)變?yōu)橐粋€(gè)包含4個(gè)隨機(jī)字節(jié)的字符串（如\x04\x00\x00\x00AAAA），是非常困難的。因此，開(kāi)發(fā)了一個(gè)轉(zhuǎn)變機(jī)制，它與OPC UA內(nèi)部結(jié)構(gòu)一起工作，根據(jù)它們的類型隨時(shí)轉(zhuǎn)變。包含所有改進(jìn)的Fuzzing測(cè)試之后，可以在較短時(shí)間內(nèi)（分鐘級(jí)）發(fā)現(xiàn)程序的崩潰情況。崩潰時(shí)創(chuàng)建的內(nèi)存轉(zhuǎn)儲(chǔ)的分析，能夠識(shí)別UA ANSI C棧中的一個(gè)漏洞，如果該漏洞被利用，可能會(huì)導(dǎo)致DoS攻擊。

2.2　利用Fuzzing分析使用OPC UA的應(yīng)用程序

任何使用OPC UA協(xié)議棧的應(yīng)用程序的兩個(gè)主要函數(shù)都是OpcUa_Endpoint_Create和OpcUa_Endpoint_Open，OpcUa_Endpoint_Create函數(shù)為應(yīng)用程序提供有關(guān)服務(wù)器和客戶端之間可用的數(shù)據(jù)通信通道以及可用服務(wù)列表的信息。OpcUa_Endpoint_Open則定義了可用的網(wǎng)絡(luò)和它將提供的加密模式。可用服務(wù)列表使用服務(wù)表來(lái)定義，該表列出了數(shù)據(jù)結(jié)構(gòu)并提供了每個(gè)服務(wù)的詳細(xì)信息。每一個(gè)結(jié)構(gòu)都包含所支持的請(qǐng)求類型、響應(yīng)類型以及在請(qǐng)求預(yù)處理和后處理期間將調(diào)用的兩個(gè)回調(diào)函數(shù)。另外，預(yù)處理函數(shù)在大多數(shù)情況下都表示為“stubs”。將轉(zhuǎn)換器代碼包含在請(qǐng)求預(yù)處理函數(shù)中。該函數(shù)使用突變數(shù)據(jù)進(jìn)行輸入、輸出與請(qǐng)求類型匹配的正確結(jié)構(gòu)。這樣可以跳過(guò)應(yīng)用程序啟動(dòng)階段，直接啟動(dòng)一個(gè)事件循環(huán)來(lái)創(chuàng)建一個(gè)單獨(dú)的線程讀取偽套接字等。使得Fuzzing測(cè)試從50個(gè)exec/s的數(shù)量級(jí)加速到2000個(gè)exec/s。

使用以這種方式改進(jìn)的fuzzing測(cè)試方法，安全人員目前已經(jīng)在OPC基金會(huì)應(yīng)用程序中發(fā)現(xiàn)了很多漏洞。

2.3　分析使用OPC UA棧的第三方應(yīng)用程序

在對(duì)OPC基金會(huì)產(chǎn)品完成了分析后，還應(yīng)分析使用OPC UA棧的商業(yè)產(chǎn)品。利用滲透測(cè)試中使用的ICS系統(tǒng)，分析了一些他們客戶的設(shè)備安全狀況，選擇不同廠商的幾種產(chǎn)品，其中包括全球領(lǐng)先的解決方案。在得到批準(zhǔn)后，研究人員就開(kāi)始分析這些產(chǎn)品中OPC UA協(xié)議的實(shí)現(xiàn)過(guò)程。

在搜索二進(jìn)制漏洞時(shí)，F(xiàn)uzzing測(cè)試是最有效的技術(shù)之一。在以前的案例中，當(dāng)分析Linux系統(tǒng)上的產(chǎn)品時(shí)，研究人員使用的就是源代碼二進(jìn)制檢測(cè)技術(shù)和AFL Fuzzing測(cè)試器。但是，本文分析時(shí)使用的OPC UA棧的商業(yè)產(chǎn)品由于是在Windows上運(yùn)行，對(duì)此，要用一種稱為AFLFuzzing的測(cè)試器。簡(jiǎn)而言之，WinAFL是移植到Windows的AFLFuzzing測(cè)試器。但是，由于操作系統(tǒng)的不同，兩個(gè)Fuzzing測(cè)試器在一些關(guān)鍵功能方面，還是有所不同的。由于WinAFL不是使用來(lái)自Linux內(nèi)核的系統(tǒng)調(diào)用，所以它是使用WinAPI函數(shù)而不是靜態(tài)源代碼工具，它使用DynamoRIO動(dòng)態(tài)檢測(cè)二進(jìn)制文件。總體而言，這些差異意味著WinAFL的性能顯著低于AFL。

在WinAFL fuzzer的源代碼中開(kāi)發(fā)者留下Fuzzing測(cè)試網(wǎng)絡(luò)應(yīng)用程序的評(píng)論。根據(jù)這些評(píng)論，對(duì)網(wǎng)絡(luò)Fuzzing測(cè)試進(jìn)行一些修改。具體地，在模糊測(cè)試的代碼中包含了與本地網(wǎng)絡(luò)應(yīng)用程序通信的功能。因此，F(xiàn)uzzing測(cè)試器不會(huì)執(zhí)行程序，而是通過(guò)網(wǎng)絡(luò)將有效載荷發(fā)送到已在DynamoRIO下運(yùn)行的應(yīng)用程序。

但是，只能達(dá)到5 exec/s數(shù)量級(jí)的Fuzzing測(cè)試率，即使使用像AFL這樣的智能Fuzzing測(cè)試器也會(huì)花費(fèi)很長(zhǎng)時(shí)間才能發(fā)現(xiàn)漏洞。因此，繼續(xù)改進(jìn)前文所述的Fuzzing測(cè)試方法進(jìn)行脆弱性測(cè)試。

（1）改進(jìn)突變機(jī)制，根據(jù)傳輸?shù)絆PC UA棧的數(shù)據(jù)類型來(lái)修改數(shù)據(jù)生成算法。

（2）為每種支持的服務(wù)創(chuàng)建了一組示例（pythonopcua庫(kù)，其中包含了與幾乎所有可能的OPC UA服務(wù)交互的功能）。

（3）當(dāng)使用帶有動(dòng)態(tài)二進(jìn)制工具的Fuzzing測(cè)試器來(lái)測(cè)試像這樣的多線程應(yīng)用程序時(shí)，在應(yīng)用程序代碼中搜索新程序是一項(xiàng)非常復(fù)雜的任務(wù)，因?yàn)楹茈y確定哪些輸入數(shù)據(jù)會(huì)導(dǎo)致應(yīng)用程序的不正當(dāng)行為。由于Fuzzing測(cè)試器是通過(guò)網(wǎng)絡(luò)與應(yīng)用程序通信的，并且研究人員可以在服務(wù)器的響應(yīng)和發(fā)送給它的數(shù)據(jù)之間建立清晰的連接（因?yàn)橥ㄐ攀窃谝粋€(gè)會(huì)話的范圍內(nèi)進(jìn)行的），所以研究人員不需要解決這個(gè)問(wèn)題，而是利用一種算法，該算法可以在從服務(wù)器接收之前尚未觀察到新響應(yīng)時(shí)，簡(jiǎn)單地識(shí)別出新的執(zhí)行路徑。

經(jīng)過(guò)改進(jìn)，F(xiàn)uzzing測(cè)試速度每秒執(zhí)行次數(shù)從1次或2次增加到70次，這對(duì)于網(wǎng)絡(luò)Fuzzing測(cè)試來(lái)說(shuō)就非常好。基于此發(fā)現(xiàn)了另外兩個(gè)無(wú)法使用智能Fuzzing測(cè)試識(shí)別的新漏洞。

3　OPC UA的脆弱性測(cè)試結(jié)論

截至2021年，上述漏洞已被識(shí)別和關(guān)閉，另外還發(fā)現(xiàn)了使用這些產(chǎn)品的商業(yè)應(yīng)用程序中的一些漏洞。目前，已經(jīng)向易受攻擊軟件產(chǎn)品的開(kāi)發(fā)人員報(bào)告了所有發(fā)現(xiàn)的漏洞。

在大多數(shù)情況下，使用OPC UA棧的第三方軟件中的漏洞是由于開(kāi)發(fā)人員未正確使用OPC基金會(huì)uastack.dll庫(kù)中實(shí)現(xiàn)的API功能而導(dǎo)致的，例如，傳輸?shù)臄?shù)據(jù)結(jié)構(gòu)中的字段值被錯(cuò)誤地解釋。

另外，在某些情況下，產(chǎn)品漏洞是由商業(yè)軟件開(kāi)發(fā)商對(duì)uastack.dll庫(kù)所做的修改引起的。例如，從套接字讀取數(shù)據(jù)的函數(shù)的不安全實(shí)現(xiàn)。值得注意的是，OPC基金會(huì)最初計(jì)劃實(shí)施的功能并未包含此漏洞。雖然并不知道開(kāi)發(fā)者為什么要修改數(shù)據(jù)讀取邏輯，但顯然開(kāi)發(fā)人員并沒(méi)有意識(shí)到OPC基金會(huì)在其中包含的附加檢查是多么的重要，因?yàn)橐磺邪踩δ苁墙⒃诟郊訖z查之上的。

在分析商業(yè)軟件的過(guò)程中發(fā)現(xiàn)開(kāi)發(fā)人員已經(jīng)從OPC UA棧實(shí)施示例中借用了代碼，并將該代碼逐字復(fù)制到其應(yīng)用程序中。顯然，他們認(rèn)為OPC基金會(huì)確保這些代碼片段的安全性與確保庫(kù)中使用的代碼安全性的方式相同。不幸的是，這個(gè)假設(shè)是錯(cuò)誤的。

以上這些漏洞會(huì)導(dǎo)致黑客發(fā)起DoS攻擊和遠(yuǎn)程執(zhí)行代碼。重要的是，在工業(yè)系統(tǒng)中，DoS攻擊漏洞比任何其它漏洞造成的威脅都大。例如，工業(yè)控制系統(tǒng)中的拒絕服務(wù)可能導(dǎo)致企業(yè)遭受重大經(jīng)濟(jì)損失，并且在某些情況下甚至?xí)?dǎo)致施工過(guò)程中斷和關(guān)閉。

4　結(jié)語(yǔ)

OPC基金會(huì)的開(kāi)放源代碼表明其發(fā)布的協(xié)議是開(kāi)放的，并致力于讓使用它的商業(yè)產(chǎn)品更加安全。同時(shí)，分析表明，目前OPC UA協(xié)議棧的實(shí)施不僅不普及，而且還存在一系列重大的基礎(chǔ)問(wèn)題。

首先，使用OPC UA棧的商業(yè)開(kāi)發(fā)人員對(duì)OPCUA棧的設(shè)計(jì)意圖不是很了解。該協(xié)議當(dāng)前實(shí)現(xiàn)中存在著有大量的指針計(jì)算，不安全的數(shù)據(jù)結(jié)構(gòu)，變化常量，函數(shù)之間復(fù)制的參數(shù)驗(yàn)證代碼以及在代碼中分散的其他過(guò)時(shí)特性。由于軟件開(kāi)發(fā)人員為了使他們的產(chǎn)品更安全，傾向于從代碼中清除這些功能。但由于被刪改的代碼沒(méi)有很好的記錄機(jī)制，這使得在使用或修改過(guò)程中更容易引入其他錯(cuò)誤。

其次，利用OPC UA的商業(yè)開(kāi)發(fā)人員顯然低估了OPC基金會(huì)聯(lián)盟提供的所有代碼的信任軟件供應(yīng)商。盡管API使用示例未包含在OPC基金會(huì)認(rèn)證的產(chǎn)品列表中，但在API使用示例代碼中留下漏洞是完全錯(cuò)誤的。

OPC UA開(kāi)發(fā)人員在進(jìn)行產(chǎn)品安全測(cè)試時(shí)，并未使用類似于本文所描述的模糊測(cè)試技術(shù)。由于開(kāi)放的源代碼不包括單元測(cè)試或任何其他自動(dòng)測(cè)試的代碼，這就使得產(chǎn)品的開(kāi)發(fā)人員在修改代碼產(chǎn)品時(shí)，更加難以利用模糊測(cè)試技術(shù)來(lái)測(cè)試OPC UA棧的安全。

盡管OPC UA的開(kāi)發(fā)人員試圖確保他們的產(chǎn)品安全，但他們?nèi)匀缓鲆暳税踩幋a的一些前提和技術(shù)。當(dāng)前的OPC UA棧實(shí)現(xiàn)不僅不能保護(hù)開(kāi)發(fā)人員免受一些小漏洞的影響，而且還容易引發(fā)更多的漏洞。考慮到現(xiàn)實(shí)情況，研究人員認(rèn)為目前商業(yè)產(chǎn)品還是慎用OPC UA。

摘自《自動(dòng)化博覽》2022年5月刊