仿冒GRE隧道地址的消息攻擊及防御方法

摘要：10年前，WAP應(yīng)用的出現(xiàn)標(biāo)志著移動數(shù)據(jù)業(yè)務(wù)時(shí)代的到來。10年后的今天，智能手機(jī)、移動數(shù)據(jù)業(yè)務(wù)已是隨處可見。WAP業(yè)務(wù)已經(jīng)是移動運(yùn)營商的重要業(yè)務(wù)收入來源，但用心不良的不法分子卻時(shí)刻窺探著移動數(shù)據(jù)業(yè)務(wù)這塊蛋糕。本文通過分析移動運(yùn)營商受到的一起普通用戶投訴的垃圾WAP PUSH，折射出目前黑客攻擊手段的高明，并針對該種攻擊給出GPRS/WAP承載網(wǎng)絡(luò)的安全加固策略。

關(guān)鍵字：GRE GPRS WAP PUSH UDP

一、背景介紹

現(xiàn)實(shí)網(wǎng)絡(luò)已發(fā)生過多種對GPRS的攻擊，這些攻擊不僅濫用業(yè)務(wù)，竊取用戶關(guān)鍵數(shù)據(jù)，更導(dǎo)致網(wǎng)絡(luò)癱瘓，給運(yùn)營商帶來經(jīng)濟(jì)和名譽(yù)損失，也損害了廣大用戶的利益。這里舉幾個比較典型的濫用實(shí)例：

德國E-Plus 曾存在GPRS 存在過計(jì)費(fèi)漏洞，非法用戶接入GPRS，而費(fèi)用記在某個合法用戶身上；

某設(shè)備提供商GGSN 存在內(nèi)核錯誤，黑客利用一個數(shù)據(jù)包導(dǎo)致GPRS網(wǎng)絡(luò)癱瘓GGSN ；

沃達(dá)豐GPRS-MMS服務(wù)曾存在計(jì)費(fèi)漏洞，用戶可免交上網(wǎng)費(fèi)；

美國T-Mobile發(fā)現(xiàn)黑客透過GPRS的DNS系統(tǒng)進(jìn)入OAM系統(tǒng)，竊取了大量用戶的社會保險(xiǎn)號碼、私人郵箱等重要用戶數(shù)據(jù)。

這些攻擊或者利用協(xié)議漏洞，或者利用網(wǎng)絡(luò)或設(shè)備漏洞，對業(yè)務(wù)運(yùn)營造成極壞的影響。

前階段，國內(nèi)某運(yùn)營商接到用戶投訴，稱收到發(fā)送者為212.138.115.X的垃圾WAP PUSH，內(nèi)容為“你有一條短信，訪問http：//hu36.com:88/***”，手機(jī)打開鏈接后顯示為“天下商機(jī)”的頁面。經(jīng)過從運(yùn)營商的短信中心數(shù)據(jù)庫仔細(xì)查詢，并未發(fā)現(xiàn)短信下發(fā)記錄。我們懷疑可能是網(wǎng)絡(luò)攻擊并通過GPRS網(wǎng)絡(luò)下發(fā)，遂針對該問題進(jìn)行了查證。

二、查證分析過程及原因

由于類似網(wǎng)絡(luò)攻擊僅出現(xiàn)在晚上20:00-23:00之間，我們從連續(xù)3日每晚進(jìn)行網(wǎng)絡(luò)抓包，逐漸發(fā)現(xiàn)了仿冒GRE隧道地址發(fā)送WAP PUSH短信整個過程。

1.查證過程

GRE路由器對INTERNET的出口（消息跟蹤點(diǎn)A）進(jìn)行了抓包

我們在GRE路由器對INTERNET的出口進(jìn)行了抓包結(jié)果如下圖，這些WSP PUSH數(shù)據(jù)包被封裝在GRE隧道里，其GRE隧道源地址為212.138.115.236（GGSNC GRE隧道地址），目的地址為WAP GRE路由器GRE隧道地址，其隧道內(nèi)數(shù)據(jù)包的源地址為212.138.115.X (X為隨機(jī)數(shù)，212.138.115.X為攻擊者隨意填寫)，目的地址為10.X.X.X（GGSNA/B的CMWAP IP地址池地址）。

2、GGSNC對INTERNET的出口（消息跟蹤點(diǎn)B）進(jìn)行了抓包

我們對GGSNC的出口進(jìn)行了抓包，結(jié)果如下圖。我們未抓到從212.138.115.236（GGSNC GRE隧道地址）發(fā)出的WSP PUSH數(shù)據(jù)包，而是抓到了GRE隧道源地址為WAP GRE路由器GRE隧道地址，目的地址為212.138.115.236（GGSNC GRE隧道地址），其隧道內(nèi)數(shù)據(jù)包的源地址為212.138.115.X(X為隨機(jī)數(shù)，211.136.115.X為攻擊者隨意填寫)，目的地址為10.X.X.X（GGSNC的CMWAP IP地址池地址）的WSP PUSH數(shù)據(jù)包。

3、原因分析

網(wǎng)絡(luò)攻擊者掌握了GGSNC與WAP GRE路由器之間的GRE tunnel地址，并偽造GGSNC GRE tunnel地址。從而在INTERNET上偽造了GGSNC 源地址與WAP GRE路由器之間建立了tunnel，并向WAP GRE路由器發(fā)送數(shù)據(jù)包。GRE路由器將數(shù)據(jù)包GRE包頭解開后，根據(jù)網(wǎng)絡(luò)攻擊者填寫的目的用戶IP地址(CMWAP IP POOL地址)，根據(jù)路由表將該數(shù)據(jù)包轉(zhuǎn)給了相應(yīng)的GGSN，并下發(fā)至用戶。示意圖如下：

該問題的發(fā)生主要由于GRE隧道僅對源地址鑒權(quán)、無加密機(jī)制且承載在公網(wǎng)，只要網(wǎng)絡(luò)攻擊者掌握移動相關(guān)網(wǎng)元組網(wǎng)結(jié)構(gòu)和IP地址，就能仿冒隧道源地址即可將數(shù)據(jù)包插入隧道。同時(shí)WSP PUSH使用UDP協(xié)議，僅需單向數(shù)據(jù)包即可成功發(fā)送PUSH。

此外，經(jīng)查http：//hu36.com:88/***對應(yīng)IP地址為117.135.141.52，為IDC地址段。

三、解決方案及建議

1、臨時(shí)解決方案：

在GRE路由器的隧道虛接口中屏蔽對手機(jī)下行數(shù)據(jù)包的WSP PUSH所使用的UDP 2948端口。經(jīng)過與各家運(yùn)營商確認(rèn)，目前可能承載WAP PUSH的UDP端口包括：2948、2949、4035、4036。我們建議在GRE路由器封堵這些UDP端口的業(yè)務(wù)量。

經(jīng)較長時(shí)間抓包未發(fā)現(xiàn)正常數(shù)據(jù)包使用UDP 2948、2949、4035、4036端口，且該端口為WAP協(xié)議規(guī)定的終端接收WSP PUSH所使用端口，對正常業(yè)務(wù)基本無影響。經(jīng)過對WAP GRE路由器進(jìn)行了實(shí)施，目前已攔截了此類非法PUSH消息，且無用戶投訴。

2、最終解決方案

【方案一】在GGSN上添加策略，阻止向手機(jī)用戶下發(fā)UDP 2948端口數(shù)據(jù)包。

我們在消息跟蹤時(shí)也發(fā)現(xiàn)網(wǎng)絡(luò)攻擊者嘗試偽造WAP GRE tunnel地址，直接和GGSNC建立鏈接的現(xiàn)象，但由于目前GGSNC無正常業(yè)務(wù)，故沒有實(shí)際影響。但如果網(wǎng)絡(luò)攻擊者了解其他GGSN地址，那就可以不通過WAP GRE路由器，直接向GPRS用戶下發(fā)數(shù)據(jù)包，此時(shí)我們實(shí)施的臨時(shí)方案將無效。

但是在實(shí)施該方案一后，我們抓包發(fā)現(xiàn)雖然GGSN阻擋了WAP PUSH，但是對于終端側(cè)以上述端口發(fā)送正常的DNS請求也會被過濾，Log如下：

Name of protocol: UDP， Packet Length: 99， Source address: 212.138.115.X:53， Destination address: 10.A.A.A:2948 Filter: pfe， Filter action: discard， Name of interface: ge-3/0/0.0

根據(jù)RFC，終端在IP網(wǎng)絡(luò)應(yīng)用時(shí)，可以在源端口使用1025-65535之間任意的端口。因此，在執(zhí)行該封堵策略時(shí)，會將這部分的用戶正常數(shù)據(jù)請求丟棄。

【方案二】為了解決目前GGSN與WAP網(wǎng)關(guān)公有GRE通道的不安全性（數(shù)據(jù)包通過CMNET轉(zhuǎn)發(fā)，存在源地址仿冒欺騙問題），希望CMWAP業(yè)務(wù)能運(yùn)行在一條GGSN與WAP網(wǎng)關(guān)之間的私用通道上來傳送報(bào)文，與Internet隔絕。這樣可避免網(wǎng)絡(luò)攻擊者從公網(wǎng)攻擊的情況，徹底杜絕仿冒包的產(chǎn)生。

在最終實(shí)施時(shí)，運(yùn)營商需要考慮對不同地理位置的WAP業(yè)務(wù)必須同時(shí)割接，建議先進(jìn)行鏈路調(diào)測和路由器的預(yù)配置，并先割接WAP業(yè)務(wù)作驗(yàn)證。

四、總結(jié)

移動數(shù)據(jù)業(yè)務(wù)即將進(jìn)入爆發(fā)增長階段。但是道高一尺，魔高一丈。數(shù)據(jù)業(yè)務(wù)的安全將長時(shí)間伴隨業(yè)務(wù)的發(fā)展。運(yùn)營商不僅要從終端側(cè)、網(wǎng)絡(luò)承載側(cè)、業(yè)務(wù)平臺側(cè)進(jìn)行端到端的安全配置跟蹤，還要應(yīng)對突發(fā)、不可預(yù)料的安全事件，任重道遠(yuǎn)！

參考文獻(xiàn)：

[1] 《3GPP TS23.060 R8》，3GPP ，2008

[2] 《中國移動系統(tǒng)安全防護(hù)要求》，中國移動通信集團(tuán)公司，2010.09