取证分析挑战 6：分析恶意编码 PDF 档案 - (由来自马来西亚分支的Mahmud Ab Rahman和Ahmad Azizan Idris提供) 利用含恶意编码 PDF档案进行的典型攻击。

请在2010年11月30日星期二之前在 https://www.honeynet.org/challenge2010/ 透过我们的表格 (请使用 [MS word解答范本](/files/[your%20email]_Forensic%20Challenge%202010%20-%20Challenge%206%20-%20Submission%20Template - Simplified Chinese.doc) 或 [Open Office解答范本](/files/[your%20email]_Forensic%20Challenge%202010%20-%20Challenge%206%20-%20Submission%20Template - Simplified Chinese.odt)) 提交您的挑战解答。结果约在12月的第三个星期公布。)

难度等级：中级

欢迎透过下列链接访问:英文版内容

挑战内容：

PDF 格式是在线文件交换的业界标准 (de facto standard)。由于它的普及性，因此亦吸引了罪犯利用它来向信任的使用者传播恶意程序。在很多攻击工具中已经包含了建立恶意编码 PDF档案的功能来散播恶意程序。如果使用者对开启 PDF 档案缺乏警觉性，恶意编码 PDF档案会是一个颇成功的攻击手段。

在网络封包记录 lala.pcap 内藏有关于一个典型的恶意编码 PDF档案。这个封包记录了一个使用者开启了一个已被入侵的网页，然后被重新转向去下载一个恶意编码 PDF档案。当浏览器内的PDF插件开启PDF时，没有安装修补程序的Adobe Acrobat Reader会被攻击，结果在使用者的计算机上无声无色地下载并安装恶意程序。

1. 在这次事故中包含了多少个 URL 路径？请列出找到的URL 路径。(1分)
2. 在PCAP档案内，你能找到什么程序代码？请解释这些程序代码做了什么。 (2分)
3. 在PCAP档案内，你能找到什么档案吗？若找到任何档案，请利用zip密码保护(密码：infected)的压缩档案方式，将档案命名为：[your email]_Forensic Challenge 2010 – Challenge 6 – Extracted Files.zip并提交到https://www.honeynet.org/challenge2010/。
4. 在PDF档案内包含多少个对象？(1分)
5. 请利用PDF 字典及对象参考详细解释PDF档案的流程结构。(1分)
6. 有多少个过滤机制应用在对象串流，它们是什么？请解释你如何将串流解压。
7. 哪个对象串流可能藏有恶意编码内容？请列出该对象及解释所使用的隐匿技术 (obfuscation technique(s))。(3分)
8. 在PDF档案内包含了什么攻击？哪一个攻击能成功执行并触发漏洞？请在答案上提供一些相应的解释。 (4分)
9. 在PDF档案内包含了什么负载 (payloads)？如果有，请列出及解释它们做了什么，那些负载(payload)会被执行？(2分)
10. 对于PDF 格式结构的理解，请解释在开启 PDF 档案时，我们能如何启动其它攻击 (2分)

奖励分：

鑑識分析挑戰 6：分析惡意編碼 PDF 檔案 - (由來自馬來西亞團隊的Mahmud Ab Rahman和Ahmad Azizan Idris提供) 利用含惡意編碼 PDF檔案進行的典型攻擊。

請在2010年11月30日星期二之前在 https://www.honeynet.org/challenge2010/ 透過我們的表格 (請使用 [MS word解答範本](/files/[your%20email]_Forensic%20Challenge%202010%20-%20Challenge%206%20-%20Submission%20Template - Traditional Chinese.doc) 或 [Open Office解答範本](/files/[your%20email]_Forensic%20Challenge%202010%20-%20Challenge%206%20-%20Submission%20Template - Traditional Chinese.odt)) 提交您的挑戰解答。結果約在12月的第三個星期公佈。)

難度等級：中級

歡迎透過下列鏈結訪問:英文版內容

挑戰內容：

PDF 格式是在線文件交換的業界標準 (de facto standard)。由於它的普及性，因此亦吸引了罪犯利用它來向信任的使用者傳播惡意程式。在很多攻擊工具中已經包含了建立惡意編碼 PDF檔案的功能來散播惡意程式。如果使用者對開啟 PDF 檔案缺乏警覺性，惡意編碼 PDF檔案會是一個頗成功的攻擊手段。

在網路封包記錄 lala.pcap 內藏有關於一個典型的惡意編碼 PDF檔案。這個封包記錄了一個使用者開啟了一個已被入侵的網頁，然後被重新轉向去下載一個惡意編碼 PDF檔案。當瀏覽器內的PDF插件開啟PDF時，沒有安裝修補程式的Adobe Acrobat Reader會被攻擊，結果在使用者的電腦上無聲無色地下載並安裝惡意程式。

1. 在這次事故中包含了多少個 URL 路徑？請列出找到的URL 路徑。(1分)
2. 在PCAP檔案內，你能找到什麼程式碼？請解釋這些程式碼做了什麼。 (2分)
3. 在PCAP檔案內，你能找到什麼檔案嗎？若找到任何檔案，請利用zip密碼保護(密碼：infected)的壓縮檔案方式，將檔案命名為：[your email]_Forensic Challenge 2010 – Challenge 6 – Extracted Files.zip並提交到https://www.honeynet.org/challenge2010/。
4. 在PDF檔案內包含多少個物件？(1分)
5. 請利用PDF 字典及物件參考詳細解釋PDF檔案的流程結構。(1分)
6. 有多少個過濾機制應用在物件串流，它們是什麼？請解釋你如何將串流解壓。
7. 哪個物件串流可能藏有惡意編碼內容？請列出該物件及解釋所使用的隱匿技術 (obfuscation technique(s))。(3分)
8. 在PDF檔案內包含了什麼攻擊？哪一個攻擊能成功執行並觸發漏洞？請在答案上提供一些相應的解釋。 (4分)
9. 在PDF檔案內包含了什麼負載 (payloads)？如果有，請列出及解釋它們做了什麼，那些負載(payload)會被執行？(2分)
10. 對於PDF 格式結構的理解，請解釋在開啟 PDF 檔案時，我們能如何啟動其他攻擊 (2分)

獎勵分：

Before we are getting worse than Duke Nukem Forever, we decided to finally release the next generation of the web application honeypot Glastopf, aka GlastopfNG!

Today we find web applications in every environment independent of company size and even in home networks. Over web attack vectors like SQL Injections and Remote File Inclusions, criminals can overtake web servers which than become part of a botnet or even a command and control server. Web servers are specially interesting for such tasks as they normally have bigger bandwidth than client computers and mostly an uptime of nearly 24 hours, seven days a week. This makes a hacked web server a dangerous weapon in the hands of a criminal.

The first one writing about this new threat was Marco Giuliani. So, Murofet or Zeus++?

Taking a look at a couple of samples we were able to identify:

• Same API hooks
• Same encryption routine for configuration file (RC4)
• Pretty much the same configuration file format

Here you can take a look at a decrypted configuration file. It’s possible to realize that it makes use of the same block-based structure of Zeus configuration files. Just like any other Zeus it has a block with id 0x214e (at offset 0x1c) where the version of the builder used to create the bot is stored (at offset 0x2c). In our case that is 2.1.0.7.

I’m interested in infostealers and specifically in banking-trojans so I didn’t want to miss this one. Samples of Carberp are floating around at least since last spring but in late September we saw such numbers increasing.

Taking a look at how Carberp hooks API it looks like yet another Zeus “clone”. What I found interesting is how it hooks system calls. This is how a normal syscall looks like
MOV EAX,0xce // ZwResumeThread syscall id MOV EDX,0x7FFE0300 // pointer to KiFastSystemCall CALL DWORD PTR DS:[EDX] RETN 0x8
And this is how the hooked syscall looks like
MOV EAX,0xce MOV EDX,0x00152958 // pointer to fake KiFastSystemCall CALL DWORD PTR DS:[EDX] RETN 0x8
Instead of overwriting the first instruction(s) with a JMP/CALL to redirect the execution flow to the hook, Carberp substitutes the pointer to KiFastSystemCall. This is nothing new but it is actually enough to hide such hook from most of the “anti-rootkit” products out there (including rkunhooker).

The deadline for the Forensic Challenge 2010/5 - Log Mysteries is quickly approaching. It seems like this challenge is a hard nut to crack as we only received a few submissions so far. If you like a challenge, give it a try. The deadline is September 30th 2010. You can access the challenge at https://honeynet.org/challenges/2010_5_log_mysteries. Did I mention there are prizes?

- “it bypasses DEP and ASLR using impressive tricks and unusual methods” - Vupen

- “it uses a previously unpublished technique to bypass ASLR” - Metasploit Blog

- “exploit uses the ROP technique to bypass the ASLR and DEP” - ZDnet/Kasperky

- “it’s so scary I ran away screaming” - anonymous

Is that PDF so scary? I don’t think so.

DEP is an hardware feature that prevents execution of data, it obviously works if software sets the execution flag only on memory pages containing code.

I’ll tell you the truth: Export Address Table Filtering, the feature of the upcoming release of EMET, “designed to break nearly all shell code in use today”, intrigued me a bit.

Since I wasn’t able to find docs about the actual implementation, I started to think about how that could be done and I wrote a simple POC that uses VirtualProtect to flag the relevant pages of the .data section of ntdll and kernel32 with PAGE_GUARD to intercept read operations over the PEB.Ldr. A Vectored Exception Handler is then used to handle the exception and to check if the faulting address is within the code section of a module(MEMORY_BASIC_INFORMATION.Type == MEM_IMAGE). Here is the pseudo-code:

A new improvement in PHoneyC DOM emulation code was committed in SVN r1624. The idea is to better emulate the DOM behaviour depending on the selected browser personality. Let’s take a look at the code starting from the personalities definition in config.py.

39 UserAgents = [ 40 (1, 41 "Internet Explorer 6.0 (Windows 2000)", 42 "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)", 43 "Mozilla", 44 "Microsoft Internet Explorer", 45 "4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)", 46 "ie60", 47 ), 48 (2, 49 "Internet Explorer 6.1 (Windows XP)", 50 "Mozilla/4.0 (compatible; MSIE 6.1; Windows XP; .NET CLR 1.1.4322; .NET CLR 2.0.50727)", 51 "Mozilla", 52 "Microsoft Internet Explorer", 53 "4.0 (compatible; MSIE 6.1; Windows XP; .NET CLR 1.1.4322; .NET CLR 2.0.50727)", 54 "ie61", 55 ), 56 (3, 57 "Internet Explorer 7.0 (Windows XP)", 58 "Mozilla/4.0 (Windows; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)", 59 "Mozilla", 60 "Microsoft Internet Explorer", 61 "4.0 (Windows; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)", 62 "ie70", 63 ), 64 (4, 65 "Internet Explorer 8.0 (Windows XP)", 66 "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; (R1 1.5); .NET CLR 1.1.4322; .NET CLR 2.0.50727)", 67 "Mozilla", 68 "Microsoft Internet Explorer", 69 "4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; (R1 1.5); .NET CLR 1.1.4322; .NET CLR 2.0.50727)", 70 "ie80", 71 ), 72 ]

The Discoverer module (see zhongjie’s blog entry) has been completed.
It consists of 2 programs, the Format Discovery and Pre-Replay processing.
Format Discovery is pretty much what i’ve blogged about in my earlier post.
Since that entry, I’ve completed the to-do tasks:

1. have a function to summarise all output for this program.

2. solve a memory leak problem in this program.

3. match replay packet to format, and if length segment changes (eg: due to shellcode change), then length field needs to change.