ChargePrint：一個互聯網規模的電動汽車充電管理系統發現和安全分析框架

作者：Tony Nasr, Sadegh Torabi, Elias Bou-Harb, Claude Fachkha and Chadi Assi

譯者：知道創宇404實驗室翻譯組

原文鏈接：https://www.ndss-symposium.org/ndss-paper/chargeprint-a-framework-for-internet-scale-discovery-and-security-analysis-of-ev-charging-management-systems/

摘要

電動汽?充電管理系統 (EVCMS) 是一組專?軟件，允許??遠程操作電動汽?充電站 (EVCS)。隨著為?持不斷增?的全球電動汽??隊?部署的 EVCS 數量不斷增加，EVCMS 的數量也在不斷增加，從?引?了新的攻擊?。在本?中，我們提出了一種新穎的多階段框架 ChargePrint，?于發現互聯?連接的 EVCMS 并調查其安全狀況。ChargePrint 利?從 EVCMS ?種?中提取的標識符，通過迭代指紋識別以及分類和聚類?法的組合來擴展設備搜索引擎的功能。使?部署于 9 個不同 EVCMS 的 1,800 個已發現主機的初始種?，我們確定了由 44 個獨特 EVCMS 檢測的 27,439 個在線EVCS。我們深?的安全分析通過研究 120 個零日漏洞，凸顯了所部署的 EVCMS 的不安全性，這揭?了針對 EVCS、其??以及連接的電?進??絡攻擊的可?性。最后，我們建議用戶采取對策來減少潛在的威脅，同時我們也通過與系統開發?員/供應商進?協調漏洞披露 (CVD) 為 EVCS ?態系統的安全做出了貢獻。這些系統開發?員/供應商承認并為發現的漏洞分配了 20 多個 CVE-ID。

I．簡介

電動汽?充電管理系統 (EVCMS) 是一組專?軟件，?于檢測底層電動汽?充電站 (EVCS)。它們為??/運營商提供先進的功能、界?和?具來遠程監視、控制和管理其 EVCS 的操作，包括安排充電會話、計費/?付、記錄保存和??管理/?份驗證[1]。

鑒于政府為刺激電動汽?的購買?提供的激勵措施[2]，全球電動汽?市場正在快速增?，?前包括1100 萬輛[3]。同樣，通過在公共/私?空間部署?量 EVCS 來滿?不斷增?的客?需求，電動汽?充電基礎設施也在不斷擴展。[4]。這意味著部署的 EVCMS 數量會增加，以檢測已安裝的 EVCS。因此，電動汽?充電?態系統會隨著擴散的攻擊???臨?量安全挑戰。

具體來說，不同且大多數EVCMS 是主要針對特定供應商的臨時開發。它們普遍缺乏法規，導致整個電動汽?充電?態系統?臨各種威脅。事實上，EVCMS 構成了對?的主要?標，因為它們提供了一個遠程攻擊向量，可以破壞底層 EVCS、其充電操作和連接的關鍵基礎設施。特別是，此類攻擊的影響會隨著其直接集成到電??被放?[5]。

盡管如此，之前的?作重點仍是調查電動汽?充電?態系統的安全性[6]，[7]，?們對?泛部署的 EVCMS 的安全狀況缺乏了解。?量部署的 EVCS 及其 EVCMS 作為新的可?攻擊?，它們擴展的遠程功能也受到了推動。我們的?標是通過評估已實施的 EVCMS 在野外的安全性來?次探索這種威脅態勢，這需要在整個互聯?上發現和映射 EVCMS 實例及其主機。由于缺乏有關已部署 EVCS 的經驗數據，這是一項具有挑戰性的任務。此外，與典型的物聯?（IoT）設備不同，利?現有的指紋識別?法[8]，[9]來識別 EVCMS 從而準確發現連接互聯?的 EVCS是不切實際的。主要因為 EVCMS 是基于云的，并且往往具有閉源實現特性。此外，雖然部署的 EVCMS 具有有限且重要的橫幅，但由于其多樣性和開發?員之間標準化的缺失，它們往往具有有限的(或沒有)?于識別它們的搜索引擎標簽和橫幅規則。

為了應對這些挑戰，我們提出了一個多層框架ChargePrint，?于指紋識別和發現互聯?連接的 EVCS，并評估其 EVCMS 的安全性以防?遠程利?。該框架依賴于分析候選 EVCMS 的種?，從其橫幅中提取標識符，然后利?著名的在線設備搜索引擎以及分類和聚類?法的組合來執?迭代發現/指紋識別。因此，該框架通過一系列混合技術（檢查相應的可訪問 EVCS 固件進??盒分析，以及通過在線檢查EVCMS 實例端點進??盒分析），對已識別的 EVCMS 及其主機實例進?深?的安全分析。此外，根據使?ChargePrint 的分析結果，我們說明了?絡攻擊的可?性，并討論了它們對 EVCS、其??和運營商以及互聯電?的影響。

此外，在我們建議采取緩解對策的同時，我們還將我們的調查結果傳達給受影響的供應商，以引起?們對現有漏洞的關注。事實上，一些系統開發商（例如施耐德電?、Cornerstone Technologies）已經承認了我們的發現，并且這些漏洞被分配了超過 20 個常?漏洞和披露 (CVE) ID [10]。最后，通過演?易受攻擊的 EVCMS 實施對電動汽?充電?態系統進??規模攻擊的可?性，我們希望激勵系統開發?員重新評估和提?其 EVCMS 的安全性，并減少未來實施中的威脅。

本文主要貢獻總結如下：

1) 我們提出了一種新的多層框架（ChargePrint）來解決EVCS 發現/指紋識別問題，并通過獲取和利?有關EVCMS 獨特標志和特征的信息來解決 EVCMS 經驗數據的缺乏問題。此外，為了證明我們的?法的有效性，我們用它實現了 ChargePrint 并?規模利，還發現了27,439 個連接互聯?的 EVCS 主機實例。這些實例由 44種不同的 EVCMS 產品進?檢測。據我們所知，我們是第一批在野外調查 EVCMS 實例的公司之一。

2) 我們?次嘗試對 EVCMS 進?全?的安全分析，定義了電動汽?充電?態系統中的新攻擊?。我們通過在ChargePrint 中實施混合安全分析的?法來檢查各種特定供應商的 EVCMS 產品的固件和在線實例，從?突出顯?EVCMS 中的主要安全缺陷。此外，我們還定制了?動掃描模塊，進??規模EVCMS漏洞分析。分析發現25,300臺EVCMS主機受到了120個可遠程利?的零日漏洞的影響。此外，我們將我們的發現傳達給了相應的系統開發?員，他們承認了這些發現并分配了 20 多個 CVE-ID。

3) 通過討論針對電動汽?充電利益相關者（即 EVCS、??/運營商和電?）的攻擊影響，我們揭?了現有 EVCMS 的不安全性。更重要的是，我們建議采取緩解對策，以加強已部署的系統抵御?絡攻擊的能?。我們通過報告的調查結果激勵開發?員提?現有和未來 EVCMS 產品的安全性，從?為?泛?態系統的安全做出貢獻。最后，我們通過跟蹤制造商發布的補丁并調查其實際部署情況，重新評估 2022 年 EVCMS 的安全狀態。

本?的其余部分安排如下。我們將在下一節中介紹相關背景信息，并在第III節中詳細描述擬議框架。第一部分介紹了所實施框架的實證評估以及實驗結果、對電動汽??態系統的威脅影響以及可能的緩解策略IV。漏洞披露信息和補丁后續?作以及經驗教訓和未來的?作研究?向 分別在V和 VI各節中注明。最后，在VIII總結本?的主要內容之前，我們在VII中檢查相關?作。

II. 背景

EVCS vs 物聯網：EVCS及其 EVCMS 具有一些常?特征，例如?于遠程管理的互聯?連接。但與物聯?設備及其嵌?式軟件相?，EVCS及其 EVCMS 具有許多獨特的特征。

第一，EVCS配備了?物聯?設備更?的處理單元和存儲容量，以滿?EVCMS存儲和處理充電記錄和活動?志的需求，并確保其繁重的性能要求和持續服務得到滿足。因此EVCS可以做到將電能輸送到電動汽?支持全天使?，實現?時間的充電周期。

第?，EVCS 的電?電?電路旨在維持?物聯?設備?得多的電源，因為它們需要從電?向電動汽?電池供電[11]。EVCS 根據其最?供電量區分了 3 個主要類別： 1 級通過120V AC輸出功率為 1.5-2 千?的插座來提供電?；2級通過208-240V連接峰值功率為19千?（平均7.2千?）的功率提供電?輸出，3級通過480-800V AC輸?峰值功率?達240千?平均 110千?提供充電。

第三，物聯?設備依賴于各種協議（例如 BLE、ZigBee等）來操作和提供某些功能 [12]，EVCS 依賴于運營商設計的專有協議，以允許各個?態系統實體以及 EVCMS 之間進?通信，這對于管理和控制 EVCS 的各種操作和功能而言?關重要。具體來說，為了標準化這種通信，開放充電聯盟 (OCA) 于2012 年設計并推出了開放充電點協議 (OCPP) [13] 考慮了EVCS 消息交換事實上的標準應?協議。

第四，EVCS 的設計?的是與??/操作員進?定期的、直接的交互，這與部署在公共場所（例如閉路電視）的物聯?設備不同。物聯網設備不會近距離使用，也不會像EVCS設置的那樣頻繁地每天發生交互。

第五，EVCMS 提供了??多數物聯?設備固件更?、更復雜的軟件界?。EVCMS 包含?量功能，因此具有更?泛的代碼庫和結構，來適應 EVCS 提供和要求的各種操作。特別是，EVCMS 旨在實時組織和跟蹤電動汽?調度，以及管理充電記錄。除了遠程管理之外，EVCMS還為 EVCS 本?的?機界? (HMI) 等物理接?提供?持。EVCMS還需要處理充電 ID 令牌，例如近場通信 (NFC) 卡。EVCMS 還實現了復雜的訪問控制機制、???份驗證和管理、????隔離和權限矩陣，這些在通常在以單個或有限??/權限運?的物聯?軟件中不可?。雖然?多數 IoT 設備固件使?標準打包壓縮格式進?交付和設備部署（例如 LZMA 和 Zip），但許多 EVCMS 仍使??定義和專有壓縮格式（例如 EPK）。我們還注意到，物聯?設備固件使?更常?的?件系統類型（例如squashfs），然而EVCMS使?不太常?的?件系統類型（例如JFFS2）。

EVCMS 資產： EVCMS可以采?不同的部署模式，其中基于固件和基于云的模式最為突出。基于固件的模型是通過將應?程序??界? (UI) ?檔集合（即 Web 界??件）直接嵌?到EVCS 固件中來實現的，EVCS 固件是最?化的操作系統(OS)，旨在提供對 EVCS 的低級控制硬件。基于云的模型是在云中的 Web 服務器上實現的，該服務器與 EVCS 連接并進行通信。在這項?作中，我們研究了基于固件和基于云的 EVCMS軟件產品，并對它們的各種實例進?了深?的漏洞分析。

指紋識別和發現：一般來說，發現聯?設備依賴于指紋識別和橫幅分析。指紋識別是設備查詢的映射：對設備類型等類標簽的響應。橫幅分析則執?互聯?范圍內的協議掃描（例如 HTTP、SSH）并收集應?層數據（即橫幅）以提取?本信息并使?一組規則識別設備。在?獻中，已經介紹了?種框架來發現和識別?向互聯?的設備[9]，[14]。

然?，盡管在識別通?物聯?和?業控制系統（ICS）遠程管理設備??取得了有希望的結果[8]，由于各種原因，這些?法對于注釋EVCS是?效的；(1) 與在線 EVCMS 相關的橫幅有限；(2) EVCMS 相關信息?多基于云或閉源，很難找到；(3) 與?量通?物聯?設備模型相?，在缺乏使?傳統指紋識別技術識別這些系統的橫幅規則的情況下，EVCMS 規范更難獲得；(4)ICS設備可以通過設備搜索引擎提供的內置標簽來識別，但EVCMS卻沒有；(5) EVCMS的多樣性和缺乏標準化開發，導致橫幅表?形式多種多樣，難以分析和跟蹤。由于各種產品及其功能之間的差異，使得提取和搜索有關它們的有?信息變得困難。這些因素使得利?現有?法來準確有效地定位 EVCS 并對其進?指紋識別是不可?的。因此，我們開發 ChargePrint 來克服這些挑戰，并提出一種有效的EVCMS 發現和指紋識別?法，這是分析其安全態勢的先決條件。

設備搜索引擎： ?多數在線設備搜索引擎通過主動掃描互聯?（例如，IPv4地址空間）來收集有關互聯?連接設備/主機的信息，同時執?后續的橫幅分析以tag/label所識別的主機。鑒于主機橫幅和已識別設備信息的存儲庫如此豐富，我們通過應?程序編程接?（API）利?現有解決?案，依靠被動掃描（基于元掃描）技術[15]來實現搜索。具體來說，我們使?四個最著名的設備搜索引擎進?實驗：(1) Shodan [16]：執?連續檢測和監控，通過索引其服務橫幅/元數據來收集有關互聯?連接設備的實時信息；(2) ??普查系統 [17 號]：通過定期探測公共IP地址和域名來監控可訪問互聯?的設備；(3)ZoomEye[18]：收集有關在線設備和服務的信息，旨在提供互聯?規模的威脅檢測；和（4）Fofa[19]：提供有關互聯?連接設備?絡資產、范圍分析和應?程序流?度統計的情報。

漏洞分析：我們解決了?獻中的關鍵差距[20]，[21] ?次嘗試分析基于固件和基于云的 EVCMS 產品的安全性，特別是EVCMS 針對遠程攻擊的彈性。為了執?此分析，我們利??盒技術來檢查可?的 EVCMS 固件和腳本，并利??盒技術來檢查從在線 EVCMS 端點提取的資產。我們主要專注于檢測和發現可遠程利?的 EVCMS 漏洞，這些漏洞將允許訪問和控制各個系統及其底層 EVCS。我們特別提到 OWASP [22] 和MITRE 解決最重要的安全問題 [23]，并且對于每個都開發了系統的?法來推斷它們在特定 EVCMS 中的存在。

III. 擬議框架：ChargePrint

我們設計并實施了ChargePrint，這是一個多階段框架，?于通過發現互聯?連接的 EVCS 主機實例并檢查其 EVCMS 的安全性來探索 EVCS 威脅態勢。如圖1所?ChargePrint 有兩個主要核?部分，即發現活動和安全分析活動。我們展?了ChargePrint 的詳細內部架構，它由多個互連的組件和層組成，?持發現和安全分析的迭代操作。

A.發現

?先，我們進?發現操作，以查找野外連接互聯?的EVCMS 主機實例并對其進?指紋識別，然后利?它們來擴展EVCMS 產品的知識，同時為識別攻擊?以進?安全分析鋪平道路。接下來，我們詳細闡述該框架的發現活動的模塊。

1）種子儲存：為了引導發現活動，我們通過從初步查找中收集和存儲的 EVCMS 種?來構建初始數據庫，其中我們利?查詢 Shodan、Censys、ZoomEye 和Fofa 中的索引主機掃描數據以及與 EVCS 相關的 23 個關鍵字（例如，EV 充電器、EVCS）的列表以及已知的 EVCMS 產品。為了驗證這些系統，我們?動檢查其 Web ??界?橫幅的特定指標，例如產品系列/型號和供應商名稱/徽標，并將它們與可?的相應 EVCMS 開發?員的軟件包?檔中的信息相關聯。此外，我們選擇信息最多的主機作為初始 EVCMS 候選集，并將其橫幅存儲到數據庫中進?分析。

2）標識符提取：下?我們詳細闡述分析種? EVCMS 以提取可?于區分各種 EVCMS 產品的標識符。

收集資產:為了獲取資產，我們收集并檢查可通過固件包訪問的 EVCMS 產品、在線部署的基于 Web 的實例的??以及與擁有???站的供應商/開發?員相關的產品。我們注意到，并不總是能夠獲得給定 EVCMS 產品的所有這些資產，因為某些情況下供應商/開發商?站上沒有可供下載的相應固件。

為了收集 EVCMS 固件，我們使?由產品和開發?員名稱、?站鏈接以及包擴展等關鍵字組成的 dork 來查詢?絡搜索引擎，以搜索屬于產品供應商/開發?員的索引?站。然后，我們通過使? Scrapy 遞歸地抓取超鏈接來檢查這些?站的站點地圖，尋找可以保存固件（例如 /download）的潛在端點[24]從而抓取??，直到到達潛在的固件獲取端點。為了收集基于 Web 的 EVCMS，我們探測主機實例的主要??端點并下載其 Web ?檔（即 HTML 和 CSS ?件）以及其他可訪問端點的?件及其語?變體。

解析資產:為了解析下載的固件，我們提取它們的包并通過雕刻和探索文件系統以及利用binwalk 的 API 構建的自定義實用程序轉儲嵌入的文件、二進制文件和目錄[25]。為了解析獲取的??，我們通過檢查?? Web ?檔的?檔對象模型 (DOM) 結構來檢查它們。到解析收集到的供應商?站，我們抓取他們的??并累積 HTML 標記內包含的?本字符串。

提取標識符:接下來，我們提取一組標識符這使我們能夠準確地代表各?的 EVCMS 候選者并將其與其他產品區分開來。提取來?固件的標識符，我們在?件系統樹中找到唯一的?件/?錄路徑名（例如，/cgi-bin/cgiServer）這將作為EVCMS產品的直接指標。為了從???站中提取標識符，我們搜索 HTML?檔的 DOM，使?正則表達式，?于充當 EVCMS 指?符的特殊元素，例如產品名稱、版本、供應商/開發?員名稱和徽標。在圖2，我們展?了主要??的屏幕截圖查看通過 ChargePrint 發現的 EVCMS 的一些?例。與供應商/開發商?站一樣，我們從先前積累的字符串中堆積出 EVCS 相關?本列表（例如EV 充電解決?案），以豐富我們的 EVCS擴展發現 EVCMS 的術語知識實例.以表I中為例，我們提出一組在 EVlink EVCMS產品上運?的候選者的標識符。

3）查詢和數據驗證：在這個階段，我們利?提取給定 EVCMS 產品的標識符，以發現由我們已擁有其標識符的相應 EVCM 檢測的主機實例，以及利用提取的 EVCS 字符串單詞表的組合來發現新的 EVCMS 產品。

查詢引擎:我們通過以下兩種?法利?提取標識符，?的是通過查詢設備搜索引擎來擴?搜索范圍并執?擴展的系統收集，以找到更多由當前已知的 EVCMS 產品和新的 EVCMS候選產品配備的主機實例。?先，我們使?提取的產品特定標識符執?有針對性的搜索，以過濾其橫幅與查詢信息匹配的主機。其次，我們使?從供應商/開發?員?站上找到的提取的 EVCMS 字符串/關鍵字編譯的單詞列表對 EVCS 相關的橫幅主機數據進?一般搜索。

相似性分析:由于我們的通?搜索結果可能包含屬于不同 EVCMS 的各種主機，因此在將它們與先前檢測到的現有或新 EVCMS 關聯之前，我們需要進一步驗證。因此，我們引入了一種新的相似性度量（DOMetric）來比較給定主機的 HTML 頁面 （H），其中包含數據庫中已知的 EVCMS 候選 （C），以識別正在運行分配給同一 EVCMS 產品系列的服務的主機實例基于其服務和接口的相似性;因為運行同一 EVCMS 產品變體的主機實例將具有相同或高度相似的 Web 文檔。

為了使? DOMetric 確定相似度得分，我們?先解析 EVCMS ??的 HTML ??以提取其結構、樣式和?本內容。我們通過解析 EVCMS 門戶的 HTML 頁面來提取其結構、樣式和文本內容。我們通過使用執行成對比較來確定結構相似性 D1（H，C）格式塔模式匹配方法[26]在序列上的標記，然后我們利?方程1查找已識別主機的標簽之間的最?公共序列（LCS）（S1）和數據庫中已知的 EVCMS 候選者（S2）。對于樣式相似性 D2（H、C），我們從?檔的 HTML 中收集嵌?的樣式聲明塊和公共標簽的選擇器，并找到兩個?檔之間最?數量的公共聲明，A（主機）和B（候選 EVCMS），使? Jaccard 指數（公式2）。最后，我們通過?量化確定?本相似度（D3）主機標簽內的封閉?本（T1）和候選?（T2）按照它們在 HTML 中出現的順序排列，然后使?余弦相似度指數（公式3）對它們進??較。 主機標簽：通過這些相似性度量，我們使?方程4計算每對主機的總DOMetric 分數（H）和候選 EVCMS（C），w是一個?例因?（例如，w=13）。其余未標記的主機將保留使?隨后的?元分類器進?進一步調查。 4）系統識別：在此階段，我們檢測屬于已知 EVCMS 產品的主機的實例（即，數據庫中具有種?候選），并確定屬于新 EVCMS 產品的實例，我們從中選擇數據庫候選，并刪除不代表 EVCMS 主機的通? (IoT) 設備實例。

主機分類：由于擴展查詢和數據驗證中存在?量未標記主機，我們采?了利? 14 個特征的?元分類器（表II) 以確定這些主機是否是 EVCMS。

我們通過從手動檢查和標記的 1，000 個主機實例（基本事實）的數據集中提取特征來評估四種常見的分類器（邏輯回歸、k 最近鄰、樸素貝葉斯和支持向量機），這些數據集具有 500 個 EVCM 和 500 個非 EVCMS 主機，分為訓練 （70%） 和測試 （30%） 以進行驗證。根據表3中提供的評估指標結果，我們選擇邏輯回歸（LR）算法作為首選分類器模型，因為它優于其他模型，具有顯著更高的準確性（93.1%）和F1-Measure（94.2%）值。但是，對于未來的工作，可以通過評估更廣泛的機器學習模型。

主機集群:為了在通過?元分類識別的 EVCMS 實例中識別新產品，我們設計并實現了算法1對新識別的進?聚類

選擇 DOMetric 閾值 為要使算法準確地將主機關聯到同一集群中，必須選擇有效的 DOMetric 相似性閾值 （α）。根據我們的觀察，屬于同一產品系列的已部署系統始終具有非常相似的結構和接口，除了由于差異而產生的差異到集成新組件的產品版本變型。EVCMS 產品版本變體是特定 EVCMS 產品系列的實例，由于版本差異，其構建有所不同，因此，雖然這些變體彼此不同，但它們仍然共享?常相似的結構和?件系統，并且屬于相同的 EVCMS 產品系列。

因此，我們必須選擇一個適當的閾值，以考慮不同 EVCMS 產品系列以及屬于同一產品系列的版本變體之間的差異。為了確定優化的 DOMetric 閾值，我們通過運行算法 1 進行多項實驗，該算法的 DOMetric 閾值 （α） 范圍從 0 到 1（包括 0 到 1），在三個自定義數據集（即集合 #1、集合 #2 和集合 #3）上進行，包含 500、2，000 和 3，500 個 EVCMS 產品主機實例，由 5 個， 分別為 10 個和 15 個 EVCMS 產品系列，以及 13、29 和 41 個 EVCMS 產品版本變體。

如圖3，我們注意到三個趨勢。?先，當以低的速度運?算法時α值（α≤0.8),我們觀察到簇的數量保持在1，然后穩步增加。簇編號不正確，表明較低的閾值會導致所檢查的系統之間存在較?的重疊；任何顯著不同的?較系統（即屬于不同的 EVCMS 產品系列）將由于低聚類條件（?α）導致聚類過程出錯。其次，當運?算法時α值范圍從 0.8 到 0.9，我們觀察到 Set #1、Set #2 和 Set #3的簇數?乎與在每個集合中找到的正確簇數相關。事實上，閾值應該是出于對分析/?較的系統主機實例之間?相似率的需要?設定的。這對應于一組具有顯著相似性的系統。因此，我們選擇最?的DOMetric相似度閾值（α=0.9）來最?限度地提?由算法1獲得的正確簇數量的準確性。第三，當運?算法時α如果值?于 0.9 且最?為 1，則結果會為每個集合?成更多數量的簇，這些簇代表 EVCMS 產品版本變體的簇。

候選人選擇：一旦識別出集群，我們就會檢查它們并為每個集群選擇有代表性的候選者（新種?系統）。我們通過選擇部署不同版本的相應 EVCMS產品且其內容/配置?于其余實例的主機實例來確定相應的候選者（在算法中1的召回函數maxContent()）。隨后，我們存儲EVCMS 候選者進入種子 EVCMS 數據庫，然后我們利用它來執行框架發現活動的新版本。這種迭代方法允許ChargePrint通過識別各種主機實例來擴展指紋識別和發現過程，這些主機實例部署了EVCMS數據庫中候選產品的相同產品，其中就迭代而言，包括新舊系統。對于每個框架迭代，我們使用在發現的第一階段收集其資產的種子 EVCMS 候選項執行新搜索。

B.安全分析

對于新獲得的EVCMS候選產品（種?），我們使?一系列系統?法進?深?的安全分析，如圖1所?。

1）資產分析：通過檢查EVCMS組件，我們分析產品資產。這些組件代表發現漏洞的攻擊?。

拆除資產：為了進?安全分析活動，我們拆除并剖析收集到的資產以進?進一步分析。為了剖析固件映像，我們轉儲并安裝嵌?式?件系統以探索它們包含的?錄/?件，具體來說，我們搜索以找到包含 EVCMS Web 服務?件的 EVCMS ?檔集合。這些?件提供各種接?和控件，其中包含??/操作員以及外部對?可以訪問的 EVCMS ??點。為了剖析沒有固件映像的候選 EVCMS 實例的資產，我們確定了 EVCMS 的主要 Web ??界?服務以及所有其他可?的 Web 路徑，并發現我們從中收集表單和參數的資源/腳本。此外，我們通過下載Web文檔集合（如Web目錄和JavaScript文件）來創建各個EVCMS主機實例的脫機鏡像。

對組件進行分類：為了組織分析過程，我們將獲得的組件分為三類：編譯?件（例如?進制?件、可執??件）、?編譯?件（例如腳本）和 Web 端點。我們從 EVCMS 產品的固件映像中提取已編譯的?件，同時從 EVCMS 主機實例的固件映像和 Web ??中收集未編譯的?件，從 EVCMS 固件映像的?檔集合中提取 Web 端點以及候選主機實例。特別是，我們通過自定義腳本從可用固件中提取端點，這些腳本利用樹列表和預編譯的自定義單詞詞典，通過搜索文件系統并識別 Web 文檔集合目錄并遞歸定位表示端點的有效服務器后端和前端文件，然后解析它們以提取參數。

分析組件：我們對收集的組件執?兩種類型的分析：?盒分析和?盒分析。我們利??盒程序來檢查我們可以直接完整訪問的 EVCMS 組件，例如?進制?件和腳本。具體來說，我們對已編譯的服務器端?進制?件（例如，cgi服務器）執?靜態分析，對未編譯的客?端/服務器端?件和腳本（例如 JavaScript、PHP）進?源代碼審查。反匯編和反編譯過程通過專?的軟件（例如，Cutter [27]），同時?動審查相應的代碼路徑和執?流程，因為發現的漏洞對于每個 EVCMS 產品和設計流程都是唯一的。源代碼審查過程是通過我們編寫的?定義腳本實現?動化的，這些腳本?于搜索潛在的易受攻擊的函數和??點，然后在?動化縮?分析范圍后進??動檢查和驗證。我們利用黑盒分析來調查我們無法直接訪問的 EVCMS 組件，例如在 EVCMS 主機實例門戶上標識的端點，由于無法獲取相關的固件映像，我們無法訪問其后端二進制文件和腳本。

2）漏洞分析：隨著EVCMS的發現僅僅使?商業掃描儀是不可能發現漏洞的，我們開發了一系列?定義模塊、腳本、?具和測試程序。我們還利??動?作來正確地參與 EVCMS 架構，因為這需要深?的調查、?泛的安全領域專業知識和安全編程經驗來識別安全錯誤并有效地指導調查過程。

部件檢查：當通過反匯編和反編譯來分析已編譯的?進制?件時，我們專注于跟蹤其執?流程以識別錯誤和業務邏輯缺陷。與審查源代碼?件時一樣，我們專注于查找缺乏輸?清理和驗證的??點，從?允許注?和執?任意代碼和查詢，這是對?控制系統的主要?標。例如，在檢查 EVCMS ?檔集合中的客?端 JavaScript ?件時，我們找到了?法正確清理數據變量的易受攻擊的函數，從?允許在受影響的 EVCMS 上下?中執?任意 JavaScript，從?破壞其邏輯和功能，從?通過以下?式攻擊??/操作員：劫持他們的會話和系統。

例如，在清單中1, 脆弱函數goToTerminal沒有實現清理通過變量傳遞的數據的機制術語號，直接在第3/6/8?使?，允許控制數據的攻擊者傳遞并執?惡意代碼，破壞合法序列并覆蓋EVCMS邏輯流程。最后，在調查收集的端點時，我們使?Burpsuite 攔截 HTTP 請求/響應流量 [28] 查找插?點（例如，GET/POST 參數）。

實體測試：固件映像及其底層實體可?于某些 EVCMS 產品，但不適?于其他產品。因此，在研究期間?法訪問運?這些EVCMS 的?部分代碼和?進制?件。相反，我們嚴重依賴?盒測試技術來進?安全分析，通過在這些后端邏輯相對未知的 EVCMS 主機實例的端點上使?精?設計的?法來檢測漏洞。該過程包括將隨機數據和精?設計的數據跟蹤到已發現的??點（例如輸?、參數）以得出意外結果，同時查找漏洞跡象。為此，我們針對所分析的 EVCMS ?成定制的有效負載測試上下?，并使??定義?具在相應的??點上運?這些列表，以收集返回的輸出以供檢查。

漏洞檢測：我們檢查 EVCMS 產品以找出 OWASP 的主要軟件弱點 [23] 利?我們定制的?定義測試程序來檢測這些特定類別漏洞的發?。為了檢測 SQL 注? (SQLi)，我們使?sqlmap [29] 在 EVCMS 端點/參數上注?睡眠延遲查詢。為了檢測外部 XML 實體注? (XXE) 和服務器端請求偽造(SSRF)，我們在 EVCMS HTTP 請求消息/參數/端點中附加精?設計的 XML 實體和地址，其中包含對我們控制的服務器的回調。為了檢測硬編碼憑據，我們檢查 EVCMS 固件?件系統中的嵌?式憑據。為了檢測逗號分隔值注? (CSVi)，我們通過提供精?設計的 CSV 負載并檢查響應來檢查 EVCMS 功能和端點。

此外，為了檢測跨站腳本（XSS），我們將字符串標記的 JavaScript 有效負載注? HTTP 請求插?點（即參數、端點、標頭），然后解析響應以驗證注?。為了檢測跨站點請求偽造 (CSRF)，我們檢查 EVCMS獲取/發布-基于配置/設置的請求缺少特定于請求的隨機令牌。為了檢測跨源資源共享(CORS) 和 Flash 跨域策略 (FCDP) 錯誤配置，我們檢查EVCMS 端點的跨域策略?件中是否存在許可規則。為了檢測信息泄露，我們解析 EVCMS 端點以獲取與底層 EVCS 和EVCMS 設置/配置相關的敏感信息。為了檢測強制瀏覽和缺少?份驗證，我們通過驗證其訪問控制機制來檢查 EVCMS 功能，并搜索邏輯缺陷以在?需登錄的情況下請求?份驗證后端點/資源。為了檢測丟失的速率限制，我們向 EVCMS 端點發送一個 HTTP 請求周期，然后?較返回的響應以確定它們是否包含差異。

3）自動掃描：為了使安全分析高效，我們構建了自動掃描模塊（圖1）。

漏洞概念驗證 (PoCs):一旦我們檢測到各個 EVCMS 產品候選中的漏洞，我們就會為每個候選產品制作定制的特定于漏洞的 PoC，其中包括包含漏洞有效負載的請求和預期響應與證明漏洞的指標相關聯，并且我們將掃描的主機實例產品模型和版本字符串與所檢查系統的模型和版本字符串相關聯。這樣可以最?限度地減少發送請求的數量，并通過依賴 Shodan 等第三?設備搜索引擎已收集的數據和詳細信息，以有限的主機交互探索索引的互聯?掃描。因此，每當一組漏洞鏈接到特定的 EVCMS 產品型號和版本號時，我們就會配置 PoC 從 HTTP 橫幅中提取掃描的主機實例版本字符串，然后將其與 ChargePrint 數據庫中易受攻擊的產品相關的詳細信息關聯起來。這允許證明給定 EVCMS 產品上是否存在漏洞，并自動確定受影響的 EVCMS 檢測的主機實例數。

主機掃描:通過迭代收集的代表 EVCMS 產品各種集群的候選主機實例數據庫，我們利??成的漏洞 PoC ?動確定易受攻擊的實例。對于數據庫中代表給定產品集群的每個候選 EVCMS，我們制作一組漏洞 PoC，以確定屬于同一集群的其他主機實例是否存在漏洞。

為了報告遭受已發現漏洞的互聯?連接 EVCMS 主機實例的確切數量，漏洞已得到確認后，我們通過發送精確數量的 PoC 請求并解析響應以對測試時的事件進?計數來對每臺主機執?有針對性的掃描。我們構建此?動掃描的基礎是，由給定 EVCMS 產品檢測的主機實例必須運?相似或相同的構建和服務，因此將遭受相同的漏洞類別。因此，我們不是對部署給定 EVCMS 產品變體的每個主機實例重新進?徹底分析，?是對較少的實例進?深?的安全分析，同時將我們的發現推?到其他類似主機。

道德考慮:與基于掃描的安全測量研究一樣，我們遵守最佳實踐[30]?[35]。特別是，我們采取了多項措施來確保所檢查的 EVCMS 的運?不會受到損害。

不可否認性：在我們的掃描中，我們在傳出的請求中設置了一個?定義??代理字符串，以表?善意的意圖并提供聯系信息，以允許系統所有者與我們溝通，并可以選擇從我們的研究中刪除。我們還向我們的機器的公共 IP 地址提供了反向 DNS 記錄，以允許?標獲取有關該研究的其他信息。

相關掃描和非利用有效負載：為了執??規模掃描，我們依賴于之前由第三?設備搜索引擎（例如 Shodan、Censys）收集的互聯?掃描數據，并且我們利?了不會產?現實?活中的利?和主動交互的?利?有效負載。我們使?側通道技術通過精?設計的概念驗證來推斷漏洞，利?版本字符串和橫幅相關性來驗證漏洞的存在，?不會對所檢查的EVCMS 造成任何損壞或持久影響，類似于設備搜索引擎的?式，例如作為 Shodan，確定主機是否受到特定 CVE 漏洞的影響。此外，我們還開發了??的?法將?量主機聚集到版本化產品中，以便對代表性候選者或相應固件進?分析，并在特定版本中查找允許與所有相關主機關聯的問題，??需與它們交互。

客戶端分析和測試環境：我們注意到，在發現的 13 個漏洞中，有 8 個是客?端漏洞，它們不會影響或對分析的EVCMS 造成任何影響，因為它們是通過離線客?端腳本分析發現的。?于其余 5 個服務器端漏洞，是通過固件分析和在供應商（特別是 Cornerstone Technologies、Bluesky Energy 和 Etrel）提供的環境中進?協調測試發現的。我們還通過與運行供應商特定 EVCM 綜合列表的當地和國家電動汽車運營商溝通，并在執行此類資產的監控任務時在受控環境中測試 PoC，驗證了 PoC 不會對分析的 EVCM 造成傷害，我們沒有觀察到任何破壞性結果。雖然我們沒有在我們掃描的所有國際供應商上測試我們的PoC是否存在漏洞，但我們確實與少數供應商（例如，Cornerstone Technologies，Bluesky Energy）合作，我們利用供應商提供的技術和工具來驗證資產是否完好無損。我們注意到，PoC 包含不利用漏洞的被動有效負載，在最壞的情況下，可以通過重新啟動 EVCMS 或 EVCS 來避免任何意外的副作用。作為額外的預防措施，在適?時，我們利?事實上的遠程監控?具，對遠程主機進?最少的輪詢，以持續驗證遠程系統和正在運?的服務的性能、完整性和可?性，并且我們根據這些過程的結果采取?動，這沒有透露任何問題。此外，我們與機構的網絡管理員和 IT 領導以及上游 ISP 進行了協調，以確保我們的掃描不會對網絡運營產生不利影響。

負責任的披露：我們執?了系統性的協調漏洞披露 (CVD) [36] 努?并及時地與受影響的供應商進?溝通，在撰寫本?之前?少 6 個?向他們報告漏洞，以便他們在準備安全修復時有?夠的時間通知各?的??/運營商。

數據隱私：我們根據有關收集的數據和 IP 地址的數據保留/管理政策獲得了機構審查委員會 (IRB) 的批準。具體來說，我們在分析期間保留了從 EVCMS 主機實例收集的數據，之后，為了保護數據的私密性和可靠性，我們從我們的機器中刪除了在研究受影響的主機實例期間收集的所有數據。

IV．實驗結果

我們實施了 ChargePrint，并在此展?其發現和安全分析活動的結果。

A.在野外發現聯網的EVCS

1）初步搜索：初始搜索查詢使?選定的引擎識別出 1,800 個運? 9 個不同 EVCMS 產品的主機，如圖所?4，初始搜索使? ZoomEye 和 Fofa 產?了?量經過驗證的主機（約 1,700 個），如下所?：

與 Shodan 和 Censys（?約 200 個主機）相?。這些顯著差異歸因于兩個主要因素。?先，每個引擎都采?不同的掃描?具和技術來進?設備發現和探測，這會在已識別的主機和橫幅數據中產?差異，例如，Shodan 和 Censys 依賴于 ZMap 和 ZTag [37] ? ZoomEye 和 Fofa 則依賴于他們??的專有掃描儀。其次，每個引擎實現不同的定制查找查詢，將搜索結構與存儲的主機信息相關聯，例如，為了優化查找并避免搜索整個數據，搜索引擎可以將給定主機與設備或系統特定的標簽相關聯（例如，從其橫幅中提取的設備類型、操作系統）。我們注意到，所選的搜索引擎都沒有定義與EVCS 相關的標簽，因此，顯著妨礙了初始搜索的結果。

2)使用ChargePrint進行擴展搜索：動機是由于初始搜索中識別出的 EVCS 主機數量有限，我們利?ChargePrint 對 EVCMS 管理的 EVCS 主機執?擴展和迭代查找/查詢。如圖所?4與初始查找相?，我們使?ChargePrint 進?的擴展查詢產?了明顯更多的主機數量，具體來說，我們利?最初 9 個 EVCMS 產品的候選者來識別由各種 EVCMS 檢測的總共 27,439 個唯一主機實例。通過利 ChargePrint，我們改進了使?所有搜索引擎的 EVCMS 查找結果，證明了其有效性，識別的主機實例數量顯著增加，使? ZoomEye ?乎達到了?倍（25,316），使? Fofa（18,484）達到了?倍，并? Shodan (5,945) 和 Censys (5,442) 增加了?倍，如圖4所?。

我們注意到，通過框架的發現和指紋識別活動的 5 次迭代，總共發現了 27,439 個 EVCMS 主機實例。此外，我們的分析表明，這些主機實例由 44 個獨特的 EVCMS 產品進?檢測，這些產品代表了在主機集群階段獲得的組數，并?動驗證為有效的 EVCMS，如第 1 節中所述Ⅲ-A4。這凸顯了ChargePrint 迭代指紋識別?法的重要性，該?法不僅擴展了對連接互聯?的 EVCS 主機總數的了解，?且還發現了更?泛的已部署 EVCMS 產品。我們在表IV列出了 44 個已發現和分析的 EVCMS 的完整列表。

3）地理分布：確定的 EVCMS主機分布在21個國家，其中匈?利、芬蘭、美國、法國和南?的主機數量明顯多于其他國家（約占78%）（圖5）。然?，這種分布并不完全符合全球部署的電動汽?充電器的數量[3]，美國和英國等國家應該分別擁有最多數量的 EVCS。這種偏差是由于 ChargePrint 依賴于許多初始 EVCMS 候選?案，這些候選?案可能通常部署在某些國家/地區。此外，雖然我們在每個國家/地區都確定了各種 EVCMS 產品（圖5），在這些國家/地區找到的?多數主機僅對應于一種或兩種獨特的產品。例如，我們確定了超過 10,000 臺部署 Ensto CSI 的主機，其中 90% 位于匈?利（4,900 臺主機）和芬蘭（4,100臺主機）。

4)港口和服務：我們利用已識別的 EVCMS 主機橫幅，查找用于運行 EVCMS Web 界面服務的開放端口，以及查找與已知服務（如 SSH）關聯的端口。如圖 6 所示，大多數確定的 EVCMS 產品都在公共端口上運行 HTTP（S） 服務（例如，80，8080、和 443），但是，我們也發現了各種 EVCMS 產品（例如 81、82 和 8888）為 HTTP（S） 服務配置的替代端口。雖然開放端口提供有關已識別 EVCMS 主機上受支持服務的信息，但這些端口的某些組合可在將來的工作中用作特定于供應商的高級功能，用于某些 EVCMS 產品的目標發現和加速指紋識別。

B.量化EVCMS的安全狀況

對 EVCMS 產品/主機實例的深?安全分析發現了屬于 13個常?弱點枚舉 (CWE) 的 120 個漏洞 [38] 具有嚴重、?和中等嚴重程度的類別（表V），發現了 25,300 個主機實例（約占所有主機的 92%），并?持遠程利? EVCMS 并控制底層EVCS。另外，如圖所?7，部署在 13,989 臺主機上的 29 個產品與?和/或嚴重漏洞相關，?乎所有剩余的具有中等嚴重漏洞的 EVCMS 產品都部署在少量主機上（≤8)，部署在超過 10,000 臺主機上的 Ensto CSI 除外。我們注意到，?約8% 的已驗證 EVCMS 主機與任何漏洞?關，這是由于?法檢查其相應的固件和??端點來執?深?的安全和漏洞分析。接下來，我們提供了所分析的 EVCMS 產品和主機實例中已識別漏洞的詳細信息和?例：

1)嚴重漏洞：如表所列V,我們發現了 5 個嚴重程度的服務器端漏洞，影響了 7 個獨特的 EVCMS 產品（圖7），檢測了 4,431 個 EVCMS 主機實例（約占 16%）。我們在 1,684 個 EVCMS 主機實例上發現了 4次 SQLi，這可以通過提取包含敏感信息（例如??帳?詳細信息和付款信息）表的存儲數據庫來充分利?主機。此外，我們還發現了 XXE 和 SSRF 漏洞，攻擊者可以利?這些漏洞強制 EVCMS 向內部/外部?絡發送任意請求，并從 EVCMS 中竊取數據。我們還發現，900 個和 1,203 個 EVCMS 主機實例分別受到硬編碼憑據和 CSVi 的影響，這將允許攻擊者通過直接訪問資源/配置并上傳持久有效負載來破壞 EVCMS。

2)高嚴重性漏洞：我們發現 4 個?嚴重性客?端漏洞影響了 9,750 個主機實例（約占總數的 35%）上安裝的 22 個 EVCMS 產品。XSS 漏洞將允許攻擊者在易受攻擊的 EVCMS 上下?中執?任意 JavaScript 代碼，劫持??帳?并使攻擊者能夠通過控制所有可?功能來操作 EVCS。此外，通過嵌?持久有效負載或通過注?的 Web shell 創建后?，可以利? XSS 弱點在相應的 EVCMS 上進?權限升級，這些后?在系統??的上下?中執?，從?允許攻擊者通過暴露來獲得對 EVCS 的管理員級別訪問權限會話cookie。此外，我們還發現了 CSRF 漏洞，這將允許攻擊者強迫?標??執?意想不到的操作，例如更改 EVCS 設置和配置（例如，重新啟動 EVCS）。此外，我們還發現了 CORS 和 PCDP錯誤配置漏洞，這些漏洞使攻擊者能夠通過竊取帳?數據和會話 cookie 來攻擊 EVCMS。

3)中度嚴重漏洞：我們發現了 4個中等嚴重性漏洞，這些漏洞影響安裝在 17，831 個 EVCMS 主機實例上的 30 個 EVCMS 產品（占總數的 65%）這些漏洞可以為訪問部分特權功能（例如通過強制瀏覽公開維護端點）打開大門，或者允許攻擊者通過信息暴露漏洞查看與 EVCS 相關的機密狀態和設置。此外，缺少身份驗證和速率限制漏洞將允許在不確認權限的情況下訪問 EVCMS 上的特定資源/功能。

C.攻擊對電動汽車利益相關者的影響

在 EVCS 之上的相互作?實體的復雜?態系統中，利?已發現的漏洞可能會導致對?破壞 EVCMS 及其相互通信，從?對利益相關者（即 EVCS、??/運營商/電網和電?公司）進?攻擊。

電動汽車生態系統和運營:在協調 EVCS 環境的 EVCMS 產品環境中發現的漏洞構成了一個重?安全問題，因為這危及整個電動汽?充電?態系統，如圖所?8。在正常情況下，??/運營商能夠通過EVCMS的中繼操作來管理他們的EVCS，通過向其發送命令來控制底層EVCS。在簡化圖上（圖9），我們介紹了連接主要實體的互通協議的詳細信息：運營商、EVCMS 和 EVCS。如圖9,互通協議可以分為4個階段:

1) 在?份驗證階段，操作員通過 HTTP POST 請求向相應的登錄端點提交憑據來請求訪問 EVCMS，如果這些憑據有效，EVCMS 將授予操作員訪問權限并將其重定向到登錄墻。

2) 在管理階段，操作員將通過發送 HTTP GET 請求來請求可?功能，EVCMS 將根據其權限級別向該請求提供適當的儀表板組件，之后操作員可以通過特定于端點的操作執?所需的各種操作HTTP GET/POST 請求。

3) 在控制階段，EVCMS建?通信通道，發送并執?所請求的特定操作的命令（例如，開始/停?充電等），之后EVCS將返回狀態以更新相應的EVCMS配置。

4) 在監控階段，操作員將通過向 EVCMS 發出 HTTP GET 請求來請求 EVCS 狀態概覽，EVCMS 提供所需的信息，然后 EVCS 通過電?鏈路連接到電?（圖8），可以從電?提取電?饋?插?式電動汽?進?充電，或將電?重新注?電?以對插?式電動汽?進?放電。EVCS 為電動汽?放電的能?依賴于?輛到電? (V2G) 技術?持的 EVCS雙向功率流功能 [39]。

針對 EVCS 的攻擊:利?所討論的漏洞的攻擊者可以操縱EVCS 充電操作和時間表（即啟動、延遲或停?充電）。許多分析的 EVCMS 都遭受了 XSS 的影響，XSS 可能允許攻擊者將惡意 JavaScript 代碼注入 EVCMS 的上下文并劫持運營商的帳戶，從而允許通過受控 EVCS 覆蓋命令來操縱和/或中斷正在進行的充電操作，從而修改運營商的帳戶和 EVCS 設置/配置。攻擊者可能會破壞通過修改其充電水平并通過承受高電壓/電流忽略關鍵的電池條件來連接電動汽車的電池 [40]。

此外，通過利? SQLi 獲得對受損 EVCMS 的?權限訪問，攻擊者可以降級 EVCS 固件并可能上傳惡意制作的固件，從?允許對 EVCS 保持難以檢測的隱蔽低級訪問，從?在 EVCS 上創建持久性。攻擊者還可以通過 SSRF 或 XXE 利?一組 EVCS，并將它們?作?絡代理，以作為僵??絡的一部分執?協調的本地和/或互聯?掃描活動。雖然這些僵??絡可?于通過分布式拒絕服務 (DDoS) 攻擊淹沒互聯?上的其他設備，但它們也可?于發現其他易受攻擊的?絡設備，這些設備可能會受到損害，從?擴?攻擊者的??點并增加攻擊?。此外，攻擊者可以利用 CSRF 鎖定 EVCS，禁用特定功能并拒絕合法用戶的物理/虛擬訪問，從而執行物理 DoS，并且此類攻擊可以使用精心設計的勒索軟件進行武器化，通過濫用對這些受損 EVC 的權力來獲得經濟利益，并鎖定它們直到兌現贖金。

針對用戶/操作員的攻擊:易受攻擊的 EVCMS 實例可被?來獲得對 EVCS 的控制并規定其與 EV 的關系，并且此類漏洞可能會暴露系統內存儲的數據，從?危及其??/操作員的安全和隱私。例如，通過 XSS 或 CORS/FCDP 錯誤配置劫持EVCMS ??會話，攻擊者可以獲得運營商/??的個??份信息 (PII)，例如姓名、地址和電話號碼，并且這些信息可能會被泄露或出售給?絡犯罪分?，然后?于勒索、騷擾和?份盜竊。除了 PII 泄漏攻擊之外，攻擊者還可以獲得EVCMS 上存儲的其他資源，例如充電記錄和電動汽?特定的?志數據，他們可以從中推斷充電時間表并?于對相應的??/運營商執?監視/間諜活動。另一??，許多 EVCS 允許通過各?的 EVCMS 進?電?賬單和?付，因此，這些數據也可能被攻擊者從受感染的 EVCMS 主機實例中泄露，并被網絡犯罪分子濫用以執行支付欺詐，通過以下方式利用諸如SQLi之類的漏洞來轉儲存儲在EVCMS中的信息。

針對電網的攻擊:脆弱的電動汽?充電?態系統引?了針對關鍵基礎設施的新的且快速增?的攻擊?，這主要是由于EVCS 在電?內的直接連接和集成，并且考慮到它在為數百萬客?提供電???發揮的重要作?，針對這種基礎設施將產?重?影響。事實上，對電網進行大規模網絡攻擊會吸引各種對手，包括大型組織和國家支持的惡意行為者，他們可能會尋求經濟和/或聲譽損害他們的對手[41]。從本質上講，要進行這些攻擊，攻擊者需要控制大量受損 EVCMS 主機實例的充電過程，以控制其底層 EVCS 并啟動并發電動汽車充電會話，以及停止/延遲正在進行的充電操作，以對電網進行幾次危險的頻率不穩定攻擊 [42]–[44]。文獻提供的信息和仿真結果演示了對電網執行頻率不穩定攻擊的幾種方法。例如，攻擊者可以通過命令易受攻擊的EVCS在短時間內對連接的EV進行充電和放電來制造開關攻擊，短時間內造成電?頻率擾動和連鎖故障[45],[46]。此外，此類攻擊可以通過對 8,300 輛電動汽?進?強制放電來執?，如[中的模擬分析結果所?]47]。考慮到使?我們的分析發現的易受攻擊的 EVCMS 的數量（即 27,439 個），以及單個EVCMS 通常管理多個 EVCS 的事實，我們得出結論，對電?進?此類頻率不穩定攻擊是?常可?的。雖然在這些研究中，作者假設EVCS會受到損害，并且不討論利用細節，但在我們的工作中，我們提出了創建受感染EVCS僵尸網絡的技術細節.

D.建議的對策

在這項工作中，我們強調了EVCMS中的主要安全漏洞，我們還建議采取一些緩解對策來解決當前被各自系統開發人員忽視的安全問題，并加強部署的EVCMS以抵御未來的攻擊。首先，緩解所討論的攻擊需要修補EVCMS中所有已識別的漏洞類別，為此，我們參考CWE MITRE [38]和Open Web Application Security Project [22]的文檔，了解有關每個漏洞的CWE-ID的已知/推薦對策的詳細信息。例如，為了防止SQLi（CWE-89），開發人員不得使用動態查詢，也不能在查詢執行中包含用戶提供的輸入，并且為了防止XSS（CWE-79），必須在響應中返回用戶提供的入口點和參數數據之前正確編碼和清理這些數據。其次，為了減輕針對電網的網絡攻擊，運營商可以監控EVCS充電計劃，通過利用機器學習模型來學習正常模式并識別異常活動，以檢測充電行為中的異常情況。

此外，為了防止 EVCS 配置和 EV 充電計劃受到篡改，EVCMS和 EV 可以實現相互共識來驗證兩端的系統修改，因此，破壞EVCMS 的對?將?法強制執??定義充電未經參與實體（例如，電動汽?運營商/??）批準的情況下安排配置。第三，為了減少 EVCMS 攻擊?，系統開發?員必須通過不斷評估安全性來采?安全設計流程。在系統開發?命周期 (SDLC) 期間的可靠性，以及運營商正確、安全地設置其 EVCS 以防?某些攻擊。例如，??應始終使?強帳?憑據替換 EVCS 固件上附帶的默認憑據，并設置彈性?份驗證?法。

此外，私? EVCS 運營商可以在其 EVCMS ??上禁?公共設備發現，以隱藏遠程互聯?攻擊者，并配置防?墻僅允許來?受信任?的連接。鑒于所發現的漏洞產?了?泛的影響/影響，應該依法制定和強制執?嚴格的EVCMS安全措施和設計標準，以激勵系統開發商/供應商付出更多努?確保他們的系統經過法律的考驗和必要程度的審查，以滿?客?的安全期望并滿?相應法律的要求。

V. 零日漏洞披露和補丁后續行動

根據既定的 CVD 流程，我們通過適當的渠道、通過發送到專用產品安全事件響應團隊 (PSIRT) 地址的加密電子郵件以及網站安全事件表格，將調查結果傳達給 EVCMS 系統開發人員，然后再披露結果以允許他們采取必要的行動。而對于各種 EVCMS 產品，沒有足夠的有關相應供應商/開發商的信息，無法將調查結果傳達給施耐德電氣等多家制造商（例如，缺乏專用電子郵件地址、無法找到供應商網站、缺乏響應）、 Cornerstone Technologies、Bluesky Energy、Eaton 和 Etrel 已收到并承認發現的零日漏洞，并與美國國家標準與技術研究院 (NIST) [48] 協調分配了 20 多個 CVEID，例如：CVE-2021- 22706（CVSS 分數：8.8/高）、CVE-2021-22722（CVSS 分數：8.9/高）、CVE-2021-22729（CVSS 分數：9.4/嚴重）、CVE-2021-22730（CVSS 分數：9.4/嚴重）此外，這些供應商還采取了措施，通過在新軟件版本中部署相應的補丁來解決漏洞，特別是指定的 CVE。

為了評估計劃和部署的軟件補丁的狀態，我們對這些制造商從最初向他們報告漏洞之?起的 2021 年 3-6-9 個?內所取得的進展進?了跟蹤。在表VI，我們展示了本次后續的結果，列出了 EVCMS 及其解決漏洞的相應軟件補丁版本。 在分析的 44 個 EVCMS 中，有 18 個（40%）發布了軟件更新版本來修補安全漏洞，我們列出了其中的最新版本以及相應的日期。 例如，EVlink 版本 R7（表 IV）中的漏洞經過多個階段的修補，并于 2022 年 5 月新版本 R8 的最終發布完成，如表 VI 所示。 對于其中一些 EVCMS 產品，我們與施耐德電氣和 Cornerstone Technologies 等制造商/開發商密切合作，執行連續測試并驗證已部署的修復。 在大多數情況下，補丁準確地解決了問題，但是，在某些情況下，會發現先前漏洞的新變體。 例如，當特定參數上的 XSS 問題得到修補時，由于引入新的軟件功能，新的/其他端點上會發現新的問題。

總而言之，基于對這些 EVCMS 軟件更新進行的靜態分析，已經實施了更好的防御機制，滿足當前 IT 系統中部署的最新安全標準。 至于其余系統，由于各種原因尚未確認或觀察到更新：（1）缺乏足夠的聯系信息，無法就發現的漏洞與相應的供應商/開發人員進行溝通，（2）補丁未發布 然而，(3) 由于后勤原因而缺乏軟件更新，例如某些產品已停產，或 (4) 制造商將工作重點從修補當前系統漏洞轉向投資新產品線。

此外，為了調查原始 EVCMS 主機實例集的更新狀態，我們通過版本字符串提取探測系統并將其與當前修補的 EVCMS 版本列表進行比較，從而執行全局掃描。 我們確定，在 27,439 臺主機中，6,980 臺 (25.5%)仍然代表最初檢測到的 EVCMS 實例，而其余 20,459 臺 (74.5%) 要么是不再與 EVCMS 實例關聯的動態 IP 地址，要么無法成功解析 。 我們注意到，在這 6,980 個 EVCMS 實例中，只有 1,112 個（15.9%）已相應更新到修補已發現漏洞的新軟件版本。 此外，我們對一組新的 14,900 個 EVCMS 主機實例執行新一輪掃描，其中版本字符串表明僅更新了 1,760 個（11.8%）實例，因此得到了適當的保護。

在這兩次掃描中，我們觀察到更新的 EVCMS 實例部署了Ensto CSI 和 EVlink，并且我們強調，總體更新數量較低可歸因于通? EVCMS 設計架構的更新頻率較低且缺乏?動更新功能，因此需要?動/技術修補，并強制要求在應?更新時重新啟動 EVCS，這是?多數??避免的操作負擔。盡管如此，這些 EVCMS 實例最好不要暴露在公共互聯?上，?僅連接到隔離或虛擬內部?絡，以減少攻擊?，并仍然保持預期的遠程功能。

VI. 經驗教訓和未來的工作

雖然我們識別并分析了 44 個 EVCMS，但我們注意到，由于某些 EVCMS 產品的專有性質，這些產品僅提供給充電點運營商 (CPO) 和預付費訂閱的企業級客?，因此獲取有關所有可? EVCMS的信息是一項艱巨的任務。此外，某些 EVCMS的安全機制使得檢查位于?份驗證??后?的內容變得不可?。在這些情況下，我們檢查了部分 EVCMS 資產，因此剩余資產仍然可能隱藏漏洞。在未來的?作中，我們注意到我們利?了分類?法和提取的特征，可以更新或修改這些特征以增強整體指紋識別結果，通過實施和評估進一步的分類模型來找到每個階段的最佳?法/參數。最后，我們還可以利?ChargePrint 和本研究的知識來構建和部署一個在線平臺，?于對 EVCMS 產品進?實時發現和漏洞分析，并將這些產品提交給各個系統開發?員進?審核。

VII. 相關工作

在這項研究中，我們通過設計一個新穎的框架，利??定義技術來規避 EVCMS 分析特有的挑戰，從?研究以前?獻中從未解決過的利基攻擊?的發現和安全??。如表VII所?，我們將之前的研究?作系統化，將?獻分為三類：設備指紋、EVCS安全和固件分析，同時在指紋和安全分析??對它們進??較。

設備指紋識別:多項研究提出了發現 IoT 和 ICS 設備并對其進?指紋識別的?法。馮等?[8] 提出了一個引擎，通過提取應用層響應數據中的相關術語，然后將它們用作網絡搜索引擎查詢來查找產品描述，生成用于發現和注釋物聯網設備的關聯規則。

科斯汀等?[49]利?監督機器學習對嵌?式設備固件數據庫進?分類，然后對在線 Web 界?進?指紋識別，將它們鏈接到數據庫中的相應圖像。佐佐?等?[14] 提出了一種專??于發現 ICS 遠程管理設備的指紋識別?法，?法是選擇可能存在 ICS 的?絡并從中收集 WebUI，然后從基于 WebUI 檢測到的遠程管理系統中識別并創建簽名，其中包含受監控設施的名稱和位置的?定義字段。作者進?了?較并指出，他們的結果超過了識別 ICS（例如 Shodan）的?業來源的結果，盡管如此，這些設備中的很?一部分已經被搜索引擎標記為 ICS。盡管如此，我們注意到，與 ICS 不同的是，ICS 已經擁有由 Shodan和 Censys 等設備搜索引擎提供的記錄完善的內置標簽，但?們對 EVCMS 缺乏了解，也缺乏?于識別它們的內置標簽。

王等?從不同的?度來看 [9]提出了一種識別物聯?設備的引擎，通過從響應數據中提取結構和?格特征，利?同一供應商或產品的物聯?設備之間響應數據的最?相似性。于等?[50]提出了一種固件識別?法，通過分析??內容來提取信息，同時使?分類和??分割來識別設備型號和固件版本。與其他設備類型相?，EVCS 具有有限且重要的橫幅，因為很難找到與其相關的信息和規范，特別是因為?多數EVCMS 產品都是基于云的且閉源的，此外還缺乏針對這些設備的橫幅規則。識別他們。此外，EVCMS 的開發?員之間的多樣性和缺乏標準化導致了?泛的橫幅表?形式，這些表?形式更難分析和跟蹤，使得使?現有?法來指紋 EVCS 變得不可?，因此，我們設計了我們的?法，從初步開始使? EVCMS 種?進?引導搜索。

EVCS 安全:先前的研究著眼于 EVCS 安全性的不同??，然?，EVCS 固件和 EVCMS 安全性很少受到學術關注。阿爾卡拉斯等?[6] 對開放充電點協議 (OCPP) 進?了安全分析，提出了允許中間?攻擊?擾 EV 資源預留的弱點，并提出了防范其提議的攻擊的對策 [51]。鮑伊等?[52] 對?輛到電?協議進?了安全分析，提出了針對充電過程的攻擊。?克等?[7] 實施了一種?線竊聽?具來進?電磁旁道攻擊，以從EVCS 電?線通信?絡恢復消息。普拉特等?[53] 制定了安全原則，以防?針對 EVCS 和電?的?絡攻擊。安圖恩等?[54] 和 Gottumukkala 等?[55] 提出了與電動汽?充電?態系統組件相關的?絡威脅的理論概述。弗萊吉等?[56] 調查了電動?互聯? (IoEV) 的安全性，指出可?于破壞其運?的?絡攻擊。穆薩維安等?[57] 提出了一種模型，可優化 EV 基礎設施內的安全?險，以處理通過 EVCS 通信?絡的惡意軟件傳播攻擊。

我們注意到，這些?作依賴于理論攻擊場景，其中假設EVCS 被惡意軟件感染，?不討論利?過程。據我們所知，我們的工作首次對 EVCMS 產品進行了深入的安全分析，同時提出了一系列允許對 EVCS 進行實際遠程利用和操縱的漏洞，從而揭示了大規模的漏洞。 規模化電動汽車生態系統的不安全性，同時警告供應商立即實施緩解措施。

系統分析:之前的一些研究檢查了物聯?和?業控制系統設備固件的安全性。科斯汀等?[20] 利?安全?具和靜態分析技術進?了?規模物聯?固件分析。佐佐?等?[14] 通過檢查不安全的配置、調查未修補的已知漏洞以及利?現有掃描儀（例如 Nmap、OpenVAS）執?滲透測試來查找零?漏洞，對 ICS 遠程管理系統進?了安全分析。雖然 ICS 主題之前已被研究過，并且有更?泛的?獻討論其安全性，但很難利?現成的?具對具有深層代碼路徑（如 EVCMS）的產品執?安全分析。因此，我們依靠量?定制的特定安全分析程序，利?靜態分析/動態指標來檢測 EVCMS 中的漏洞。鄭等?[21] 提出了一種物聯?固件模糊器，通過??和系統模式模擬來發現 1 天漏洞。斯??斯塔?等?[58] 為基于Linux 的固件構建了一個仿真和動態分析框架，該框架采?模糊測試和靜態分析技術來發現軟件錯誤。賴特等?[59] 對固件重新托管領域的流?作品進?了分類，并提出了系統仿真和分析過程中?臨的常?挑戰。陳等?[60] 提出了一種?動化系統 (Firmadyne)，該系統通過完整的系統仿真對嵌?式設備固件進?動態分析。

我們在收集的 EVCMS 固件映像上測試了 Firmadyne，試圖觀察分析結果，但是，由于它?法分析 EPK 等專有?件壓縮，因此它?法運?許多提供的 EVCMS 固件。盡管如此，我們在 ChargePrint 的設計中融?了 Firmadyne 引?的一些分析技術，例如與?件系統提取?法相關的技術。法薩諾等?[61] 提出重新托管作為固件仿真的替代?案，?于硬件系統的動態分析。雖然這些研究在分析 IoT 固件??很有效，但?多數?法都依賴于已知的 CVE 漏洞和安全掃描程序，因此除了誤報率較?之外，?法發現新的漏洞。?多數這些研究也僅對固件包進?分析，?我們對可?固件和在線端點進?分析，??需訪問底層固件。此外，?多數這些研究依賴動態分析技術來檢查嵌?式設備圖像，但由于硬件限制和與 QEMU 等仿真軟件不兼容的專有固件，這在分析EVCMS 圖像時實際上是不可?的[62]。

VIII. 結論

我們通過評估 EVCMS 作為新攻擊?的安全狀況，?次嘗試探索與 EVCS 相關的威脅。我們提出了一種新穎的發現和安全分析框架 (ChargePrint)，可以在分析其漏洞的同時對野外 EVCMS 實例進?指紋識別。此外，我們利用 ChargePrint 識別實現44 種不同 EVCMS 的 27,439 臺主機，擴展現有搜索引擎的設備發現/指紋識別功能。此外，我們的深?分析發現了 120 個 0day 漏洞，這些漏洞可能導致?多數 (92%) EVCMS 主機被遠程利?，從?引起了?們對?規模實施的EVCMS 不安全性的嚴重擔憂。最后，雖然我們注意到對電動汽?充電?態系統中各個利益相關者的攻擊影響，但我們將我們的發現傳達給各?的系統開發?員，以激勵他們提?EVCMS 和整個電動汽?充電?態系統的安全性。

致謝

我們感謝審稿?的時間和寶貴的反饋。這項?作得到了加拿??然科學與?程研究委員會（NSERC）和康考迪亞?學的?持。這項?作還得到了美國國家科學基?會 (NSF)、?級?絡基礎設施辦公室 (OAC) #1907821 和#2104273

參考?獻

[1] Hydro-Quebec, “Electric Vehicle Charging Stations: Technical Installation Guide,” https://www.hydroquebec.com/data/ electrification-transport/pdf/technical-guide.pdf, 2015.

[2] Gouvernement du Qu′ebec, “New Electric Vehicle Rebate,” https://vehiculeselectriques.gouv.qc.ca/english/rabais/ve-neuf/ programme-rabais-vehicule-neuf.asp, 2020.

[3] International Energy Agency, “Global EV Outlook 2021,” https://www.iea.org/reports/global-ev-outlook-2021, Jun. 2020.

[4] F. Lambert, “Electric car charge points soar to 7.3 million chargers, 60% growth in public chargers,” https://electrek.co/2020/06/15/ electric-car-charge-points-data, Electrek, Jun 2020.

[5] D. Shelar et al., “Compromising Security of Economic Dispatch in Power System Operations,” in Proc. of the 47th Annual IEEE/IFIP Int. Conf. on Dependable Systems and Networks (DSN), 2017, pp. 531–542.

[6] C. Alcaraz, J. Lopez, and S. Wolthusen, “OCPP Protocol: Security Threats and Challenges,” IEEE Transactions on Smart Grid, vol. 8, no. 5, pp. 2452–2459, 2017.

[7] R. Baker and I. Martinovic, “Losing the car keys: Wireless PHYLayer insecurity in EV charging,” in 28th USENIX Security Symposium (USENIX Security 19). Santa Clara, CA: USENIX Association, Aug.2019, pp. 407–424.

[8] X. Feng et al., “Acquisitional rule-based engine for discovering Internetof-Things devices,” in 27th USENIX Security Symposium (USENIX Security 18). Baltimore, MD: USENIX Association, Aug. 2018, pp. 327–341.

[9] X. Wang et al., “Iottracker: An enhanced engine for discovering internet-of-thing devices,” in 2019 IEEE 20th International Symposium on” A World of Wireless, Mobile and Multimedia Networks”(WoWMoM). IEEE, 2019, pp. 1–9.

[10] National Vulnerability Database, “Common Vulnerabilities and Exposures (CVE),” https://cve.mitre.org, 2021.

[11] Office of Energy Efficiency & Renewable Energy, “Vehicle Charging,” https://www.energy.gov/eere/electricvehicles/vehicle-charging, 2020.

[12] J. Tournier et al., “A survey of iot protocols and their security issues through the lens of a generic iot stack,” Internet of Things, vol. 16, p.100264, 2021.

[13] OCPP, “OCPP 2.0 Part 2: Specification. Technical Report,” 2018.

[14] T. Sasaki et al., “Exposed infrastructures: Discovery, attacks and remediation of insecure ics remote management devices,” in 2022 IEEE Symposium on Security and Privacy (SP). IEEE, 2022, pp. 2379–2396.

[15] B. Zhao et al., “A large-scale empirical study on thevulnerability of deployed iot devices,” IEEE Transactions on Dependable and Secure Computing, 2020.

[16] Shodan, “The search engine for Internet-connected devices.” https://www.shodan.io, Shodan, 2021.

[17] Censys, “A search engine based on Internet-wide scanning for the devices and networks.” https://censys.io, Censys, 2021.

[18] Zoomeye, “ZoomEye - Cyberspace Search Engine,” https://www.zoomeye.org, Zoomeye, 2021.

[19] Fofa, “Fofa,” https://fofa.so, Fofa, 2021.

[20] A. Costin et al., “A Large-Scale analysis of the security of embedded firmwares,” in 23rd USENIX Security Symposium (USENIX Security 14). San Diego, CA: USENIX Association, Aug. 2014, pp. 95–110.

[21] Y. Zheng et al., “FIRM-AFL: High-Throughput greybox fuzzing of IoT firmware via augmented process emulation,” in 28th USENIX Security Symposium (USENIX Security 19). Santa Clara, CA: USENIX Association, Aug. 2019, pp. 1099–1114.

[22] OWASP, “OWASP Foundation — Open Source Foundation for Application Security,” https://owasp.org, 2021.

[23] MITRE, “2021 CWE Top 25 Most Dangerous Software Weaknesses,”https://cwe.mitre.org/top25/archive/2021/2021 cwe top25.html, 2021.

[24] Zyte, “Scrapy — A Fast and Powerful Scraping and Web Crawling Framework,” https://scrapy.org, Scrapy, 2021.

[25] R. Labs, “Binwalk: Nb 1 Firmware extraction tool in the world.” https://www.refirmlabs.com/binwalk, Refirm Labs, 2021.

[26] J. W. Ratcliff and D. E. Metzener, “Pattern-matching-the gestalt approach,” Dr Dobbs Journal, vol. 13, no. 7, p. 46, 1988.

[27] rizin.re, “Cutter,” https://cutter.re, rizin.re, 2021.

[28] PortSwigger, “Burp Suite - Application Security Testing Software - PortSwigger),” https://portswigger.net/burp, 2021.

[29] B. Damele and M. Stampar, “sqlmap: automatic SQL injection and database takeover tool,” http://sqlmap.org, 2021.

[30] O. Alrawi et al., “The betrayal at cloud city: An empirical analysis of Cloud-Based mobile backends,” in 28th USENIX Security Symposium (USENIX Security 19). Santa Clara, CA: USENIX Association, Aug. 2019, pp. 551–566.

[31] S. Schrittwieser, M. Mulazzani, and E. Weippl, “Ethics in security research which lines should not be crossed?” in 2013 IEEE Security and Privacy Workshops. IEEE, 2013, pp. 1–4.

[32] J. Dittmer, “Minimizing Legal Risk When Using Cybersecurity Scanning Tools.” https://www.sans.org/white-papers/37522/, SANS, Jan.2017.

[33] Z. Durumeric, E. Wustrow, and J. A. Halderman, “ZMap: Fast internetwide scanning and its security applications,” in 22nd USENIX Security Symposium (USENIX Security 13). Washington, D.C.: USENIX Association, Aug. 2013, pp. 605–620.

[34] F. Li et al., “You’ve got vulnerability: Exploring effective vulnerability notifications,” in 25th USENIX Security Symposium (USENIX Security 16). Austin, TX: USENIX Association, Aug. 2016, pp. 1033–1050.

[35] T. Ristenpart et al., “Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds,” in Proceedings of the 16th ACM conference on Computer and communications security, 2009, pp. 199–212.

[36] Organisation for Economic Co-operation and Development (OECD), “ENCOURAGING VULNERABILITY TREATMENT,” Online at https://one.oecd.org/document/DSTI/CDEP/SDE(2020)3/FINAL/en/ pdf, 2021.

[37] The ZMap Project, “The ZMap Project,” https://zmap.io, The ZMap Project, 2021.

[38] MITRE, “Common Weakness Enumeration (CWE),” https://cwe.mitre. org, 2021.

[39] Z. Zhou et al., “Secure and efficient vehicle-to-grid energy trading in cyber physical systems: Integration of blockchain and edge computing,” IEEE Transactions on Systems, Man, and Cybernetics: Systems, vol. 50, no. 1, pp. 43–57, 2020.

[40] F. Sagstetter et al., “Security challenges in automotive hardware/software architecture design,” in 2013 Design, Automation Test in Europe Conference Exhibition (DATE), 2013, pp. 458–463.

[41] G. Liang et al., “The 2015 ukraine blackout: Implications for false data injection attacks,” IEEE Transactions on Power Systems, vol. 32, no. 4, pp. 3317–3318, 2016.

[42] S. Soltan, P. Mittal, and H. V. Poor, “BlackIoT: IoT botnet of high wattage devices can disrupt the power grid,” in 27th USENIX Security Symposium (USENIX Security 18). Baltimore, MD: USENIX Association, Aug. 2018, pp. 15–32.

[43] S. Acharya, Y. Dvorkin, and R. Karri, “Public Plug-in Electric Vehicles + Grid Data: Is a New Cyberattack Vector Viable?” IEEE Transactions on Smart Grid, pp. 1–1, 2020.

[44] O. Erdinc et al., “Smart household operation considering bi-directional ev and ess utilization by real-time pricing-based dr,” IEEE Transactions on Smart Grid, vol. 6, no. 3, pp. 1281–1291, 2014.

[45] A. K. Farraj and D. Kundur, “On Using Energy Storage Systems in Switching Attacks that Destabilize Smart Grid Systems,” in Proc. of the IEEE Power & Energy Society Innovative Smart Grid Technologies Conference (ISGT), 2015, pp. 1–5.

[46] L. Shan et al., “A Coordinated Multi-Switch Attack for Cascading Failures in Smart Grid,” IEEE Transactions on Smart Grid, vol. 5, no. 3, pp. 1183–1195, 2014.

[47] M. A. Sayed et al., “Electric vehicle attack impact on power grid operation,” International Journal of Electrical Power & Energy Systems, p. 107784, 2021.

[48] National Institute of Standards and Technology (NIST), “National Institute of Standards and Technology — NIST,” https://www.nist.gov, 2021.

[49] A. Costin, A. Zarras, and A. Francillon, “Towards automated classification of firmware images and identification of embedded devices,” in IFIP International Conference on ICT Systems Security and Privacy Protection. Springer, 2017, pp. 233–247.

[50] D. Yu et al., “Large-scale iot devices firmware identification based on weak password,” IEEE Access, vol. 8, pp. 7981–7992, 2020.

[51] J. E. Rubio, C. Alcaraz, and J. Lopez, “Addressing Security in OCPP: Protection Against Man-in-the-Middle Attacks,” in 2018 9th IFIP International Conference on New Technologies, Mobility and Security (NTMS), Paris, France, 2018, pp. 1–5.

[52] K. Bao et al., “A Threat Analysis of the Vehicle-to-Grid Charging Protocol ISO 15118,” Computer Science-Research and Development, vol. 33, no. 1-2, pp. 3–12, 2018.

[53] R. M. Pratt and T. E. Carroll, “Vehicle Charging Infrastructure Security,” in 2019 IEEE International Conference on Consumer Electronics (ICCE), Las Vegas, NV, USA, 2019, pp. 1–5.

[54] J. Antoun et al., “A Detailed Security Assessment of the EV Charging Ecosystem,” IEEE Network, vol. 34, no. 3, pp. 200–207, 2020.

[55] R. Gottumukkala et al., “Cyber-physical System Security of Vehicle Charging Stations,” in 2019 IEEE Green Technologies Conference (GreenTech), Lafayette, LA, USA, 2019, pp. 1–5.

[56] Y. Fraiji et al., “Cyber Security Issues of Internet of Electric Vehicles,” in 2018 IEEE Wireless Communications and Networking Conference (WCNC), Barcelona, Spain, 2018, pp. 1–6.

[57] S. Mousavian et al., “A risk-based optimization model for electric vehicle infrastructure response to cyber attacks,” IEEE Transactions on Smart Grid, vol. 9, no. 6, pp. 6160–6169, 2018.

[58] P. Srivastava et al., “Firmfuzz: Automated iot firmware introspection and analysis,” in Proceedings of the 2nd International ACM Workshop on Security and Privacy for the Internet-of-Things, 2019, pp. 15–21.

[59] C. Wright et al., “Challenges in firmware re-hosting, emulation, and analysis,” ACM Computing Surveys (CSUR), vol. 54, no. 1, pp. 1–36, 2021.

[60] D. D. Chen et al., “Towards automated dynamic analysis for linux-based embedded firmware.” in NDSS, vol. 1, 2016, pp. 1–1.

[61] A. Fasano et al., “Sok: Enabling security analyses of embedded systems via rehosting,” in Proceedings of the 2021 ACM Asia Conference on Computer and Communications Security, 2021, pp. 687–701.

[62] Software Freedom Conservancy, “QEMU: A generic and open source machine emulator and virtualizer.” https://www.qemu.org/, QEMU, 2021.

本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/2096/