Lỗ hổng khai thác nghiêm trọng trong chipset Wi‑Fi của MediaTek: lỗ hổng zero-click

 (blog.sonicwall.com)
1 điểm bởi GN⁺ 2024-09-22 | 1 bình luận | Chia sẻ qua WhatsApp

Lỗ hổng nghiêm trọng trong chipset Wi‑Fi của MediaTek: lỗ hổng zero-click (CVE-2024-20017) đe dọa router và smartphone

Tổng quan
  • Nhóm nghiên cứu mối đe dọa SonicWall Capture Labs đã xác định lỗ hổng CVE-2024-20017, đánh giá tác động của nó và phát triển biện pháp giảm thiểu
  • CVE-2024-20017 là một lỗ hổng zero-click nghiêm trọng với điểm CVSS 3.0 là 9.8, ảnh hưởng đến MediaTek Wi‑Fi chipset MT7622/MT7915 và gói driver RTxxxx SoftAP
  • MediaTek SDK phiên bản 7.4.0.1 trở về trước, OpenWrt 19.07 và 21.02, được sử dụng trong sản phẩm của nhiều nhà sản xuất như Ubiquiti, Xiaomi và Netgear, đều bị ảnh hưởng
  • Lỗ hổng này cho phép thực thi mã từ xa mà không cần tương tác của người dùng, và MediaTek đã phát hành bản vá để giảm thiểu rủi ro
  • Lỗ hổng này đã được công bố và vá vào tháng 3, nhưng PoC được công khai gần đây làm tăng khả năng bị khai thác
Tổng quan kỹ thuật
  • Lỗ hổng tồn tại trong wappd, một daemon mạng nằm trong MediaTek MT7622/MT7915 SDK và gói driver RTxxxx SoftAP
  • wappd có vai trò cấu hình và quản lý giao diện không dây cùng các access point, đặc biệt liên quan đến công nghệ Hotspot 2.0
  • Kiến trúc của wappd gồm chính dịch vụ mạng, một tập hợp dịch vụ cục bộ tương tác với giao diện không dây của thiết bị, và kênh giao tiếp giữa các thành phần thông qua Unix domain socket
  • Lỗ hổng phát sinh do tràn bộ đệm vì một giá trị độ dài lấy trực tiếp từ dữ liệu gói tin do kẻ tấn công kiểm soát được dùng cho thao tác sao chép bộ nhớ
Kích hoạt lỗ hổng
  • Lỗ hổng xảy ra trong hàm IAPP_RcvHandlerSSB, nơi giá trị độ dài do kẻ tấn công kiểm soát được truyền vào macro IAPP_MEM_MOVE
  • Không có kiểm tra biên nào ngoài việc xác nhận không vượt quá độ dài gói tối đa 1600 byte
  • Kẻ tấn công phải gửi gói tin với cấu trúc mong đợi được gắn trước payload tấn công
  • Độ dài của cấu trúc RT_IAPP_HEADER phải nhỏ, và trường RT_IAPP_HEADER.Command phải là 50
Khai thác
  • Mã khai thác được công bố sử dụng chuỗi ROP để đạt thực thi mã từ xa bằng kỹ thuật ghi đè bảng địa chỉ toàn cục
  • Nó tận dụng lời gọi system() để thực thi lệnh gửi reverse shell về cho kẻ tấn công
  • Reverse shell được thiết lập bằng các công cụ Bash và Netcat
Bảo vệ của SonicWall
  • Các chữ ký sau đã được triển khai để giúp khách hàng SonicWall phòng vệ trước việc khai thác lỗ hổng này
    • IPS: 20322 MediaTek MT7915 wlan Service OOB Write 1
    • IPS: 20323 MediaTek MT7915 wlan Service OOB Write 2
Khuyến nghị giảm thiểu
  • Do mã khai thác đã được công khai, người dùng được khuyến nghị mạnh mẽ nâng cấp lên phiên bản firmware mới nhất cho chipset bị ảnh hưởng
Liên kết liên quan

Tóm tắt của GN⁺

  • Bài viết này đề cập đến một lỗ hổng zero-click nghiêm trọng trong chipset Wi‑Fi của MediaTek, cho phép thực thi mã từ xa mà không cần tương tác của người dùng
  • Nhóm nghiên cứu của SonicWall đã xác định lỗ hổng này và phát triển biện pháp giảm thiểu, đồng thời khuyến nghị người dùng nâng cấp lên firmware mới nhất
  • Lỗ hổng ảnh hưởng đến router và smartphone của nhiều nhà sản xuất, và khả năng bị khai thác tăng cao do PoC mới được công khai gần đây
  • Một sản phẩm có chức năng tương tự là chipset Wi‑Fi của Qualcomm, và điều quan trọng là phải kiểm tra các bản cập nhật bảo mật định kỳ

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-09-22
Ý kiến trên Hacker News

  • Từ góc nhìn của người từng so sánh mã nguồn driver SDK của vendor MediaTek với mt76, chuyện này không có gì quá bất ngờ. Nói nhẹ thì nó khá lộn xộn
    Đáng tiếc là vì thông lượng nhỉnh hơn mt76 một chút, vẫn có một số bản build firmware bên thứ ba dùng driver của vendor
    May mắn là ở MediaTek và bộ phận WiSoC có vài kỹ sư tích cực giao tiếp với cộng đồng phần mềm tự do/mã nguồn mở, và họ cũng tự duy trì một fork OpenWrt nhỏ dựa trên mt76: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk...

    • Không hiểu sao phần cứng/firmware kiểu này cứ tạo cảm giác như mã proof-of-concept được triển khai vào môi trường production. Họ không thuê được người thật sự hiểu việc à
    • Tôi tò mò không biết có thông cáo báo chí hay thông tin nào về mục tiêu của chương trình đó, hoặc bao nhiêu phần trong feed ấy đã được merge upstream không

  • Cách đặt tiêu đề hơi dễ gây hiểu nhầm. Nhà tôi có vài router dùng mt76 Wi-Fi, nên tôi bấm vào link vì tưởng là lỗi firmware hoặc silicon; hóa ra là lỗi trong đống mã SDK của vendor nên thấy nhẹ nhõm
    Hỗ trợ mt76 trong mainline kernel và hostapd khá tốt, nên tôi không hiểu vì sao lại có người muốn dùng thứ kia

    • Nói “thấy nhẹ nhõm vì đó là lỗi trong đống mã SDK của vendor” thì vẫn có nhiều vendor phải lo đấy
      Bài viết nói đó là “gói driver được dùng trong sản phẩm của nhiều nhà sản xuất, gồm Ubiquiti, Xiaomi, Netgear, v.v.”
      Tuy vậy cũng có những vendor như Ubiquiti nói rằng họ không dùng gói này trong sản phẩm thực tế: https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
    • Dòng OpenWRT 21.02.x được nói là bị ảnh hưởng dù dựa trên mainline kernel 5.4. Những người bên này khá rành mạng không dây Linux, và theo tôi biết driver mt76 trong mainline kernel thực ra cũng do một developer OpenWRT duy trì

  • Blog gốc: https://blog.coffinsec.com/0day/2024/08/30/exploiting-CVE-20...

    • Dịch vụ wappd chủ yếu được dùng để cấu hình và điều phối hoạt động của giao diện không dây và access point bằng Hotspot 2.0 cùng các công nghệ liên quan
      Kiến trúc ứng dụng hơi phức tạp, nhưng về bản chất gồm một dịch vụ mạng, các dịch vụ cục bộ tương tác với giao diện không dây của thiết bị, và kênh giao tiếp giữa các thành phần dùng Unix domain socket
      Điểm còn may là nghe có vẻ đây không phải lỗi nằm trong firmware baseband, mà là vấn đề ở phía dịch vụ “giá trị gia tăng” không thật sự cần thiết cho hoạt động của chính card mạng không dây
      Nó làm tôi nhớ đến cách gói driver của một số thiết bị: driver thật sự thì nhỏ và im lặng, nhưng lại cài kèm bloatware lớn hơn vài bậc độ lớn cho những tính năng mà 99% người dùng không cần và cũng không muốn. Máy in và GPU đặc biệt tệ ở khoản này

  • Tôi tự hỏi trong quy tắc đặt tên của MediaTek có logic gì không, hay mọi thiết bị chỉ đơn giản là MTxxxx với x là số tăng dần hoặc số ngẫu nhiên
    Tôi có một thiết bị dùng chip Wi-Fi mt6631; nó không nằm trong danh sách bị ảnh hưởng nên có thể đoán là ổn, nhưng thật khó biết nó nằm ở đâu trong dòng sản phẩm

  • Họ nói OpenWrt 19.07 và 21.02 bị ảnh hưởng, nhưng nhìn thì có vẻ các bản build OpenWrt chính thức chỉ dùng driver mt76 chứ không dùng SDK của Mediatek

  • Không hiểu sao cứ mua laptop dùng CPU AMD là luôn kèm card Wi-Fi MediaTek RZ616
    Tôi đã thay tất cả bằng card Wi-Fi Intel, và giờ có cả một đống card RZ616 sẽ trở thành vi nhựa trong tương lai

    • Intel bán hai loại card Wi-Fi. Model có số cuối là 1 dùng giao thức CNVI, chỉ chạy với chip Intel và được bán cho OEM với giá rất rẻ
      Model có số cuối là 0 dùng PCIe tiêu chuẩn và bán cho OEM đắt hơn khoảng 10 đô la
      AMD đã rebrand MediaTek MT7921 và MT7922 lần lượt thành RZ608, RZ616 để có thứ bán cho OEM ở cùng mức giá với chip xx1 của Intel
    • Lenovo cũng bất mãn với MediaTek nên bắt đầu hàn chip Qualcomm cho WLAN trên nền tảng AMD, nhưng rồi lại dính lỗi tương tác giữa firmware và driver trên Linux. Điều đó xảy ra dù Lenovo chính thức bán và hỗ trợ Linux
      Khi thế hệ chipset không còn mới nhất, nguồn lực hỗ trợ phía mainline kernel của Qualcomm trở nên khá mỏng. Muốn thúc Qualcomm làm việc thời nay cần áp lực rất lớn từ vendor
    • iwlwifi cũng có vấn đề riêng, lớn nhất là không có chế độ AP 5GHz. Giấy phép firmware của Intel cũng hạn chế hơn MediaTek, và vì là fullmac nên firmware gánh nhiều việc hơn hẳn
      Cá nhân tôi thích softmac hơn. Dạo này không có nhiều lựa chọn tốt, và thời hoàng kim của ath9k đã qua rồi
    • Tôi tò mò không biết bạn đã thật sự dùng thử chưa, thay vì chỉ đơn giản là “không tin MediaTek”
      Tôi lần lượt dùng ThinkPad Intel và ThinkPad AMD cho công việc; Wi-Fi chipset MediaTek ở máy AMD tốt hơn hẳn chipset Intel bên máy Intel
      Bên Intel rớt mạng nhiều lần mỗi giờ, và độ trễ tệ đến mức dùng ssh trên 5GHz cũng cảm nhận được ngay. Thiết bị MT7921 tôi đang dùng hiện rất ổn định trên Linux trong 2–3 năm qua
      Có vẻ cuối cùng vẫn phụ thuộc khá nhiều vào tổ hợp chipset và laptop

  • Tôi nhớ điện thoại của mình cũng dùng chipset MediaTek. Và tôi mang máng nhớ lý do nhà sản xuất sau đó rời bỏ MediaTek là vì, ừm, chất lượng của các sản phẩm đó
    Tôi không biết Wi-Fi trên điện thoại được cấu hình thế nào. Có cách nào kiểm tra điện thoại này có bị ảnh hưởng không? Tôi gần như không dùng Wi-Fi vì có dữ liệu di động không giới hạn và vùng phủ sóng tốt, nhưng biết vẫn hơn

    • Trong termux, chạy "sudo su" rồi xem ls /sys/module là được
      Output sẽ trông tương tự lsmod

  • Ngay cả trong thời nay, khi người ta mua bất cứ loại silicon nào có thể kiếm được, tôi vẫn không hiểu vì sao các vendor hạng C như thế này không theo chiến lược PC: mở hoàn toàn firmware và để cộng đồng mã nguồn mở lo

    • Các quy định của FCC yêu cầu phải làm cho việc phát ngoài băng tần được cấp phép trở nên khó khăn thường dẫn đến tình huống này

  • Bài viết nói “các phiên bản bị ảnh hưởng gồm MediaTek SDK 7.4.0.1 trở xuống và OpenWrt 19.07, 21.02”, “lỗ hổng nằm trong network daemon wappd có trong MediaTek MT7622/MT7915 SDK và gói driver RTxxxx SoftAP”, nhưng thực ra có vẻ OpenWRT không dùng wappd

    • Với tư cách là người đóng góp cho OpenWrt, tôi thắc mắc tại sao mọi người không phân biệt OpenWrt và SDK độc quyền của vendor. Nếu Nobara có bug thì chắc họ đã không nhắc đến Fedora
    • Tôi cũng thắc mắc điểm tương tự vì mạng nhà tôi dùng OpenWRT trên nhiều AP Netgear. Theo mô tả này thì tôi vẫn ổn đúng không

  • Vì vậy chúng ta cần firmware tự do. Tôi chán Broadcom và Ralink lắm rồi