針對傳真軟體攻擊面的研究

企業內容管理會話劫持 · 發表 2018-10-08 10:35:12

摘要：前言估計你聽到“傳真機”這幾個字，都覺得它是個很古老的裝置，現在即時通訊裝置十分普遍，傳真機的使用環境已經非常的少了。但是在許多關於商務和法律的公司內，傳真機的使用率還是比較高的。不過由於傳真機的市場份額正在逐年減少，所以開發商對這方面的技術研發投入也越來越少。這意味著傳真機的許多關鍵技...

前言

估計你聽到“傳真機”這幾個字，都覺得它是個很古老的裝置，現在即時通訊裝置十分普遍，傳真機的使用環境已經非常的少了。但是在許多關於商務和法律的公司內，傳真機的使用率還是比較高的。不過由於傳真機的市場份額正在逐年減少，所以開發商對這方面的技術研發投入也越來越少。這意味著傳真機的許多關鍵技術還停留在十幾甚至幾十年前，而這期間網路技術的發展和黑客技術的應用，都上了一個新的臺階，所以針對傳真機的攻擊面研究，就顯得非常必要，而且目前的攻擊目標主要是針對企業和各種組織的。傳真機的傳統連線技術，就是通過電話訪問，以及通過乙太網連線到本地網路。

老實說，我並不知道傳真機的詳細執行原理和過程。雖然讀了很多關於這方面的文件，但我還是對其一知半解。不過，由於我的研究目標並不是實現對硬體的反彙編，因此，我可以通過目前市面上流行的許多軟體專案，實現對傳真機的各種屬性和過程分析，並且可以完全訪問原始碼。

有了清晰的程式碼稽核，再加上使用一些模糊測試工具（模糊測試是一種通過向目標系統提供非預期的輸入並監視異常結果來發現軟體漏洞的方法），就可以開始研究了。

傳真軟體的超低安全性

雖然傳真機仍然可以在世界上任何一個辦公場所找到，但很明顯，如果沒有特殊情況，是沒有人喜歡用傳真來進行交流的。你可以在網上快速搜尋一下，目前在用的許多傳真軟體專案都是很久以前的了，比如，HylaFAX。HylaFAX功能強大，應用靈活，執行穩定，管理方便，即使與商業傳真軟體相比，也毫不遜色。HylaFAX即是一款支援G3標準的傳真軟體。前身是SGI的Sam Leffler在八十年代末期為公司編制的傳真軟體。後來SGI同意Sam將該軟體貢獻出來，放到網上供更多的人免費使用。早期的軟體稱為FlexFAX，後來發現和已有的商標相沖突，才改用現名。再比如eFAX傳真軟體，是基於PSTN（電話交換網）和網際網路絡的傳真儲存轉發，也稱電子傳真。它整合了電話網、智慧網和網際網路技術。原理是通過網際網路將檔案傳送到傳真伺服器上，由伺服器轉換成傳真機接收的通用圖形格式後，再通過PSTN傳送到全球各地的普通傳真機上。還有Sendfax，它是個很早以前的傳真軟體。它允許你通過標準的faxmodem傳送傳真。你可以直接傳送，也可以通過shell指令碼傳送，使用“fax polling”或者建立新的fax佇列。同時，這個軟體還允許你通過電話線接收和撥號傳送。另外還可以使用mgetty+sendfax建立一套功能完整又好用的傳真服務軟體，這一系列網路化的傳真軟體專案將有助於傳真的廣泛使用。

ICTFAX是一款面向服務提供商和企業的免費開源GNU GPLv3多使用者和基於Web的軟體解決方案。 ICTFAX是一個電子郵件到傳真，傳真到電子郵件和Web到傳真閘道器，支援G.711傳真，PSTN傳真和FoIP T.38發起和終止，ICTFAX基於開源Freeswitch，ICTCore和Drupal 7。

IAXmodem作為軟體調變解調器連線IAX-supporting使用者交換機(如Asterisk)和你的傳真物件。

粗略地說，我可以找出傳真軟體的三個通訊層:

資料層：在這個通訊層，調變解調器會開始發出傳真機打的噪聲並在傳真的雙方之間建立資料通道，允許它們交換資料符號；

會話層：協商傳真通訊引數的通訊層，如頁面格式，頁面傳輸速度，影象壓縮等；

影象或頁面層：接受或發出一方的傳真機會對接受或發出的頁面資訊進行編碼或解碼，壓縮或解壓縮，應用、檢查並糾錯，最後生成要傳真或打出的文件。

根據調變解調器(物理或模擬)處理的這些層的數量，我可以識別出不同型別的傳真裝置:

第1類裝置含有調變解調器處理資料層，會讓傳真軟體進行所有的會話和頁面處理；

第2類裝置含有調變解調器處理資料和會話層，會將影象處理留給軟體端；

還有其他類調變解調器可以帶來其他的傳真功能，比如讓傳真速度發生變化，不過本文，我只關注第1類裝置。

因此，含有傳真軟體(如HylaFAX)和傳真調變解調器的裝置，任何人都可以通過命令列傳送和接收傳真資訊。

傳送傳真時，你只需要手動輸入文件資訊(影象或pdf檔案)和對方電話號碼，而傳真軟體將自動負責撥號、編碼和傳輸資料。在對方接收傳真時，程序通常會偵聽通過調變解調器串列埠發出的傳入呼叫，然後接收所有信息並將其放在本地檔案系統或將其傳送給使用者。

攻擊測試設定

有了以上的介紹，現在我可以針對傳真軟體的每一層，發起有針對性的攻擊。為了實現攻擊，我會將幾個傳真元件組合在一起，它們有：

1.2臺90年代的老式傳真機；

2.2個USB傳真調變解調器，

3.Cisco SPA112；

4.Asterisk；

5.IAXmodem；

6.HylaFAX，eFAX和mgetty；

7.GDB；

8.VIM；

9.AFL；

我的設定組合允許我部署一系列不同的攻擊配置，Asterisk將是主要的PBX，將負責路由呼叫，提供一個私人電話網路，可以讓我們的不同元件互相撥號，而不用去公共電話網路(PSTN)。我可以使用Cisco SPA將傳真機和usb調變解調器，通過物理方法，連線到Asterisk網路，而IAXmodem調變解調器模擬將是一個完美的傳真伺服器設定軟體。最後，我利用gdb和vim來閱讀原始碼並逐步完成程式碼彙編。

與此同時，在本次研究的大部分時間裡，我多次使用AFL進行模糊測試，其目的就是試圖濫用我正在研究元件的不同程式碼塊。我所選用的模糊測試工具特別適用於測試程式碼中那些複雜且可疑的程式碼，同時又保證我可以繼續閱讀程式碼。儘管如此，它們在查詢我所需要的崩潰和弱程式碼路徑方面仍是快速而高效的。

攻擊測試結果

經過測試，我發現了很多漏洞，並向軟體維護人員進行了報告，其中一些目前已經發布了修復漏洞。

MGETTY存在多個漏洞，以下是已發現和報告的漏洞詳情:

CVE-2018-16741：通過Mgetty中的程序描述進行shell注入；

CVE-2018-16742：在Mgetty中通過cli引數進行基於堆疊的緩衝區溢位；

CVE-2018-16743：和CVE-2018-16742一樣，都是在Mgetty中通過cli引數進行基於堆疊的緩衝區溢位；

CVE-2018-16744：通過配置引數在Mgetty中基於堆疊的緩衝區溢位；

CVE-2018-16745：通過配置引數在Mgetty中實現緩衝區溢位；

更多資訊，請閱讀ofollow,noindex">https://www.x41-dsec.de/lab/advisories/x41-2018-007-mgetty/

HYLAFAX中的遠端程式碼執行攻擊

在尋找Hylafax中的漏洞時，我仍然使用的是以上所講的方法，不過效率就慢很多了，但最後，我還是找到了一個可以遠端利用的漏洞CVE-2018-17141。

CVE-2018-17141:遠端攻擊者可以在可以在Hylafax的傳真接收會話期間寫入未初始化的指標

在本次研究中，我發現HylaFAX及其解決方案對於傳真通訊來說是一個非常有特色和完整的解決方案。它們給我的感覺是強大而流暢，並且幾乎能在我所測試的任何樣本中順利的進行通訊。它們的大部分原始碼都易於閱讀，這讓我能夠更好的理解這些傳真機的工作原理。不過偶爾也有例外，比如當出現ECM頁面提示的時候。

在大多數傳真機上，你可以在設定選單的高階部分中啟用ECM。一旦啟用，ECM會自動將每個傳真頁面分解為部分頁面，並掃描該頁面以確認資料準確性。如果發現錯誤，則會停止傳輸並提示你重新發送傳真。該功能的性質使ECM不容錯誤，即使是微不足道的錯誤。此靈敏度可能會減慢或妨礙傳真傳輸。如果你使用VoIP電話服務，則可能需要停用ECM以使你的傳輸與VoIP提供的連線型別相容。

在閱讀與頁面資料傳輸相關的程式碼時，我偶然發現了以下這些程式碼:

// from https://github.com/ifax/HylaFAX/blob/09ad7eb6244e6160b42e9646495f0496f80d63fc/faxd/CopyQuality.c%2B%2B#L446
memcpy(recvRow, (const char*) buf, cc);
recvRow += cc;

這是一個典型的緩衝區溢位模式，對吧？很明顯這是一個漏洞，我試圖將其隔離。以下這幾行程式碼屬於FaxModem::recvPageDLEData()，它們的作用就是在啟用JPEG傳輸時處理接收的傳真資訊，這樣在快取整個接收頁面時，就可以避開傳真機設定的“邊界檢查（"Boundary Check"）”。

// from https://github.com/ifax/HylaFAX/blob/09ad7eb6244e6160b42e9646495f0496f80d63fc/faxd/CopyQuality.c%2B%2B#L987
case JP_GREY+4:
case JP_COLOR+4:
recvEOLCount = 0;
recvRow = (u_char*) malloc(1024*1000); // 1M should do it?

找到易受攻擊的程式碼

在進行安全測試時，我希望在向受害者傳送傳真時，能觸發此緩衝區溢位漏洞。不過經過測試，這點很難做到。原因有以下幾點：

1.HylaFAX不正式支援JPEG接收，並且明確禁用此功能，而且在FAX sessiom開始時的握手期間就開始禁用；

2.惡意攻擊者可以選擇不遵守此協議，無論接收方宣佈它的禁用功能是哪些，攻擊者都可以在會話引數中啟用接收JPEG的功能；

3.HylaFAX很樂意把JPEG作為會話傳輸格式，並遵循它實現的那些程式碼路徑來處理JPEG接收的問題；

4.但HylaFAX也會啟用ECM（錯誤糾正模式），遵循完全不同的執行流程，但這不包括呼叫FaxModem::recvPageDLEData()，而是呼叫FaxModem::writeECMData()。

這樣我原本計劃中能輕而易舉地發現的漏洞，看來是很難實現了。但是彆氣餒，看一下在ECM模式下處理JPEG接收的程式碼，它們看起來是這樣的:

// from https://github.com/ifax/HylaFAX/blob/09ad7eb6244e6160b42e9646495f0496f80d63fc/faxd/CopyQuality.c%2B%2B#L1045
memcpy(recvRow, (const char*) buf, cc);
recvRow += cc;

是不是看起來很眼熟，我準備利用它們來實現漏洞。我準備利用我已經準備好的概念證明，啟用JPEG標記，傳送足夠的資料來實施緩衝區溢位，並希望在執行時覆蓋一些易用的heap元資料。在我將概念證明發送給受害者時，對gdb進行了hook，等待奇蹟發生。傳真傳輸開始時，受害者程序崩潰的速度比預期的要快得多，不幸的是，在試圖寫入到記憶體位置0時出現了段錯誤。

這是為什麼呢？可能有些東西並不像我們預期的那樣順利。最後，負責分配recvRow記憶體的開關塊並沒有被執行，使得recvRow未初始化並指向物件構造之前的任何值。

未初始化的指標很有趣，因為它們會在物件構造過程中，以非常明顯的方式獲取一個安全值，但是會在物件例項化時從記憶體中存在的任何無用資訊中獲取它們的值。

總結

本文對傳真軟體的漏洞研究有助於我們更好的理解“傳真安全”，並順便了解其中一些系統的複雜工作原理。使用免費軟體專案是快速瞭解傳真通訊每一層的一個很好的方法，同時也更容易發現有趣和可疑的程式碼片段。傳真系統已存在了數十年，它被設計用來穩定且清晰的通過不可靠和含有很大幹擾的電話線來傳輸影象，並且這一目標幾十年前就實現了。在這以後該領域的創新幾乎就沒有了，而且開發商已將研發重點和努力轉移到了其他領域。

針對傳真軟體攻擊面的研究

HYLAFAX中的遠端程式碼執行攻擊

您可能也會喜歡…