ช่องโหว่ร้ายแรงในชิปเซ็ต Wi-Fi ของ MediaTek: ช่องโหว่ zero-click

 (blog.sonicwall.com)
1 คะแนน โดย GN⁺ 2024-09-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ช่องโหว่ร้ายแรงในชิปเซ็ต Wi-Fi ของ MediaTek: ช่องโหว่ Zero-Click (CVE-2024-20017) คุกคามเราเตอร์และสมาร์ตโฟน

ภาพรวม
  • ทีมวิจัยภัยคุกคาม SonicWall Capture Labs ตรวจพบช่องโหว่ CVE-2024-20017 ประเมินผลกระทบ และพัฒนามาตรการบรรเทา
  • CVE-2024-20017 เป็นช่องโหว่ zero-click ระดับร้ายแรงที่มีคะแนน CVSS 3.0 อยู่ที่ 9.8 ซึ่งส่งผลต่อชิปเซ็ต Wi-Fi MediaTek MT7622/MT7915 และชุดไดรเวอร์ RTxxxx SoftAP
  • MediaTek SDK เวอร์ชัน 7.4.0.1 และก่อนหน้า รวมถึง OpenWrt 19.07 และ 21.02 ที่ถูกใช้ในผลิตภัณฑ์ของผู้ผลิตหลายราย เช่น Ubiquiti, Xiaomi และ Netgear ได้รับผลกระทบ
  • ช่องโหว่นี้เปิดให้รันโค้ดจากระยะไกลได้โดยไม่ต้องมีการโต้ตอบจากผู้ใช้ และ MediaTek ได้แจกจ่ายแพตช์เพื่อบรรเทาปัญหานี้แล้ว
  • ช่องโหว่นี้ถูกเปิดเผยและแพตช์ไปตั้งแต่เดือนมีนาคม แต่ PoC ที่เพิ่งเผยแพร่ล่าสุดทำให้ความเป็นไปได้ในการนำไปใช้โจมตีสูงขึ้น
ภาพรวมทางเทคนิค
  • ช่องโหว่นี้อยู่ใน wappd ซึ่งเป็น network daemon ที่รวมอยู่ใน MediaTek MT7622/MT7915 SDK และชุดไดรเวอร์ RTxxxx SoftAP
  • wappd มีหน้าที่ตั้งค่าและจัดการ wireless interface และ access point โดยเฉพาะที่เกี่ยวข้องกับเทคโนโลยี Hotspot 2.0
  • สถาปัตยกรรมของ wappd ประกอบด้วยตัวบริการเครือข่ายเอง ชุดบริการภายในเครื่องที่โต้ตอบกับ wireless interface ของอุปกรณ์ และช่องทางสื่อสารระหว่างคอมโพเนนต์ผ่าน Unix domain socket
  • ช่องโหว่นี้เกิดจาก buffer overflow ที่เกิดขึ้นเมื่อมีการนำค่าความยาวซึ่งดึงมาจากข้อมูลแพ็กเก็ตที่ผู้โจมตีควบคุมโดยตรงไปใช้ในการคัดลอกหน่วยความจำ
การกระตุ้นให้เกิดช่องโหว่
  • ช่องโหว่นี้เกิดขึ้นในฟังก์ชัน IAPP_RcvHandlerSSB โดยค่าความยาวที่ผู้โจมตีควบคุมจะถูกส่งต่อไปยังมาโคร IAPP_MEM_MOVE
  • ไม่มีการตรวจสอบขอบเขตใด ๆ นอกจากตรวจว่าต้องไม่เกินความยาวแพ็กเก็ตสูงสุด 1600 ไบต์
  • ผู้โจมตีต้องส่งแพ็กเก็ตโดยแนบโครงสร้างที่คาดหมายไว้ไว้ด้านหน้าของ payload สำหรับโจมตี
  • ความยาวของโครงสร้าง RT_IAPP_HEADER ต้องมีขนาดเล็ก และฟิลด์ RT_IAPP_HEADER.Command ต้องเป็น 50
การนำไปใช้โจมตี
  • โค้ด exploit ที่เผยแพร่สาธารณะใช้ ROP chain เพื่อทำให้เกิดการรันโค้ดจากระยะไกลด้วยเทคนิคเขียนทับ global address table
  • มีการใช้การเรียก system() เพื่อรันคำสั่งที่ส่ง reverse shell กลับไปยังผู้โจมตี
  • reverse shell ถูกตั้งค่าด้วยเครื่องมือ Bash และ Netcat
การป้องกันของ SonicWall
  • SonicWall ได้เผยแพร่ซิกเนเจอร์ต่อไปนี้เพื่อให้ลูกค้าป้องกันการโจมตีจากช่องโหว่นี้ได้
    • IPS: 20322 MediaTek MT7915 wlan Service OOB Write 1
    • IPS: 20323 MediaTek MT7915 wlan Service OOB Write 2
คำแนะนำในการบรรเทาความเสี่ยง
  • เนื่องจากมีการเผยแพร่โค้ด exploit แล้ว จึงขอแนะนำอย่างยิ่งให้ผู้ใช้อัปเกรดเป็นเฟิร์มแวร์เวอร์ชันล่าสุดสำหรับชิปเซ็ตที่ได้รับผลกระทบ
ลิงก์ที่เกี่ยวข้อง

สรุปโดย GN⁺

  • บทความนี้กล่าวถึงช่องโหว่ zero-click ระดับร้ายแรงในชิปเซ็ต Wi-Fi ของ MediaTek ซึ่งเปิดให้รันโค้ดจากระยะไกลได้โดยไม่ต้องมีการโต้ตอบจากผู้ใช้
  • ทีมวิจัยของ SonicWall ตรวจพบช่องโหว่นี้และพัฒนามาตรการบรรเทา พร้อมแนะนำให้ผู้ใช้อัปเกรดเป็นเฟิร์มแวร์ล่าสุด
  • ช่องโหว่นี้ส่งผลต่อเราเตอร์และสมาร์ตโฟนจากผู้ผลิตหลายราย และ PoC ที่เพิ่งเผยแพร่ล่าสุดทำให้ความเสี่ยงในการถูกนำไปใช้โจมตีเพิ่มขึ้น
  • ผลิตภัณฑ์ที่มีความสามารถใกล้เคียงกัน ได้แก่ ชิปเซ็ต Wi-Fi ของ Qualcomm และการตรวจสอบอัปเดตด้านความปลอดภัยเป็นประจำเป็นสิ่งสำคัญ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-22
ความเห็นจาก Hacker News

  • ในฐานะคนที่เคยเอาซอร์สโค้ดไดรเวอร์จาก vendor SDK ของ MediaTek ไปเทียบกับ mt76 ก็ไม่ได้รู้สึกแปลกใจเท่าไร พูดแบบดีสุดก็คือมันค่อนข้างเละ
    น่าเสียดายที่เพียงเพราะมันให้ throughput ดีกว่า mt76 อยู่เล็กน้อย จึงยังมีเฟิร์มแวร์ third-party บางชุดที่ใส่ไดรเวอร์ของ vendor ลงไปใช้งานอยู่
    โชคดีที่ใน MediaTek และแผนก WiSoC ยังมีวิศวกรบางคนที่สื่อสารกับชุมชนซอฟต์แวร์เสรีและโอเพนซอร์สอย่างจริงจัง และยังดูแล OpenWrt fork ขนาดเล็กที่อิงกับ mt76 ด้วยตัวเองอยู่ด้วย: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk...

    • ไม่เข้าใจว่าทำไมฮาร์ดแวร์/เฟิร์มแวร์พวกนี้ถึงให้ความรู้สึกเหมือนเอา โค้ดพิสูจน์แนวคิดไปปล่อยใช้จริงใน production กันอยู่เรื่อย ๆ เขาจ้างคนที่รู้จริงไม่ได้หรือไง
    • สงสัยว่ามีข่าวประชาสัมพันธ์หรือข้อมูลอะไรเกี่ยวกับเป้าหมายของโครงการนั้นไหม หรือใน feed ชุดนั้นมีส่วนไหนบ้างที่ ถูกรวมกลับเข้าโครงการต้นน้ำ แล้ว

  • ชื่อเรื่องค่อนข้างทำให้เข้าใจผิดนิดหน่อย ผมมีเราเตอร์ที่ใช้ mt76 Wi‑Fi อยู่หลายตัวที่บ้าน เลยกดเข้ามาเพราะนึกว่าเป็นบั๊กในเฟิร์มแวร์หรือซิลิคอน สรุปว่าเป็นบั๊กในโค้ดจับฉ่ายจาก SDK ของ vendor ก็เลยโล่งใจ
    ทั้งที่การรองรับ mt76 ใน mainline kernel กับ hostapd ก็ค่อนข้างดีอยู่แล้ว แต่ก็ยังไม่เข้าใจว่าใครจะอยากใช้ตัวนั้น

    • จะบอกว่า “โล่งใจเพราะเป็นบั๊กในโค้ดจับฉ่ายจาก SDK ของ vendor” ก็พูดยาก เพราะ vendor ที่น่ากังวลมีหลายเจ้า
      ในบทความระบุว่าเป็น “driver bundle ที่ถูกใช้ในผลิตภัณฑ์จากผู้ผลิตหลายราย รวมถึง Ubiquiti, Xiaomi, Netgear และรายอื่น ๆ”
      แต่ก็มี vendor บางราย เช่น Ubiquiti ที่ระบุว่าในผลิตภัณฑ์จริงของตัวเองไม่ได้ใช้สิ่งนี้: https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
    • มีการระบุว่า OpenWRT สาย 21.02.x ก็ ได้รับผลกระทบแม้จะอิงกับ mainline kernel 5.4 คนฝั่งนี้มักจะรู้เรื่อง Linux wireless networking ดีพอสมควร และเท่าที่รู้ ไดรเวอร์ mt76 ใน mainline kernel ก็ยังมีนักพัฒนา OpenWRT เป็นผู้ดูแลอยู่ด้วย

  • บล็อกต้นฉบับ: https://blog.coffinsec.com/0day/2024/08/30/exploiting-CVE-20...

    • บริการ wappd ถูกใช้เป็นหลักเพื่อกำหนดค่าและประสานการทำงานของอินเทอร์เฟซไร้สายและการทำงานของ access point โดยอาศัย Hotspot 2.0 และเทคโนโลยีที่เกี่ยวข้อง
      โครงสร้างของแอปพลิเคชันค่อนข้างซับซ้อนอยู่บ้าง แต่โดยแก่นแล้วมันประกอบด้วย network service ตัวหนึ่ง, local service ที่โต้ตอบกับอินเทอร์เฟซไร้สายของอุปกรณ์, และช่องทางสื่อสารระหว่างองค์ประกอบต่าง ๆ ที่ใช้ Unix domain socket
      อย่างน้อยเรื่องที่ยังพอโล่งใจได้ก็คือ ฟังดูเหมือนนี่จะไม่ใช่บั๊กในเฟิร์มแวร์ baseband แต่เป็นปัญหาในบริการ “เพิ่มมูลค่า” ที่ไม่ได้จำเป็นต่อการทำงานพื้นฐานของการ์ดเครือข่ายไร้สายเอง
      มันทำให้นึกถึงบางแพ็กเกจไดรเวอร์ของอุปกรณ์ที่ตัวไดรเวอร์จริงเล็กและเงียบมาก แต่กลับพ่วง bundleware ที่ใหญ่กว่ากันหลายหลัก มาด้วยเพื่อฟีเจอร์ที่ผู้ใช้ 99% ไม่ต้องการและไม่อยากได้ โดยเฉพาะพวกเครื่องพิมพ์กับ GPU

  • สงสัยว่ากฎการ ตั้งชื่อรุ่น ของ MediaTek มีตรรกะอะไรอยู่หรือเปล่า หรือว่าอุปกรณ์ทุกอย่างเป็นแค่ MTxxxx แล้ว x ก็เป็นเลขเรียงหรือเลขสุ่ม
    ผมมีอุปกรณ์ที่ใช้ชิป Wi‑Fi mt6631 ซึ่งไม่ได้อยู่ในรายชื่อที่ได้รับผลกระทบ เลยพอจะเดาได้ว่าน่าจะปลอดภัย แต่ก็ยังยากที่จะรู้ว่ามันอยู่ตรงไหนของตระกูลผลิตภัณฑ์นี้

  • เขาว่า OpenWrt 19.07 และ 21.02 ได้รับผลกระทบ แต่เท่าที่ดูเหมือน build ทางการของ OpenWrt จะใช้แค่ไดรเวอร์ mt76 ไม่ได้ใช้ MediaTek SDK

    • Ubiquti ก็คล้ายกัน: https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
      เขาบอกว่ามีไดรเวอร์ที่มีช่องโหว่สำหรับชิปเซ็ตบางตัวที่ใช้ในฮาร์ดแวร์ UBNT ก็จริง แต่ไม่มีผลิตภัณฑ์ตัวไหนเลยที่ใช้ไดรเวอร์นั้น

  • ไม่เข้าใจว่าทำไมโน้ตบุ๊กที่ใช้ AMD CPU ถึงชอบแถม การ์ด Wi‑Fi MediaTek RZ616 มาด้วยตลอด
    ผมเปลี่ยนเป็นการ์ด Wi‑Fi ของ Intel มาตลอด และตอนนี้ก็เลยมีกองการ์ด RZ616 ที่จะกลายเป็นไมโครพลาสติกในอนาคตอยู่กองหนึ่ง

    • Intel ขายการ์ด Wi‑Fi อยู่สองแบบ รุ่นที่ลงท้ายด้วย 1 ใช้ โปรโตคอล CNVI จึงทำงานได้เฉพาะกับชิป Intel และขายให้ OEM ในราคาถูกมาก
      ส่วนรุ่นที่ลงท้ายด้วย 0 ใช้ PCIe มาตรฐาน และขายให้ OEM แพงกว่าราว 10 ดอลลาร์
      AMD จึงเอา MediaTek MT7921 และ MT7922 มา rebrand เป็น RZ608 และ RZ616 ตามลำดับ เพื่อให้มีของไปขาย OEM ในช่วงราคาเดียวกับชิป xx1 ของ Intel
    • Lenovo เองก็เริ่มไม่พอใจกับ MediaTek จนหันไปบัดกรีชิป Qualcomm สำหรับ WLAN ลงบนแพลตฟอร์ม AMD แต่ก็ยังเจอปัญหาเพราะ บั๊กการทำงานร่วมกันระหว่างเฟิร์มแวร์กับไดรเวอร์ บน Linux อยู่ดี ทั้งที่ Lenovo ก็ขายและซัพพอร์ต Linux อย่างเป็นทางการ
      พอชิปเซ็ตรุ่นนั้นไม่ใช่รุ่นใหม่ล่าสุดแล้ว Qualcomm ก็มักจะมีทรัพยากรฝั่งการรองรับ mainline kernel ค่อนข้างบาง ทุกวันนี้ถ้าอยากให้ Qualcomm ขยับต้องใช้แรงกดดันจาก vendor มหาศาล
    • iwlwifi เองก็มีปัญหาในแบบของมัน และอันใหญ่สุดคือไม่มี โหมด AP 5GHz ใบอนุญาตเฟิร์มแวร์ของ Intel ก็เข้มงวดกว่า MediaTek ด้วย และเพราะเป็น fullmac เฟิร์มแวร์จึงต้องรับภาระงานมากกว่ามาก
      ส่วนตัวผมชอบ softmac มากกว่า เดี๋ยวนี้ตัวเลือกดี ๆ มีไม่เยอะแล้ว และยุคทองของ ath9k ก็ผ่านไปนานแล้ว
    • สงสัยว่าที่เปลี่ยนมันออกนี่ได้ลองใช้งานจริงหรือเปล่า มากกว่าจะเป็นแค่ “ไม่ไว้ใจ MediaTek”
      ผมเคยใช้ทั้ง ThinkPad Intel และ ThinkPad AMD สำหรับงาน และ Wi‑Fi ของชิปเซ็ต MediaTek ฝั่ง AMD กลับดีกว่าชิปเซ็ต Intel ฝั่ง Intel มาก
      ฝั่ง Intel หลุดการเชื่อมต่อเครือข่ายหลายครั้งต่อชั่วโมง และ latency แย่มากจนรู้สึกได้ทันทีเวลาใช้ ssh แม้อยู่บน 5GHz ส่วนอุปกรณ์ MT7921 ที่ใช้อยู่ตอนนี้มีเสถียรภาพมากบน Linux ตลอด 2–3 ปีที่ผ่านมา
      ดูเหมือนว่าสุดท้ายแล้วมันขึ้นอยู่กับคู่ผสมระหว่างชิปเซ็ตกับตัวโน้ตบุ๊กพอสมควร

  • เท่าที่จำได้ โทรศัพท์ของผมก็ใช้ชิปเซ็ต MediaTek เหมือนกัน และผมก็จำลาง ๆ ได้ว่าที่ผู้ผลิตเลิกใช้ MediaTek ในภายหลังก็เพราะ เอ่อ คุณภาพ ของสินค้าพวกนั้น
    ผมไม่รู้ว่า Wi‑Fi บนมือถือถูกจัดวางอย่างไรบ้าง มีวิธีเช็กไหมว่าโทรศัพท์เครื่องนี้ได้รับผลกระทบหรือเปล่า? ปกติผมแทบไม่ใช้ Wi‑Fi อยู่แล้วเพราะมีดาต้ามือถือไม่จำกัดและสัญญาณก็ดี แต่รู้ไว้ก็คงดี

    • รัน "sudo su" ใน termux แล้วตามด้วย ls /sys/module ได้เลย
      เอาต์พุตจะคล้ายกับ lsmod

  • แม้ในยุคนี้ที่คนซื้อซิลิคอนอะไรก็เอาหมดตามที่หาได้ ผมก็ยังไม่เข้าใจว่าทำไม vendor ระดับ C พวกนี้ไม่เดินตามกลยุทธ์ฝั่ง PC ด้วยการเปิดเฟิร์มแวร์ทั้งหมด แล้วปล่อยให้ชุมชนโอเพนซอร์สดูแลไปเลย

    • ปกติสถานการณ์แบบนี้มักเกิดจาก ข้อกำหนดของ FCC ที่ต้องทำให้การส่งสัญญาณนอกย่านที่อนุญาตทำได้ยาก

  • มีข้อความว่า “เวอร์ชันที่ได้รับผลกระทบรวมถึง MediaTek SDK 7.4.0.1 หรือต่ำกว่า และ OpenWrt 19.07, 21.02” และ “ช่องโหว่อยู่ใน wappd ซึ่งเป็น network daemon ที่รวมมาใน MediaTek MT7622/MT7915 SDK และ RTxxxx SoftAP driver bundle” แต่ดูเหมือนว่า OpenWRT ไม่ได้ใช้ wappd เลย

    • ในฐานะผู้มีส่วนร่วมกับ OpenWrt ผมสงสัยว่าทำไมคนถึงไม่แยก OpenWrt ออกจาก vendor SDK แบบปิดซอร์ส ถ้า Nobara มีบั๊ก ก็คงไม่มีใครพูดว่า Fedora มีบั๊กหรอก
    • ผมก็สงสัยเหมือนกันเพราะที่บ้านใช้ AP ของ Netgear หลายตัวที่แฟลช OpenWRT อยู่ ถ้าตามคำอธิบายนี้ก็น่าจะไม่มีปัญหาสินะ

  • เพราะแบบนี้แหละถึงต้องมี เฟิร์มแวร์เสรี ผมเบื่อ Broadcom กับ Ralink เต็มทีแล้ว