国产欧美日韩精品a在线观看-国产欧美日韩精品一区二区三区-国产欧美日韩精品综合-国产欧美中文字幕-一区二区三区精品国产-一区二区三区精品国产欧美

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

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

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

1　OPC UA的二進制安全性

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

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

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

2　OPC UA協(xié)議分析

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

2.1　將UA ANSI C棧進行Fuzzing測試化處理

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

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

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

2.2　利用Fuzzing分析使用OPC UA的應用程序

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

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

2.3　分析使用OPC UA棧的第三方應用程序

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4　結(jié)語

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

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

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

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

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

摘自《自動化博覽》2022年5月刊