2023 SDC 議題回顧 | 輕舟“難”過萬重山——工控漏洞挖掘的探索實踐
工控安全漏洞挖掘之路面臨萬重“山”:缺乏相關裝置,無工控實踐環境,研究者知識儲備不足,公司經費支援方面不足等。面對這些問題,議題分享者將結合過去的工業控制系統的漏洞挖掘思路,以及自身在做工業控制系統漏洞挖掘的過程中,所採取的各種探索方式、透過協議通訊分析、流量抓包偽造篡改、攻擊指令碼編寫、工控軟體逆向、工控 app 逆向分析、模擬模擬、fuzz 測試等角度。
以及最終有效獲取漏洞,並獲得漏洞編號的方式進行闡述,並對工控軟體漏洞挖掘的基本思路和方法進行描述,從工控軟體採購,模擬模擬,工控梯形圖的分析,逆向分析,以及工控流量分析、工控安全人才培養以及安全體系建設等角度對工控安全問題進行闡述。
下面就讓我們來回顧看雪·第七屆安全開發者峰會(2023 SDC)上《輕舟“難”過萬重山——工控漏洞挖掘的探索實踐》的精彩內容。
01
演講嘉賓
【劉洋-山石網科安全研究員】
長期致力於工業控制系統漏洞挖掘,研究方向為移動安全、工控安全、逆向分析。具有多年攻防競賽參賽與命題經驗,挖掘過多個工業控制系統漏洞,擁有多場攻防競賽出題經驗(逆向工程、移動安全、工控安全方向)、擁有豐富的企業,院校及個人網路攻防培訓經驗。
02
演講內容
以下為速記全文:
各位嘉賓、專家大家上午好,我是來自山石網科安全技術研究院的劉洋,今天分享的議題叫“輕舟難過萬重山-工業控制系統漏洞挖掘”,那麼究竟“難”在哪裡?我這裡會給大家進行一個講解,主要是我對於工控漏洞挖掘的一些探索和實踐。我個人的職位是安全研究員,平時會接觸一些攻防競賽、命題、出題、比賽的參賽等,研究方向是逆向工程、工業控制系統安全,還有二進位制漏洞挖掘。
整個工控安全領域的研究還是要涉及到逆向,不光涉及到工業控制系統,還涉及到移動安全,還有其他的一些知識點。
議題圍繞4點,第一個是工控安全研究的基本介紹和相關研究背景,第二個是研究難點,第三個是相關解決方法和思路,最後是探索實踐。
先看第一點,日常我們使用的自來水,燈光,電力設施,還有平時用的化妝品,一些醫療的藥品,都是需要一些工廠,包括很多車企車輛的製造工業以及加工廠等運輸系統,也包括我們的交通訊號燈,彙集了我們生活的各方各面,背後都要用到工控裝置。
總結來說工控系統可以分為PCS、 DCS、 SCADA這三種,我們的研究目標就是針對這三種不同的系統做一個系統的安全分析。先來看一下過去國際上出現的重大工控安全事件:2010年的時候,震網病毒問世,它就是世界上首個針對工業控制系統的病毒。蠕蟲病毒造成的影響讓整個伊朗國家的核設施計劃瓦解掉了。
第二個就是2012年的火焰病毒,在中東地區大範圍的傳播。也造成了很多重大影響。緊接著就是烏克蘭的電廠大規模停電,140萬的居民被迫停電。2021年美國的東部石油管道被攻擊,駭客把整個美國東部的石油管道勒索,造成了大量的石油供應鏈中斷,油價大漲。以上都是工控安全領域的一些著名案例。
我們國家針對工控安全提出了諸如《關鍵基礎設施保護條例》,《網路安全法》、《資料安全法》等法律法規,其中針對安全PLC的相關標準都有相應的出臺。
隨著OT系統與傳統IT的融合,還有工業4.0等概念的提出,導致我們的工業控制系統網路架構非常的複雜。IT系統是傳統網際網路,OT就是工業控制系統。
OT、IT要融合會涉及兩個問題,從我們安全企業角度來講,我們要保護工控系統不被攻擊。首先面臨的第一個難點:採購研究裝置困難,面臨的工控裝置品類非常多,比如說國際大廠諸如西門子、施耐德,三菱等,它的每一個品牌都會對應不同的產品線,作為研究員不可能為了安全研究把所有品牌都買回來一套。
第二個難點:裝置單價非常高,像過去西門子S7型號的一個PLC,其二手價格基本上都在1000塊錢一個,但是買回來一個單獨的PLC是沒有太大價值的,需要構建出整個工控網路還是比較困難的,還需要買網路模組、儲存模組等,所以這是第二個面臨的問題。
第三個難點:作為安全研究人員,知識面相對來說還是比較狹窄的,比如說過去最開始做安全研究,以Web安全為主,之後從事逆向、移動安全研究等,再到後來工控安全研究。那對於自動化專業該領域的知識肯定沒有相關行業的專家研究更熟絡。
無論是作為擁有工業控制系統的廠商,還是其它企業,都面臨安全意識的薄弱的問題。第二點就是安全體系建設的單一,最開始設計的工業控制系統,由於OT系統是獨立的,且跟網際網路是單獨隔離的,就單純認為其整個系統是絕對安全的,這種觀念是錯誤的,透過分析震網病毒就知道實際情況並不是預想這樣。第三點就是安全開發能力不足,可能要基於原有的PLC上位機軟體進行一些補充維護、賦能操作,研發人員可能會寫一些未經程式碼審計、有安全風險的有bug的一些程式碼。
作為二進位制安全研究人員在研究這些工控PLC韌體或者其元件、工控軟體時,會遇到了如下問題:第一個問題就是有的工控軟體有混淆,有的軟體透過LLVM這種編譯器,透過最佳化之後,使用IDA檢視虛擬碼難以直接逆向和還原原始碼。
第二個問題就是有花指令,有反除錯等。第三個問題是其函式呼叫關係複雜,像這個龍捲風圖一樣,這個是火焰病毒函式呼叫關係圖。之前,國際安全廠商分析火焰病毒,最後得到了一個函式之間呼叫邏輯關係圖,要分析一個函式,就得抽絲剝繭,程式碼呼叫關係的上下游都要看,會發現這個函式憑一己之力短時間內將它分析出來,幾乎不可能。
尤其是針對軟體有OLLVM控制流平坦化這種混淆很難直接去分析。對於我們來說難度太大、工程量巨大、人力成本極高。
軟體逆向方向走不通,那麼從協議分析的層面來分析,目前的工控協議主要是以下三種:第一種是公開標準協議,比如國際通用標準的 modbus協議、DNP3協議、IEC104的電力系統協議。
第二種就是私有公開的協議,私有公開就是廠商他自己開發出來的協議,而且提供了開發文件,這個是便於除錯以及跟其他廠商產品進行相容的。比如三菱系統的歐姆龍FINS協議,就屬於私有公開協議,廠商自己的裝置,在通訊過程當中會產生大量資料包文。而西門子的S7協議,雖然屬於私有不公開協議,但大家可以在網上找到很多關於西門子S7協議的分析。
協議分析的難點在於針對私有不公開協議的裝置。類似霍尼韋爾這種國外廠商的工控系統,研究者發現這以上三種方法都沒進行測試。要進行工控安全漏洞的挖掘,想要找到霍尼韋爾或者其他廠商的一些漏洞難度較大。
首先從modbus協議開始,該協議有一定的脆弱性,起初這個協議是1979年提出來的,它是通用標準,基於乙太網(TCP/IP)的分散式應用,TCP協議剛剛我們段教授也講了,它有協議自身的一個限制性、侷限性。協議頭可能健壯性不夠,modbus設計之初,可能一個報文只能接收500多個位元組,我們可以透過Peach寫Pit指令碼或者使用其它模糊測試工具進行fuzz,短時間內傳送大量的報文進行協議測試,就會讓PLC裝置 crash掉,工控裝置一旦停掉,造成的拒絕服務影響就非常之大了。
我在研究霍尼韋爾的時候做以上研究實踐,結果都無疾而終,沒有任何成果,在霍尼韋爾這套裝置是沒法去直接透過協議fuzz的方式去獲取漏洞的。
接著就是上位機的執行環境,既然從抓包的角度沒法進行協議分析,嘗試對上位機軟體進行逆向。但是函式呼叫關係複雜,逆向工程量巨大,困難重重,短時間內沒法解決。
那麼Wireshark它既然能解析除了常規的協議,部分工控協議也能解析,可以使用Wireshark來解析工控協議格式中的功能碼,或者參考網際網路上其他安全研究人員的研究文章。
這是工控現場獲取到一個資料包,協議中有功能碼,其功能碼就是讀對應的暫存器的值,並進行賦值操作,點位對應的值都是可以直接看到,說明這個協議是沒有進行任何安全加密,非常的不安全。如果駭客傳送了底下這一串資料, 這個payload在網際網路上可以找到,一旦傳送出去,只要是對應的工控協議,工控廠商整個執行環境就會被停掉。
接著,Wireshark的原始碼當中,我們可以看到比較早期的諸如西門子的H1協議,這個是針對於西門子的S5裝置,非常古老,可能1980年左右開發出來的一套工控系統,Wireshark也可以解析。包括電力系統的IEC104協議、西門子的S7協議。
在協議頭內可以看到對應原始碼,Wireshark既然能解析這個協議,底層原始碼是C語言寫的,可以看到函式呼叫關係,比如西門子的PLC功能碼0x29,那麼我們清楚的知道一旦傳送0x29,在協議報文中被構造出來,它就可以對西門子PLC在進行停機操作。
很多安全廠商都把功能碼操作整合在對應的安全產品中。類似於西門子的確認報文,其使用者資料段的內容也是明文可見的。包括其它裝置諸如電梯樓宇自動化、將來整套智慧的智慧家居,在未來的研究過程中。協議層面也依舊會存在一些安全隱患,我們也可以沿用工控安全研究協議分析的這種思路去做。
開源工具ISF它對工控系統的安全測試也非常重要,該工具它可以直接對諸如S7-300型號和S7-400型號的PLC進行控制,可以執行停機指令,也可以進行重啟操作。如果駭客具備MSF的使用經驗,就可以去一個工控廠商去使用ISF指令碼,如果是相對應的工控裝置就會發生嚴重的問題。
起初我們透過研究modbus協議能對工控協議的脆弱性有初步的認識,且網際網路上都有相關的公開研究內容,可以按照之前這種研究思路去嘗試,挖掘艾默生這種裝置時,其思路一致的。
還有基於TCP通訊的fuzz技術,對協議的健壯性進行測試,還有從Windows系統上的上位機軟體入手,三個方向耗費了約大半年的時間進行了測試,多次結果都是失敗告終,失敗後又重新測試,這就是工控安全研究面臨的萬重“山”。
接著我就在想,是不是自己的研究思路有問題。“他山之石,可以攻玉”,就去看看國外研究人員是怎麼研究漏洞的,是如何取得那麼大成就的。我們都知道pwn2own大賽,匯聚了全球的一些頂級駭客,也關注到有一個pwn2own邁阿密賽事。邁阿密賽事應該是2020年左右才開始逐步的去接受選手比賽報名,pwn2own邁阿密賽場中選取工控裝置及工控軟體給選手作為攻擊靶標。
pwn2own邁阿密它主要是讓全球頂級駭客去測試工控產品當中是否存在漏洞。
ICONICS是美國的一家工業自動化供應商,1986年成立,主要是給石油、煉化、汽車、樓宇、天然氣、廢水處理、可再生能源等行業提供工業自動化服務。該公司的產品被作為選手測試的一個目標。在2020年的比賽中,選手針對暴露的網路服務進行漏洞測試,針對該產品進行安全測試,選手透過WCF技術,客戶端執行了對應的SQL語句,透過WCF任意執行SQL命令。透過命令執行的漏洞獲取到2萬美金的獎金。
當時就在想,要研究工控漏洞,針對工控軟體有沒有一些不被別人知道的較為小眾的一些元件,或者說一些其他類似這種第三方元件的技術。緊接著2022年pwn2own邁阿密賽場中的另外一個隊伍,他們是從另外一個角度去挖掘漏洞的。
將工控程式安裝好之後,從檔案格式的角度去考慮。該程式的檔案格式是一個軟體ISO安裝映象,使用者可以透過映象檔案進行安裝,安裝過程中可以生成demo檔案。從映象檔案入手,去看整個系統的檔案當中的程式碼是否存在注入漏洞、以及其它安全風險。首先第一個點看有沒有這種像Java反序列化、PHP反序列化等這種序列化的風險。
發現物件在開啟檔案的時候會發生一個序列化,主要序列化的點主要是在以上區域。
程式碼中的type型別,使用的是JScriptNet這樣的型別,平時很少有開發者去使用這樣的一個程式語言。
透過維基百科查詢,發現該語言是由微軟開發,是針對於.net的一個衍生,可以進行一些函式的處理。函式處理中有的函式對於我們安全研究員來講異常敏感。比如說exec,execute,system等。
接著去開啟對應的專案檔案,發現需要賬號登入,這裡嘗試能否進行繞過。
該軟體生成的除了預設檔案,它對應的同專案檔案目錄中還有一個模板檔案,字尾為tdfx,而這個檔案它可以由軟體直接開啟,不需要任何登入,且在對應的標籤裡可以插入JScriptNet語言程式碼,此時身份認證已經被繞過。
接著透過翻閱開發手冊,可以看到使用者可以自己定義JScriptNet程式碼,使用者可以去寫一些自動化外掛化的程式碼來實現對應的功能。
比如上圖中寫的一個demo,使用JScriptNet對應的語法,寫了這樣一個彈窗。
接著就可以構造程式碼去做一個命令執行的操作,只需要寫這兩行程式碼就獲得了2萬美金的獎金。從我們研究者角度來講,這兩行程式碼很容易理解,只要稍微相關程式語言的語法,然後呼叫這個函式去執行相關程式碼,就可以進行命令執行,彈出計算器。pwn2own是直接承認以上操作,是屬於漏洞的,直接給獎金而且記了20個大師分。所以有的時候研究者的思路需要被開啟,還是需要持續進步的。
針對檔案格式的相關漏洞研究及測試也是一個非常好的方向,可以看到UAF漏洞、越界寫、棧溢位等。以上是針對 CX-Programmer這個工控軟體去做的漏洞挖掘。
這是另外一個非常著名的工控系統漏洞,透過審計程式碼發現,程式程式碼在校驗使用者的使用者名稱和密碼的時候,沒有校驗密碼。
駭客只要偽造一個token,就可以獲取到系統許可權。
我們回到研究最開始的部分,震網病毒的解構,發現涉及的內容包括 STL,即工控梯形圖,電氣工程師使用STL給 PLC進行程式設計,而我們一般的程式設計師是不會特意去學梯形圖相關操作的。
緊接著還有DLL注入,震網病毒最後其實是透過被人帶進去的隨身碟進行“擺渡”攻擊進入到對應廠區,透過去尋找對應的作業系統上是否安裝WinCC軟體,有沒有安裝 step 7這種西門子的上位機軟體,如果有的話,用DLL注入這種方式直接把對應的惡意程式碼注入到對應系統。DLL劫持程式後再將病毒進行擴散。當時的網路狀況肯定是OT和IT相分隔,但是隨身碟“擺渡”攻擊打破了所有的網路隔離界限。
回到最開始霍尼韋爾的安全研究,從協議角度我們發現協議中有大量的TCP報文,協議內還有對應的data資料包文,由於Wireshark的原始碼裡是沒有專門針對這個協議的解析。透過研究發現它的協議是基於 FTE的網路架構,最終實現的一個效果能獲取到該裝置的型號以及它的一些功能處理資訊,屬於一個漏洞。回到震網病毒中的DLL劫持,可以設想一下,如果說某個廠商他用了這樣一套裝置,系統正常運轉能正常開啟對應的工程檔案,但是駭客透過研究這個程式的漏洞,去構造DLL劫持,或者去劫持上位機執行環境,比如劫持Windows系統的元件等。
可以看到攻擊者構造了兩個dll。在軟體目錄中放入構造的DLL惡意程式碼,然後就會發現程式已經被劫持。針對不同的工控系統行業,其工控軟體一旦被劫持,其專案工程都無法開啟,勢必會對整個工廠的正常運轉造成一些影響。
針對工業APP的逆向也是重點研究方向,這是過去國外的一套工業APP,該程式是沒有進行加殼、混淆,而且核心邏輯都是透過Java編寫,不透過so層做處理。透過Java的程式碼審計,可以輕鬆查詢到 IP地址,及其連線的502埠。其協議使用的就是modbus協議。該工業APP的功能實現,就可以用手機來實時監控整個廠區的一個執行狀態,包括點位,溫度。未來工業APP的安全研究應該也是個趨勢。
國外有很多非常頂尖的工控安全研究員,透過分析這些研究員,也能獲取到不少漏洞挖掘的思路。首先就是這些研究工控安全的人員他是什麼出身,他們是如何做到在短時間內挖掘到大量工控漏洞的?諸如透過今年BlackHat的議題,就能學習到他們研究opc-ua工控裝置的攻擊思路。透過領英也能夠找到其團隊成員的履歷,包括這個團隊的基本資訊,Team82團隊短短几年時間就挖出了上百個工控漏洞。
網路安全的競爭歸根結底是人才的競爭,工控安全競賽的舉辦也極大的推動了相關人才的培養。諸如本次全國總決賽中的這道題目,考核選手的綜合能力。
第一個點,就是要透過逆向分析。首先進行Base64解碼,拿到題目描述中的第一個key值,但第二個key值沒法直接逆向拿到,透過寫爆破指令碼,最終爆破獲取得到第二個值,之後填入到題目中的梯形圖裡,模擬得到最終結果。這道題要考察傳統網路安全中的逆向分析能力,編碼解碼能力,電氣工程師的梯形圖程式設計模擬能力。所以我覺得未來的工控網路要實現IT、OT的融合,就需要這方面的人才。電氣工程師要掌握網路安全的知識,網路安全的人員要去掌握工控的知識,這樣才能達到輕舟已過萬重山。
之後最好是達到乘風破浪會有時,直掛雲帆濟滄海”的這樣一個局面,我也覺得未來是非常明朗的,尤其工控安全行業。說完了工控安全人員所應該劇本的基本素質和要求,那就說一下工控安全的人員究竟如何去招聘,需要哪些人才。
CTF競賽其實蠻關鍵的,因為我們在研究一些工控軟體的時候,一些混淆加殼,如果沒有相關經驗,第一次接觸就不會有任何頭緒。但是透過CTF競賽當中有些題目,其涉及到加殼混淆、花指令等,透過平時的小練習來積累經驗。以小勝積大勝其實是可以解決這些問題的。當然也需要Web安全研究人員,一些工控系統的配置專案是放在網站頁面上的,需要Web安全研究人員從滲透測試的角度去找漏洞。我們也需要有做Pwn的二進位制漏洞挖掘人員。
從二進位制漏洞挖掘的角度去挖掘工控系統漏洞。也需要有Misc這種發散型的思維和頭腦。更需要逆向底層的安全研究,尤其是PLC程式設計、協議分析、韌體逆向、漏洞挖掘、PLC程式設計等角度進行安全研究。所以對人員能力的要求還是比較綜合的,並且要具備快速學習的能力。
*峰會議題PPT及回放影片已上傳至【看雪課程】https://www.kanxue.com/book-leaflet-171.htm
PPT及回放影片對【未購票者收費】;
【已購票的參會人員免費】:我方已透過簡訊將“兌換碼”發至手機,按提示兌換即可~
《看雪2023 SDC》
看雪安全開發者峰會(Security Development Conference,簡稱SDC)由擁有23年悠久歷史的頂尖安全技術綜合網站——看雪主辦,面向開發者、安全人員及高階技術從業人員,是國內開發者與安全人才的年度盛事。自2017年七月份開始舉辦第一屆峰會以來,SDC始終秉持“技術與乾貨”的原則,致力於建立一個多領域、多維度的高階安全交流平臺,推動網際網路安全行業的快速成長。
鑽石合作伙伴
黃金合作伙伴
相關文章
- 2023 SDC 議題預告 | 輕舟“難”過萬重山 ——工控漏洞挖掘的探索實踐2023-10-11
- 2023 SDC 議題回顧 | 從探索到利用:揭示安卓模擬器漏洞2023-11-14安卓
- 2021看雪SDC議題回顧 | 基於模擬模擬的藍芽協議棧漏洞挖掘2021-11-01藍芽協議
- 2023 SDC 議題回顧 | 探索軟體定義汽車的安全攻擊面2023-12-07
- 2023 SDC 議題預告 | 深入Android可信應用漏洞挖掘2023-10-16Android
- 2021看雪SDC議題回顧 | SaTC:一種全新的物聯網裝置漏洞自動化挖掘方法2021-11-09
- 2023 SDC 議題預告 | 從探索到利用:揭示安卓模擬器漏洞2023-10-13安卓
- 2020 看雪SDC議題回顧 | 世界知名工控廠商密碼保護機制突破之旅2020-11-02密碼
- 2022 SDC 議題 | 漫談AOSP藍芽漏洞挖掘技術2022-10-10藍芽
- 2023 SDC 議題預告 | USB FUZZ 工具前沿探索2023-10-17
- 2023 SDC 議題回顧 | 晶片安全和無線電安全底層滲透技術2023-11-22晶片
- 2023 SDC 議題回顧 | 從邏輯計算到神經計算:針對LLM角色扮演攻擊的威脅分析以及防禦實踐2023-11-07
- 2023 SDC 議題回顧 | JDoop:下一代針對Java Web應用的靜態分析框架2023-11-06OOPJavaWeb框架
- 2019 SDC 議題回顧 | 工業集散控制系統的脆弱性分析2019-07-29
- 2019 SDC 議題回顧 | 基於雲資料的司法取證技術2019-07-24
- 2023 SDC 議題預告 | 探索軟體定義汽車的安全攻擊面2023-10-20
- 2019 SDC 議題回顧 | 是誰推開我的“窗”:iOS App介面安全分析2019-07-29iOSAPP
- 2020 看雪SDC議題回顧 | 麒麟框架:現代化的逆向分析體驗2020-11-03框架
- 2021看雪SDC議題回顧 | APT針對恐怖主義的間諜活動剖析2021-11-04APT
- 使用蜻蜓安全挖掘漏洞實踐(一)2022-04-30
- 2020 看雪SDC議題回顧 | 生物探針技術研究與應用2020-10-30
- 2023 SDC 議題預告 | 車聯網——站在研發視角挖漏洞2023-10-18
- 2020 看雪SDC議題回顧 | 高通移動基帶系統內部揭密2020-11-04
- 文字輿情挖掘的技術探索和實踐2019-01-07
- 關於學習.NET的歷程回顧與今後的探索實踐方向2024-07-24
- 2020 看雪SDC議題回顧 | Android WebView安全攻防指南20202020-10-29AndroidWebView
- 2019 SDC 議題回顧 | 安全研究視角看macOS平臺EDR安全能力建設2019-07-23Mac
- ChunJun框架在資料還原上的探索和實踐 | Hadoop Meetup精彩回顧2022-10-10框架Hadoop
- W13Scan 掃描器挖掘漏洞實踐2020-12-03
- 2022 SDC 議題 | 面向業務守護的移動安全對抗實踐2022-10-17
- 2020 看雪SDC議題回顧 | 敲開晶片記憶體保護的最後一扇“門”2020-11-02晶片記憶體
- 2020 看雪SDC議題回顧 | 基於量子邏輯閘的程式碼虛擬(vmp)保護方案2020-11-02
- iOS實踐:通過核心動畫完成過山車2017-11-29iOS動畫
- 2022 SDC 議題 | 從後門到漏洞——智慧裝置私有協議中的安全問題2022-10-12協議
- 2022 SDC 議題 | Linux 核心漏洞檢測與防禦2022-09-22Linux
- 某知名系統漏洞挖掘與利用思路探索2022-09-19
- 華為敏捷DevOps實踐:產品經理如何開好敏捷回顧會議2018-11-21敏捷dev
- 華為敏捷 DevOps 實踐:產品經理如何開好敏捷回顧會議2018-11-22敏捷dev