知識星球來自：FreeBuf.COM
*參考來源：Checkpoint，clouds編譯
http://www.freebuf.com/vuls/182869.html
從遠古時代的飛鴿傳書到後來的郵政快遞，寫信人與收信人之間的物理訊息傳遞方式逐漸在演變發展，之後，傳真技術的出現從某種程度上說，幫助人們走出了信件傳遞的黑暗時代。
然而，技術發展到今天，就通訊手段而言，我們有電子郵件、社交聊天、行動通訊渠道、網路服務和高大上的量子衛星通訊等等，但在這種喜新厭舊的資訊時代中，傳真技術仍然沒被淘汰，且依舊被廣泛使用。根據簡單的谷歌搜尋可以發現，網上出現了超過3億個的在用傳真號碼，看來，傳真技術還是我們常用的辦公通訊方式之一。
為此，CheckPoint 決定深入研究一下這種“老派”的通訊方式，看看它除了具備嘈雜的傳呼機功能和官僚主義負擔之外，是否存在著嚴重的網路安全風險。以下為CheckPoint 的相關研究：
研究背景
傳真通訊是利用掃描和光電變換技術，從髮端將文字、影象、照片等靜態影象透過有線或無線通道傳送到接收端，併在接收端以記錄的形式重顯原靜止的影象的通訊方式。傳真是基於傳統電信線路電話交換網（PSTN）與軟交換技術（NGN）的融合。
如今的傳真技術被廣泛整合於多功能一體印表機裝置中，之後，家庭或企業透過乙太網、WiFi、藍芽等介面把這些一體機接入內網使用。當然，為了支援傳真功能，這些一體機還連線了傳統話務（PSTN）的電話線。
我們在研究一開始就定下了這種假設，攻擊者能否僅僅透過電話線和相應的傳真號碼，就能向多功能一體印表機傳送惡意傳真來實現入侵呢？如果答案是“能”，那麼透過這臺受控印表機，就有可能深入向企業內網滲透。終於，經過漫長而乏味的研究，我們有了突破。
事實上，我們在多功能一體印表機中發現了幾個關鍵漏洞，利用這些漏洞，透過向其傳送構造的惡意傳真，就能實現對其完全的入侵控制。這樣一來，開啟了企業內網之門，也就什麼可能都存在了，攻擊者可以潛伏在多功能一體機中，向脆弱的企業內網電腦發起“永恆之藍”漏洞攻擊，或透過傳真方式竊取內網電腦資料並向外回傳。
我們把這種攻擊稱之為“Faxploit”攻擊。以下為實際網路環境中的PoC影片：
演示影片：
逆向韌體
首先，在韌體逆向分析過程中，我們使用IDA來識別傳真功能中實際的執行行程和環境，有了一些發現：
架構
我們測試的多功能一體機是基於ARM 32bit的CPU架構的大端儲存樣式（Big-Endian），主CPU使用共享儲存區與控制LCD螢幕的MCU元件進行通訊。
作業系統
作業系統是Green Hills的ThreadX式嵌入式實時作業系統，它使用平面記憶體架構，很多工行程執行於核心樣式下，使用同一個虛擬地址空間。也是由於這種平面記憶體架構的原因，我們認為任務行程的通訊是透過訊息佇列方式進行的（FIFO），另外，其虛擬地址空間是固定的，未部署任何地址空間佈局隨機化（ASLR）保護機制。
DSID值
然而，當我們在分析T.30狀態機任務(“tT30”)時，偶然發現了很多使用特別ID的追蹤方法（trace），深入分析發現，這些ID也被用於一些以“DSID_”為字首開頭的字串串列中。實際上，這些字串看似是與那些使用ID的追蹤方法（trace）邏輯相匹配，這也給了我們重要的逆向提示線索。於是乎，我們從所有不同的DSID串列中建立了一個列舉型別，形成了任務中的各種追蹤方法文字描述。以下為trace追蹤方法中使用的DSID值：
T.30狀態機中的DSID串列：
在追蹤方法中應用DSID列舉：
任務不一致性
當我們逆向T.30狀態機和之後處理HDLC的傳真貓（“tFaxModem”）時，發現缺少了多個函式指標表。之後我們還發現，有兩種常規的程式碼樣式貌似和 allocation/deallocation路徑有些相似。每個模組中採用的方法，是為了接收來自其它模組的訊息，或者，也可能是把快取傳送到下一模組中，如下圖使用某個功能表從另一個任務接收資料幀：
如果我們不能定位這些模組中採用的具體方法，也就無法弄清韌體中的資料流形式，會對韌體的下一步分析造成阻礙。由於我們無法定位到大多數方法指標的初始化，所以，我們需要一種動態方法，也即除錯器來進行除錯。
建立除錯器
序列除錯介面
首先，我們分析了一體機的主機板，想找到上面的序列除錯埠，不一會，我們就有了發現。下圖為連線JTAGULATOR到印表機的序列除錯器：
但接入除錯器之後，我們才發現其除錯介面的預設許可權是受限的，不能有效地執行我們的預設命令：
這看起來是需要提權才行了，但提權就得需要漏洞啊，那就來找找看吧！
匹配已知漏洞
尋找已知漏洞
當你要exploit一種特定韌體時，首先的方法就是去看看它使用了哪些開原始碼，對比不同版本，盡可能地找到能用的CVE。這項工作1天已經足夠了，對於除錯目的來說也是綽綽有餘。有兩種方法來判斷使用的開原始碼：
在韌體逆向程式碼中使用字串查詢，從中找出關鍵字串
從廠商網站中查詢一些產品的開原始碼認證資訊
另外，要發現這些開原始碼漏洞有幾種方法：
在CVE庫中查詢與其程式碼庫相匹配的漏洞
用熟悉的漏洞進行驗證
關註US-CERT每週釋出的CVE更新訊息
gSOAP工具包除錯漏洞 – CVE-2017-9765
在開原始碼分析中，我們發現其中使用了gSOAP庫，經分析確認，gSOAP庫曾存在“魔鬼綠蘿”（Devil’s Ivy）的CVE-2017-9765漏洞，是早前在監控攝像頭開源軟體中爆出的0-day漏洞，曾影響了全球大量IoT裝置。以下為該漏洞程式碼段的反編譯程式碼：
利用該漏洞，向多功能一體機傳送超過2Gb的XML資料時，將造成整型下溢，最終會導致棧緩衝區上限溢位，可執行任意程式碼，能實現對標的多功能一體機的完全控制。
但是，該漏洞的利用存在兩個前提限制：
漏洞利用程式碼的傳輸需要耗費大量時間，最佳化後，傳輸時間還是在7分鐘左右
只能在IDA和每次嘗試失敗時產生的基本序列轉儲環境下來開發這個漏洞
對Devil’s Ivy的CVE-2017-9765漏洞利用
該漏洞可以觸發棧緩衝區上限溢位，但存在一些限制型字元。這種字元如下：
不可列印的: 0x00 – 0x19
‘?’對應的: 0x3F
該漏洞的一個好處是上限溢位無限制，也就是說，我們可以把整個漏洞利用鏈傳送到標的裝置的棧區中進行攻擊。
但在嵌入式環境中，我們需要註意的是其CPU的各種快取可能會對漏洞觸發造成影響。CPU中接收到的資料包會存放在資料儲存區 Data Cache (D-Cache)，而執行指令則會在Instruction Cache (I-Cache)中進行。也就是說，即使沒有NX位支援，由於CPU會透過 I-Cache 執行程式碼，那麼我們也不能直接在棧緩衝區中實現漏洞Payload的觸發。
如何才能繞過以上這些各種限制呢？我們需要用到一種包含以下部分的Bootstrapping演演算法利用：
可以掃清D-Cache 和 I-Cache 的基本的ROP（面向傳回的程式設計）控制
載入到除錯器網路載入端的解碼shellcode
整個除錯器可以透過網路傳送到載入端
在此，我們就不展開詳談漏洞利用鏈構造過程，如果你感興趣請自己嘗試測試。接下來，我們來說說漏洞利用的各種載體。
Scout除錯器
我們構建的除錯器是一個基於指令的網路除錯器，它支援基本的記憶體讀寫請求，還能擴充套件支援特定韌體指令。我們使用除錯器從多功能印表機中提取了其記憶體，然後對它進行了一些擴充套件測試。
一旦除錯器被配置了附帶韌體API函式，如memcpy、sleep和send等地址後，由於它是位置無關的，所以除錯器就可以載入任意地址。Scout Debugger下載地址：https://github.com/CheckPointSW/Scout
ITU T.30 – Fax協議
多功能一體機如果支援傳真功能，那麼也一定能支援涉及傳真裝置的ITU-T G3協議標準，該標準定義了傳真傳送端和接收端的基本功能，以及協議的不同實現階段，如下圖所示：
我們重點來看上圖的Phase B和Phase C，Phase B負責傳送端和接收端之間的協商（握手），而Phase C則根據協商規定進行資料幀傳輸。資料幀利用面向位元的高階資料鏈路控制協議（HDLC），透過電話線來進行傳輸，如下圖所示：
挖掘攻擊向量
傳送TIFFs
存在一種誤解，也就是傳真只是一種簡單地TIFF報文傳送手段。實際上，T.30協議能傳送頁面，且Phase B階段協商的引數中就已經包括了頁面長度和寬度，而且，Phase C階段則主要是傳輸頁面的資料行。也就是說，傳真最終的輸出是一個包含IFD標簽的TIFF檔案，IFD標簽在該過程中用於構建協商用的元資料，.TIFF檔案中包含有接收到的頁面行。
儘管.tiff解析器存在很多漏洞，但很多都是在IFD標簽的解析程式碼漏洞，而且我們這裡的研究用例中，這些IFD標簽都是由多功能列印一體機自己建立的，這裡唯一會對我們的頁面內容執行的處理過程就是，列印過程中開啟其壓縮內容。
TIFF壓縮
不幸的是，.tiff格式使用的壓縮機制有多個名字，因此首先需要把它們找出來。以下是它們的一個基本對映關係：
TIFF Compression Type 2 = G3 without End-Of-Line (EOL) markers
TIFF Compression Type 3 = G3 = ITU T.30 Compression T.4 = CCITT 1-D
TIFF Compression Type 4 = G4 = ITU T.30 Compression T.6 = CCITT 2-D
由於傳真基本是黑白顏色的，所以，壓縮機制實際上是一種使用了固定霍夫曼表的黑白程式碼行程編碼方式（RLE）。因此，我們再對T.4 和 T.6 的程式碼壓縮機制進行分析，沒發現什麼可以利用的漏洞。
T.30擴充套件
在Pahse B階段，傳真貓會進行功能交換，所以它可以找出能支援的最佳傳輸方式。為此，我們編寫了一個簡單指令碼對這些使用ITU T.30標準的訊息進行了語法分析，下圖為對數字識別訊號（DIS）的解析結果：
看似我們測試的一體機支援ITU T.81 (JPEG) 格式，也就是說，它能傳送彩色傳真。而在分析彩色傳真的處理程式碼過程中，我們有了另外的新發現：接收到的資料按原樣儲存到.jpg檔案中，與.tiff檔案中標頭由接收端建立的不同，這裡的.jpg我們可以對整個檔案進行控制。
我們基於標準對這種傳真行為進行了檢查後發現，由於JPEG格式非常複雜，其標頭Header（也稱為標記maker）確實是透過電話線傳送的，接收端負責處理它們並決定保留下什麼。一些標頭可能不受接收端支援，會被丟棄，如COM的其它標頭則會被忽略。在我們對韌體和開原始碼的測試檢查中，接收內容總會被無過濾地轉儲到一個檔案中儲存，這也就成了攻擊者的一個很好的“獵物”。
列印彩色傳真
概括來說，當標的印表機接收到一個彩色傳真，它就會簡單地無安全過濾地，把其內容轉儲到一個.jpg檔案中，通常來說，這個檔案位於%s/jfxptemp%d%d.jpg。然而，接收傳真只是第一步，接下來還需要列印傳真，為此列印模組需要首先確認接收檔案的長度和寬度，所以，還要進行一個基本的語法分析。
JPEG解析器
存在一些說不清的原因，這種特定韌體的開發者傾向於把主流開源專案中實現的模組功能進行重新編寫，改善最佳化，也就是說，他們不會用開源的libjpeg標準庫，轉而是用自己的 JPEG 解析器。從攻擊者角度來說，這就是一個可以利用的點，在開發者自己開發的複雜檔案格式解析器中來發現可利用的漏洞，似乎也不是沒有可能。JPEG解析器原理非常簡單：
先檢查影象開始SOI標記：0xFFD8
迴圈分析各個支援標記
完成以上步驟後向呼叫者傳回相關資料
這不，我們就以此為突破口，發現了以下兩個漏洞。
CVE-2018-5925 – COM標記解析緩衝區上限溢位漏洞
根據ITU T.30 standard標準，COM標記 (0xFFFE)是一種大小可變的文字欄位，這種文字欄位一般用來代表文字型別的註釋說明。從這個點上，我們希望發現某種解析漏洞。比較搞笑的是，根據ITU T.30 標準來看，這種COM標記應該要被傳真接收端丟棄才是。然而，我們卻在其中發現了以下漏洞：
解析模組會解析一個低位元組序或小端樣式的2位元組長度欄位，並反覆執行從傳真檔案中複製資料到一些全域性陣列中的操作。貌似陣列中的每個條目都有2100位元組的大小，而我們的構造的長度欄位可以高達64KB，這就給了我們一個大容量的可控緩衝區上限溢位區域。
CVE-2018-5924 – 解析DHT標記時的堆疊緩衝區上限溢位漏洞
由於上一個漏洞的發現是標準實現中不應支援的標記所導致的，所以，我們繼續把關註點擴充套件到了其它標記身上。在解碼檔案的資料幀時，DHT標記(Difine Huffman Table) 定義了一個特定的霍夫曼表來使用。而且，這個DHT標記漏洞涉及到的函式比上個漏洞函式還簡單容易一些：
可以看到存在一個讀取16位元組的初始解析迴圈，這是因為每個位元組代表了一個長度欄位，所有這些位元組最後累積成為一個總的長度變數
存在一個全0填充的256位元組本地備用堆疊
第二個解析迴圈會使用之前的長度欄位，從傳真檔案中複製資料到本地堆疊緩衝區中
一個簡單的計算就能知曉具體的漏洞成因：16 * 255 = 4080 > 256，也就是說，我們可以構造一個大容量可控且無限制的堆疊緩衝區上限溢位，這是多好的一個漏洞啊。
建立漏洞利用程式碼
對比以上兩個漏洞，由於DHT標記解析漏洞相對容易實現。在Devil’s Ivy漏洞中，其中的除錯exploit利用程式碼，也是利用了一個堆疊上限溢位漏洞，那麼這裡我們也是一樣，僅只需要對除錯exploit作出一些小修改即可。
自動化Payload – 實現圖靈機機制
我們可以使用同樣的網路載入器來構造除錯exploit。然而，當前的攻擊向量有一個主要的優勢：完整的攻擊Payload可以儲存在傳真傳送的“JPEG”中，鑒於它不對傳真內容執行任何安全過濾檢查，因此我們可以把整個Payload都儲存在傳送檔案中，不需要擔心它是否會被轉儲為一個非法的JPEG檔案。
而且檔案的fd檔案描述符也儲存在可訪問的全域性變數中，所以， 我們編寫了一個基於檔案的載入器，該載入器會從檔案中讀取Payload，然後把它載入到記憶體中去。之後，每次Payload想要用輸入執行任務時，它就會從同一檔案中讀取輸入並按照其中的指令實現任務操作。為此，我們構建了一個基本的圖靈機機制來從傳送傳真中讀取輸入並實現操作。
透過網路傳播
入侵控制一臺企業印表機也不錯，但是我們想做的遠不只這些。實際上，如果能透過印表機來控制整個企業內網，那影響和威脅就就非常之大了。所以，我們利用我們漏洞分析團隊之前的研究結果，綜合了NSA武器 – “永恆之藍”（ Eternal Blue）和“雙脈衝星”（Double Pulsar），應用於此次傳真漏洞的基於檔案的圖靈機中來。
我們的漏洞Payload具備以下功能特點：
可以控制多功能一體機的LCD顯示屏 – 這是一種印表機完全控制權的體現
檢查多功能一體機的網路是否為連通狀態
使用NSA“永恆之藍”（ Eternal Blue）和“雙脈衝星”（Double Pulsar）武器，攻擊標的內網受害主機，實現入侵控制。
由此，我們透過傳真漏洞遠端實現企業內網的多功能一體機入侵控制，並以此為據點，可向企業內網深入進行橫向滲透。
總結
我們測試用的多功能一體機為 HP Officejet Pro 6830，研究測試表明，這種當前的傳真實現協議存在安全隱患，其它啥都不用，僅需要向標的一體機傳送一份傳真就能完全控制裝置，可以此為潛伏據點，用已知的NSA漏洞exploit深入向企業內網滲透。
從現在起，傳真機也能成為滲透入侵企業內網的途徑之一。我們認為，這種傳真技術存在的安全風險應該被重視，因為它延伸了現代企業網路的安全邊界，網路印表機和傳真機都有能成為網路架構中的一個入侵風險點。
漏洞披露行程
在與惠普公司（HP）進行協商之後，有了以下的漏洞披露行程：
2018.5.1 向HP公司上報漏洞
2018.5.1 HP公司感謝提交並著手處理漏洞
2018.5-2018.6 不停的重現PoC場景，修補漏洞
2018.6.2/3 與HP公司面對面溝通
2018.7.23 發現的兩個漏洞被標記為高危
2018.8.1 HP公司公佈韌體升級補丁
2018.8.12 在 DEFCON 26 會議中首次公開
●編號705，輸入編號直達本文
●輸入m獲取到文章目錄
Python程式設計
更多推薦《18個技術類公眾微信》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
