RUN!PC


	最新活動訊息
	雜誌目錄
	程式碼下載
	I T 基測
	訂閱雜誌
	出刊/補寄時間
	雜誌期數速查表
	聯絡我們
	召兵買馬
	關於RUN!PC雜誌


	VoIP攻擊實作 SIP網路電話安全攻擊分析與探討文／劉作仁、沈志昌．責任編輯／陳啟川本文將目前在SIP通訊協定上弱點。以攻擊方式分為三類，接下來將針對各種類型的攻擊手法進行詳細的說明，輔以工具進行實際的攻擊示範，讓讀者對於各種攻擊手法有更深入的了解。
	隨著現今電腦處理速度以及網路頻寬的大幅增加，許多技術也漸漸開始轉換到網際網路的平台上，期許透過新的平台來為新的系統帶來更好的效率以及更少的花費。以往的電信網路中，都是採用傳統的PSTN架構來進行通話，不過PSTN其電路交換的特性，必須透過電信局所建置的實體線路進行語音資料的傳輸，因此每個月都必須繳交一筆不小的金額給電信局，對於錙銖必較企業來說，能省下不必要開銷就會有最大貢獻；對於跨國企業來說，通訊話費的節省早被列為首要解決問題。企業為了減少支出，尋求最大的利潤下，許多企業便開始尋找新的節費方案，希望能夠盡可能減少企業的額外支出。然而，在眾多的節費方案中，最受注目的便是「網路電話 (Voice over IP, VoIP)」。企業發現網路電話所帶來的方便性以及其通話費用較低廉的特性，便紛紛逐漸將企業內部原有的電話網路轉換成網路電話的形式。不過，企業在導入網路電話系統的同時，往往都忘了考量到其安全性的部份。網路電話所採用的協定以Session Initial Protocol (SIP)為大宗，SIP是基於Internet 所設計出來的協定，因此發現在Internet上的攻擊也可能會發生在SIP上，然而企業內部的資訊人員在建置系統的同時卻忽略了這點；再加上有許多企業甚至是研究單位為了貪圖一時之便，大多是採用網路上Open Source的軟體來建置自有的網路電話系統，由於Open Source軟體的開發品質不一，也隱藏了不少安全性的威脅。本文將透過案例的方式說明，在網路電話系統上能會發生的攻擊行為，並針對這些攻擊提出建議的預防方案。本文將目前在SIP通訊協定上弱點。以攻擊方式分為三類，接下來將針對各種類型的攻擊手法進行詳細的說明，輔以工具進行實際的攻擊示範，讓讀者對於各種攻擊手法有更深入的了解。圖1為本文在進行所有攻擊示範所使用的環境。圖1：系統架構。黑心招數一：Flooding Attack(團結力量大) Flooding Attack通常又稱作阻斷服務式攻擊(Denial of Service Attack, DoS Attack)，是目前在Internet上經常發生的攻擊類型之一。攻擊者透過本機電腦發送大量的封包至Server 端，讓Server端疲於處理攻擊者所發出的封包，造成整個系統處於停擺的狀況下，便無法提供正常的服務給其他合法的使用者。除了傳統的TCP/UDP協定可以用於進行 Flooding Attack之外，攻擊者也可以透過 SIP協定發送Flooding Attack。目前在SIP協定上較常發生的Flooding Attack大多是透過發送大量的請求封包(Request)。這些請求封包大多是使用REGISTER和INVITE這兩種訊息，由於這兩個訊息都會連接到Server後端的資料庫進行資料的存取，因此較其他訊息花費Server端較多的運算時間，若同時有過多的 REGISTER和INVITE訊息要進行處理時，便會耗盡Server端所有的運算資源而無法提供正常的服務。 INVITE Flooder攻擊實作下面的範例即是透過現有工具實作在SIP 協定是如何進行這類型的壞招數；筆者是使用 Hacking Exposed VoIP中所提供INVITE Flooder進行示範。首先必須先編譯此程式，當然在此我們已經編譯完成了。那麼該用多少能量攻打對方呢？如圖2所示，我們使用5萬個INVITE封包到Server端進行Flooding Attack，不過需注意的是本次攻擊所針對的使用者是不存在於本系統中，只是一個虛擬的帳號而已。圖2：針對虛擬的帳號進行Flooding Attack。 Server與Client端的反應情況在程式持續發送攻擊封包的同時，我們同時在Server端上擷取封包進行觀察發現Server端收到了數量相當龐大的INVITE封包，而這些封包都是從攻擊端傳送過來的。由於本次目標的使用者實際上並不存在，Server端並不會實際地將這些封包轉送到其他使用者，因此受到影響的就只有Server端（當然囉，不存在的帳戶攻擊等於是在打空氣）。接下來就是正式上陣了，這次將目標使用者設為一個正在使用網路電話的使用者victim_1，那麼這次的攻擊對於 Server端以及victim_1又會有什麼影響呢？圖3：在使用者victim_1的電腦中所擷取到的攻擊封包以及軟體電話的反應。從圖3很明顯地知道，使用者victim_1的軟體電話收到了一堆INVITE訊息，軟體電話一直不斷地在響玲（要怎樣停掉？關掉是最好辦法了），但是victim_1的軟體電話無法在短時間處理如此大量的INVITE訊息，因此許多電話都變成了未接電話，所以在通話紀錄的未接電話中，滿滿的盡是剛剛由攻擊端所發送出來的INVITE攻擊封包。現在僅僅是傳送五個萬封包就對於Server端以及使用者帶來不小的影響，若現在攻擊端同時發出上百萬甚至是上千萬的封包時，勢必會攤瘓整個網路電話系統。從以上的示範可以得知，攻擊端只要透過一隻小程式就可以發送大量的封包到Server 端，若有其他合法的使用者此時想要使用的網路電話服務時便會發現無法順利登入，因為此時Server端已經沒有多餘的運算資源可以處理其他使用者的封包了。黑心招數二：SIP Parser Attack(改頭換面，手忙腳亂) 在網路電話的環境中，通話雙方要實際進行通話之前，必須先利用SIP協定去建立通話連線。SIP透過類似HTTP般三方交握(Threeway hand shake)的步驟，使得Server端和 Client端可以在封包交換的過程中交換資料。在雙方進行封包交換的過程中，Server端和 Client端都會從封包中的表頭去擷取所需要的資料。除此之外，存放在表頭中的資料都是以明文的方式儲存，如程式設計師在開發軟體的同時，並未對表頭內的資料進行驗證，若此時攻擊者在表頭中故意放入錯誤的資料，甚至是加上了惡意的程式碼的同時，輕微的話只影響到該次雙方的通話，嚴重的話則將對整個系統造成破壞。變形封包測試下面的範例將示範，該如何利用程式設計師在開發軟體時的疏忽，使用惡意格式的封包進行攻擊：筆者在此會使用一套由芬蘭Oulu 大學的Secure Programming Group (OUSPG)團隊所開發專門針對SIP進行測試的用的工具 (http:// http://www.ee.oulu.fi/ research/ouspg/protos/testing/c07/sip/)，該工具中裡面包含了許多已經將表頭資料修改過的封包，透過這些變形後的封包來對一般大眾所使用的話機進行各種不同的檢測，透過檢測的結果可以知道該話機是否會因為這些非合法的表頭資料而造成無法運作的現象。在本範例中，筆者使用一台在坊間便可以購買到的硬體話機進行測試，基於某些理由，我們不便公開此硬體話機的廠牌。接下來我們同樣從Attacker端進行檢測，我們發現當進行完第8個測試個案的時候，我們的硬體話機便發出惱人的叫聲，我們從victim_1撥電話給 victim_2時也一直停在Calling的狀態，正如圖4的所示，一點反應都沒有。沒辦法，我們能做的就只有拔掉電源了。圖4：victim_1撥電話至victim_2時，遲遲沒有回應。進行SIP Method欄位測試我們到PROTOS的網站中去查詢得知第8 個測試檔案是針對SIP封包初始行(First Line) 中的SIP Method這個欄位進行測試。在這個測試檔案中所使用的Method是長度為255的 a。而我們用的這台硬體電話沒有辦法對於這個Method進行分析，導致整台話機無法正常運作，於是就發出惱人的哀嚎聲。圖5：PROTOS中第8個測案檔案的內容。黑心招數三：SIP Application-Level Attack(利用程式開發漏洞，防不勝防) 此類型的壞招數，會有不少的變形，原因在於儘管在RFC 3261中完整地規範了SIP整體的運作流程，但是有些枝微末節的部份是在其中並沒有加以詳細規定的。當程式設計師實際上根據此規範在進行開發的同時，往往卻也不會去注意到這些細節。而這些在一般人眼裡看似平淡無奇的東西，在功力高深的攻擊者眼中卻是一大肥肉，若程式設計師在開發時並沒有注意到這些細節，很容易就變成攻擊者所使用的漏洞，進一步造成企業莫大的損失。有鑑於此，我們將在此段中介紹攻擊者是否如何利用這些看似不起眼的細節發起攻擊，進一步迫使整個系統無法提供正常的服務給合法的使用者。手段一：BYE Attack(我切我切我切切切) 第一種手段的原理在於當通話雙方要結束通話的時候，會發出一個BYE訊息的封包。當另一方收到對方所發出的BYE訊息之後，便會切斷雙方進行語音傳輸的RTP連線。然而在這當中卻有個相當嚴重的漏洞：在這個 BYE訊息的封包中，並沒有進行使用者身份的驗證，因此只要攻擊者能夠偽造其他表頭欄位的資料，便可以切斷其他人正在進行的通話。如此一來，使用者會經常碰到電話講到一半，通話就莫名奇妙地被中斷了。接下來，我們將以現有的工具進行示範，攻擊者該如何強迫中斷使用者的正常通話連線。在這裡已先在攻擊端的電腦中安裝好 Teardown程式，用以示範BYE attack該如何進行。圖6：發送BYE訊息到通話雙方的其中一方。圖7：在victim_1所擷取到的封包內容。現在已經有victim_1以及victim_2正在進行通話，此時攻擊者已經透過其他工具取得了雙方通話時所使用的Call-ID、FromTag、ToTag之後，攻擊端便可以偽裝為其中一人向對方發出BYE的訊息，強制中止雙方的通話。為了證實雙方通話結束是由第三方所發起的，我們在victim_1的電腦上面擷取封包，藉由觀察封包的來源位址來證明是由攻擊者中斷本次通話的。從圖7中得知，雙方通話一開始是由victim_ 1所發起，透過Server端轉傳到我們的受話方 victim_2。此時眼尖的讀者應該發現下面的BYE訊息是由攻擊端發送給Server端，而 Server也轉傳了這個BYE訊息，另一方接到之後便中斷了彼此之間的連線了。這就是由於 Server端並沒有針對BYE訊息進行使用者認證，因此攻擊者只要知道通話雙方的Call-ID、 From Tag、To Tag，便可切斷雙方的通話。手段二：Registration Removal(移花接木) 認證機制是否也會淪為攻擊對象？手段二將示範此方式，為了避免公司內部所建置的網路電話系統被不肖人士所濫用，因此系統管理者都會建立認證的機制，系統管理者可以透過此機制對於權限進行管理，也可以藉由Log紀錄得知每位使用者在什麼時候撥打電話給誰，對於日後的異常行為也比較方便進行追蹤。在RFC 3261中有明確定義使用者可以透過REGISTER訊息進行註冊以及反註冊，攻擊者只要多花點時間去研究一下封包的內容，便可以很輕易地反註冊原先已註冊的使用者，卻不被該名使用者所發現。由於該使用者已經被反註冊了，攻擊者只要趁機再用該名使用者的帳號登入，所有原本應該撥到該名使用者的電話都會全部被轉接到攻擊者的電話。當然，我們也會針對如此簡單且有效的攻擊進行示範攻擊者是如何利用工具將原先已註冊的使用者反註冊。圖8：攻擊端發起Registration Removal 攻擊。圖9：Server端受到Registration Removal攻擊，已經找不到victim_2的資料。我們在此做了個實驗，victim_1先撥了電話給victim_2，以確保victim_2還在線上。此時，我們使用erase_registration工具，將victim_ 2的紀錄從Server端上給刪除。此時，victim _1 又撥了通電話給 victim_2，但是由於攻擊者已經將victim_2的資料從主機端上刪除了，因此此時victim_1 所得到的訊息只會是404 Not Found，代表使用者不在線上，如圖9所示。此時就代表了攻擊端已經將victim_2的資料從Server端給刪除了，因此當Server端要轉送victim_1所發送出來的INVITE時會發現 victim_2不在線上，便回傳404 Not Found 訊息給vitcim_1。 VoIP的安全防護建議看了上述的各種黑心招數，你還覺得VoIP系統很安全嗎？不可諱言的，便利仍是企業在使用技術上會先討論的部分，但隨著VoIP技術的普及，安全問題已經不能如往常一般忽略，畢竟系統損失或是停擺，立即衝擊的就是業務問題，實在不可輕忽。為此，針對上述這些問題，本文也提出一些建議，讓讀者參考，期望能夠對於系統管理者在未來管理VoIP系統的安全性能夠有所幫助。如日後真的遇到真正的攻擊時，系統管理者便可以透過下列各種機制，以減少這些攻擊對系統所造成的傷害。防護一：使用TCP和TLS協定進行SIP連線在RFC 3261中規定，Server端須同時支援UDP 以及TCP協定。若Server端採用TCP 協定時，使用者端便可以跟Server端建立持續性的TCP連線，加上TCP協定的特性，使用者便可以使用Sequence number等方式，防止使用者誤收由連線外的攻擊者所發送出來的封包。除此之外，系統管理者也可以使用TCP搭配TLS (Transport Layer Security)以提供更高的隱私性以及更強的認證機制，以防止攻擊者在訊號傳送時進行竊聽。不過TLS並非點對點(End-to-End)的協定，因此若要在連線時提供TLS的功能，必須在通話雙方中間所有的設備要能夠支援TLS，若其中任一個設備不支援TLS的話，便無法使用TLS為通話雙方提供更高的安全性。防護二：使用Switch上所提供的DoS防禦機制目前市面上有許多switch有提供DoS偵測以及防禦機制。系統管理者便可以使用這些機制去偵測DoS Attack，更進一步防止這些封包送往被攻擊的目標。防護三：啟用認證機制在RFC 3261中規定，Server端必須要能夠支援Digest-based認證機制。在使用者在發送INVITE、REGISTER、OPTION等訊息時，必須先通過認證才能進行下一步的動作。以我們在此做的第二個實驗為例的話，若 Server端若有開啟認證機制的話，由於攻擊者所送出的封包並沒有帶著認證的資訊，那些 INVITE封包就不會被轉傳到使用者victim_1 的網路電話中。防護四：改變Server端預設所使用的Port 5060 目前大多數使用在S I P環境中的P r o x y Server大多使用預設的Port 5060進行連線。我們建議以隱藏式保全(Security Through Obscurity)的觀念，改變Server端所使用的 Port以提供較高安全性的保護。防護五：建置網路電話系統專用的防火牆透過防火牆可以偵測不同類型的攻擊，包括了UDP和上述所示範的INVITE Flooding 攻擊，檢查所有送往Server端的封包內容，可以減少Flooding Attack對於系統所造成的傷害。垃圾語音的問題除了我們在上述所提到的三個黑心招數之外，還有一樣東西是系統管理者可以去率先思考的，那就是垃圾語音(SPAM over Internet Telephony, SPIT)。就像過去電子郵件在剛剛起步的時候，許多不肖的業者或者是駭客都會使用SPAM的方法發送大批的垃圾郵件到使用者的信箱。每當使用者打開自己的信箱時，這些沒有用處的垃圾郵件如雪花般飛進，使用者總是花了許多時間在刪除這些垃圾郵件，有時不小心公司主管或者是公司重要客戶所寄來的mail就被刪除了，換來的可能是公司損失了一個重要的客戶，甚至連自己的工作機會也不保。試想現在將整個情境從電子郵件換成網路電話，從一大早開始工作時候，身邊的電話就一直不斷地響起，但是大多數的電話卻都是廣告商所發送出來的廣告，常常因為疲於接聽這些沒有意義的電話卻漏接了重要的電話，實在是得不償失。為了避免網路電話走上電子郵件的後塵，受到廣告商或者是駭客的濫用，該如何針對SPIT進行有效的防堵也是系統管理者在防範整個網路電話系統的安全性之外不得不注意的地方。若網路電話日後想要取代現有的 PSTN成為新一代電信網路的標準，是網路電話在未來發展過程中相當重要的一環。垃圾語音辨識技術由於網路電話不同於電子郵件，電子郵件可以在Server端先行讀取郵件內容，藉由寄件者、主旨、內容等資訊判斷該郵件是否為垃圾郵件；但是，網路電話是透過語音在交談的，我們並沒有辦法在使用者收到來電時，就針對其內容進行分析。因此在電子郵件上所使用的 SPAM機制在網路電話中並無用武之處，勢必需發展出一套機制可有效地對垃圾語音進行防堵。為此我們研究團隊在網路電話中投注了相當心血，針對此議題有一定程度地研究。研究團隊亦提出了一項機制，每當使用者有來電時，系統會自動將電話接起並發問簡單的問題（如：基本的個數位加法），透過語音辨識的技術來判斷來電者的答案是否正確，藉此得知使用者是機器人或是正常的使用者。除此之外，本機制除了語音辨識技術之外，運作時搭配兩階段黑白名單的方式增加系統在運作時的效率以及阻擋垃圾語音的準確度。本機制在此所使用的兩階段式黑白名單是指在使用者端的話機內部有一份黑白名單，在 Server端有另外一份黑白名單。透過我們所設計的方法，使用者和Server端會定期互相交換所擁有的名單，使得所有使用者以及其他的 Server內的名單一致，進一步地達成全面防堵垃圾語音的作用。網路電話應用被電信產業視為新興的殺手及應用，但在高度便利的優勢下，卻又隱藏了許多目前仍不被列為首要的安全議題。因此，身為公司內部的系統管理者，除了將這些應用導入到公司中，增加公司的競爭力之外，該如何妥善地處理這些應用所帶來的負面的效應，也是系統管理者需注意的地方。在此透過實例示範，希望能夠讓系統管理者對於網路電話系統有可能遭受到的危機，有更進一步的了解。
	【原文刊載於RUN!PC雜誌：2007年十二月號】