有趣的快閃記憶體：通過實踐分析意外內存泄漏

寫在前面的話

在這篇文章中，我們將對快閃記憶體進行分析。我的實驗目標是一台別人「捐贈」過來的Netcomm N300路由器，在進行了深入研究之後，我可以通過修改設備快閃記憶體的讀入操作並從未認證的Web介面獲取目標Web伺服器的內存數據。

開始分析

我們的路由器使用的是一塊Macronix MX15L12835FMI快閃記憶體晶元（16針腳SOP）：

首先，我需要觀察晶元的常規操作。在研究過程中，我發現它的快閃記憶體並沒有得到充分使用，只有設備在啟動（或載入整個操作系統）時或在使用Web管理面板時會使用到快閃記憶體。快閃記憶體晶元似乎使用的是Single API模式，其常規讀取命令如下所示：

命令開頭為一個05 FF命令，根據數據表提供的信息，這條命令可以讀取出寄存器的狀態信息。我最初的目的是對快閃記憶體讀取命令進行篡改，並用它來從硬碟中讀取數據。

考慮到SPI命令是與時鐘信號同步的，那我的攻擊同樣可以跟同一個時鐘信號同步：我可以記錄下時鐘上升沿信號的數量，並在特定數量的時鐘信號下將快閃記憶體晶元的15號針腳接地，然後修改快閃記憶體的讀取命令並用它來讀取其他信息。放大時鐘信號後我們可以看到，數據只會在時鐘信號的下降沿發生變化，所以我們的攻擊應該是有效的。

首先我們進入到設備的串列控制台中，然後使用命令cat /dev/mtdblock0來觸發快閃記憶體的讀取命令。該命令的原始狀態如下所示：

為了方便進行對比，所以我運行了cat /dev/mtdblock2：

接下來，我連接了一個晶體管和一個FPGA，FPGA可以讀取時鐘信號並控制晶體管的開關，接地針腳15暫時等待幾個時鐘周期，並讓其中的一個讀取指令地址失效：

我還專門編寫了一個腳本來讓程序等待一定的時鐘周期，並修改快閃記憶體的讀取操作，然後運行cat /dev/mtdblock2並通過示波器來監控快閃記憶體的命令執行情況：

如果你仔細看的話，你就會發現右邊是原始快閃記憶體讀取操作的殘餘部分（原始命令/dev/mtdblock2為03 01 00 00），我們可以通過運行cat /dev/mtdblock2命令來驗證我們的發現：

需要注意的是，命令確實成功執行了，/dev/mtdblock2的第一個數據塊跟之前/dev/mtdblock0的一樣，表示我們的操作已經成功了。

現在，我們就可以用這種方法來對Web伺服器介面進行攻擊了，如果我可以讓硬碟中的某個資源載入失敗，理論上來說我就可以讓它來讀取任何我想要讀取的內容了，比如說通過Web請求來獲取到固件文件等等。

但是，我很快就遇到了如下所示的問題：

雖然我可以從物理快閃記憶體中讀取任意區塊，但我無法保證數據可以正確解壓。雖然Web伺服器似乎還可以正常工作，但是其中的一個圖片已經無法正確載入了。用Burp進行分析後，我很快就找到了「罪魁禍首」：

這是一個針對/wireless_1.gif的有效請求的一條響應數據，我知道這是一個無效的GIF文件，但我並不知道它到底是什麼，我猜測它要麼來自於Web伺服器的內存，或者是磁碟中的數據塊。

為了進行測試，我對整個Web應用程序進行了分析，然後發送了一條新的/wireless_1.gif請求：

神奇的是，這個gif文件竟然自己發生了變化，而且我也沒觀察到其他的SPI流量生成，這表示我成功實現了內存泄漏（很可能是一個內存用後釋放漏洞），只不過唯一的遺憾是它並非目標系統的密碼文件。

攻擊代碼

PoC：【點擊底部閱讀原文獲取】

總結

雖然這項攻擊技術對物聯網設備來說可能沒那麼有效，但是它的影響還是顯而易見的，因為我們可以在不需要系統級訪問控制許可權的情況下，就能夠隨意載入出快閃記憶體中存儲的數據了。

* 參考來源：

，FB小編Alpha_h4ck編譯，轉載請註明來自FreeBuf.COM

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！