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 門戶）（左：流量捕獲、右：字節位置表示）

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個字節。

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

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

2、脆弱性實驗分析

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