📜 [專欄新文章] Private key security and protection / 私錀的安全與保護 — Tim Hsu
✍️ 洪偉捷
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Private key security and protection / 私錀的安全與保護 — Tim Hsu

Crosslink Taipei 在10/19、10/20 台北矽谷會議中心舉辦的 區塊鏈conf。 這是Crosslink Taipei 下午的演講，主講者是擔任CYBAVO CTO的徐千洋(Tim Hsu)先生，同時也是幣托、OTCBTC的資安顧問。

2018年一月被發現的硬體漏洞meldown跟spectr，我們的硬體為了要讓執行速度更快，processor會預先執行某些指令，也因此駭客可以透過這種方式，間接檢測出我們記憶體的內容，把敏感資訊都dump出來。雖然後這之後各CPU廠商都有推出針對這個bug的軟體update，但是在這之後硬體安全的問題逐漸浮出來面，也使世人意識到硬體資安的問題。而今天我們要談的部分不僅有軟體安全，也有硬體安全跟使用者資安觀念的問題。

淺談交易所與錢包

在從交易所提幣的時候，首先Server會先將這筆交易紀錄到交易所自己的資料庫內，之後再取得交易所金庫的private key去金庫取錢，再打到使用者的錢包內。在這個過程中，如果駭客可以竄改Server或資料庫的交易金額，原本要打給使用者1 BTC，變成10BTC，或是直接取得金庫的private key，對交易所都是一大噩夢

圖(一) 從交易所提幣的流程

攻擊手法

1. 交易所的網路架構

案例一: 交易所因為怕被偷交易資料與客戶資料，所以都把這些資訊先加密後再存到資料庫，但是這些資料仍然會被偷(交易所遭到電話詐騙)，往後將這些資料加了三層密，仍無法防範資料被偷的情形，原因出在圖(二)的交易所網路架構。

圖(二) 交易所的網路架構(OA與資料庫間沒防火牆)

因為OA 與資料庫之間的網路沒有防火牆保護，所以駭客不用正面攻擊有防火牆的部分，而是攻擊OA的部分，再藉由OA連線到資料庫。一封藏有病毒的email求職信寄到HR的電腦，都有可能造成交易所資料外流。

解決方式: 就是在OA與資料庫間架個防火牆，如圖(三)所示。例如: 只有Engineer、RD 可以連線到資料庫，QA則只能連到測試環境，HR、CEO不需要、也不能連線到資料庫，依職責對連線範圍做縮限，則駭客可以攻擊的目標變少，我們也比較好做應對。講者重要的一句話: 「千萬不要輕忽駭客攻擊OA的能力」

圖(三) 好的交易所的網路架構

2. DNS Attack

透過汙染AWS 的DNS Server 將交易所網頁導向駭客的網頁，來騙取使用者個資。雖然在導向駭客頁面時，很容易發現駭客的網頁沒有使用安全憑證，或是安全憑證不是SSL核發，但使用者仍可能因資安觀念低落，而堅持連線到不安全的網站。

3. Online Paper Wallet

很多人因為覺得私鑰放電腦覺得不安全，又沒錢買硬體錢包，所以透過線上私鑰轉換器將私鑰轉換成QR code，然而再轉換時勢必要輸入自己的私鑰，容易使私鑰遭竊。

圖(四) 私鑰轉換詐騙網頁

4. 使用者對私鑰保護的意識很低

例如: 不了解私鑰的註記詞或其他相關資訊保密的重要性，而無意間通過社交軟體洩漏了這些重要資訊(硬體錢包開箱文 XD)。

5. 硬體錢包的漏洞

TREZOR 錢包是業內公認的研發最早最警慎最安全的加密儲存器，但是今年仍被發現硬體相關的漏洞。只要駭客輸入特定24碼pin碼，就可以通過硬體的側通道分析，輕易提取出未加密的私鑰，而且這個必須重新設計硬體架構才能夠防止這樣的攻擊。所以即便硬體錢包掉了，仍有被攻擊的疑慮，最好的解決辦法就是硬體錢包外再設定一個long Password，這樣就可以避免掉硬體錢包時帳戶虛擬貨幣遭竊

圖(五) 硬體錢包漏洞

題外話 — Iphone Jailbreak問題

今年在twitter，有人公布了最新攻擊iphone的方式，而問題出在手機晶片。Iphone開機時第一個執行的程序是 bootrom，而bootrom的程式碼則是位於記憶體唯獨區域，所以無法竄改。駭客可以利用bootrom上的bug來攻擊手機，而這些有問題的晶片出現在Iphone 6 ~ Iphone X。其實這攻擊方式充滿限制，不僅要取得欲攻擊的手機，而且這種攻擊方式每次重開機就會刷新。不過這也衍伸出新的問題，以後的iOS作業系統都更容易遭到入侵，因為我們可以在舊的手機上裝新的iOS系統，然後透過bootrom的漏洞來了解新的iOS系統的運作方式，因此這個問題應該被更加重視。

圖(六) axi0mX針對此bug的文章

保護方式

透過secure sharing將私鑰拆成User、Company、Vendor，分散私鑰存放風險

圖(七) 拆散私鑰，分散存放的風險

保護思維

未來除了在演算法的鑽研，也應該多多關注整個 區塊鏈產業的資安問題，從身分認證、系統安全、IT架構，都應該要從安全的角度來設計。

圖(八) 講者參考的設計架構

以上方的圖片為例，很多軟體架構在設計時都忽略了作業系統這一塊，而講者分享了他在設計時針對Server或資料庫的 OS做的處理，如下圖

圖(九) OS層級的安全防護

我們的app、網站、服務都跑在Sandbox層上，Sandbox可以限制由內到外的網路封包收送，同時在Sandbox之上還有Host-IDS(Host-based Intruction Detection System)會記錄及過濾程式在Sandbox跑的所有指令，而且有任何非法存取記憶體或網路封包的行為都會都過Host-IDS被記錄到Threat Intelligence，並且通知使用者。 我覺得這樣的好處是，使用者不僅可以在第一時間知道自己的帳號遭到駭客攻擊，也因為一切的動作都被Host-IDS過濾以及被記錄到Threat Intelligence，工程師也可以更快找到安全漏洞。

結語

近年來因網路的應用，資安越來越重要，除了軟體方面外，硬體方面也要兼顧安全，而使用者的觀念宣導更重要，否則不管我們的系統做的再怎麼嚴密，只要使用者意外連到駭客網站或是洩漏自己的私鑰，一切都是白談。演講中有一句話我覺得很值得借鏡，就是「我們一定要假設我們的系統會被駭客破解，而我們要做的就是盡可能減少被入侵後的損失」，上面提到的Host-IDS就是這樣的觀念，我們無法防止駭客進到Sandbox，但是可以記錄駭客的進到Sandbox後所有行為，這樣的架構才能在第一時間修正系統漏洞。

參考資料

Trezor錢包漏洞: https://bcsec.org/index/detail/id/585/tag/2

Iphone 漏洞: https://www.pcmarket.com.hk/2019/09/30/iphone-bootrom%E8%B6%8A%E7%8D%84%E5%B7%A5%E5%85%B7%E5%85%AC%E9%96%8B-4s%E8%87%B3x%E5%85%A8%E9%81%AD%E6%AE%83%E5%B9%B8%E5%8D%B1%E9%9A%AA%E6%80%A7%E4%BD%8E/

spectre&meldown介紹: https://www.youtube.com/watch?v=bs0xswK0eZk

Private key security and protection / 私錀的安全與保護 — Tim Hsu was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

網路安全專家劉俊雄先前曾經接受iThome的專訪，
分享他對於DDoS攻擊的觀察。
囿限於媒體篇幅和屬性，
劉俊雄趁著夜深人靜之際，
把他對於DDoS攻擊的觀察有更深入的分享！！
關注DDoS攻擊所有的資安與IT人員，
都不要錯過這一篇動人的分享！！

感謝奧天大大不藏私的經驗分享～～

[淺談 DDoS 攻擊]
　
　
幾個月前受訪談了些 DDoS 的話題，沒想到最近一連串爆發了這麼多事件，也讓個人淺見出現在幾篇 iThome 的報導
　
http://www.ithome.com.tw/news/109932
http://www.ithome.com.tw/news/110135
http://www.ithome.com.tw/news/110144
http://www.ithome.com.tw/news/110137
http://www.ithome.com.tw/news/111861
　
因訪談限制及媒體屬性，無法很完整的表達我的看法，趁著夜深人靜時整理一下 ：
　
DDoS 大略可分為三個層級 - 網路層、系統層、應用層，
　
網路層為癱瘓目標頻寬，典型手法為 UDP/ICMP Flood、以及近年流行的各種 Reflection&Ampplification 洪水攻擊；
系統層為癱瘓目標的基礎建設或系統層，典型手法為 SYN Flood、Fragment Packet Flood、Connection Flood 等；
應用層為癱瘓目標的應用服務，典型手法為 SSL Flood、HTTP Flood、DNS Flood、Exploit、Slow Attack 等。
　
十多年前個人剛接觸 DDoS 的時候，盛行的是「細巧」的系統層/應用層攻擊，但近幾年因許多協定的 反射&放大 手法被開發、以及 IoT Botnet 的盛行，應該會有一段時間轉為 「爆量」 的網路層攻擊。
　
以開店作生意比喻 - 將店門口及前方道路視為網路出入口及上游，店裡設施和走道空間視為基礎建設，結帳櫃檯視為應用系統。則攻擊者可以堵住店門和馬路、可以塞爆店裡的走道和空間、又或者癱瘓結帳櫃檯。
　
而 DDoS 為何難防 ?
這與企業為何很難阻止駭客入侵的原因一樣，攻擊方與防守方處於不對等的立場，攻擊者有太多的方式可選擇，且可不斷的調整與嚐試，防守方卻礙於人力與預算限制，難以全天候對每一種手法都有良好的對應措施。
　
許多老闆總認為花錢買設備就可以了事，但偏偏這不是單一設備、單一解決方式可以完全處理的，應該沒有一家的服務或設備直接上架，完全不需調校就可以完美對應每一種攻擊手法，需要有經驗豐富的專業人士視實際攻擊狀況調校參數及規則。有如同一把大刀，在關公和小孩手上耍起來實有天壤之別啊！
　
以本次券商 DDoS 事件來說，由媒體報導看起來是屬於 [網路層] 的攻擊方式，但即使加大頻寬、或由ISP端阻擋住了，難保哪天不會出現針對系統層或應用層等更為精細、打得更為巧妙的手法，加上金融業幾乎全用 SSL 加密應用服務，會使中間的清洗商更難介入分析應用層攻擊（除非提交 SSL 金鑰）。
　
至於實務上應該要怎麼阻擋會比較理想？
　
我的看法是需 雲端清洗+本地防護，量大的攻擊由雲端或上游清洗處理，而細巧的攻擊可能穿過清洗中心，則由本地的防護機制處理，但絕對不會是由 "防火牆" 這萬年設備，至於用什麼設備可達到較好的阻擋效果請洽各大 SI。
　
另外若預算許可下，還可建立多個資料中心或介接多條 ISP 線路，配合 GSLB 機制快速切換 DNS ，讓攻擊者難以鎖定每一個出入口，可增加攻擊難度及應變時間。
　
另外真的遭遇 DDoS 攻擊時，個人的簡易 SOP 大概如下 -
1. 快速診斷，描述症狀由專業人士判斷（有側錄封包更佳）
2. 對症下藥
　　- 洪水攻擊 : 請求 ISP/清洗商 協助、Black Hole、更換 IP / Multi ISP / GSLB
　　- 系統層攻擊 : 更換撐不住的設備、關閉負載高的功能、調整系統參數延緩攻擊影響
　　- 應用層攻擊 : 增加服務能量、減少異常存取
3. 減少異常存取的方法：辨識特徵 + 過濾
　　- 網路層特徵 (IP/PORT/ID/TTL/SEQ/ACK/Window/...)
　　- 應用層特徵 (SSL/URL/Parameter/User-Agent/Referer/Cookie/Language/...)
4. 如果打到沒有特徵可過濾，則需靠應用層的機制來辨識真實使用者
　　- Redirection
　　- Challenge
　　- Authentication
5. 若無上述功能則儘快商調適合的設備。
　
　
以上是個人的看法，但我已經很多年沒直接處理 DDoS 的事件，也非任職於 ISP 方或 DDoS 防護服務廠商，只是單純的以技術角度分享，如有錯漏之處也請業界真正的高手不吝指教。
　
　
題外話，最近 DDoS 正夯，服務商們可仿效已有許多資安業者提供的 IR Retainer 服務，推出 DDoS Retainer，也許是不錯的商機 XD
　
　
　
[以上轉載請註明出處]