日本在线www-日本在线播放一区-日本在线不卡免费视频一区-日本在线不卡视频-成人影院久久久久久影院-成人影院一区二区三区

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

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

OPC UA是目前已經使用的工業標準的補充，更有效地對擴展性、工業互聯網適應性以及獨立性做了完善工作；研究OPC UA安全性，可以幫助工業自動化系統和工業軟件的供應商實現對現代網絡攻擊的更高級別的保護，此外對其安全性研究的技術細節和發現有助于軟件提供商控制其產品質量，也有助于安全研究人員對工業通訊協議的研究工作。

1　OPC UA的二進制安全性

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

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

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

2　OPC UA協議分析

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）改進突變機制，根據傳輸到OPC UA棧的數據類型來修改數據生成算法。

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

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

經過改進，Fuzzing測試速度每秒執行次數從1次或2次增加到70次，這對于網絡Fuzzing測試來說就非常好。基于此發現了另外兩個無法使用智能Fuzzing測試識別的新漏洞。

3　OPC UA的脆弱性測試結論

截至2021年，上述漏洞已被識別和關閉，另外還發現了使用這些產品的商業應用程序中的一些漏洞。目前，已經向易受攻擊軟件產品的開發人員報告了所有發現的漏洞。

在大多數情況下，使用OPC UA棧的第三方軟件中的漏洞是由于開發人員未正確使用OPC基金會uastack.dll庫中實現的API功能而導致的，例如，傳輸的數據結構中的字段值被錯誤地解釋。

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

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

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

4　結語

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

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

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

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

盡管OPC UA的開發人員試圖確保他們的產品安全，但他們仍然忽視了安全編碼的一些前提和技術。當前的OPC UA棧實現不僅不能保護開發人員免受一些小漏洞的影響，而且還容易引發更多的漏洞。考慮到現實情況，研究人員認為目前商業產品還是慎用OPC UA。

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