TWNIC DDNS 管理通訊協定密碼傳輸沒加密！

財團法人台灣網路資訊中心（TWNIC）^參考1 十餘年前自行研發了一套 DDNS 系統^參考2 ，並免費提供多種平台上的 client 軟體讓網域名管理者使用^參考3。此套軟體使用了自訂的明文通訊協定，並透過 UDP port 1053 及 port 1055 與 TWNIC server 進行溝通。若使用網路監聽軟體針對該 UDP port 進行記錄，可輕易在 DDNS client 軟體啟動時捕捉到與伺服器認證的通訊內容。

上圖為認證過程當中的其中一個 UDP 封包，highlight 起來的部分為 payload。重新整理過後，不難看出其資料格式使用純文字編碼：

101 150 1041 6.1 debut.tw 52gCh<kAl5hDg8g=k>g>

觀察這一段純文字封包內容後，可大膽假設是在針對 debug.tw 域名進行認證。如果事實真是如此，則封包最後的奇怪字串 52gCh<kAl5hDg8g=k>g> 將非常有可能是編碼或加密過的密碼。根據這個假設繼續演繹下去，我們能判斷這種認證的通訊協定與架構設計將產生高度危險，因為

1. 該通訊協定本身（至少在認證的階段）並未加密，許多人可輕易側錄封包內容。雖然密碼的部分有經過編碼或加密，往後若其演算法被研究出來，則可對側錄得到的資料直接解密或暴力破解。
2. 就算無法解開密碼原文，仍然可能可以使用 replay 攻擊^參考4。

事實上，我能證明前述的假設是正確的──這個奇怪的字串是一個使用兩位數字（且第一位不為 0）當做 salt 進行加密後的結果。更慘的是，這個加密演算法除了正向運算極其簡單之外，更是可逆的！做為可逆運算的 PoC 程式請參考 https://github.com/mifanbang/twnic_ddns_pwd。

最後讓我引用又帥又親切的 Allen Own 大大的定義，來為這篇文章做下結論：「TWNIC DDNS 管理通訊協定」密碼沒加密！

只要是駭客可以輕易取得、還原的密碼，都視同沒有加密。^參考5

後記

最早會注意到 TWNIC DDNS client 的原因是它有 GDI handle leak 的問題，平均每周需要手動重新執行一次。原本的打算是針對它所使用的通訊協定進行逆向工程，並自己重新寫一支跨平台的 client。通訊協定逆向工程完成後，發現了它安全上的致命缺陷，遂決定徹底放棄使用 TWNIC DDNS 而改租 VPS 。

Edits:
2017.12.11 - 更新 proof-of-concept 連結

Reference

1: Wikipedia. "台灣網路資訊中心" https://goo.gl/2U1dxh

2: TWNIC技術組. 2002."動態DNS使用技術介紹(一)" http://www.myhome.net.tw/2002_12/articl/articl_0101.htm

3: TWNIC. "動態DNS說明" https://rs.twnic.net.tw/dyndn_intro.html

4: Wikipedia. "Replay attack." http://en.wikipedia.org/wiki/Replay_attack

5: Allen Own. 2013. "什麼是「加密」？什麼是「沒加密」？" http://plainpass.com/2013/10/to-encrypt-or-not-to-encrypt.html