前言

IDA和Ghidra對mips64架構的識別貌似不是很友好，賽場上由于反編譯實在難看，所以很難靜下心來去逆，于是賽后在期末考試前稍微花點時間做了一下復現。

(資料圖片僅供參考)

準備

checksec一下，發現是mips64 大端，沒開Canary RELRO，可以溢出，可以覆寫got表，這里開了NX和PIE，NX對mips64這種異架構來說好像并不會起作用，如果服務端是用qemu起的，PIE好像也啥作用。

把文件拖進IDA分析，發現我的IDA根本反編譯不了。

拖進ghidra分析，乍看起來貌似并沒有什么問題，仔細看一下會發現少了很多函數。

這可能是由于ghidra基址識別錯誤導致的，于是我們把ghidra的加載地址由0x100000改為0x0，可以得到較為全面的反編譯。

逆向分析

從題目名字mqttsvr大概就能猜到這題基于mqtt協議，不過賽場上不能聯網，不知道mqtt協議的大致格式，純靠逆向就很難受了，復現的時候可以上網查查，感覺還可以。一開始會分配一個堆塊，然后進入一個循環，這個堆塊后來可以知道是存放標志位用的。

函數FUN_000042fc比較長，容易關注到其中的switch，這個操作是對某個字節右移4，也就是取了該字節的高bit位，來作為選擇項。通過以下mqtt Connect報文，可大概推斷這個switch就是判斷報文的不同類型的請求，并且給出相對應的處理。那么漏洞大概率就存在這些請求的處理函數中。

0x10             // 固定報頭：報文類型（Connect）和保留標志位0x0C             // 可變報頭長度0x00 0x04 0x4D 0x51 0x54 0x54 // MQTT協議名稱（長度為4）0x05             // MQTT協議版本號0xCE             // 連接標志0x00 0x3C        // Keep Alive時間（以秒為單位，此處為60秒）// 有效載荷0x00 0x04 0x63 0x6C 0x69 0x65  // 客戶端標識符（Client Identifier）0x00 0x0A 0x2F 0x75 0x73 0x65 0x72 0x73 0x2F 0x31 0x32 0x33 // 遺囑主題（Will Topic）0x00 0x06 0x77 0x69 0x6C 0x6C 0x2F 0x31  // 遺囑消息（Will Message）0x00 0x04 0x75 0x73 0x65 0x72  // 用戶名（Username）0x00 0x06 0x70 0x61 0x73 0x73 0x77 0x6F  // 密碼（Password）

并且我們不難發現除了case 1，其他在進入處理函數前，都會有一個pbVar1[1] == 0的判斷，猜測這里的case 1是一個連接認證的請求。直接進入FUN_00003200看一下，但是發現ghidra識別不出這個函數。

我這里采用的方法是，直接到0x3200+0x4的地方，直接強行創建一個函數，發現可以識別出來。還是有少許函數調用識別不出來，對著匯編看看就行。

FUN_00003200函數大概流程是，獲取客戶端標識符，用戶名和密碼并對其進行檢查。這里的客戶端標識符和用戶名經過簡單逆向可知應該分別為Car_MQTT_Client和Car_Administrator。對于用戶密碼來說，在獲取到密碼之后會經過FUN_000049f0，FUN_00004a68，FUN_00004c84進行處理。進入函數內部看一下，可以得知實現了一個md5加密，同時把加密之后的數據，通過strncmp與"\x64\x1C\x73\x9C\x22\xC8\xF5\xC0\x67\xE1\x1F\xC3\x0B\xEC\x9D\x7A"循環異或0x73進行比較，這里可以發現，第三位會出現\x00截斷，故這里可以通過爆破，得到一個加密后前3字節為\x17\x6f\x00的密碼即可，我這里爆破出一個\x00\xDD\x5E\x85。發送如下報文即可成功連接。

# Connectsleep(0.1)s.send(b"\x10" + b"\x34")VariableHeader = b"\x00\x04MQTT" + b"\x04\xC2" + b"\x43\x21" # \x04 + MQTT + \x04\x02 + \x43\x21VariableHeader+= b"\x00\x0F" + b"Car_MQTT_Client"VariableHeader+= b"\x00\x11" + b"Car_Administrator"VariableHeader+= b"\x00\x04" + b"\x00\xDD\x5E\x85"# Subscribe 1sleep(0.1)s.send(VariableHeader)

接下來分析case 3的函數FUN_000039b0，一開始有一大堆的函數，其中也有memcmp來進行判斷，不過這里不太好看出來是和什么進行的比較，我去調試了一下，可以知道是與IOTcar_topic進行比較，這些數據會用全局變量null_ARRAY_00017360來存放其指針進行保存，同時最后會進入函數FUN_000037d8。

函數FUN_000037d8中也有一些memcmp，并且可以很清楚得之是與什么進行的比較。

可以發現，一個字段是與 IOTcar_topic，另一個是與 car_car進行比較，并且如果 *** (calloc_ptr+ 2) == "\x01"，*(calloc_ptr+ 3) == "\x05"**，那么就可以進入函數 FUN_0000250c，并且上面把 null_ARRAY_00017360 + local_30 * 0x20 + 0x13（存放字段car_car的堆地址）拷貝到 acStack_48上。后期經過調試得知 FUN_0000250c本意可能是用來泄露出一個堆地址，不過由于我這里是 qemu啟動的原因，堆地址都是 0x4000018000，會出現 00截斷的問題，不知道遠程是不是用其他方式啟動的，還是我的啟動方式的原因。不過這里的 (calloc_ptr+ 2) == "\x01"，(calloc_ptr+ 3) == "\x05"還并不滿足，我們需要對其他函數進一步分析。

case 5，6的處理函數比較簡單，同時并沒有起到什么作用，故分析略過。

case 8的函數 FUN_00003dfc中，可以很明顯看出有一個堆溢出漏洞，它在申請堆塊時，malloc_size=(size&0xff)，并且如果其中的一個字段等于 IOTcar_topic，就會把 *(calloc_ptr+ 2)的值設置為 1，這是泄露堆地址的條件之一。

case 10的功能是吧 case 8申請的堆塊釋放掉，并且把 (calloc_ptr+ 2)的值設置為 0。case 12*的功能是使得 *(calloc_ptr+ 3) = *(calloc_ptr+ 3)+1，通過發五次這個請求包可以滿足 *(calloc_ptr+ 3) == "\x05"。

漏洞分析

這題的漏洞有如下幾個。第一個是在連接時，用戶密碼由于md5之后存在\x00截斷的問題，故可以爆破出一個滿足條件的密碼。第二個是訂閱IOTcar_topic主題，并且發送5次\xC0開頭的請求，再發送特定的消息即可泄露堆地址。第三個是存在一個堆溢出。

漏洞利用

泄露出堆地址之后，就可以得到程序基地址。可以劫持got表，并且NX沒有效果，那么我們就可以把malloc等函數的got表改為某一個堆地址，并且在這個堆地址上寫入shellcode即可。uclibc mips64的堆利用我參考https://eqqie.cn/index.php/search/mips64 ，發現有三個不同的malloc版本。但我并不知道怎么判斷當前 uclibc是哪一個版本，我就用 malloc-standard這個版本的利用方法試了一下，直接覆蓋一個杯釋放堆塊的 fd，發現二次分配，可以申請到預期位置（malloc_got - 0x20）。

覆蓋成shellcode地址之后，我們即可執行提前布置好的shellcode，從下圖可見我們成功跳轉到我們提前布置的shellcode上，不過雖然最后我可以走到execve("/bin/sh", NULL, NULL)，但是似乎系統調用并沒起作用。有知道原因的師傅可以聯系我一下，我再改一下這里。

Poc

https://github.com/fxc233/CTF/blob/main/IOT/2023XCTFcar-mqttsvr/exp.py