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

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

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

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

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

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

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

2　OPC UA協(xié)議分析

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

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

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

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

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

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

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

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

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

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

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

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

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

（1）改進(jìn)突變機制，根據傳輸到OPC UA棧的數據類(lèi)型來(lái)修改數據生成算法。

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

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

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

3　OPC UA的脆弱性測試結論

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

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

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

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

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

4　結語(yǔ)

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

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

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

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

盡管OPC UA的開(kāi)發(fā)人員試圖確保他們的產(chǎn)品安全，但他們仍然忽視了安全編碼的一些前提和技術(shù)。當前的OPC UA棧實(shí)現不僅不能保護開(kāi)發(fā)人員免受一些小漏洞的影響，而且還容易引發(fā)更多的漏洞?？紤]到現實(shí)情況，研究人員認為目前商業(yè)產(chǎn)品還是慎用OPC UA。

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