員外 Security

BASH ShellShock 漏洞分析

2014-10-02T14:53:00.001+08:00

這回的 bash 漏洞很有趣，定義一個 script 函式竟然能夠被自動觸發執行。CVE-2014-6271 漏洞揭露後，經過數日，許多人不斷地在找尋可利用此漏洞的方法，試圖可以進行遠端入侵或本地提權等，也有不少人瘋狂找尋 bash 或其它 shell 的類似問題，當然各資安相關媒體或廠商也不斷 "提醒" 大家要盡快升級 bash，彷彿有了 bash 就會被入侵一般。

目前 shellshock wiki 描述及收集了詳細的資訊，這篇 BASH 代碼注入的安全漏洞也針對漏洞作了詳細說明，以及 DevCore 的 Shaolin 寫的這篇。所以我打算針對漏洞成因，以及漏洞利用環境作探討。

漏洞原因

在 bash 的原始碼 variables.c 中可以看到 bash 在初始化環境變數時，會掃瞄環境變數中是否有函式定義，其函式定義的 keywords 為 "() {"，見第 11 行。若有函式定義的字串，應該僅轉換為函式內容，不應該執行該函式，見第 21 行。

Patch 的方式可見 patch ，主要是導入兩個參數定義

+ #define SEVAL_FUNCDEF 0x080  /* only allow function definitions */
+ #define SEVAL_ONECMD 0x100  /* only allow a single command */

然後在原來呼叫 parse_and_execute() 的地方改用
parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);

並且在 parse_and_execute() 裡再去檢查是否有 SEVAL_FUNCDEF|SEVAL_ONECMD。

遠端執行指令碼

想要利用這個 bash 漏洞，就要非常了解 Linux 的環境變數繼承關係。事實上，在 Unix 系統中以環境變數來傳遞參數或資料是很平常的事，因為環境變數是 key=value 格式，又具有行程間繼承的作用。

因此，要找到可利用的情況，首先要找尋一個網路服務程式，此程式會將網路上接收的資料或請求(Request)轉換為環境變數，若是網路服務程式再透過 execle()/execvpe()/execve() 或是 system()/popen() 來執行其它程式時，因為上述函式會繼承環境變數的關係，才有成功利用的機會。

以 httpd 為例，其實 httpd 並不會接收遠端傳來的環境變數，而是 httpd 在 mod_rewrite 模組執行時將 HTTP Request 中的欄位轉換填入對應的環境變數中，再經由 mod_cgi 模組執行 CGI 程式。所以 CGI 程式可以透過環境變數的方式取得 HTTP Request 所需要的內容。
例如，將 HTTP Request 中的 User-Agent 欄位的內容，轉換為環境變數為 HTTP_USER_AGENT 的內容，以便任何語言開發的 CGI 程式可以透過環境變數 HTTP_USER_AGENT 取得 User-Agent 欄位內容。

C 語言 CGI 範例

在此 C 語言的範例中，即便 system() 中執行的命令是固定，不可被 Command Injection，但透過 CVE-2014-6271，則可以執行任意命令，因為 system() 是透過 /bin/sh -c 來執行 /bin/hostname。

事實上，不只 C 語言開發的 CGI，任何語言開發的 CGI 程式透過 httpd mod_cgi 執行，都可能會被利用此漏洞。不過若是直接用 bash script 開發的 CGI 程式，則不需要再透過呼叫 system()，直接就可以利用此漏洞。

bash script 語言 CGI 範例

經過測試 mod_cgi 搭配各語言，發現 perl 和 ruby 在某些情況下無法利用此漏洞。原因是，
perl 和 ruby 在進行 system()/popen() 之類的呼叫時，會先經過最佳化，判斷是否只是執行外部程式而非真的 script 命令，只有是 script 命令才會透過 /bin/sh -c 來執行，否則會直接執行(execve)該外部程式。
例如 perl 語言中:

system ("/bin/env > /dev/null");
system("/bin/uname -a");

第一行的命令字串中因為有 > 重新導向輸出的符號，因此會透過 /bin/sh -c 來執行該命令，但是第二行的命令字串中，僅是直接執行 /bin/uname，因此並不會透過 /bin/sh -c 來執行該命令，也就不會造成漏洞利用。

下列是我在 CentOS 6.4 + Apache 2.2.15 測試了各語言版本 CGI 程式，搭配不同的環境，所測試的結果:

V: 可直接利用或透過 system()/popen() 利用
O: 在未最佳化執行的 system()/popen() 情況下可利用
X: 不可被利用

我建議 Linux 伺服器管理者優先將 Linux 伺服器作 bash 升級，並且將網站環境作分析，評估不再使用 mod_cgi 或 mod_fastcgi。另外也請將 Linux 作安全性強化，可參考 Kenduest Lee (小州)的 Security Enhanced Linux。

另外一個例子是透過 DHCP 發送含執行代碼的封包，讓 Linux 的 dhclient 被利用此漏洞來入侵。從 Internet Systems Consortium DHCP Distribution Version 4.2.4 的原始碼來看，的確是 dhclient.c 會從 DHCP 封包中將參數值透過內建的 client_envadd() 轉換成環境變數，再經由 execve() 執行了 dhclient-script (bash script)，所以當然也就中獎了。

下列兩道指令可用來檢測系統上的 dhclient 是否會被此漏洞影響，當然 patch bash 才是王道。

$ /sbin/dhclient - 2>&1 | grep "ISC"
This version of ISC DHCP is based on the release available

$ which dhclient-script

/sbin/dhclient-script

另一個漏洞 CVE-2014-7169

env X='() { (a)=>\' sh -c "echo date"; cat echo

這行環境變數的設定，會使得原來應該是 echo date，顯示 "date" 字串，變成執行 "date" 指令。從 bash 原始碼中可發現，在 shell_getc (y.tab.c) 讀取輸入字串遇到錯誤時會呼叫 reset_parser() (y.tab.c)，然而控制字元讀取位置的 global 變數 int eol_ungetc_lookahead 卻沒有重置歸 0，修補方式請看 patch。

所以 () { (a)=>\ 是用 = 字元故意製造錯誤，字元讀取位置因為沒被重設，還留在 > 字元，因此在讀取 "echo date" 後原本要執行 "echo" 變成了讀取 ">echo date"，執行後結果變成執行 "date" 命令，將結果輸出至 "echo" 檔案中。

這個漏洞要利用的條件限制更多，而且不像 CVE-2014-6271 可以指定任何命令執行，而只能讓原本要執行的命令作改變，有點類似當年 Unix IFS 的問題。

結論

目前此漏洞仍然在發酵中，有些人找尋了特定 CGI 網站程式進行攻擊，也有人試圖找尋其它的相關漏洞，也許這漏洞真的有機會得到今年的 Pwnie Award 呢。

[References]
1. https://access.redhat.com/articles/1200223
2. https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/
3. http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052
4. http://www.cnblogs.com/LittleHann/p/3992778.html
5. http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-shellshock.pdf
6. http://jaxbot.me/articles/cases-where-bash-shellshock-is-safe-09-25-2014
7. http://security.stackexchange.com/questions/68448/where-is-bash-shellshock-vulnerability-in-source-code

十年

2014-06-08T22:23:00.001+08:00

近日陰雨綿綿，潮溼略帶悶熱，轉進人潮擁擠的捷運站內，赫然見到一位身穿黑色T恤的男孩從身邊匆匆走過，看著衣服上的小灰帽，思緒不禁帶到那個充滿熱情的夏天。

一個年輕小夥子，站在坐滿百人的教室內，正在淊淊不絕地講述如何透過駭客技巧，免費觀賞熱情視訊(WebCam Girls)，這一場壓軸讓全場充滿歡笑，代表第一次舉辦台灣駭客年會的成功，也開啟了台灣駭客們的夢。

2004 年六月，CHROOT 資安社群成立，匯集了當時台灣地下駭客組織成員、資深的資安專家和白帽駭客，並且決定參考美國拉斯維加斯的駭客年會(DEFCON) 在台灣舉辦一場屬於自己的駭客年會，定名為 Hacks In Taiwan (HIT)，這個名稱的由來其中一個原因係紀念已解散的著名駭客組織(Hackers In Taiwan)，另一方面強調對於駭客技術的熱情不只在資安領域，而是汎指各項技術上的 Hacking。中文名稱取作「台灣駭客年會」更是挑戰當時對於「駭客」名詞的負面看法，希望對「駭客」一詞有正面概念的傳達。

對於一群只熟悉網路技術的宅男們來說，辦一個研討會是大夥從沒有過的挑戰，不知道要探討什麼主題；不知道有沒有講師，不知道要有預算概念；不知道會議流程如何進行；不知道有沒有贊助商；不知道會有多少人報名參加。因此，CHROOT 決定花一年的時間準備，每個月固定聚會討論會議主題，分享研究成果，訓練演講技巧，觀摩其它研討會，找尋各方資源，選定在七月中旬於文化大學大新館舉辦，希望帶給參加者一個不同於商業性質，充滿駭客技術分享，充滿熱情有趣，具有表現自我機會的研討會，這些後來也成為每一屆的重要精神。

還記得，我們定了一個當時不算低的票價，而且還得先匯款才能完成報名，網站只有少數資訊且還放了一頁奇怪文字訊息，官方郵件服務還不穩定，偶爾會有退信情況發生。有趣的是，當時我向文化大學訂場地時，擔心用「駭客年會」名義會被校方拒絕，所以我用「資安社群研討會」，導致許多報名者想向文化大學求證時，都被回覆「文化大學並無駭客年會相關活動舉辦」。

第二屆舉辦時，我們就發現文化大學數位演講廳的兩百個位子已不夠，因此第三至第五屆移到台灣科技大學國際演講廳，同時，在更多的贊助商及各路先進協助下，參與人數近四百人，成長兩倍有餘。到了 2010 年，終於有了能滿足空間、設備及費用的場地 - 中研院人文社會科學館，直到 2013 年，HITCON 現場參與人數突破 850 人，報名開放僅三分鐘內門票即售磬，創記錄的讓 30 位國內外資安專家發表演講，這還真是台灣少見的大規模資訊技術研討會。

要舉辦大型的研討會，其實都靠優秀的工作人員齊心合力完成。前幾屆都是由 CHROOT 成員的女友、老婆或兄弟姊妹們，充當工作人員，他們的辛勞付出與經驗傳承，也讓 HITCON 在往後招募志工上，更為容易。不管是親朋好友找來幫忙，或是自願加入協助活動舉辦，都是每年 HITCON 能成功的背後重要因素，值得我們心存感激。

說實在的，一年舉辦一次研討會，其實已經讓 HITCON 籌辦團隊忙到焦頭爛耳，但又時時覺得希望多一點活動，讓台灣更多人重視資安，提起學生們對 Security 的興趣，進而發揮更大的影響力。為了讓重大資安事件被各界重視，我們開始辦 HITCON Freetalk，以小規模活動方式邀請各政府單位及企業參與，第一時間將完整訊息揭露，協助加速應變及處理，例如去年三月韓國發生的嚴重資安攻擊，今年 OpenSSL HeartBleed 嚴重漏洞。此外，這幾年我們見到每年在 HITCON 舉行的 Wargame 競賽逐漸受到重視，除了政府舉辦的資安金盾獎，今年四月初賽門鐵克第一次在台灣舉辦駭客攻防競賽，五月初，HITCON Wargame 組長 Alan，組團帶領台大 217 學生團隊，前往南京參加百度 BCTF 競賽獲取冠軍，憑著這股勢氣和不放棄的精神，在上週末的 DEFCON CTF 資格賽搶下寶貴名額，準備在八月以 HITCON CTF 團隊名義，代表台灣出賽，和全球頂尖駭客爭奪世界冠軍。

透過 HITCON ，我們逐漸實現多年前的夢想，確切來說，我們透過 HITCON 的力量協助台灣年輕的駭客們逐夢，也是實現我們的夢，而他們對 HITCON 的熱情和支持，也是我們在舉辦 HITCON 精疲力精後的一股強心針。

“I like the dreams of the future better than the history of the past.”

― Thomas Jefferson

接下來，HITCON 籌辦團隊試著把 HITCON 帶向永續發展及培養更多資安人才的方向努力，我也期望 HITCON 的未來十年，能創造及完成更多的夢想。堅持、努力以及不放棄的挑戰，也是駭客心中的信念，不是嗎?

穿著小灰帽衣的男孩仍在捷運上滑著手機，聽著關門的催促聲，我踏出車箱，回頭望著駛離的捷運列車，視線逐漸模糊。

By Tim 2014.5

Defcon 21 競賽解題思路 - linked

2013-06-18T01:02:00.000+08:00

題目給了一個 C 的 struct
typedef struct _llist {
struct _llist *next;
uint32_t tag;
char data[100];
} llist;

並且給了一小段 C 的程式碼

register char *answer;
char *(*func)();
llist *head;
...
func = (char *(*)(llist *))userBuf;
answer = (char *)(*func)(head);
send_string(answer);
exit(0);

此關卡程式會亂數配置若干 linked-list。要解開此關，則要送一段 shellcode 給 Server 執行，即 answer = (char *)(*func)(head); 這行呼叫。

Write me shellcode that traverses the randomly generated linked list, looking for a node with a tag 0x41414100, and returns a pointer to the data associated with that tag, such that the call to send_string will output the answer.

看來只要寫個 shellcode，走訪每個 linked-list，檢查 tag 是否為 0x41414100，若是則將此 linked-list 的位址傳回，應該就能讓 Server 吐出答案。
用 C 來表示大概像這樣:

char *shellcode(llist *head)
{
while(1) {
if (head->tag == 0x41414100)
return head->data;
head = head->next;
}
}

看來很簡單吧！
不過實際轉換成 shellcode 送出才發現，Server 回應 shellcode 只吃 16 bytes，也就是 shellcode 長度不能超過 16 bytes。這個長度限制馬上讓這題變成一個難解之題，不管怎麼縮小，改變 asm 指令等，都相當有難度。
此時，就想到如果不照題目所給的流程走，讓 shellcode 直接吐出走訪 linked-list 的所有資料，那 shellcode 能否控制在 16 bytes 之內呢?

用 C 來表示大概像這樣:

char *shellcode(llist *head)
{
dump:
write(4, head, 100);
head = head->next;
goto dump:
}

若是照正常的系統呼叫設定各暫存器，那鐵定超出長度，因此有些暫存器要故意忽略不設，例如呼叫 write() 的長度，C 這邊我寫 100，實際上完全不確定會 write 多少字元。

最後寫出的 shellcode 長得這樣:

沒幾行，分別解說如下:

7. pop edi
8. pop ecx

此兩行主要是因為 (char *)(*func)(head); ，也就是 call 之前會將參數 head 先放入堆疊(Stack) 再執行 call 時 x86 又會將返回位址放到堆疊，因此 pop edi 則會將返回位址取到 edi，而 pop ecx 則會將 head 存至 ecx。此時 ecx = head

10. mov ecx,[ecx]

此行則為 head = head->next，會放在一開始則完全是 shellcode 長度限制考量。

11. xor eax,eax
12. add eax,4

設定 eax = 4，因為 write 系統呼叫編號為 4。

14. push eax
15. pop ebx

恰好打算要輸出的 socket = 4，所以透過 push/pop 把 eax 複製到 ebx，一樣是長度限制考量。

16. ;mov edx,100
17. int 0x80
18. jmp _run

本來想設定 edx，代表要輸出的長度，不過受到長度限制考量，就完全不理長度，看當時執行此 shellcode 時 edx 暫存器值為何，就輸出多少長度，所以把這行註解掉了。
最後就是系統呼叫 int 0x80 把記憶體內容吐出來，然後 jmp _run 則不斷地走訪 linked-list 不斷地吐資料。

寫個小程式 dump，把 shellcode 輸出到 stdout，再透過 nc 送出給 Server。

大概收集個100M ~ 900M，完全看運氣，然後再從 dump 出的記憶體中找尋關鍵字 "The key"。
答案出來!

Defcon 21 競賽解題思路 - incest

2013-06-17T23:39:00.000+08:00

好久沒來寫點東西啦！前兩天又是一年一度的 Defcon Quals，照例 CHROOT 集合多位朋友一塊解題闖關。今年我沒能花太多時間在解題，只看了較有把握的兩題也順利解出，先來分享 "\xff\xe4\xcc" 的第一題 - incest。

此題目給了兩隻 Linux x64 binary，maw 和 sis 。當然二話不說，先來 strings。

$ strings maw

eth0
Could not open key.
/home/services/sis

$ objdump -D sis > sis.disasm

從 sis.disasm 反組譯的內容中，可以看到此程式有 fork() 產生的子行程，會配置一塊記憶體，再將 recv() 收到的內容放到此記憶體空間，最後直接呼叫 callq *rdx，跳躍到該記憶體區域執行。而父行程也配了一塊記憶體，從某檔案中讀取內容後，就不斷呼叫 sched_yield()。
如果轉寫成 C 程式碼，大概長得像這樣:

很明顯 maw 是一個網路 daemon，accept() 連線後再執行 sis，執行時會先 open() key file，然後將 key file 的 fd 和 socket fd 一塊傳給 sis。根據 strace/ltrace 可以發現，key_fd = 3，sock_fd = 4，而且 sis 的子行程會直接跳到遠端傳送的資料裡執行。注意到，呼叫 mmap() 配置 sock_buffer 時，是用 PROT_READ|PROT_WRITE|PROT_EXEC，可讀可寫可執行，就可以塞 shellcode 執行啦。

但是，要怎麼取得 key file 的資料呢?

原來的想法是透過打造 open("key", O_RDONLY)，然後 read(key_fd) 再 write(sock_fd)，但測試結果發現會 Permission denied。而根據題目 incest 原意，搭配 sis.c，可以猜想應該是要由子行程透過 ptrace() 來讀取父行程裡的資料，也就是父行程已 read(key_fd, key_buffer)，只要能讀取父行程的 key_buffer 內容，再 write(sock_fd) 就能遠端取得 key_buffer 內容啦。

打造 x64_86 的 shellcode，我是參考此文 64-bit-linux-shellcode，然後用 nasm 寫了一小段程式碼。流程大概如下:
shellcode()
{
int ppid;
int key_buffer_address;
int key_buffer;
int i;
char buffer[40];
user_regs_struct regs;
ppid = getppid();

ptrace (PTRACE_ATTACH, ppid, NULL, NULL);
wait(NULL);
ptrace (PTRACE_GETREGS,ppid, NULL, &regs);
key_buffer_address = regs.rbp-0x18;
ptrace (PTRACE_PEEKDATA, ppid, key_buffer_address, &key_buffer);
for(i = 0; i < 10; i++)
ptrace (PTRACE_PEEKDATA, ppid, key_buffer+i*8, buffer+i*8);
write(4, buffer, 40);
}

根據前面所提的 sis.disasm

400949: e8 82 fd ff ff callq 4006d0
40094e: 48 89 45 e8 mov %rax,-0x18(%rbp)

可以發現，取得父行程 rbp 暫存器值後去 -0x18，即為存放 calloc() 配置的記憶體位址。所以透過
key_buffer_address = regs.rbp-0x18;
ptrace (PTRACE_PEEKDATA, ppid, key_buffer_address, &key_buffer);

則會得到父行程的 key_buffer 位址啦，接著用一個 for-loop 把父行程的 key_buffer 存的內容讀出來，再透過 write() 輸出到 sock_fd = 4，就能看到解答。
此題 shellcode 的 nasm 如下:

使用 nasm 編譯後，寫了一個小程式 dump，把 shellcode 輸出 stdout。

這樣就過關啦！

Defcon17 Wargame Crypto_Badness 400 解題過程

2009-06-12T02:29:00.000+08:00

接續上一篇 Defcon 17 Wargame 競賽解題心得，這次分享的是 Crypto_Badness 400 的題目解題過程。

此題提供下載一個檔案，題目說明表示，此程式正在 pwn11.ddtek.biz 主機上執行，該程式為一 FreeBSD 的可執行檔，執行時會開 TCP Port 7852。直接用工具 nc 連向 pwn11.ddtek.biz 7852，即出現詢問 Password。所以按照慣例，先來個 strings 指令，觀察檔案內容。

其中有個字串，”chickenfingers” 應該就是該 Password 要問的答案了。當 Password: 提示出現時，輸入 chickenfingers，出現 What is your name? 時，隨便亂輸入 1234567890，最後出現如下圖:

要求解出該加密過的字串，該加密字串的每一字元用 16 進制表示。
接下來就不知要幹嘛，只好把原來的 FreeBSD執行檔，再來作分析，這一次改用工具 objdump 作反組譯(Disassemble)以及逆向工程(Reverse Engineering)，分析結果如下:

為一對稱式加密法，先取得五個亂數數值，每個亂數值為 0~255 (0x00~0xff) 之間，再建立一個 256 字元的陣列，陣列中每個值介於 0 至255。利用此五個亂數數值為亂數種子，擴充成 256 個亂數數值，存於此陣列中。
利用簡單的 XOR 運算來加密，從明文中逐一取得字元，再從前面擴充成 256 個亂數陣列中，取一數值，來和明文的該字元 XOR，當明文的每一字元完成 XOR 後，即為密文。每次從 256 個亂數陣列中取值的方式則和明文字元的位置有關。
由於 XOR 的特性，若是把密文的每個字元和 Key 的每個字元作 XOR 就可以反解成明文。透過程式的逆向工程，可以知道加密演算法，甚至可以直接取用相關計算函式。如此一來，我們只要猜測一開始亂數取得的五個亂數字元，就可以把 256 字元的亂數陣列值計算出來。
不過，若是嘗試寫程式用暴力法計算，五個亂數數值全部猜測，就要計算 256 的 5 次方，而且，如何判斷該亂數值是否猜測正確呢?
由於明文是從純文字檔內讀取 32 個字元，所以假設明文都是可顯示之字元(包含大小寫英文、符號及空白字元)，那就可以在暴力法每回解出明文時，掃瞄一次明文字元是否都為可顯示之字元，若是，就假設為明文字串，全部顯示出來。

這下就可以寫程式，計算 256 的 5 次方，求解明文了！但是這樣跑程式實在太慢了，就算試著用一些最佳化或分散運算的方式，仍然要等上很久。

回過頭來重新檢視之前的輸入輸出。當 Password: 提示出現時，輸入 chickenfingers，出現 What is your name? 時，則輸入 1234567890，最後出現如下圖:

奇怪，1234567890 字串到 ? 字元出現的中間有一段空白，改用 hexedit 編輯看看:

這樣就看清楚了，在 1234567890 字串後面，接了 6 個空白字元(0x20)，然後一個字元(0xCE)，再一個 : (0x3A)字元。這個 0xCE 字元，即為一開始取五個亂數值中的第一個數值。
五個亂數值中，第一個數值已知，如此一來，就可以動手寫暴力破解程式，計算 256 的 4 次方，即可找出\x5f\x92\x84\xbc\xe\x16\xab\x2a\x92\x97\x63\x78\x06\x5f\xa1\x3a\xa3\xee\xa9\xc3\xee\x49\xea\xea\x92\x1a\x36\x2e\xa8\x7c\x28\x0cf 的明文。

透過分散數台電腦來分批執行暴力破解程式，但仍然很慢，花了數個小時仍找不出明文字串。這時想到，原來的程式中，輸出的函式有兩組，另一組會輸出兩倍長度的字元。假若我可以改變程式流程，跳躍至另一組輸出函式，也許可以輸出五個亂數值中的前兩個數值，這樣就可以跑計算次數降為 256 的 3 次方。

將所附的程式碼再重新反組譯，可以觀察出程式中有一個變數可以控制字元輸出的長度。該變數位在 -0x25(%ebp)，此變數值是由 -0x29(%ebp) 和 1 作 AND 運算後的結果，若此變數 -0x25(%ebp) 的值為 1 是，則會輸出兩倍長度的字元。

當 Password: 提示出現時，輸入 chickenfingersa (故意多打一個字元，造成 one byte 溢出)，出現 What is your name? 時，則輸入 ABCDEFGHIJKLMNOABCDEFGHIJKLMNO，最後出現如下圖:

在 ABCDEFGHIJKLMNOABCDEFGHIJKLMNO 字串後面，接了 2 個換行字元(0x0A)，然後三個字元(0xD9、0xE2、0x00)，再接一個 : (0x3A)字元。其中 0xD9、0xE2 字元，即為一開始取五個亂數值中的前兩個數值。這樣一來跑暴力破解程式實在快多了，不到十秒就出現一組明文。

不過這明文怎麼看都不像啊！讓暴力破解程式繼續執行，很快地，又發現第二組明文啦。

賓果! 解出明文了！

註: 暴力破解程式的解密函式是直接從原程式作逆向工程後取用，變數處理要注意 signed/unsigned 的問題，否則從亂數陣列取值時會計算不正確。

Defcon 17 Wargame 競賽解題心得

2009-06-10T21:59:00.000+08:00

上週末剛好是美國知名駭客大會 Defcon 17 的 Wargame 外圍競賽期間。和往年一樣，這一次大夥又一塊聚在一起解題目，各展長才，不論是卡關卡的很痛苦、解謎解的快抓狂，或是終於解出答案的喜悅，總之我喜歡這樣的感覺。

經過兩天的努力，成績差強人意，雖然還是未能打進前十名，但應該也有二十多名，在全球兩三百個團隊競賽下，也不算太差吧！這兩日我共解了兩題，一題 100 分，另一題 400 分，我打算把解法寫出來，和大家分享交流。

這題是屬於 Binary_L33tness 的 100 分題目，題目很簡單，給一個檔案然後 "Find the key"，如圖:

下載完檔案，第一步當然用 Linux 的 file 指令來判斷檔案型態囉！

[timhsu@localhost 100]$ file 100.file
100.file: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped

此 100.file 檔為 Linux 的靜態執行檔，而且被 strip 過。不要怕，直接執行看看。

[timhsu@localhost 100]$ ./100.file
What is the password? 123
I smack you down. Step off bitch.

看來是要猜密碼耶。可以猜想一下，這個題目應該是密碼字串就在 Binary 執行檔裡，只要把檔案用 strings 指令來找這個字串，應該就是答案了。

有這麼容易嗎? 哦！若是直接用 strings 指令，大概找不出什麼像答案的字串吧！來用 hexdump 把檔頭資料印出來瞧瞧。

[timhsu@localhost 100]$ hexdump -C 100.file -n 256
00000000 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 03 00 01 00 00 00 e8 83 c0 00 34 00 00 00 |............4...|
00000020 00 00 00 00 00 00 00 00 34 00 20 00 02 00 28 00 |........4. ...(.|
00000030 00 00 00 00 01 00 00 00 00 00 00 00 00 10 c0 00 |................|
00000040 00 10 c0 00 d0 7b 00 00 d0 7b 00 00 05 00 00 00 |.....{...{......|
00000050 00 10 00 00 01 00 00 00 1c 0e 00 00 1c 0e 05 08 |................|
00000060 1c 0e 05 08 00 00 00 00 00 00 00 00 06 00 00 00 |................|
00000070 00 10 00 00 01 99 69 2e 55 50 58 21 e6 07 0d 0c |......i.UPX!....|
00000080 00 00 00 00 a6 03 01 00 a6 03 01 00 14 01 00 00 |................|
00000090 9a 00 00 00 02 00 00 00 63 3f 64 f9 7f 45 46 46 |........c?d..EFF|
000000a0 01 00 02 00 03 00 0d 92 ff b7 d9 ee 04 08 34 06 |..............4.|
000000b0 2c e5 17 0b 20 00 07 00 28 00 26 00 23 00 cf 3d |,... ...(.&.#..=|
000000c0 77 b1 06 0f 03 80 04 08 e0 0b 03 5a b3 69 9a 05 |w..........Z.i..|
000000d0 04 03 14 01 81 1b 05 1b ac fb 03 13 0f 13 1b 01 |................|
000000e0 03 ef b5 9f 8b 00 3b 03 a4 5b 0a 03 3f cf b9 b1 |......;..[..?...|
000000f0 d9 00 10 1f 13 eb 1b 03 50 d7 75 5f ec 78 22 00 |........P.u_.x".|

檔頭裡發現關鍵字串 "UPX"，為一加殼程式，也就是說這個 Linux 執行檔被 UPX 加殼過，真正的檔案內容要在執行期間才會解開執行。直接用 upx 工具來作解殼動作，還原檔案內容。

[timhsu@localhost 100]$ upx -vvv -d 100.file
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2008
UPX 3.03 Markus Oberhumer, Laszlo Molnar & John Reiser Apr 27th 2008

File size Ratio Format Name
-------------------- ------ ----------- -----------
upx: 100.file: Exception: checksum error

Unpacked 1 file: 0 ok, 1 error.

失敗！upx 工具的解殼動作出現 checksum error，所以無法解開。
好吧，換個思維想想，既然加殼程式在執行期間會在記憶體還原原檔案內容，所以我們就可以試著在檔案執行時，把記憶體內容傾印出來。

試著建立 CoreDump 檔。

[timhsu@localhost 100]$ ulimit -c unlimited
[timhsu@localhost 100]$ ./100.file &
What is the password? [1] 22488

[1]+ Stopped ./100.file
[timhsu@localhost 100]$ kill -11 22488
[timhsu@localhost 100]$ ls
100.file*
[timhsu@localhost 100]$ ps
PID TTY TIME CMD
22408 pts/4 00:00:00 bash
22488 pts/4 00:00:00 100.file
22490 pts/4 00:00:00 ps
[timhsu@localhost 100]$ bg
[1]+ ./100.file &
[1]+ Segmentation fault (core dumped) ./100.file

CoreDump 建立成功！馬上用 strings 指令瞧瞧檔案內容。

[timhsu@localhost 100]$ strings core.22488 | more
...<略>...
,[^_]
[^_]
What is the password?
visilooksgoodinhotpants
, %d byte packets
CWR ECN
...<略>...
/lib/i686
libc.so.6
What is the password?
rotection after relocation
apic
mtrr
...<略>...
[timhsu@localhost 100]$

有兩組可能的密碼，試一下就知道。

[timhsu@localhost 100]$ ./100.file
What is the password? visilooksgoodinhotpants
You're my daddy! See you at the hacker swinger's club next week.

成功！這樣看來很簡單是吧?
事實上，當時我是用幾年前自己寫的小工具 dump2bin 來傾印執行檔，後來才想到不必寫程式的 DumpCore 方法，也許有其它方法，大家可以動動腦筋。

下回我將分享 Crypto_Badness 400 分的解題心得。

大陸 DNS 暴風門事件

2009-06-03T17:20:00.000+08:00

上個月，在中國地區有個驚人的網路消息爆發，在 5/19 日時，大陸的 DNS 發生大規模的故障: 後來稱作「暴風門」事件。

「5月19日晚間訊息，來自廣州、杭州等地中國電信客服人員向新浪科技證實，這些地區的網路出現故障，致使用戶無法上網。從晚間九點開始，陸續有多位網友反映稱，包括廣州、山西網通、上海、浙江等地均出現了不同程度的DNS癱瘓故障。」--- 節錄自: http://4i4u.com/blog/dns-baofeng-dnspod/

當時事件發生時，有網友猜測是 DNS 伺服器被黑客大規模 DDoS 攻擊，但這影響層面廣大是前所未聞。後來經過這陣子的調查，大家才了解事情的始末。

在 5/18 日時，著名 DNS 服務廠商 DNSPod 的 6 台伺服器受到 DDoS 的攻擊，直到 5/19 日，DNSPod 承受不了如此大流量攻擊下，被迫停止 DNS 服務。但為何這樣幾台 DNS 伺服器下線，就會造成大規模的網路異常呢?

這是因為，大陸地區最盛名的影音播放軟體 - 暴風影音，該公司的 DNS 服務就是由 DNS Pod 所提供的。因此，暴風影音播放器的用戶端無法解析出伺服器的 IP，開始不斷向網路供應商的 DNS 伺服器發送解析請求，造成 DNS 伺服器堵塞。據說，暴風影音的 1.5 億的客户端，其中約一半的客户端解析不到域名，令人詬病的是，暴風影音軟體會啟動自動連線程式，約每 15 秒連線暴風影音，若 DNS 查詢失敗則會不斷重試，因此，各地的客户端不停地發送 DNS Query (UDP 封包)，各地 ISP 的 DNS 伺服器也就連帶著被暴風影音的用戶 DDoS 了。

相關消息及資料整理如下:

1. 5月19日大陸DNS發生大規模故障
2. 暴风影音DNS故障追踪：由24岁站长引发的蝴蝶效应
3.暴风长老, 请收了神通吧!
4.大陸出現罕見網絡大癱瘓網民不滿
5.大陸DNS大規模故障始末：網域服務商遭DDOS攻擊
6.“5·19网络大瘫痪案”告破
7.暴风召回1.2亿播放软件称损失应由黑客赔偿

當中也可以發現由於黑客地下經濟的興盛，從木馬程式開發、販售、「肉雞」養成，到提供各項網路攻擊，只要有錢，就可以胡作非為。

這些文章中也提到了 2006 年 12 月時，台灣發生地震，波及海底光纜，造成台灣對外如大陸地區、東南亞和澳洲等無法正常連線。事實上，當時台灣網路對外連線困難的影響，還意外地讓大家注意到了中華電信(hinet)偉大的 DNS 伺服器: 168.95.1.1。

我們可以在網路上找到許多網路教學或設定的文件，幾乎都是教人設定 DNS 伺服設定為: 168.95.1.1。還不止這樣，google://168.95.1.1 把範圍縮小到網路設備手冊，不論中文還是各國語言，也可以看到熟悉的 IP: 168.95.1.1！當然，台灣這幾年來在網通設備上的開發，出廠預設值的 DNS 伺服器，自然也是 168.95.1.1！

這也就是台灣 2006 年 12 月的地震，衝擊了世界上其它地區數以萬計的網友無法正常上網。真好奇 168.95.1.1 這台的 DNS Query 流量如何，而有多少 DNS Query 來自非台灣地區? :-)

DNS 的重要性看來很明顯，直到去年，都還有 DNS 伺服器的問題被爆出來 (Multiple Vendors DNS Spoofing Vulnerability) ，或許還有些我們不知道的問題在未來會發生，像這次「暴風門」事件，除了期望 ISP 固好 DNS 外，我們能試著改變一些習慣?
例如，DNS 的設定上除了 168.95.1.1 我們還可以設定其它 ISP 提供的 DNS 作為 Secondary。

不久前，有位友人和我打趣地說，若是 168.95.1.1 不回應 ICMP 的話會如何? 我說，大概很多人都以為網路對外不通吧！

網站轉址攻擊-ARP掛馬

2009-03-12T23:48:00.000+08:00

從上一篇「網站轉址攻擊事件」發文後，有朋友來信問我，為何能確信是「ARP掛馬」，而不是「IP-Spoofing」。

事實上，此攻擊事件不論是「ARP掛馬」或是「Non-Blind Spoofing」，都能得到類似網站轉址的效果。

看來這回的攻擊事件，爭議點只剩下究竟是「ARP掛馬」還是水落石出的「Non-Blind Spoofing」。

我曾看了 Fyodor Y. 的留言以及他的看法，也和他交換了意見，對於他的技術能力，我毫無懷疑，甚至我覺得他寫的「Non-Blind Spoofing」模擬攻擊程式寫得很好，很值得研究參考。

那為何我不選擇相信是「Non-Blind Spoofing」，難道我有作什麼實驗，或是整天在網路上抓封包測試嗎。我的依據是什麼呢？

這篇，我就來說明一下這兩個攻擊的可能性，以及我的質疑和判斷。

「Non-Blind Spoofing」這個攻擊，事實上是需要封包監聽以及插入封包，並且搶在真正的回應封包前，傳送惡意封包回 Client 端。

那要在那個網路節點上封包監聽作這樣的攻擊呢？任何一點都有可能。
但問題是，有可能監聽到嗎？二話不說，馬上實驗，各位就立刻執行 Wireshark 看看，來監聽看看你老闆的 MSN 吧！若是你聽到了你老闆的的談話，你就選擇相信「Non-Blind Spoofing」，一點問題都沒有。

另外有一種可能。這也是水落石出的可能了:

「某個網路節點的 Router 被入侵，並且改了設定」

這是要逼 ISP 啞巴吃黃蓮嗎？

Router 被入侵的可能性當然是有，然而中華電信 ISP 天天在檢查，完全沒有發現異常的情況。

再說，改了設定是要把封包 Mirror 到那裡？中華電信機房該 Router 旁的主機嗎？
那來的這台「Router 旁的主機」？中華電信機房可以隨便放機器就是了？
那設定封包 Mirror 到較遠的主機呢？那你怎麼搶送封包回 Client 端？
而且能不能照原路由傳送回假封包都是問題！！
以上問題若不能回答出來，就請別再誤導各位網友了好嗎？

好，那另外一種「ARP掛馬」攻擊的可能性呢？

我在上一篇文章有提到，國內之前早有人揭漏了「ARP掛馬」攻擊。而最近的國外安全研究機構 SANS 的討論，大家可以看一下 Massive ARP spoofing attacks on web sites
這篇。

另外，遠在 2007 年的一篇技術報告 "Studying Malicious Websites and the Underground Economy on the Chinese Web" 中提到「ARP 掛馬」攻擊大陸的 "Norton China" 網站，我擷圖如下，覺得不清楚或想看整篇文章的朋友可以自行閱讀。

此外，這一兩年大陸駭客在各駭客論壇或駭客雜誌裡，早已把「ARP 掛馬」講到爛了，有興趣的朋友，可 Google 「ARP 掛馬」或「ARP-Spoofing」，有一堆的事件資料可參考。
這說明了什麼呢？這說明，利用「ARP-Spoofing」作攻擊是最可行的方式！

也許有人質疑，這回攻擊所側錄的封包和使用「ARP掛馬」攻擊的封包有些差異。但是，就憑網路封包 ID/TTL 的不同，就說和「ARP掛馬」無關，這樣的否定會不會太粗糙了？

要修改封包回應或插入不同的封包內容，這對程式能力高的駭客來說，這是幾分鐘就可以改的，要亂數處理也行，愛怎麼變就怎麼變，唯一不變的是，要達成這樣的攻擊，「ARP Spoofing」是最容易，也最現成，更是大陸駭客流行許多的手法，而且，重要的是

「不會有駭客這麼閒，整天在看部落格後一直改攻擊程式的」。

所以，從以上我的觀點，所得到的結論如下:

1. 會作 ARP-Spoofing 掛馬攻擊的原因，絕大部份是因為該網站的防護很強，無法攻破後直接掛馬，所以只好作「ARP 掛馬」。
2. Sniff 不同網站的封包流量當然有可能得到不同的攻擊方式，而且不用預測下一波，因為「ARP 掛馬」不斷發生，總是會有新聞可以炒作。這點資安專家們可以安心。
3. 和基礎架構和設備無關，這類的攻擊在世界各地都可能常發生。

最後我要說的是：
指控中華電信 ISP 的路由器有異常，是非常嚴重的事，也關係著商譽問題。一般說來，資安專家或廠商發現了異常或漏洞，都會有道德的與出問題的一方作好溝通，釐清真正問題點，再選擇適當時機公佈詳細資訊(Full−disclosure)。

但是，若證據都不足的情況下，貿然的指控，只是會令人懷疑背後的動機。

身為資安廠商，除了技術能力和新聞議題外，更重要的是道德，不是嗎？

網站轉址攻擊事件

2009-03-10T11:31:00.000+08:00

上週開始，陸續有人發現在連到 www.msn.com.tw、tw.msn.com、taiwan.cnet.com 等網站時，發生了一些異常行為，瀏覽器被硬生生的導到其它網站(www.dachengkeji.com) 等。

詳細的討論可看 Richliu 的某些 ISP 疑似被 hijacking 攻擊一文。

事情看來很大條，各專家紛紛出來澄清或解釋這樣的攻擊。
有專家說，這是「新型態的網路攻擊手法」！
有專家說，這是「電信業者的DNS主機遭攻擊」！
有專家說，這是「某 ISP 的路由器(Router)被攻破」，甚至還說 Router 被感染了。真不知道是被感染了什麼鬼玩意。
當然也有專家真的分析了封包內容，提出了可能是「Non-Blind Spoofing」的結論。

看到這些說法，我其實蠻訝異的。

我上週知道這件事發生後，就和幾位 CHROOT 的成員討論過，並在第一時間透過管道，得到了 ISP 的「三不一沒有」的資訊:
「不是 DNS 問題、不是 Proxy 問題、不是 Router 問題，沒有被入侵」
(昨日 3/9, 中華電信資安辦公室證實了這點 http://www.itis.tw/node/2601)

而我們的結論是「這是大陸駭客愛用的 ARP Spoofing 攻擊」，不過攻擊地點在 IDC 端。
我們以為這並非什麼新的攻擊型態，不過專家就是專家，總要有自己的看法，不知道原因的，也要說成是新的攻擊型態，混合了幾種專業名詞大家就點頭稱是了。

事實上，對岸駭客真的把「ARP Spoofing + 網頁掛馬」，簡稱「ARP 掛馬」技術發揮到了極點，從 MSN SHELL 所在SERVER遭ARP掛馬就提到了在 IDC 端的「ARP掛馬」案例。

我的看法如下:
1. 被導向的網站 www.msn.com.tw、tw.msn.com、taiwan.cnet.com，「當時」都在位在新加坡電信Singtel。我想應該台灣的 ISP 應該和新加坡電信窗口聯絡，知會一下狀況。

2. 並非每次或每個人瀏覽都會被導向，原因應該是流量過大，封包處理不及，或是該攻擊有時間間隔處理。

3. 此事件中，看來只有從台灣連去的封包被影響，有針對性。

4. 以現在的工具來看, 利用「ARP 掛馬」發展得很成熟，大家可以 google 看看 zxarp，我甚至可以告訴你，這個工具參數怎麼下，放在「對」的地方，就可以造成這次的效果。呃，上述的第 2、3 點，該工具都有參數支援啦。

當然啦，每個人的看法不同，堅持是什麼「新的攻擊型態」的專家，或許這回真的可以揚名國際！但若是真的「ARP 掛馬」，也請認真的研究一下這個攻擊，並提醒大家，這種攻擊的嚴重性。

至於會不會有真的證明是「ARP 掛馬」呢？我不知道！(謎之聲: 誰會承認自己 IDC 被 ARP 掛馬)

套句某駭客的名言「忍一下就過去了！」，有道理，不是嗎？ :-)

x86 shellcode detection and emulation - libemu

2009-02-03T17:08:00.000+08:00

去年我在研究開發惡意文件偵測技術 - mdscan 時，就在試著找尋適合的 x86 emulator。可惜，找到的幾乎都是 Virtualizer 性質，非我所需要。
一月時無意間發現了 libemu，這兩天就著手將原來 mdscan 的動態追蹤核心，換成 libemu 來模擬執行。

Malicious Document Scan Tool Version 0.5
---------------------------------------------------
Copyright (c) 2009 Net-Hack Technology Co.,Ltd. All rights reserved.

Scanning CVE/MS08-014/69a7b1dd0af391523ae55a846232c68f
opcode: E8E4FFFFFF call 0xffffffe9
opcode: 5E pop esi
opcode: 8BFE mov edi,esi
opcode: 8BD6 mov edx,esi
opcode: 83C214 add edx,0x14
opcode: 52 push edx
opcode: B96A030000 mov ecx,0x36a
opcode: AC lodsb
opcode: C0C000 rol al,0x0
opcode: AA stosb
opcode: 49 dec ecx
opcode: 75F8 jnz 0xfffffffa
opcode: AC lodsb
opcode: C0C000 rol al,0x0
opcode: AA stosb
opcode: 49 dec ecx
opcode: 75F8 jnz 0xfffffffa
opcode: AC lodsb
opcode: C0C000 rol al,0x0
opcode: AA stosb
opcode: 49 dec ecx
opcode: 75F8 jnz 0xfffffffa
opcode: AC lodsb
opcode: C0C000 rol al,0x0
opcode: AA stosb
opcode: 49 dec ecx
opcode: 75F8 jnz 0xfffffffa
opcode: AC lodsb

不過，libemu 缺乏詳細的文件，而且有些 instructions 並沒有 mapping(例如 opcode: A8 and A9)，有些 API 也不甚明白是什麼作用，畢竟還在 version 0.2 開發中吧！

想試著研究 shellcode 追蹤或是自動化解殼(unpack)的朋友，不妨試試。

舊 blog 文章轉換到 blogger

2009-02-03T16:15:00.000+08:00

感謝 google-blog-converts-appengine 的 blog 轉換程式，已成功將我舊 blog 的內容，轉移至此啦！
google-blog-converts-appengine 是用 python 語言開發，要額外裝 ElementTree 即可正常執行。

Gmail 釣魚網站

2008-03-08T17:45:00.000+08:00

今日有研究員 D 先生回報，收到 Gmail 釣魚網站郵件，分析如下，僅供參考。

------ 底下為釣魚郵件內容 -------
From: Gmail 小組 <mail-noreply@gmail.com>
Date: 2008/3/6 16:40
Subject: 請及時更新您的Gmail服務，以免對您的使用造成不便
To: timhsu.tw@gmail.com

Google近日開始對用戶的Gmail電子郵件服務進行升級

，新版Gmail服務不僅在界面上有所變化，在內部結構上也針對Firefox2和IE 7進行了優化。

由於對JavaScript後端系統進行了重新設計，所以新版Gmail服務的訪問速度將更快，打開一封郵件的時間將不到200毫秒。

免費Gmail電子郵件的存儲空間將由原來的4G增至6G。

請按下面的步驟及時提交您的申請，我們將在24小時之內為您提供新版服務，舊版服務可能在一週之內過期，對您造成的不便請諒解。

步驟一：進入服務申請頁面 https://mail.google.com/mail/updateservices
步驟二：驗證客戶信息。
步驟三：完成申請。

感謝您使用 Gmail！
衷心感謝！
Gmail 小組敬上

請勿回複本電子郵件。如果您希望與Gmail小組聯係，請登錄您的帳戶並點擊任何網頁
頂部的"幫助"。然後，點擊位於支持中心底部的"與我們聯係"。

------ 以上為釣魚郵件內容 -----------

其中在釣魚郵件內容中的，步驟一：進入服務申請頁面 https://mail.google.com/mail/updateservices，若點擊，則網址會連至(已把 link 改為無效)

http://googleaccounts-login.dynalias.com/google/ServiceLoginservicemail&passivetrue/Fmail.google.com3Dl&ltmpldefault&ltmplcache/google.asp?user=timhsu.tw@gmail.com

同時，此頁面隱含(嵌入iframe)有 MS-06014 針對 IE 瀏覽器的攻擊.

經過查詢，googleaccounts-login.dynalias.com 的 IP 為 211.22.79.234 底下為 whois 資訊：

Li Wai Sh Co., Ltd.

Netname: LI-WAI-SH-CO-E4-NET
Netblock: 211.22.79.232/29

Administrator contact:
hn84050286@hn.hinet.net

Technical contact:
hn84050286@hn.hinet.net

此應為立瑋仕公司(http://www.device-giant.com.tw/) 所有之 IP 範圍，已被駭客利用來作釣魚網站及攻擊跳板。

www.device-giant.com.tw 的 whois 資訊為：

Domain Name: device-giant.com.tw
Registrant:
蝡讠�隞閗隞賣����
Device-giant Co.,Ltd
5F-1,No. 161,Sung Teh Road Taipei Taiwan

Contact:
John Lin john@device-giant.com.tw
TEL: 23463210
FAX: 27593009

Record expires on 2008-11-14 (YYYY-MM-DD)
Record created on 2000-08-30 (YYYY-MM-DD)

Domain servers in listed order:
device-giant.com.tw 211.22.79.234
ntweb.device-giant.com.tw 211.22.79.234

CGoban

2006-03-12T19:51:00.002+08:00

最近對圍棋特別感興趣，有點時間就上網找人廝殺，不過都是被別人殺得一踏糊塗。
我使用 Java 版的 CGoban2下網路圍棋。至於象棋，我都跑去 PTT下棋，不過好像沒有像 CGoban2 這麼好用又跨平台的軟體。
底下是我看別人下圍棋時的快照：

X 的設計原則

2006-03-08T00:44:00.002+08:00

無意見看到 Wikipedia 對於 X 設計的原則描述，茲引言如下：

1984年，Bob Scheifler和Jim Gettys制訂了X的早期原則：
* 除非沒有它就無法完成一個真正完整的應用程式，否則不用增加新的功能。
* 決定一個系統不是什麼和決定它是什麼同樣重要。與其去適應整個世界的需要，寧可使得系統可以擴展，這樣可以用上層相容的方式來滿足新增需求
* 只有根本沒有實例才會比只有一個實例更糟。
* 如果問題沒有完全弄懂，可能最好根本就不要去解決它
* 如果預期要用百分之90的努力去完成百分之10的工作，應該用更簡單的辦法解決。 (參見更糟就是更好。)
* 盡量避免複雜性。
* 提供機制而不是策略。實踐中把用戶界面策略放在用戶手裡。

第一條原則在設計X11時修改為：「除非制訂有真實的應用程序需要，否則不用增加新功能。」 X基本上一直遵循這些原則。參考實現是從擴展和改進的著手來進行開發，同時和1987年的最初的協議幾乎保持完全相容。

上文提及的更糟就是更好，中文維基百科裡還沒有中譯。當然除了 X 外，也一定會想到 UNIX 的設計哲學:

1. Small is beautiful.
2. Make each program do one thing well.
3. Build a prototype as soon as possible.
4. Choose portability over efficiency.
5. Store data in flat text files.
6. Use software leverage to your advantage.
7. Use shell scripts to increase leverage and portability.
8. Avoid captive user interfaces.
9. Make every program a filter.

基本上，以上提及的設計原則，都離不開「簡單就是美」的哲學。說來慚愧，寫程式多年至今，還未能接觸到大型且複雜的程式，更沒有能力與機會參與設計龐大的軟體架構。只靠賣弄些程式技巧，雖足以過活，但心裡知道，若要實現一些想法，還有一大段功夫要磨練。

好好思索，好好反省，我所寫過的程式是不是稱得上「美」呢？唉。

資安展遊記

2006-03-06T23:26:00.002+08:00

上週的「台北國際資訊安全科技展」，算是台灣資安界年度大拜拜。趁著這個機會，我也逛了許多廠商的攤位，為的是了解資安設備發展的方向。

1. Novell 攤位上只有一位好心的小姐在介紹，雖然她熱心的想提供 SuSE Linux 上課折價卷，但是我真的不需要啊。如果有人想上課考 NCLP，請參考 CdChen 的恆逸將開辦 NCLP 課程

2. 諮安科技的線上弱點掃瞄服務( !Patrol SNAP online)，嗯，很好，不過我情願用 Nessus

3. 我在 openfind 攤位上告訴一位美麗的小姐，mail2000 系列許多政府和學校使用，十分有名氣，可說是國內少數成功的商業 webmail。當然，就被贈送了免費使用半年的 mail2000 帳號。

4. 力麗科技的 Message Server 50，多功能郵件伺服器。這應該是 mail2000 競爭產品，不過，防垃圾郵件、防病毒郵件就算了，為何要加上個防駭客攻擊呢？答案是，可以防駭客 DoS 攻擊。帥吧。

5. 看到一個號稱全球唯一可側錄 skype 語音通話內容以及文字聊天內容的超強系統。陶華科技代理的 MIS Keeper - 資訊稽核管理系統。哇！一看就被嚇到吧，不過當業務談到要在使用者電腦上裝管理軟體時，我腦裡想的盡是如何移除該「類 rootkit 的 spyware」。

6. 8e6 的網路安全行為管理系統。喔，又是一個監控員工上網行為的設備。不過，我倒對封鎖 spyware 軟體封包和防詐騙網站、惡意程式碼攻擊等較感興趣。號稱有分門別類的 URL 強大資料庫，並且會定時掃瞄所有大型網頁來作資料庫，提供比對，以封鎖釣魚網站。

當然，還有許多優秀的產品，我就不一一細說。只是有種感覺，那就是網路安全管理和內容安全管理已經開始作到爛了，大部份產品的定位都在企業應用上，都在幫企業想如何控管員工上網行為，如何讓員工的電腦更受保護。

能讓電腦或網路更安全的設備，大家都樂意接受，一旦要被約束、被管理、甚至被監視，那就是千百個不願意了。如果像電影「全民公敵」那樣，說過的每句話，做過的每件事，去過那裡，吃過什麼鳥蛋，喝過什麼鳥咖啡都被他人記錄並檢閱，你如何開心的上班，歡欣的把工作完成呢？在怎麼爽，也是公司的 MIS 和老闆互相在爽而已啊！

是不是要多為更多的 End Users 著想？人們用電腦上網，圖的是方便和私密，大家已經受夠了為了病毒，要被迫裝上醜不拉嘰的防毒軟體，還要隔一段時間就 Windows Update 一下，好補補 Windows 的破窗。現在，人們還要面對正版後門監控軟體，「類 rootkit 的 spyware」，對於手無寸鐵只會下載 A 片的員工們，只有被張開嘴等著宰殺的份。你可能不知道自己電腦已被植入這類的「間諜軟體」，或著你明明知道，就無法移除它。它就那麼可惡的從「間諜」化身成「稽核」。不就是上個網看看色情圖片、傳傳打情罵俏的 MSN 訊息，抱怨一下上司的豬頭，有這麼嚴重到要剝奪那麼一點的隱私和樂趣嗎？

算了算了，來吧，大家來改用 Linux，練習一下 ssh/http tunnel、GPG 加密郵件、Gaim-encryption 加密通訊內容吧。至於什麼都不懂的人們，就只好學習「忍」了。

SSH TCP FORWARDING

2006-02-18T03:48:00.002+08:00

有些公司或機關會試著用一些防火牆和監控設備，來對公司內部同仁上網作加以控管。最常見的例子就是對 IM (MSN/Yahoo!)等作記錄或限制。如果防火牆有開放 ssh 連線，或是沒有對 HTTP Protocol 作查核，那就可以試著用 ssh 的 tcp-forwarding 來建立加密連線(secure tunnel)。

(公司外部 Server: proxy.nosuchserver.org)
1. 先架好 Proxy，例如可以 bind 在 3128 Port.
2. 設好 Firewall 規則，只開放 localhost 連線:
iptables -A INPUT -p tcp -s ! 127.0.0.1 --dport 3128 -j DROP
3. 加個帳號叫 tunnel

(公司內部 Linux: 192.168.1.10)
1. 用 ssh 登入 proxy.nosuchserver.org
ssh -L 8080:127.0.0.1:3128 tunnel@proxy.nosuchserver.org
2. 此時可以將 MSN 或 WWW-Browser 的 proxy 設定指向 127.0.0.1:8080
3. 利用此 tunnel 即可對外加密連線

如果你想讓公司內其它同事共享此 proxy，則可以利用新版 ssh 的功能:

ssh -L 192.168.1.10:8080:127.0.0.1:3128 tunnel@proxy.nosuchserver.org

那麼大夥通通把 proxy 設定指向 192.168.1.10:8080 即可。

如果對外沒開放 port 22，那就只好試著讓 Server 上的 sshd 聽 port 80 或其它開放的 port 囉。

某金控網站被入侵

2006-02-15T01:31:00.002+08:00

今天下午某位朋友告訴我，當他連上某國內知名金控網站時，防毒軟體發出了警告。該網站的首頁疑似被加入了一行不顯示的 iframe 連結。順著該連結到另一個公司的網站，就會啟動一個惡意的 Javascript，而此 script 的動作則是執行一個植入後門的程序。
想看此惡意 javascript 原貌? 看看 ICST上的相關討論吧。
顯然，至少有兩家公司被入侵，網頁內容遭駭客篡改。但被植入惡意 Javascript 的網站，也許已經讓許多的使用者電腦中了後門。

害怕了嗎？還不快把 MS-IE 換掉！

至於被植入的後門，經過 Birdman 大師的 Archon 惡意軟體掃瞄，其結果如下圖：

十三號星期五

2006-01-14T00:48:00.002+08:00

今天的日子，總會令我不禁想起年少時狂熱追求電腦病毒技術的時代。
從 (c) Brian 到 Jerusalem 的泛濫，恰是我從 GW-BASIC 往 Assembly 學習的時間。旗標早期出版的 DOS 技術手冊、組合語言、組合語言程式設計實例、電腦病毒徹底研究等，都是我國中和高中時不可或缺的精神食糧。
印象中，黃瑞強先生有段時間在第三波雜誌開了個專欄，剖析各種電腦病毒，以及最新的病毒技術。諸如，病毒產生器、多形病毒、變體引擎、伴隨型病毒等。當然，這也是當時我最愛的雜誌專欄。
回憶就此打住！就來看看當年十三號星期五發作的 Jerusalem，倒底是長得什麼模樣?
從Jerusalem 病毒原始碼可以看到一開頭就有個熟悉的字串 "sUMsDos"！
底下程式片段是利用 int 21h 取得日期，判斷是否為十三號星期五，若是，就把 b000E 設為 1，代表病毒發作日。


mov     ah,2Ah
int     21h		;  get date, cx=year, dx=mon/day
mov     cs:[b000E],0
cmp     cx,7C3h
je      loc_6
cmp     al,5
jne     loc_5
cmp     dl,0Dh
jne     loc_5
inc     cs:[b000E]

接著，病毒常駐到記憶體後，當使用者欲執行檔案時，遇到發作日，就把該執行檔刪除，若非發作日就感染該執行檔。底下的 loc_12 程式片段就是為了刪除檔案。


loc_12:
xor     cx,cx
mov     ax,4301h
int     21h	;  get/set file attrb, nam@ds:dx
mov     ah,41h
int     21h	;  delete file, name @ ds:dx
mov     ax,4B00h
popf
jmp     dword ptr cs:[pv21]
loc_13:
cmp     cs:[b000E],1
je      loc_12

程式寫的真美，是不？

對了，如果看不懂 Jerusalem 程式請勿來信問我，因為我早就忘光 DOS 呼叫和 MZ EXE 了啊。

Gaim-Encryption

2005-12-27T07:27:00.002+08:00

Gaim-Encryption 是一個 Gaim 通訊加密模組，它利用 Mozilla 的 NSS (Network Security Services) 來提供 RSA 加密。
今天 Nanika 要找人測試 Gaim-Encryption，才想起一年前我曾抽了點空將 Gaim-Encryption zh_TW.po 翻譯好。
連上官方網站才發現 i18n 網頁上竟把中文放在第一行，而進度統計卻是將 zh_TW.po 排在最後。這讓偷懶了一年的我看了真有點汗顏。於是，馬上就抽空下載了 Gaim-Encryption 3.0beta2 並試著更新 zh_TW.po。
此外，我也順便下載了 Gaim 2.0beta1，果然高級啊，可以看得到 MSN 小動畫了哩。真讚！
經過一番努力，已把 zh_TW.po 更新並送至 mailing-list了。希望可以順利在 Gaim-Encryption 3.0 Release 時看到中文化的成果囉。

如果你怕你的 MSN 訊息被監聽，或是怕被監控記錄，請愛用 Gaim-Encryption 吧！

BTW, 我是用 gtranslator 這套工具處理 po 檔的。

註：Gaim-Encryption i18n 統計其實是用開頭字母順序排的啦！ :-)

Enigmail OpenPGP

2005-12-08T00:10:00.002+08:00

自從下定決心開始要來使用 OpenPGP 後，我花了幾乎一整個下午在處理 Thunderbird Enigmail。

當然，我不會錯過用 urpmi 工具來輕鬆安裝 enigmail，只要敲入 urpmi enigmail，相關套件就裝好了。只不過，重新啟動 Thunderbird 後，Enigmail 並不能正確的運作。幾乎所有 Enigmail 相關的功能，全數不能使用。

然後就不斷的從 google 裡找答案，試了好幾次的移除(rpm -e) 和安裝(urpmi)。即使，試著直接從 Enigmail 的網站 http://enigmail.mozdev.org下載，最後安裝還是失敗。

也許是 mozilla-thunderbird-1.0.2-5.1.102mdk 版本太舊? 好吧，我決定從 Thunderbird網站直接下載升級 Thunderbird。不用 RPM 套件了！

將下載回來的 thunderbird-1.0.7.tar.gz 解壓到 /usr/lib
# tar zxf /tmp/thunderbird-1.0.7.tar.gz
# mv thunderbird/ /usr/lib/mozilla-thunderbird-1.0.7
再編輯 /usr/bin/mozilla-thunderbir，將其中 moz_libdir=/usr/lib/mozilla-thunderbird-1.0.2 字串改為
moz_libdir=/usr/lib/mozilla-thunderbird-1.0.7

然後下載 Enigmail-0.93.0後，執行 Thunderbird。
再從 Thunderbird 裡的 Tools->Extensions 裡安裝 enigmail-0.93.0-tb10-linux.xpi。
最後，重新執行 Thunderbird。

太讚了，OpenPGP Key Management 可以用了。看來一切應該都正常可以用了。酷吧！

加密式檔案系統

2005-12-05T23:19:00.002+08:00

自從前兩天可愛小硬碟入手後，我將它放入 USB Mobie Disk，不久，就發現一件悲慘的事情。

我的 USB Mobie Disk 不愛穿衣服！

一但我將 USB Mobie Disk 的上蓋蓋起來，USB 連接線一接上 X31，X31 馬上發瘋似地重開機，履試不爽。現在，只好讓它脫了上蓋，給它一個清涼，但外觀看起來就是沒這麼漂亮有質感啊！

好吧，不愛穿衣服就算了。我又想到萬一某天，這顆備份資料用的小硬碟，不小心遺失了的話，我可不希望裡頭一些私密資料讓人看光光。於是乎，我就想試試 Linux 的加密式檔案系統。

只不過，試了半天才發現，我現在用的 Linux 系統(MDK LE 2005)並不支援 AES Multi Key (V2=64 keys / V3=65 keys)。所以，底下的步驟是建立一個 10G 的加密式檔案系統，並利用 AES 128 加密。

1. 建立一個約 10G 的大型檔案，檔案內容塞滿亂數資料

# dd if=/dev/urandom of=mystuff bs=1M count=10000

2. 產生單一 AES Single Key 並用 GPG 加密起來
# head -c 2925 /dev/urandom | uuencode -m - | head -n 66 | tail -n 1 | gpg --symmetric -a > /etc/fskey.gpg

3. 將 mystuff 檔案利用 aes-128 加密並掛上 /dev/loop0
# losetup -e aes-128 -K /etc/fskey.gpg /dev/loop0 mystuff

4. 格式化
# mkfs.ext3 /dev/loop0
# tune2fs -m0 /dev/loop0

5. 將 aes-128 加密的檔案系統掛載上 /mnt/crypto
# mkdir /mnt/crypto
# mount -t ext3 /dev/loop0 /mnt/crypto
# df-h
Filesystem 容量已用可用已用% 掛載點
/dev/loop0 9.7G 33M 9.6G 1% /mnt/crypto

如果你有些敏感資料或很隱私的內容，需要以加密的方式儲存時，Linux 的加密式檔案系統將是一個不錯的選擇。

參考資料：
1. Cryptoloop-HOWTO
2. loop-AES.README

可愛小硬碟

2005-12-04T01:19:00.002+08:00

下午跑去 NOVA 買了顆 2.5 吋 WD800UE 小硬碟，它的外觀如下：

據說 WD Scorpio?技術還不錯，夠安靜。

當然，回到家就馬上接上 X31，底下是 Linux 偵測到的硬體資訊：

USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
Vendor: WDC WD80 Model: 0UE-00HCT0 Rev: 09.0
Type: Direct-Access ANSI SCSI revision: 00
usb-storage: device scan complete
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: assuming drive cache: write through

接著用 fdisk /dev/sda 作切割：

Command (m for help): p

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 9729 78148161 83 Linux

再用 mkfs.ext3 -c -j /dev/sda 作檢查並格式化，最後用 tune2fs -m 0 將保留空間釋放。
# mount /dev/sda1 /mnt/tmp/
# df -h /dev/sda1
Filesystem 容量已用可用已用% 掛載點
/dev/sda1 74G 33M 74G 1% /mnt/tmp

來測測看速度吧！X31 裡硬碟的速度：
# hhdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 74 MB in 3.00 seconds = 24.66 MB/sec
而新入手的 WD 小硬碟呢
# dparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 60 MB in 3.05 seconds = 19.64 MB/sec

嗯，慢了一點，不過還是適合我用來備份資料 :)

駭客大騙局

2005-11-24T02:49:00.002+08:00

The Art of Deception: Controlling the Human Element of Security

本書作者是駭客界鼎鼎大名的 Kevin David Mitnick。當年他被拘捕後，駭客界成立了 Free Kevin 網站要求美國政府將他釋放。 2003 年，Kevin 出獄，目前成立了一家資訊安全公司。

駭客大騙局這本書都是在描述社交工程(Social engineering)。作者虛構了許多小故事，其中內容宛如電影情節般，利用假冒的身份和高段的談話技巧等，入侵企業設施，竊取商業機密。作者也進一步描述如何預防社交工程的攻擊，以及提供一些忠告。

我不禁會想到，台灣治安最頭大的詐騙集團也是操作社交工程技倆的佼佼者啊。如果人人都學了社交工程，也許我們善良百姓還能以反社交工程回敬對方呢。

當然，如果有人利用巧克力攻擊法，我也會跟著乖乖交出密碼的啦。

製作長生不死藥

2005-11-21T08:32:00.002+08:00

剛看完成龍的電影 - 神話
我可能比較冷血一點，體會不出劇中的痴情浪漫，倒是對麗山瀑布後的秦陵巧思，以及女主角金善喜小姐的楚楚之美，覺得印象十分深刻。
不過，我卻對長生不死藥的研發，心裡啟了疑竇。
假若我在古代要研究長生不死藥，要怎麼證明藥的效用? 或是秦始皇要如何證明藥是有效的呢? 研發長生不死藥的人，總要人體實驗後才能知道效果，才知道有無副作用。但研發的人如果活得不夠久，根本就研發不出來啊。

下面這段文字節錄於凡事大前未有樣者，不易做，剛好和電影神話裡的劇情有關。

公元前212年，發生了歷史上有名的坑儒事件。坑儒是由方士求神仙不得引起的。俗話說得好，人的欲望是無止境的，當了皇帝就想長生不死，秦始皇就是這樣。當時有兩個方術之士侯生和盧生，投其所好，答應給秦始皇找長生不死藥，但他們到哪裡去弄呢？很快就到了交差的時間。沒辦法，他們隻好散布說秦始皇剛愎自用，貪於權勢，所以求不到仙藥，並且逃走了。秦始皇知道后非常惱火，下令御史追查此事。在追捕中牽涉了460多人，除方士之外還有一批對秦始皇心懷不滿的儒生。秦始皇盛怒之下，將這些人全部坑殺。第二年，東郡（今河南濮陽）落下一塊大隕石，有人偷偷在石頭上刻了?始皇帝死而地分?七個字。秦始皇還是派御史去調查，因找不到刻字的人，結果將居住在隕石周圍的百姓全部殺光。

古代的歷史或神話故事，都反映了中國人對長生不死的執著，人們除了希望長生不死，還希望青春健康。
萬一將來真有那麼一天，順了人們長生不死的願，身份證上還得寫上萬歲萬歲萬萬歲呢。

奇怪的 Zyxel P-330W

2005-11-21T04:20:00.001+08:00

今天到燦坤買了台 Zyxel P-330W 無線寬頻分享器，外表看來還蠻可愛的，會員價不到兩千元，還送 7-11 的 iCash 卡。

沒想到，買回去接到網路上，PPPoE 撥接竟然屢次失敗 :(
不甘心，連到 Zyxel 網站上，竟然找不到 P-330W 型號，也沒有 firmware 好下載. 好不容易從 google 問到一個官方 firmware 卻是奇怪的 V1.4 版本。
沒辦法，死馬當活馬醫，把下載回的奇怪 V1.4 版本上傳更新後，那隻可愛的 P-330W 管理介面變成了英文版，重點是，PPPoE 撥接還是不行。

怒了後，只好跑回燦坤，燦坤的維修工程師沒有環境可以測試 PPPoE 撥接，最後加了幾百塊換了 D-Link DI-524 Wireless Router。

結果呢? DI-524 設定完 PPPoE 撥接帳號密碼，就馬上連上 Internet 了啊。
突然想到，奇怪的 P-330W 只讓我輸入帳號、密碼，不像 DI-524 還會要求再輸入密碼確認。
雖然我對 D-Link 也沒啥好感，不過還真的比較好用，而那個 Zyxel 會不會也太扯了點，
Zyxel P-330W 還是用 Embedded Linux 作的哩。