寫在前面

前面我們說了工業控制系統的各種通訊協議，大家肯定會想到PROFINET、ETHERNET/IP、ETHERCAT等工業以太網：

最詳細的工業網絡通訊技術與協議總結解讀（現場總線、工業以太網、工業無線）

技術解讀PROFINET、Ethernet/IP等7種主流工業以太網

最全整理工業通訊上的領域各種總線+協議+規范+接口—數據采集與控制

對于工控協議，除了大家所熟知的modbus opcua等，西門子、施耐德等廠商也開發了自己的私有協議，如大家所熟知的西門子S7comm/S7commPlus，施耐德的UMAS等，前面我們就詳細分析過S7以及Ethernet/IP等：

S7-1200+SCADA：詳解西門子S7協議與數據讀寫

入門工業通訊之EtherNet/IP協議分析
基于S7協議對西門子PLC S7-1500的漏洞分析與復現（附演示視頻）

今天我們來聊一聊西門子S7 PLC漏洞攻擊實驗～

近期關注了文章“Vulnerability analysis of S7 PLCs：Manipulating the security mechanism”，文章對Siemens PLC環境（特別是S7CommPlus 的通信協議）進行了深入分析。研究人員使用WinDbg和Scapy工具，對協議中使用的反重放機制進行了研究，包括創建有效網絡數據包所需的特定字節的標識，文章基于試驗性分析方式，對新漏洞（包括對加密密鑰的操作）進行了研究，演示了利用漏洞進行通信會話session、使工程師無法配置PLC 、對PLC工作狀態進行未經授權的更改、以及其他對完整性和可用性的破壞。原文較長，本文僅對文章區別于當前已有資料的獨到分析和總結之處進行翻譯和概括，以饗讀者。

1、相關研究

前期已有對S7-1200/S7-1500 PLC的研究文章，對S7ComPlus協議的多個版本做了分析，下圖對此作了梳理：

S7-1200 和 S7-1500 PLC 協議和安全性比較的基本情況如下:

S7CommPlus協議在 TCP (TTPKT)和面向連接的傳輸協議 (COTP) 上運行，用于在 PLC 和工程軟件之間傳輸關鍵的操作和配置信息、例如 PLC 邏輯、診斷信息、配置詳細信息和數據塊值。操作員從TIA Portal初始化到 PLC連接，例如，點擊TIA 門戶中的“ Go online ”按鈕，如下圖： 以下步驟將被執行： 1、TIA Portal 向 網絡廣播 Profinet Discovery 和基本配置協議 (PN-DCP) “Identify All”數據包。 2、所有PLC或設備都使用PN-DCP “Identify OK” 數據包回復 TIA Portal。 3、TIA Portal初始化與PLC的TCP握手，PLC將回復。 4、TIA Portal和PLC交換COTP連接信息。 5、TIA Portal發送第一個S7數據包。 6、PLC使用包含1字節和20字節反重放機制的數據包進行回復。 7、TIA Portal 會回復一個包含反重播字節和 132 字節陣列的數據包、即反重放響應。 8、TIA Portal將數據包連同請求的操作一起發送到PLC，并在每個數據包中進行20字節的完整性檢查，其中包含特殊字節，如果任何 S7CommPlus反重放字節數或完整性檢查值數據不正確，連接的另一端將發送TCP重置數據包，會話將終止。

圖4 S7CommPlus 會話和反重放機制

圖5 S7CommPlus （連接）請求（來自 TIA 門戶）

圖6 S7 質詢數據包（來自 PLC ）

圖7 S7CommPlus 響應數據包（來自 TIA 門戶）（左：流量捕獲、右：字節位置表示）

1.1 抗重放字節

S7CommPlus協議在防重放機制中使用1個字節值，自S7-1200固件版本3開始使用。當TIA Portal初始化連接時，PLC發送0x06至0x7F范圍內的質詢字節，TIA Portal將向PLC回復一個響應，該響應通過將值0x80添加到質詢中來計算。例如，如果PLC質詢為0x08，則TIA響應將為0x08+0x80=0x88，如圖中的標簽④所示。圖上質詢位于第25個字節位置，響應位于相應數據包的第24個和第29個字節。在PLC固件版本3中，S7響應數據包之后的后續功能數據包必須在第24個字節位置包含相同的防重放字節；在固件版本4中，發現它是相關數據包的第57個字節或第62個字節。

1.2 響應數據包中的加密

從固件版本4開始，來自TIA Portal的響應數據包必須包括除上述單個防重放字節之外的幾個字節。2017年，Cheng[6]發現了數據包中涉及的兩個16字節加密，其中第二個加密依賴于第一個加密。兩個16字節的值開始于S7響應包的第235和第291字節，如上圖中的標簽⑨和⑩所示。第一次加密是XOR運算，而第二次加密是通過更復雜的算法生成的。

1.3 功能包“加密”

響應數據包發送到PLC后，TIA Portal將開始發送與TIA Portal功能相關的字節，本文其余部分將其命名為“功能數據包”。所有這些分組必須包括32字節的“加密”值，如下圖的標簽?所示。該“加密”被發現是由基于散列的消息認證碼（HMAC）促進的完整性檢查，并且與防重放字節有關。Cheng[6]提出了通過利用協議來啟動和停止PLC的可能性，但沒有提供描述協議漏洞的詳細信息，只是指出數據包完整性檢查功能是一種“加密”。隨后，Biham將S7協議中使用的底層機制確定為HMAC，并發現HMAC的密鑰細節是通過橢圓曲線EL-Gamal類密鑰交換來交換的。然而，沒有描述具體的協議機制，例如，反重放響應的每個字段都用偽代碼松散地標識，而算法執行細節缺失。類似地，在函數分組HMAC計算中，發現先前未識別的具有兩個不同密鑰的兩組HMAC.因此，在第四節中對解決這些差距的研究進行了調查，并與相關算法一起進行了進一步介紹，其中對協議和漏洞進行了詳細分析，以提供支持加密的機制的更詳細視圖。

圖8 S7CommPlus功能包（來自TIA門戶） 如下表，對上述幾個圖中的標號字段進行了總結：

2、脆弱性實驗分析

實驗環境包括運行TIA Portal V14的工程站、兩個固件版本為V4.1.3和V4.2.3的S7-1211C PLC和一臺“受損”機器，所有這些都通過交換機連接到共享LAN。

2.1 TIAPortal分析

為了了解生成反重放響應的算法，并探索可能的漏洞，使用WinDBG對TIA Portal進行了分析。本節描述了在實驗過程中進行的逐步分析過程。出于實驗目的，在TIA Portal中搜索可訪問設備的功能用于生成S7CommPlus流量。在分析過程中發現的結果如圖所示。下圖中的標簽A-F將在整個討論中被引用。圖中有兩個主要部分：如何處理挑戰數組（藍色框）和此后命名為“函數B”（黃色框）的進程，該進程是生成反重放機制的大多數字節的地方。

圖9 步驟A至F，用于分析TIA門戶流程。藍框顯示“挑戰陣列”。黃色框顯示“功能B ” 為了支持分析，在軟件和PLC之間的通信期間設置了幾個斷點。通過手動分析發現，每次TIA Portal發出請求時，字節數組都會發生顯著變化。通過使用SCAPY向PLC發送完全相同的連接請求數據包，可以確認該20字節塊與連接請求數據包的有效負載沒有明顯關系。從以前的工作來看，鑒于S7CommPlus協議的可用信息有限，從哪里開始逆向工程過程并不明顯。因此，對于任何進行這種分析的人來說，第一個挑戰是確定生態系統中易受攻擊的部分和分析的切入點，如下所示。為了開始分析，在沒有任何斷點的情況下使用一次TIA Portal的搜索功能，并生成一個完整的通信會話（由來自PLC的TCP重置數據包結束）。通過軟件上的WinDbg手動啟動中斷，然后使用命令“s”在存儲器中搜索來自PLC的20字節，可以識別包含該20字節塊的存儲器地址。該存儲器地址可以僅通過一次“s”搜索來定位，或者通常僅定位存儲整個接收到的S7詢問分組的區域。進一步的搜索必須通過使用訪問時斷點來完成，并跟蹤該20字節數組被寫入的特定地址。一旦確定了該地址，在重新啟動TIA Portal之前，該地址不會更改。如標簽所示，在該地址上設置訪問時斷點“斷點A”。在使用TIA Portal初始化另一個S7通信后，發現斷點A是通過兩個不同的位置訪問的，這兩個位置都是涉及將20字節塊復制到另一個地址的功能。第一個函數復制斷點A指向的地址，而第二個函數將字節復制到特定地址，如標簽所示。因此，為了繼續調查，為兩個識別的地址中的每一個設置了另外兩個訪問斷點，即斷點B和斷點C。發現斷點B指向第3字節的地址，并且斷點C存儲20字節數組的第3到第18字節（圖6中的標記⑤）。這個16字節值（字節3到18），或“挑戰數組”，已被發現在字節生成過程的其余部分起著重要作用。進一步發現，斷點B和C所指向的兩個存儲器位置分別涉及為s7commplus響應和功能分組生成字節。 此時，DLL“OMSP_core_managed.DLL”第一次出現，斷點A、B和C指向的地址都在此DLL的范圍內。在分析過程中，確認該模塊（或DLL）是生成所有防重放字節的地方。下面將解釋S7響應分組和S7功能分組中的防重放字節的生成。

2.1.1來自TIA Portal的S7響應包

在訪問質詢數組的新S7會話中，通過跟隨斷點B，使用WinDbg中的“uf”命令識別來自模塊“ OMSP_core_ managed.dll”的“功能B”，如標簽所示?.請注意，“uf”命令返回地址所屬的整個函數。在通過回溯函數B的調用堆棧進行進一步調查后，確認其為生成S7CommPlus響應數據包的位置，響應數據包可以分為幾個部分，如下所述。

2.1.1.1可以操作的字節

在調查中發現，至少使用了兩次哈希算法Sha-256。這些哈希的輸入由“CryptGenRandom” Windows API生成。生成的兩個哈希用作輸入的一部分，以生成響應數據包中的字節。這些字節包括：9字節和8字節塊，（分別為⑥和⑦），132字節塊⑧的前76個字節，以及加密1，⑨和加密2，⑩之間的字節。如所示，可以通過使用WinDbg更改哈希函數的輸入來操作這些字節塊，例如將輸入設置為全零，并且這些字節的輸出將在每個會話中保持不變。這可能是一個非常強大的漏洞，因為一旦生成這些字節，就可以在不需要TIA Portal或WinDbg的情況下生成數據包。只要其他字節也是由適當的算法生成的，PLC就會接受這些“特制的”數據包。該點說明了如何將散列之一標識為生成兩個16字節密鑰（圖1中的“密鑰1”和“密鑰2”）的過程的一部分。這些密鑰隨后用于S7CommPlus響應中的兩個對稱密鑰加密過程，特別是AES-128。這兩個過程將被稱為“第一次加密”和“第二次加密”，如圖9右側所示。由于可以操縱這些哈希的輸入（見?），因此可以生成輸出哈希，從而生成兩個密鑰，并根據算法的輸入而改變。因此，標簽?可以被認為是一個黑盒子。還有一些值根據哈希算法的輸入而變化，這些值由另一組函數生成。為了所呈現的分析的目的，不需要知道這些功能的詳細操作，并且因此它們也可以被認為是黑箱，其在上節圖中被標記?，這將在適當的時候再次討論。目前認為，如果不訪問可編程邏輯控制器（PLC）的內存或安裝了TIA Portal的上位機，就不可能操作這些值。然而，攻擊者可能能夠使用中間人代理，例如在受危害的機器中以TIA Portal的形式，將密鑰更改為所需的密鑰。雖然Biham認了操縱哈希輸入的可能性，但我們在這里記錄并可視化（圖9）字節的操縱如何影響機制其余部分的安全性。從安全研究人員的角度來看，此信息非常重要，因為它揭示了專有協議的其他未知問題，并突出了可能存在多個TIA門戶和PLC實例的安全限制。由于本研究是根據Cheng[6]的研究進行的，因此分析的表述和術語與一致，即將主要組件確定為第一加密、第二加密和功能包完整性檢查。

2.1.1.2第一次加密

Cheng[6]首先提到了響應數據包中使用的兩種加密,然而僅給出了它們在IP分組中的位置，并且很少給出關于這兩個加密的其他信息。比Biham隨后添加了額外的信息，記錄了用于生成這些字節的底層算法，這是橢圓曲線EL-Garmal密鑰交換的專有版本。作為進一步的貢獻，我們現在介紹低級字節操作和操作反重放機制所需的過程。如下圖所示，第一加密是位于先前識別的132字節塊的第77到第93字節中的16字節值。發現通過使用?中生成的132字節塊的第61到第76字節作為明文并使用“密鑰1”作為對稱密鑰加密算法的加密密鑰來進行加密。然后，該加密的輸出將與質詢數組進行異或運算，并在發送到PLC之前存儲在處理通信的地址中。但是，由于明文和密鑰都與?中的操作哈希相關，因此可以將此加密視為16字節常量和質詢數組的簡單XOR運算。

圖10 第一次加密

2.1.1.3第二次加密

第二次加密使用與第一次加密相同的加密算法，然而，明文是由更復雜的算法生成的，該算法使用第一次加密作為輸入的一部分。完整算法的分析如下圖13所示。此外，還確定了生成明文所需的許多構建模塊。下面以詳細的偽代碼的形式呈現這些低級字節操作。該偽代碼旨在幫助所提出的實驗（以及[6]和[7]）的再現性。(1）“有限域”增量算法（見圖11).有限域是具有有限階的元素的集合，并且乘法和加法的運算應該符合某些規則。域的階是域中元素的個數，并且階應該是素數的冪。

圖11“有限域”增量算法 對于該遞增，字段的順序是2128，其可以由16字節值表示。在分析過程中，不可能找到廣義不可約多項式（有限域中的運算規則），因此計算由一組運算和一組常數來表示。要開始操作，將16字節值乘以從0到255的所有整數。此16字節值是從與兩個加密密鑰相同的哈希生成的（請參閱標簽）。它采用四個4字節小字節值的形式。計算如圖11所示。在乘法過程中，如果乘數的nTH根為2，其中n為正整數，即乘數為2，4，8…，輸出將與特定值xpn進行異或運算，并存儲在具有256個元素的數組或數組“ value256[]”中，其中每個元素都是16字節值。由于值必須保持在“有限域”內，乘法的其余部分不能簡單地通過將輸入值乘以乘數來實現。通過首先以其二進制形式表示乘數來完成計算。然后從最高有效位讀取乘法器的二進制。如果是“ 0 ”，則沒有進一步的操作。但是如果它是'1'，例如，如果乘數是“9”，其在二進制中是“1001”，則value256[23]和value256[20]將被異或在一起，并且輸出被存儲在value256中。

圖12算法a480

圖13 第二次加密(2) 算法A480。該算法以地址的存儲器偏移量命名為“算法A480 ”，取圖11中的“值256[]”。“有限域”增量算法的輸出，以及作為輸入的16字節值。16字節輸入“ B_輸入”被分成四個4字節數組，它們以小端格式表示。圖12示出了算法A480的偽代碼，算法的第一部分在循環中執行，將依次讀取4字節值的每個字節位置。通過從B_輸入的第一元素中的第一字節位置開始讀取，到第二元素中的第一字節位置，等等。（即B_輸入[0][0]，然后B_輸入[1][0]，等等）。與十六進制中的任何值一樣，它可以是0x00到0xFF，這對應于value256[]中16字節值的不同256個元素。16字節值（第一個讀取值為value256[B_input[0][0]]）將附加零，零的長度取決于它當前所在的元素。例如，對于元素0或B_INPUT[0]，追加了16個零。類似地，對于B_輸入[1]到B_輸入[3]，將分別添加12、8或4個零。結果將被存儲，并與添加了零的下一個值進行異或運算。（例如，經XOR運算的前兩個值是Value256[B_輸入[0][0]]和Value256[B_輸入[1][0]]，兩者都添加了零）。在進行到下一字節位置（例如，從B_輸入[X][0]到B_輸入[X][1]）之前，每一遞增的結果將被轉換成大端字節序，向右移位1個字節，并且再次被轉換回小端字節序值。對于最后一個位置，不是將32字節值向右移動1個字節，而是執行更復雜的操作。操作從偽代碼中語句的左側開始。該操作包括：“<<”二進制左移、“>>”二進制右移和“^”逐位異或。在移位期間，任何方向上超過16字節限制的字節都將被丟棄。生成的32字節值將被劃分為8個不同的4字節值用于操作。在算法結束時，通過將四個4字節數組連接成字節串來獲得16字節串。(3) 明文生成。如圖13所示，在用于第二加密的明文生成過程中有五個不同的輸入。這五個輸入是：1）16字節值；2）第一次加密的結果（圖13中的紅框）;3）16字節密文（圖13中的綠色框）;4）從另一個密文縮減的8字節值（圖13中的藍框）；以及5）用零填充的4字節計數器值。實驗已經表明，除了第一次加密的結果之外，所有這些輸入相對于點?處標識的兩個散列是恒定的。明文生成過程的每一步都涉及對兩個輸入進行XOR運算，并通過“算法A480”運行結果。(4) 完成第二次加密。在生成明文之后，使用“密鑰2 ”對其進行加密（參見圖9），使用與第一加密相同的對稱密鑰加密。密文將用作132字節塊的最后16個字節，即來自TIA Portal的反重放響應。圖13示出了“有限域”增量算法、算法A480和明文生成是如何相互關聯的。輸入在132字節數組中的字節位置以及如何生成第二次加密也可以在圖中找到。與Cheng[6]的工作相比，對S7響應數據包的生成提供了更完整的描述，兩個加密的細節也提供了Biham后來工作之外的額外信息。值得注意的是，算法A480先前已被簡要地呈現為制表散列，但沒有圍繞用于生成第二加密的步驟的細節。由于先前描述的較低級字節計算，現在呈現該進一步分析。這允許對修補可能的操縱提出初步建議。

2.1.2來自TIA Portal的功能包

在交換S7詢問和響應數據包之后，將發送S7功能數據包。這些數據包包括通信的目的和細節，圖8顯示了其中一個數據包，該數據包包含由第III.B節中給出的示例中的TIA Portal發送的控制信息。每個數據包都必須在有效載荷之前包括32字節“加密”（如Cheng[6]所稱），如同一圖中的輪廓字節所示。在該分析中發現，該32字節塊實際上是對分組的HMAC完整性檢查。這種完整性檢查有兩個目的：確保有效載荷不被操縱；以及驗證發送方（因為只有連接中涉及的主機才知道HMAC的密鑰）。為了生成這個32字節值，需要進行兩次HMAC計算。第一個用于生成所有后續HMAC的密鑰。第二個用于對所有功能包進行簽名。兩個HMAC都基于與其余機制相同的哈希算法。圖14顯示了兩個HMAC如何生成完整性字節。

圖14 完整性檢查

圖15.用于生成8字節塊的偽代碼，它是第一個HMAC明文的一部分

2.1.2.1第一次HMAC

第一次HMAC的計算在S7響應分組被發送到PLC之前完成。HMAC的明文由從斷點C讀取的8字節值和16字節質詢數組組成（參見圖9).圖15示出了用于8字節生成的偽代碼，該偽代碼對于S7函數完整性檢查是關鍵的，但是在文獻中先前沒有描述。該算法未被識別為標準化算法，因此偽代碼是通過分析匯編代碼生成的。由于8字節生成算法是完整性字節生成的基本部分，因此從安全角度來看，該分析具有指導意義。然后，使用在圖9中標簽?處的黑盒中生成的24字節密鑰來對組合的24字節值進行簽名。32字節的HMAC輸出將被縮減為24字節值，該值將被存儲并用作第二個HMAC的密鑰。

2.1.3.2第二個HMAC

第二個HMAC用于生成實際的完整性校驗字節，這些字節被插入到雙方發送的功能包中。這里已經首次識別了第二次HMAC的密鑰如何是第一次HMAC的結果，并且進一步識別了S7功能分組有效載荷的哪一部分被用作第二HMAC的輸入。函數數據包的長度并不總是相同的，但數據包中的32字節HMAC總是從數據包的第13個字節開始。該HMAC的輸入包括分組中HMAC之后的所有字節，即從第45個字節開始，不包括分組的頁腳，該頁腳通常是最后四個字節（例如，8在數據包的末尾是“72 03 00 00”）。由于每個數據包的長度和所包含的信息可以變化，因此頁腳的長度和內容也會相應變化。然而，為了重放分組，由于密鑰是已知的，簡單的試錯法可以識別需要什么字節作為HMAC的輸入。

2.1.3總結和討論

本節記錄了獲取有關S7CommPlus協議中使用的反重放機制的信息所需的方法和實驗過程。這些新發現的信息，包括使用的標準化哈希和加密算法，以及用于明文和密鑰生成的專有算法，可能會被利用來創建生成“合法”S7通信的工具。 基于上述實驗，現在將討論一些有趣的實踐方面，旨在為該領域的未來研究人員提供指導，以幫助重現類似的實驗結果。

盡管在本次調查中未使用“IDA Pro”或新的開放式軟件“Ghidra”，但它們可能會顯著加快調查速度，尤其是發現軟件各個部分中使用特定功能的位置。

在存在質詢和響應機制的情況下，跟隨或回溯存儲器中質詢的存儲器位置可以為反向工程過程提供入口點。

在WinDbg中記錄“ta”（trace to address）命令的輸出提供了一種查找生成特定字節的位置的方法。雖然在這項工作中沒有使用，但自定義腳本可能有助于在跟蹤期間轉儲額外信息。

當發現內存中使用或存儲的各種字節是密碼函數使用的常量時，該研究中的大多數重大突破都出現了。例如，AES的S盒和Sha-256的初始哈希值。因此，當執行類似的分析時，當僅有匯編代碼可用時，搜索存儲器中使用的密碼學常數可以提供識別特定算法的簡單方式。

在找到要使用的標準算法（例如AES）之后，在存儲器中的搜索和對父函數的回溯可以提供揭示使用該算法的多個實例的信息。

如果僅從通信的一方生成密碼密鑰，而沒有來自另一方的輸入，則可以操縱該密鑰

審核編輯 ：李倩