《電子技術(shù)應(yīng)用》
您所在的位置:首頁 > 其他 > 業(yè)界動態(tài) > SIP協(xié)議安全分析與解決方法

SIP協(xié)議安全分析與解決方法

2009-01-15
作者:賈 衍1, 徐東升2, 卜 哲

??? 摘? 要: 分析了幾種常見的SIP協(xié)議的安全威脅,,提出了兩種可能性也很大的安全威脅,,在此基礎(chǔ)上從SIP協(xié)議消息交互過程出發(fā),提出了幾種新的解決思路和方法,。?

????關(guān)鍵詞: SIP協(xié)議; 安全

?

1 SIP協(xié)議?

??? 會話初始協(xié)議SIP(Session Initiation Protocol)[1]是由IETF(Internet工程任務(wù)組)提出的IP電話信令協(xié)議,。它是一個應(yīng)用層的控制協(xié)議,,可以用來建立、修改,、終止多媒體會話,。SIP協(xié)議工作于通訊協(xié)議之下,并不依賴于建立的會話類型。?

??? SIP協(xié)議是采用UTF-8字符集進行編碼的文本協(xié)議,。SIP消息分為請求和響應(yīng)兩類,分別由起始行,、一個或多個頭字段、可選的消息體組成,。RFC3261中定義了六種請求方法:邀請對方參與會話(INVITE),、確認信息(ACK)、用于取消會話(CANCEL),、查詢服務(wù)器的能力(OPTIONS),、用于結(jié)束會話(BYE),、發(fā)送注冊請求信息(REGISTER),。同時,RFC3261中還定義了六種應(yīng)答狀態(tài)碼:臨時響應(yīng)(1XX),、成功響應(yīng)(2XX),、重定向響應(yīng)(3XX)、客戶機錯誤(4XX),、服務(wù)器錯誤(5XX),、全局故障(6XX)。?

??? SIP系統(tǒng)包含用戶代理,、重定向服務(wù)器,、注冊服務(wù)器和代理服務(wù)器。用戶代理UA(User Agent)是一個邏輯功能實體,,當產(chǎn)生請求消息時作為用戶代理客戶端(UAC),當接收請求并產(chǎn)生響應(yīng)時作為用戶代理服務(wù)器端(UAS),。?

2 SIP協(xié)議的安全問題?

??? SIP協(xié)議具有易用性、靈活性和擴展性強等特點,,這使得SIP協(xié)議的應(yīng)用越來越廣泛,。但由于SIP一般使用文本方式在IP網(wǎng)絡(luò)上傳輸,并且SIP使用了代理服務(wù)器,、重定向服務(wù)器等中間設(shè)備,,使其消息的完整性、保密性,、可用性和真實性存在安全隱患,。但可以通過研究幾種比較常見的、典型的SIP安全威脅的方式來找到必要的解決方法,,以保證SIP協(xié)議的安全運行,。?

2.1 注冊劫持?

??? 這種安全威脅發(fā)生在SIP的注冊過程中,SIP注冊就是用戶終端向注冊服務(wù)器登記終端用戶在何處可以被訪問,。一方面,,注冊服務(wù)器根據(jù)發(fā)起注冊請求的UA所發(fā)送的注冊消息的From頭字段中的信息來判斷其身份,同時也判定其是否可以修改已經(jīng)注冊的聯(lián)系地址。但是,,由于From頭字段可以被UA任意修改,,這就使惡意注冊成為可能。另一方面,,SIP中允許第三方代表用戶來注冊聯(lián)系信息,,這也為惡意注冊提供了方便。這類威脅存在的根本原因是用戶發(fā)出的注冊請求消息沒有進行必要的加密,,并且用戶也被允許任意修改這些信息,,同時沒有一類安全機制使SIP實體能夠認證請求發(fā)送者的身份。?

2.2 服務(wù)器偽裝?

??? 攻擊者通過偽裝服務(wù)器而達到攻擊的目的,。在SIP消息交互過程中,,請求消息中的Request-URI域詳細說明了該消息發(fā)送的目標域。UA通常直接向域中的服務(wù)器發(fā)出呼叫請求,,呼叫請求再由服務(wù)器向被呼叫者或者下一跳服務(wù)器轉(zhuǎn)發(fā),,這就給攻擊者偽裝成服務(wù)器的機會。當UA的請求被截獲,,泄露會話的關(guān)鍵信息后,,就存在攻擊者假冒服務(wù)器的可能。攻擊者還可以假冒注冊服務(wù)器獲取注冊信息,。為了防止這類服務(wù)器偽裝攻擊,,就需要UA對服務(wù)器的合法身份進行鑒別。?

2.3 消息篡改?

??? SIP UA通過信任的代理來路由呼叫,,雖然UA可以鑒別代理服務(wù)器是否可信,,但是它卻不檢查請求消息實體是否已被篡改。UA通過SIP消息體來傳送媒體會話加密的密鑰時,,惡意的代理就可以改動消息體,,或者作為中間人,或者直接改寫會話加密的安全特性,。防止這類攻擊的手段就是需要保證消息頭和消息體的安全,,這包括私密性、完整性和認證鑒權(quán),。?

2.4 中斷會話?

??? SIP通過BYE請求結(jié)束會話,,攻擊者能夠偽造BYE請求,一旦偽造的BYE請求被接收者收到,,會話就會被提前結(jié)束,。同樣,攻擊者可以通過發(fā)送偽造的re-Invite請求來改變會話,。這類安全威脅出現(xiàn)的原因是攻擊者通過獲取會話的一些初始化信息,,從而得到會話的一些參數(shù)(如To標記,、From標記等)。防止這類安全威脅至少有兩種方法:一是對BYE消息發(fā)起者的身份進行鑒別,;二是保證會話初始化信息的機密性,,使攻擊者無法獲取偽造會話消息的會話參數(shù)。?

2.5 拒絕服務(wù)與服務(wù)放大?

??? 拒絕服務(wù)一般指通過向特定的網(wǎng)絡(luò)接口發(fā)送大量的信息使系統(tǒng)被破壞或暫不可用,。拒絕服務(wù)攻擊的表現(xiàn)是獲得授權(quán)的實體不能獲得對網(wǎng)絡(luò)資源的正常訪問,,或推遲實時操作等。多數(shù)情況下,,SIP系統(tǒng)的重定向服務(wù)器,、注冊服務(wù)器、代理服務(wù)器位于Internet上,,這就為攻擊者發(fā)起拒絕服務(wù)攻擊提供了機會,。SIP設(shè)備除了作為直接被攻擊的對象外,還有可能作為DOS攻擊的幫兇,,起到放大DOS攻擊的作用,。?

??? 上述這些情況需要SIP協(xié)議運行于一個具有良好的安全體系結(jié)構(gòu)網(wǎng)絡(luò),,從而盡可能降低這類拒絕服務(wù)攻擊的安全威脅,。?

2.6 客戶端偽裝(Impersonating a Client)?

??? 通過獲取一個UA發(fā)出INVITE請求消息的From頭字段的方式,攻擊者可以偽裝成被攻擊的UA主動發(fā)起會話建立請求或修改已經(jīng)存在的會話屬性,。這種攻擊一方面可能造成被攻擊的UA與其他UA的會話信息被泄露,,例如,攻擊者可以假冒UserA與UserB進行會話,,攻擊者Attacker只需將自己的From頭字段內(nèi)容修改成為UserA的,,然后向UserB發(fā)起會話請求,SIP服務(wù)器將此請求發(fā)送給UserB,,由于SIP服務(wù)器與UserB都無法鑒別請求發(fā)送者的身份,,所以攻擊者Attacker就假冒UserA與UserB進行會話,其流程如圖1(a)所示,。另一方面這種攻擊也可能中斷或修改已經(jīng)建立的會話,。例如,UserA與UserB已經(jīng)建立了SIP會話,,這時,,攻擊者可以分別假冒UserA與UserB向?qū)Ψ桨l(fā)送BYE請求,這時,,請求接收方UserB與UserA都會誤以為是對方發(fā)送的BYE請求,,會話即被中斷,其流程如圖1(b)所示,。要防止這類攻擊就需要服務(wù)器對UA的合法身份進行鑒別,。

?

?

2.7 破壞會話建立(Breaking up the Connection)

??? 當會話請求INVITE被發(fā)送以后,,可以通過發(fā)送CANCEL請求來取消這個會話。攻擊者可以通過假冒會話發(fā)起方發(fā)送CANCEL請求,,從而達到破壞會話建立的目的,。例如,UserA發(fā)給UserB的INVITE請求被攻擊者Attacker截獲,,獲得了To,、From等內(nèi)容后,在消息中插入了發(fā)給UserB的CANCEL請求,,于是,,UserA的會話請求被取消,無法與UserB建立會話,,其流程如圖2所示,。?

?

?

3 SIP協(xié)議的安全機制?

??? 通過對以上幾種現(xiàn)有的或補充的SIP協(xié)議可能受到的安全威脅進行分析,據(jù)此就有可能提供必要的安全機制來保證SIP協(xié)議的安全運行,。目前現(xiàn)有的一些安全機制有:HTTP Digest,、S/MIME、TLS和SIPS URIS,。?

3.1 HTTP Digest身份認證[2]?

??? HTTP Digest身份認證是基于HTTP的challenge/response的機制,,即只接受有證書(credential)的請求,對沒有證書的請求則通過401/407要求對方重發(fā)包含認證信息的請求,。但由于目前HTTP Digest認證僅能實現(xiàn)Server(包括Proxy,、Registrar和Redirect Server)對本域內(nèi)的UA的認證,而無法實現(xiàn)UA對Server的認證,、Proxy對Proxy的認證和Proxy對域外UA的認證,,所以已經(jīng)出現(xiàn)的不少攻擊正是針對這些缺陷來實施的。?

3.2 S/MIME[3]?

??? 安全多用途互聯(lián)網(wǎng)郵件擴展協(xié)議S/MIME(Secure/Multipurpose Internet Mail Extensions)是一種端到端加密方式,,它是單向散列算法和公/私鑰相結(jié)合的加密體系,,采用對稱加密和非對稱加密結(jié)合,用公鑰加密會話密鑰,,會話密鑰來加密消息,,能夠提供保密、鑒別,、數(shù)字簽名等功能,。但S/MIME的局限性在于證書的權(quán)威性。用戶本應(yīng)該向公開授權(quán)機構(gòu)申請證書,,但用戶也可以自己簽發(fā)證書,,并且自制證書在會話初始能否通過鑒別是由用戶決定的,這就留下了潛在的安全漏洞,。?

3.3 TLS保護?

??? 傳輸層安全TLS(Transport Layer Security)用于在兩個通信應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性,,是面向連接協(xié)議即TCP之上的傳輸層安全,,該協(xié)議分為上層的TLS Handshake協(xié)議和下層的TLS Record協(xié)議。但由于在SIP協(xié)議中,,傳輸層的機制是基于點到點的,,使用TLS機制發(fā)送請求到代理服務(wù)器的SIP UA并不能保證請求在整個端到端的路徑中都是用TLS機制。另外,,TLS不能在UDP上運行,,目前大多數(shù)SIP都運行在UDP上,對SIP服務(wù)器來說,,同時維持大量的TLS連接負荷會很重,,導致容量不足的問題。此外,,TLS在穿越防火墻時也存在一些問題,。?

3.4 SIPS? URIS?

??? 統(tǒng)一資源定位符URI(Uniform Resource Identifier)是網(wǎng)絡(luò)環(huán)境下一種簡單和可擴展的標識機制。SIPS URI和SIP URI都是用于標識定位SIP網(wǎng)絡(luò)中網(wǎng)絡(luò)資源,,URI中包含了足夠的信息以滿足SIP網(wǎng)絡(luò)中的資源的互訪,。除了應(yīng)用在Request-URI上,SIPS安全機制還可以應(yīng)用到其他的SIP URI中,,包括注冊地址和聯(lián)系地址等,。?

4 新的解決思路與方法?

??? 上述的幾種安全機制都是針對整個通信過程中所有完整的SIP消息進行的端到端或點到點的加密或鑒權(quán)機制,這些安全機制本身存在著或多或少的不足,,例如,,因額外的計算所帶來的處理負擔更容易受到DDOS類的攻擊,需要額外的投入來進行鑒權(quán)機制的建立等,。?

??? 本文從SIP協(xié)議自身出發(fā),著眼于消息交互流程,,提出有別于上述幾種安全機制的一些思路與方法,,即考慮在SIP消息格式或SIP消息交互流程上運行一些完善措施,避免對每個SIP消息進行整體的加密或身份鑒權(quán),。這樣,,既可以減少對鑒權(quán)機制和一些加密算法的使用,減輕了設(shè)備的負擔,,又可以提高消息傳輸速率,,在安全與簡單有效之間進行一個較為平衡的折中。?

4.1 加入一次握手的確認信息?

??? 通過研究上述幾種安全威脅,,分析其具體攻擊過程,,可以發(fā)現(xiàn)SIP協(xié)議最容易受到攻擊的一種情況就是:沒有一次握手的確認信息。在這種情況下,,可以加入身份認證,,有針對性地防范安全威脅,。?

??? 方法是:當服務(wù)器端或者客戶端UserB接收到具有特殊意義的SIP消息時,根據(jù)原始請求發(fā)送者UserA的Contact地址,,向其發(fā)送一次握手的確認信息,,該確認信息采用身份認證的方式,通過發(fā)送ACK消息來向原始請求發(fā)送者UserA詢問其是否發(fā)了消息,,該ACK消息帶有隨機數(shù)nonce,、作用域realm。當原始請求發(fā)送者UserA接收到消息時,,若之前具有特殊意義的消息是其發(fā)送的,,則回復(fù)帶有由用戶名username、共享密鑰password,、隨機數(shù)nonce和作用域realm幾項經(jīng)過組合并利用MD5算法生成后的結(jié)果的200 OK狀態(tài)碼,,接收端UserB對收到的結(jié)果進行認證。若UserA之前沒有發(fā)送具有特殊意義的消息,,則根據(jù)其是客戶端還是服務(wù)器端,,回復(fù)不同的錯誤狀態(tài)碼(4XX/5XX)。超時不回復(fù)的,,也視為錯誤處理,。具體實現(xiàn)流程如圖3所示。?

?

?

??? 此方法比較適用于防范下面幾種常見的攻擊:?

??? (1) 注冊劫持攻擊:注冊劫持攻擊的特點是攻擊者冒充注冊用戶向注冊服務(wù)器發(fā)送注冊注銷請求,。當注冊服務(wù)器接收到Contact:*,Expires:0的消息或From頭字段值和To頭字段值不相同的消息時,,需要加入一次握手的確認信息,來確認消息發(fā)送者的身份,。?

??? (2) 中斷會話和破壞會話建立攻擊:這兩種攻擊方式的特點是客戶端或服務(wù)器端收到BYE,、CANCEL或re-Invite請求。當UA收到以上三種消息請求時,,需要加入一次握手的確認信息,。?

??? (3) 服務(wù)器端偽裝和客戶端偽裝攻擊:可以采用通過在客戶端或服務(wù)器端建立一個列表來保存上一次通信的(From, Contact)對的方法,當接收到新的請求時,,查詢(From, Contact)對,,如果不相符,則加入一次握手的確認信息,,這種方法一定程度上也可以減少對請求發(fā)送者的身份認證,。但也可以設(shè)置一個老化時間參數(shù),在一定時間內(nèi)刷新(From, Contact)對,。?

4.2 在服務(wù)器端和客戶端各增加一個Contact地址列表?

??? 這種方法的思路是:在通信雙方之間建立一個可信域,,對可信域范圍外的可疑請求一律進行身份認證。?

??? 由于SIP消息中的Contact頭字段給出下一次SIP服務(wù)器或目的UA與自身的聯(lián)系地址,,通常攻擊者通過把自身地址改為Contact地址的方式,,使得將發(fā)往被攻擊者的一切消息轉(zhuǎn)為發(fā)給攻擊者,,從而實施了攻擊。因此,,可以在客戶端和服務(wù)器端都增加一個Contact地址列表,,如果請求發(fā)送方UserA的Contact地址在其列表之內(nèi)的,則接收方UserB無需對其進行身份認證,;如果是在地址列表之外的請求,,UserB需對UserA用身份鑒權(quán)機制進行驗證,確認其可信后,,將該地址加入自己的Contact地址列表,。否則,不接收請求,。具體實現(xiàn)流程如圖4所示,。?

?

?

4.3 給SIP消息頭域增加一個頭字段?

??? 這種方法是對SIP協(xié)議消息中重要的關(guān)鍵字段進行加密,將加密后的數(shù)據(jù)存放在SIP消息頭域新增加的一個頭字段Au中,。其示意圖如圖5所示,。相對于SIP安全機制的端到端加密或點到點加密的方法,部分加密的優(yōu)點在于在降低了身份鑒權(quán)和加密機制的復(fù)雜程度的同時,,有效地保證了SIP協(xié)議的安全,。?

?

?

??? 一個具體的實現(xiàn)方式是在消息交換過程中,消息發(fā)送方UserA發(fā)送第N個消息時,,選取共享密鑰表中第N個密鑰,,對關(guān)鍵字段進行“不可逆”加密[4],將計算結(jié)果作為Au頭字段發(fā)送給接收方UserB,,接收方對利用第N個密鑰對Au字段數(shù)據(jù)進行解密,,并對結(jié)果進行如下判斷:解密后的關(guān)鍵字段是否與接收消息中對應(yīng)的關(guān)鍵字段一致,若不一致則判斷其受到了安全威脅,,若相同則對接收的消息進行處理,。這種方法需要雙方在交換消息前,實現(xiàn)共享的密鑰表,,密鑰表的復(fù)雜度可根據(jù)需要具體選擇。?

??? 這種方法盡管同樣應(yīng)用了加密算法和身份鑒權(quán)機制,,但加密方式相對比較簡單,,在降低計算負擔的同時也能保證SIP協(xié)議的安全運行。本文中所列出的幾種常見安全威脅都可以采用這種方法進行有效防范,。?

??? SIP憑借其簡單,、易于擴展、便于實現(xiàn)等優(yōu)點越來越得到業(yè)界的青睞,。隨著越來越多支持SIP的客戶端軟件和智能多媒體終端的出現(xiàn),,SIP用戶不斷增加,, SIP的安全問題也將受到更多的關(guān)注。SIP的安全對策研究將不斷深化,,安全機制將不斷完善,,它將會進一步為廣大用戶提供更加多樣、安全的服務(wù),。?

參考文獻?

[1] ROSENBERG J, SCHULZRINNE H. SIP:Session Initiation?Protocol. RFC3261,2002.?

[2]?王宇飛,范明鈺,王光衛(wèi).一種基于HTTP摘要認證的SIP安全機制.重慶郵電學報(自然科學版),2005,(17):749.?

[3]?王原麗,嚴劍.基于S/MIME 的SIP 安全機制.信息安全與通信保密,2005,(5):40.?

[4]?王朔中, 張新鵬, 張開文. 數(shù)字密寫和密寫分析[M].北京:清華大學出版社,2005.

本站內(nèi)容除特別聲明的原創(chuàng)文章之外,,轉(zhuǎn)載內(nèi)容只為傳遞更多信息,并不代表本網(wǎng)站贊同其觀點,。轉(zhuǎn)載的所有的文章,、圖片、音/視頻文件等資料的版權(quán)歸版權(quán)所有權(quán)人所有,。本站采用的非本站原創(chuàng)文章及圖片等內(nèi)容無法一一聯(lián)系確認版權(quán)者,。如涉及作品內(nèi)容、版權(quán)和其它問題,,請及時通過電子郵件或電話通知我們,,以便迅速采取適當措施,避免給雙方造成不必要的經(jīng)濟損失,。聯(lián)系電話:010-82306118,;郵箱:[email protected]