寫在前面的話

在這篇文章中，我們將對閃存進行分析。我的實驗目標是一臺別人“捐贈”過來的Netcomm N300路由器，在進行了深入研究之后，我可以通過修改設備閃存的讀入操作并從未認證的Web接口獲取目標Web服務器的內存數據。

開始分析

[[228668]]

我們的路由器使用的是一塊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：【點我獲取】

總結

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