changed 7 years ago
Linked with GitHub

8/03 (五) 14:00 - 17:00

  • 講師 : 李奇育 交通大學資工系

  • 4G

  • Outline(?)

    • 3G/4G基本架構和方式
    • 安全機制
    • 找漏洞
      • 計費功能
      • 4G高音質通話 (VolTE)
      • 4G簡訊系統
    • 知道攻擊才能解決弱點
  • 大綱

    • 行動網路系統與單全簡介
    • 4G高音質通話潛在安全威脅
      • 實作3ㄍ
        • 資料流認證
        • VoLTE漏洞檢測
        • 開發具有原生碼(Native Code)的Andriod手機APP測試工具
  • 課題一

    • 行動網路
      • 與網際網路同等規模的最大網路架構
      • 廣泛覆蓋範圍和無處不在的連線
      • 203ㄍ國家
    • 大綱 行動網路系統跟安全大綱
      • 系統的演化
      • 1G. AMPS NMT TACS
      • 2G. GSM.GPRS EDGE cdmaOne
      • 3G. WDCDMA
      • 4G.LTE
    • 行動網路的主要標準 3GPP
      • 依序發展和訂定2G GSM&3G UMTS&4G LTE
      • 主要探討3GPP標準
        • 類似的有3GPP2 WiMax Foruum
    • 目前全球的演化:3G -> 4G
      • 4G LTE 行動寬頻的第一個全球標準
      • 2G -> 3G ->4G
      • 2G
        • 電路交換的語言服務
      • 3G
        • 封包交換的上網服務
      • 4G
        • 所有服務皆封包交換
        • IP-based
    ​​​​​​- 電路交換
    ​​​​​​  - 通話需端點之間資源的保留
    ​​​​​​  - 資源:連結頻寬和交換機容量
    ​​​​​​  - 專用的資源:不能分享
    ​​​​​​  - 電路式的保證效能
    ​​​​​​  - 需要通話資源的建立
    ​​​​​​- 電路機換信令
    ​​​​​​  - 用於建立維持和拆除虛擬電路
    ​​​​​​  - 用於2G和3G的通話服務
    ​​​​​​  - 但不能使用於現今的Net
    
    • 封包交換
      • 裝置A和B的封包沒有固定傳輸模式
        • 頻寬分享且多工
      • 網際網路中的路由器採儲存和轉送(Store-and-forward)的方式
      • 使用於網際網路
    • 封包交換信令
      • 網路曾不須通話資源的建立(end-to-end connections)
        • 網路層沒有連線的概念
      • 根據終點(Destination)位址轉送封包
        • 兩點之間連線的封包可能由不同的路徑轉送
    • 4G/3G 行動網路架構

    • 主要運作方式
      • 兩個主要的運作層面 (planes)
        • 資料或用戶層(Data/User plane): 資料的傳送
        • 控制層(Control plane): 信令的傳送
        • 控制層的主要3功能
          • 無限資源的控制(RRC,Radio Resource Control)
          • 移動控制(MM,Mobility Management)
          • 連線控制(CM,Connection Management)
        • 如何建立一個用於上網服務的4G網路連線?
        • 目前4G網路的安全機制
        • 總結
          • 用戶認證
            • 控制層 (Control plane) 安全機制
            • 行動裝置和移動管理元件(MME)之間的NAS信令加密且完整保護
            • 保護信令的傳送:移動更新、資源保留、連線建立等控制功能
            • 行動裝置和基地台之間的AS信令加密且完整保護
            • 用戶層 (User plane) 安全機制
            • 行動裝置和基地台之間的資料加密
            • 基地台和封包閘道器之間資料加密非必要,因封包傳送皆發生於封閉的行動網路中
            • 但是,如此完善的行動網路安全機制仍然存在安全性弱點 !
  • 課題二:計費功能(Charging)之潛在安全威脅

    • 用戶資料流之認證(Authentication)與授權(Authorization)
    • 用戶資料流之認證與授權
      • 與資料流量之統計機制息息相關
      • 若有安全性弱點而遭受攻擊,有可能使得
        • 用戶的資料流量被惡意增加
        • 攻擊者可以取得某些資料流量的免費使用
    • 用戶資料流之認證與授權
      • 認證 (Authentication)
        • 每一資料流的費用應記在真正使用此資料流的用戶
        • 但若認證發生問題,某資料流的費用有可能記在錯誤的用戶上
          • e.g., 用戶 A 用的資料流費用記在用戶 B 的帳上
      • 授權 (Authorization)
        • 行動網路所傳送的每一資料流都應是該資料流的用戶所授權的
        • 但若授權發生問題,受害者用戶可能需要為他們未授權的資料流負擔費用
  • 上網資料量收費方式

  • 行動網路的資料流量統計方式

  • 用戶認證及授權與行動網路的資料流量統計

    • 以下兩個問題,答案有可能是否定的
      • 每一承載連線(Bearer)一定只有此認證過的用戶可以使用嗎?
      • 每一承載連線(Bearer)上的資料,一定是用戶所授權的嗎?
      • 我們接下來介紹否定的答案在什麼狀況下會發生、可能遭受到的攻擊、以及原因
      • 攻擊者所需的條件 (Threat Model)
      • 不需接觸行動網路的所有設備和受害者的手機或在它們上面安裝惡意軟體
      • 只需市面上販售的Android手機 (需有系統管理者權限)
  • 用戶認證的安全性弱點與攻擊 – 正常狀態

  • 用戶認證的安全性弱點與攻擊

    • 攻擊的機制:行動網路核心網根據IP統計資料流量
      • 假造IP (IP Spoofing) 攻擊
      • 攻擊者利用受害者的IP製造上行資料流,可讓核心網認為是受害者所送的資料流
      • 核心網因而將此假造IP的資料流統計於受害者的帳單中
      • 我們曾發現美國的電信商AT&T有此安全漏洞
  • 用戶認證的安全性弱點與攻擊 – 原因分析

    • 從協定堆疊(Protocol Stack)的角度分析
  • 用戶認證的安全性弱點與攻擊 – 解決方法

    • 從協定堆疊(Protocol Stack)的角度分析
  • 用戶資料流授權的安全性弱點與攻擊 – 正常狀態

  • 用戶資料流授權的安全性弱點與攻擊

  • 用戶資料流授權的安全性弱點與攻擊-2

  • 用戶資料流授權的安全性弱點與攻擊-3

  • 用戶資料流授權的安全性弱點與攻擊-4

  • 用戶資料流授權的安全性弱點與攻擊-5

  • 用戶資料流授權的安全性弱點與攻擊 – 原因分析

    • 安全性弱點:對於下行的資料流無適當的授權機制
      • 只要有上行的資料流穿越防火牆
      • 防火牆就認定下行的資料流是合法
      • 然而,上行資料流有可能被多種方法所惡意製造或利用
      • 我們曾發現過美國電信商AT&T和T-Mobile有此安全漏洞
      • 以及在中國、香港和日本的電信商皆有發現此漏洞
  • 用戶資料流授權的安全性弱點與攻擊 – 解決方法

  • 總結:用戶資料流之認證與授權機制

    • 用戶資料流之認證
      • 安全弱點:只根據IP統計資料流量
      • 可能遭受之攻擊:假造IP (IP Spoofing) 攻擊
      • 解決方法:跨層的安全綁定 (IP和Bearer)
      • 用戶資料流之授權
      • 安全弱點:對於下行的資料流無適當的授權機制
      • 可能遭受之攻擊:經由MMS、Skype和IP spoofing等方法增加受害者的上網數據量
      • 解決方法:取消資料流授權的機制
      • 這些安全弱點起因於行動網路的演化:電路交換網路至封包交換IP網路
      • 舊有的安全機制無法防護這些新的安全弱點
      • 網際網路上的安全弱點皆有可能發生在行動IP網路中
  • 學習到的經驗

    • 當系統在演化過程中,任何重大的改變都有可造成安全的漏洞
      • 舊有的安全機制無法防護新系統的安全漏洞
      • 如:行動網路的認證AKA機制和行動上網資料流的安全
      • 新技術本身可能帶來更多的安全威脅
      • 如:3G/4G行動網路使用IP網路
      • 以下原因皆有可能造成安全漏洞
      • 技術設計上的問題 (3GPP標準)
      • 執行上的缺陷 (設備和手機製造商)
      • 運作上的錯誤 (電信商)
      • 因此,在系統的演化過程中,所有可能的安全威脅應從各方面 (設計、執行、運作),根據新技術的使用重新檢視
  • 課題三:4G行動網路簡訊系統(SMS)之潛在安全威脅

    • 簡訊服務(SMS)仍然是非常流行的
      • 幾乎所有的手機都支援SMS (Short Message Service)
      • 各式各樣的產業和服務依賴在SMS上
    • 三種SMS服務的運作方式
    • IMS-based SMS:四個可能的安全性問題
      • 與傳統的CS-based SMS比較,以下特性可能造成安全性問題
        • 基於軟體設計的SMS客戶端
        • 彈性的協定設計
        • 用戶層的溝通管道
        • 多項的安全機制選擇
    • IMS-based SMS:基於軟體設計的SMS客戶端
    • IMS-based SMS:彈性的協定設計
    • IMS-based SMS:用戶層的溝通管道
    • IMS-based SMS:多項的安全機制選擇
    • IMS-based SMS的安全性弱點和可能遭受的攻擊
      • 安全性弱點一:SIP會話資訊的洩漏

      • 安全性弱點二:SIP訊息無完整性保護

        • 沒有資料完整性的保護
        • 只要知道SIP訊息的架構,很容易可以假造
      • 安全性弱點三:手機上不安全的SMS存取控制

        • Android用 SEND_SMS permission控制APP是否能傳送SMS訊息
        • 防毒軟體或Android會監控擁有SEND_SMS permission的APP
        • 但,這並不適用於IMS-based SMS服務
        • 我們發現如果Android APP要傳送一個SIP訊息(帶著SMS內容),它只需要取得INTERNET permission
        • 因此,惡意軟體可以偷偷發送惡意的SMS,不被目前的SMSpermission所限制
          • 沒有任何限制
          • 不會有任何警示
      • 安全性弱點四:IMS伺服器沒有檢查假造的SMS

        • 不是所有的電信商都會檢查SIP訊息中傳送者的電話號碼
      • 四個IMS-based SMS的安全性弱點

        • SIP會話資訊的洩漏
        • SIP訊息無完整性保護
        • 手機上不安全的SMS存取控制
        • IMS伺服器沒有檢查假造的SMS
      • SMS假造攻擊

        • 我們開發一個Android APP可以發送SIP(包含IMS-based SMS)訊息
          • 只需要Internet permission
          • 不被現有的SMS permission所限制
          • 它允許假造傳送者的號碼,且指定接受者的號碼
        • 利用假造SMS攻擊基於SMS的FB服務
          • Facebook簡訊服務攻擊
            • 幫受害者更新狀態、加朋友和加Like
            • Demo: 攻擊者幫受害者加朋友,過程中,不需要受害者的任何動作
        • 利用假造SMS攻擊基於SMS的FB服務
          • Facebook簡訊服務攻擊
            • Demo: 攻擊者(ResearchThree)幫受害者(Scott)加朋友
        • 利用假造SMS攻擊基於SMS的ARC服務
          • 非授權的捐款
            • SMS捐款服務:美國紅十字會 (American Red Cross)允許捐款者使用SMS捐款
            • 捐款是從傳送者的電信帳單收費
            • 例如:發送REDCROSS到號碼90999,就表示傳送者要捐10元給紅十字會
        • 建議的解決方法
          • 手機

            • 升級SMS permission
            • IPSec的實現不應該依賴在系統功能
          • IMS系統

            • SIP訊息應該有資料整性保護
            • 需檢測SIP訊息的傳送者號碼
          • 基於SMS的服務系統

            • 需要使用者主動的註冊
            • 使用簡短的認證碼
      • 已發現安全漏洞的狀態(2016/10)

        • 已將發現的漏洞通知Google、美國電信商和Facebook
        • 在Andoird Marshmallow版本或更新的版本中,沒有管理者權限無法取得IMS位址
        • Facebook已經實現了MobilePIN,而且移除了從SMS控制"addfriend"和"like page"功能

圖片支援終止線
下面待施工

  • 課題四:4G新世代高音質通話系統(VoLTE)之潛在安全威脅
    • 什麼是VoLTE?

    • VoLTE的運作和安全機制

    • VoLTE的安全性弱點和可能遭受的攻擊

    • VoLTE安全弱點的原因和解決方法

    • 4G LTE:演化至全IP網路架構

      • 使用封包同時提供通話語音和上網資料服務
        • 如同網際網路:通話服務(e.g., Skype)
      • Why?
        • 可以提供更好品質的服務
          • 如:高音質、影像通話等
        • 減少成本和系統複雜度
    • 主要的改變:通話語音服務

      • 從電路交換系統(CS)轉移至封包交換(PS)
      • 新興的語音通話服務VoLTE (Voice over LTE)
        • 又稱高音質通話服務 (HD Voice)
    • 如何在行動網路中支援VoLTE ?

      • 傳統語音通話:電路交換 (CS)
      • 4G LTE語音通話:封包交換 (PS)
    • 如何在行動網路中支援VoLTE ?

      • IP多媒體子系統 (IMS, IP Multimedia Subsystem): 一個用來傳送IP多媒體服務的新架構
        • 像Skype的伺服器
        • 也支援其他多媒體服務:如:影像通話 (ViLTE, Video over LTE)
    • VoLTE 高音質通話服務

      • 聲音讓人感覺通話雙方就在旁邊
        • 清晰的通話品質
        • 較少的背景雜音
      • 語音通話和上網資料服務可以同時使用4GLTE的高速傳輸
    • VoLTE的運作

      • 一般上網資料服務承載 (Data Bearer)
      • VoLTE 信令承載 (Signaling Bearer)
      • VoLTE 語音承載 (Voice Bearer)
    • VoLTE的運作

      • VoLTE信令:對談發起協定 (SIP,Session Initiation Protocol)
      • VoLTE語音:實時傳輸協定 (RTP,Real-time Transport Protocol)
    • VoLTE的運作和安全機制

      • VoLTE安全機制:手機和IP多媒體子系統之間用IPSec保護
      • IPSec (網際網路安全協定):用戶認證和資料完整性
    • VoLTE的運作和計費機制

    • VoLTE如何達到電信等級(Carrier-Grade)的語音服務品質?

      • 利用不同服務品質的承載來支援VoLTE,避免受行動上網服務影響
    • VoLTE的安全性弱點和可能遭受的攻擊

      • 威脅一

        • 圖P17
        • 威脅一 – 信令承載
          • 我們是否可以使用VoLTE的信令承載(Signaling Bearer)傳送資料封包?

            • 然而,此安全威脅可能受在手機和4G閘道器上的存取控制而避免
          • 圖(P19)

          • Yes to Q1:手機上沒有適當的存取控制

            • #1: 在Android作業系統上 (2015),對於VoLTE信令承載 (網路介面) 沒有適當的權限控制
              • 一個行動軟體想要傳送封包至信令承載,只需擁有Android上的網際網路權限 (Internet permission)
            • #2: 在手機硬體上,也沒有存取控制
            • #3: 網路中,對於VoLTE信令承載有不適當的路由
              • T-Mobile: 手機到網際網路和另一手機
              • AT&T: 手機到另一手機
        • 威脅一 – 兩種主要的攻擊
          • 免費上網服務攻擊
            • 攻擊者:行動用戶
            • 受害者:行動網路
            • 驗證攻擊的美國電信商:AT&T、T-Mobile和Verizon
          • 上網拒絕服務攻擊 (DoS, Denial-of-Service)
            • 攻擊者:行動用戶
            • 受害者:行動用戶
            • 驗證攻擊的美國電信商:AT&T、T-Mobile和Verizon
          • 免費資料傳輸服務攻擊
            • 經由VoLTE信令承載,建立資料傳輸通道
            • 圖P23
            • 但可能只有ICMP封包可以通過閘道器至網際網路
              • 為了可以正常使用上網服務,我們需建立ICMP通道 (Tunnel)
                • 將所需傳的資料封裝至ICMP封包中
                • 網際網路需要有一個ICMP通道伺服器負責將資料放進ICMP或從ICMP拿出
                • 圖P24
            • 上網拒絕服務攻擊 (DoS)
              • 經由VoLTE信令承載,傳送大量垃圾封包 (Spamming)
                • 利用此承載的高優先級
            • 上網拒絕服務攻擊(DoS)結果
      • 威脅二

        • 圖P18

        • VoLTE的可能安全威脅二 – 語音承載

        • 不安全的 VoLTE 語音承載存取控制

          • 語音封包是從數據機產生的,而不是從作業系統
          • 我們的APP可以傳送垃圾封包到VoLTE語音承載
        • 如何將垃圾封包送至VoLTE的語音承載呢?

          • 我們發現當封包送往IMS伺服器用來服務這個語音通話的IP和Port,這些封包就會被modem送至語音承載 (voice bearer)
          • 每次建立通話時,手機和IMS伺服器會經由信令承載(signaling bearer)溝通雙方要使用的IPVO和PortVO
          • 通話建立成功後,modem就會將擁有IPVO和PortVO的封包當成是語音封包,而送至語音承載
        • 如何取得IPVO和PortVO

          • 當我們要利用APP傳送垃圾封包對受害者發動攻擊時
            • 此APP是一個惡意軟體,應假設無法取得管理者權限 (Root privilege),而只有普通的上網權限 (Internet permission)
            • 所以它無法即時取得信令封包內容
            • 利用語音承載的QoS特性偵測而取得PortVO
        • 威脅二 – 攻擊

          • 語音拒絕服務攻擊 (DoS)
            • 攻擊者:惡意軟體
            • 受害者:行動用戶
            • 驗證攻擊的美國電信商:AT&T和T-Mobile
            • 驗證攻擊的手機廠商:Samsung和Sharp (都使用Qualcomm的modem chipset)
          • 不同以往對於語音通話的攻擊方式
            • 以前:無法建立通話
            • 現在:雖可建立通話,但雙方無法聽到對方的聲音
          • 原因&建議的解決方法
            • 主要有三個面向的安全性問題:VoLTE的標準、行動網路和行動裝置
            • VoLTE的標準:設計的缺陷
              • 缺乏對VoLTE服務和高優先級承載的保護機制
            • 行動網路
              • 不適當的路由和缺乏VoLTE信令的統計機制 (accounting)
              • 解決方法:修正路由、限制高優先級乘載的速度、增加VoLTE信令的統計機制
            • 行動裝置
              • 軟體(行動作業系統)和硬體(Modem)皆缺乏適當的存取控制
              • 新版Android已經增加了對VoLTE資訊和網路介面的存取控制
Select a repo