寫在前面的話

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

開始分析

[[228668]]

我們的路由器使用的是一塊Macronix MX15L12835FMI閃存芯片（16針腳SOP）：

首先，我需要觀察芯片的常規(guī)操作。在研究過程中，我發(fā)現(xiàn)它的閃存并沒有得到充分使用，只有設(shè)備在啟動（或加載整個操作系統(tǒng)）時或在使用Web管理面板時會使用到閃存。閃存芯片似乎使用的是Single API模式，其常規(guī)讀取命令如下所示：

命令開頭為一個05 FF命令，根據(jù)數(shù)據(jù)表提供的信息，這條命令可以讀取出寄存器的狀態(tài)信息。我最初的目的是對閃存讀取命令進行篡改，并用它來從硬盤中讀取數(shù)據(jù)。

考慮到SPI命令是與時鐘信號同步的，那我的攻擊同樣可以跟同一個時鐘信號同步：我可以記錄下時鐘上升沿信號的數(shù)量，并在特定數(shù)量的時鐘信號下將閃存芯片的15號針腳接地，然后修改閃存的讀取命令并用它來讀取其他信息。放大時鐘信號后我們可以看到，數(shù)據(jù)只會在時鐘信號的下降沿發(fā)生變化，所以我們的攻擊應(yīng)該是有效的。

首先我們進入到設(shè)備的串行控制臺中，然后使用命令cat /dev/mtdblock0來觸發(fā)閃存的讀取命令。該命令的原始狀態(tài)如下所示：

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

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

我還專門編寫了一個腳本來讓程序等待一定的時鐘周期，并修改閃存的讀取操作，然后運行cat /dev/mtdblock2并通過示波器來監(jiān)控閃存的命令執(zhí)行情況：

如果你仔細(xì)看的話，你就會發(fā)現(xiàn)右邊是原始閃存讀取操作的殘余部分（原始命令/dev/mtdblock2為03 01 00 00），我們可以通過運行cat /dev/mtdblock2命令來驗證我們的發(fā)現(xiàn)：

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

現(xiàn)在，我們就可以用這種方法來對Web服務(wù)器接口進行攻擊了，如果我可以讓硬盤中的某個資源加載失敗，理論上來說我就可以讓它來讀取任何我想要讀取的內(nèi)容了，比如說通過Web請求來獲取到固件文件等等。

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

雖然我可以從物理閃存中讀取任意區(qū)塊，但我無法保證數(shù)據(jù)可以正確解壓。雖然Web服務(wù)器似乎還可以正常工作，但是其中的一個圖片已經(jīng)無法正確加載了。用Burp進行分析后，我很快就找到了“罪魁禍?zhǔn)?rdquo;：

這是一個針對/wireless_1.gif的有效請求的一條響應(yīng)數(shù)據(jù)，我知道這是一個無效的GIF文件，但我并不知道它到底是什么，我猜測它要么來自于Web服務(wù)器的內(nèi)存，或者是磁盤中的數(shù)據(jù)塊。

為了進行測試，我對整個Web應(yīng)用程序進行了分析，然后發(fā)送了一條新的/wireless_1.gif請求：

神奇的是，這個gif文件竟然自己發(fā)生了變化，而且我也沒觀察到其他的SPI流量生成，這表示我成功實現(xiàn)了內(nèi)存泄漏（很可能是一個內(nèi)存用后釋放漏洞），只不過唯一的遺憾是它并非目標(biāo)系統(tǒng)的密碼文件。

攻擊代碼

PoC：【點我獲取】

總結(jié)

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