ความไม่มั่นคงของสแต็กโทรคมนาคมที่เผยให้เห็นหลัง Salt Typhoon

 (soatok.blog)
1 คะแนน โดย GN⁺ 2025-03-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังเหตุละเมิดของ Salt Typhoon ระหว่างตรวจสอบโอเพนซอร์สด้านโทรคมนาคม พบ บัฟเฟอร์โอเวอร์โฟลว์แบบไม่ต้องยืนยันตัวตน ในไลบรารี XMLRPC ที่บันเดิลมากับ FreeSWITCH
  • ช่องโหว่เกิดจากโค้ดที่เขียน Request URI ที่ผู้โจมตีส่งมา ลงในตัวแปรสแตกขนาด 4096 ไบต์ด้วย sprintf() และอาจสามารถส่ง คำขอที่ยาวเกิน 4096 อักขระ ได้ โดยไม่ขึ้นกับข้อจำกัดของเบราว์เซอร์
  • SignalWire ตอบว่า PR แก้ไข 3 รายการถูกเผยแพร่บน GitHub ในเดือนกุมภาพันธ์ 2025 แต่ระบุว่า FreeSWITCH Community ยังไม่มีแผนออกรีลีสใหม่จนถึงฤดูร้อนปี 2025
  • บน Shodan มีผลการค้นหา FreeSWITCH ประมาณ 8,300 รายการ และผู้ดูแลที่ไม่มีแท็กรีลีสต้องรับมือเองด้วยการบิลด์จากซอร์สหรือบล็อกด้วยไฟร์วอลล์
  • กรณีนี้แสดงให้เห็นว่าความเสี่ยงด้านความปลอดภัยโทรคมนาคมไม่ได้เพิ่มขึ้นจากตัวช่องโหว่เท่านั้น แต่ยังมาจาก การจัดการช่องโหว่และการตอบสนองด้านรีลีส ด้วย และแม้ CVE-2025-44087 จะถูกกำหนดเมื่อวันที่ 30 เมษายน 2025 ก็ยังไม่มีรีลีสของ FreeSWITCH

จุดเริ่มต้นที่ทำให้ตรวจสอบ FreeSWITCH หลัง Salt Typhoon

  • ปลายปี 2024 ข่าวที่ว่ากลุ่ม Salt Typhoon ซึ่งมีรายงานว่าเกี่ยวข้องกับรัฐบาลจีน ละเมิดระบบของ T-Mobile และผู้ให้บริการโทรคมนาคมรายอื่น ๆ กลายเป็นจุดเริ่มต้น
  • แม้จะไม่สามารถตรวจสอบเครือข่ายผู้ให้บริการมือถือได้โดยตรง แต่บน GitHub มี โปรเจกต์โอเพนซอร์ส ที่เกี่ยวข้องกับโทรคมนาคมจำนวนมาก
  • เคยมีประสบการณ์ทำงานกับบริษัทที่ใช้ Asterisk และ FreeSWITCH มาก่อน แต่ไม่เคยวิเคราะห์ PBX, SIP และการเข้ารหัสเสียงอย่างลึกซึ้ง
  • คาดว่าในวงการโทรคมนาคมมีโปรแกรมเมอร์ C ที่ยอดเยี่ยม ชุมชนแฮกเกอร์เก่าแก่ และธรรมเนียมของวิศวกรจาก Bell Labs ดังนั้นช่องโหว่พื้น ๆ น่าจะถูกพบไปแล้ว
  • แต่ทันทีที่เปิดดูซอร์สโค้ดของ FreeSWITCH ก็พบช่องโหว่

บัฟเฟอร์โอเวอร์โฟลว์ในตัวจัดการคำขอ HTTP ของ XMLRPC

  • ตัวจัดการคำขอ HTTP ของไลบรารี XMLRPC ที่บันเดิลมากับ FreeSWITCH เขียน URI ลงใน บัฟเฟอร์บนสแตกขนาดคงที่ z[4096]
  • โค้ดที่เป็นปัญหาอยู่ในรูป sprintf(z, "Index of %s" CRLF, uri); โดย uri มาจากส่วน path ของ Request URI จึงถูกควบคุมโดยผู้โจมตีได้
  • เบราว์เซอร์ทั่วไปมักไม่รองรับ URL ที่ยาวกว่า 2048 อักขระนัก แต่ RFC ที่เกี่ยวข้องส่วนใหญ่รองรับได้ราว 8KB และ Cloudflare รองรับถึง 32KB
  • จึงสมเหตุสมผลที่จะมองว่าผู้โจมตีสามารถส่ง Request URI ที่ยาวเกิน 4096 อักขระได้ และเงื่อนไขนี้นำไปสู่ บัฟเฟอร์โอเวอร์โฟลว์แบบไม่ต้องยืนยันตัวตน ในไลบรารี XMLRPC
  • ไม่กล่าวถึงกระบวนการขยายผลไปสู่การรันโค้ดจากระยะไกล

วิธีแก้และแพตช์ที่เผยแพร่

  • แนวทางแก้ไขคือใช้ snprintf() แทน sprintf()
  • นี่ถือเป็นแนวปฏิบัติพื้นฐานของการเขียน C แบบป้องกันความผิดพลาด
  • SignalWire ระบุว่าปัญหาถูกแก้ไขเมื่อไม่นานมานี้ พร้อมชี้ไปยัง PR ต่อไปนี้
  • เนื่องจากแพตช์ถูกเผยแพร่บน GitHub แล้ว จึงเห็นว่าสามารถเขียนบทความสาธารณะได้

กระบวนการเปิดเผยช่องโหว่และช่องว่างของรีลีส

  • วันที่ 27 มกราคม 2025 ส่งรายละเอียดช่องโหว่ไปยังอีเมลที่ระบุไว้ในนโยบายความปลอดภัยของ FreeSWITCH
  • วันที่ 7 กุมภาพันธ์ 2025 ส่งอีเมลติดตามเพื่อยืนยันว่าได้รับรายงานหรือไม่
  • วันเดียวกัน Andrey Volk ตอบว่าช่องโหว่ถูกแก้ไขเมื่อไม่นานมานี้ และให้ดู PR ที่เกี่ยวข้อง
  • เมื่อถามถึงกำหนดการแท็กรีลีสที่รวมแพตช์ความปลอดภัยใหม่ ได้รับคำตอบว่ารีลีส FreeSWITCH Community ยังไม่มีแผนจนถึงฤดูร้อนปี 2025
  • ด้วยเหตุนี้ ผู้ใช้ที่ไม่ได้จ่ายค่า FreeSWITCH Advantage อาจยังคงอยู่ในสถานะเสี่ยงจนกว่าจะถึงรีลีสปกติ

ขนาดการเปิดเผยและผลกระทบต่อผู้ดูแลระบบ

  • ขณะนั้นผลการค้นหา FreeSWITCH บน Shodan มีประมาณ 8,300 รายการ
  • เนื่องจากยากจะเชื่อว่าอินสแตนซ์เหล่านี้ทั้งหมดจ่ายค่าสนับสนุนระดับองค์กร จึงมองได้ว่าสแต็กโทรคมนาคมหลายพันแห่งทั่วโลกอาจยังคงมีช่องโหว่จนถึงฤดูร้อน
  • แม้แพตช์จะเผยแพร่บน GitHub แล้ว แต่หากไม่มีแท็กรีลีส ผู้ดูแลทั่วไปก็อัปเดตได้ยาก
  • ผู้ดูแล FreeSWITCH ควรพิจารณามาตรการต่อไปนี้ แทนการรอรีลีสจาก SignalWire
    • รีบิลด์ โดยตรงจากซอร์ส
    • บล็อกการเข้าถึง HTTP สาธารณะ ของสแตก FreeSWITCH ในระดับไฟร์วอลล์

ปัญหาเชิงโครงสร้างของความปลอดภัยโทรคมนาคม

  • จากการพูดคุยกับคนรู้จักในวงการโทรคมนาคม มีปฏิกิริยาว่าแม้แต่ความเร็วในการตอบสนองของ FreeSWITCH ก็ถือว่าเร็วแล้ว
  • แม้ในเดือนธันวาคม 2024 ก็ยังมีการเตือนอีกครั้งเกี่ยวกับ ช่องโหว่ SS7 ที่มีอยู่ในเครือข่ายโทรศัพท์มานาน 17 ปี
  • หลังประสบการณ์นี้ ไม่ได้ตรวจสอบ Asterisk หรือซอฟต์แวร์อื่นเพิ่มเติม
  • สรุปได้ว่า ความปลอดภัยโทรคมนาคมในปัจจุบันอยู่ในสภาพไม่ดี
  • สาเหตุใหญ่ดูเหมือนจะเป็นการที่แทบไม่มีแรงจูงใจทางการเงินในการทำให้ระบบเหล่านี้ปลอดภัย

สถานะหลังจากนั้น

  • ในอัปเดตวันที่ 30 เมษายน 2025 บัฟเฟอร์โอเวอร์โฟลว์ที่รายงานได้รับหมายเลข CVE-2025-44087
  • ณ เวลาเดียวกัน ก็ยังไม่มีแท็กหรือรีลีสของ FreeSWITCH

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

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

 
GN⁺ 2025-03-14
ความคิดเห็นจาก Hacker News

  • ผู้เขียนยอมรับว่า ไม่มีประสบการณ์ด้านโครงสร้างพื้นฐานระดับผู้ให้บริการโทรคมนาคมเลย แต่ข้อสงสัยโดยรวมถือว่าถูกต้อง
    ที่จริงเคยทำ penetration test และงานวิจัยความปลอดภัยกับ 4G/5G ให้ผู้ให้บริการโทรคมนาคมรายใหญ่หลายรายอยู่พอสมควร และแม้จะแตกต่างกันไปตามผู้ให้บริการและผู้ผลิตอุปกรณ์ แต่ก็ยังใกล้เคียงกับโชว์สยองขวัญเต็มรูปแบบ
    จนกระทั่งไม่นานมานี้ ความปลอดภัยแทบจะเป็นแค่ security through obscurity เท่านั้น และแม้มาตรฐาน 4G/5G จะเริ่มจัดการเรื่องนี้แล้ว แต่ก็ยังมีช่องโหว่ขนาดใหญ่ที่น่ากังวลอย่างร้ายแรงหลงเหลืออยู่
    ไม่เกินจริงที่จะมองว่าผู้คุกคามระดับกลางขึ้นไปที่ต้องการสร้าง foothold ในผู้ให้บริการโทรคมนาคมสามารถทำได้ และเคยสาธิตให้เห็นหลายครั้งในฐานะงานอาชีพ
    ผู้ผลิตอุปกรณ์จากประเทศหนึ่งในเอเชียตะวันออกบางรายมีคุณภาพ software stack ต่ำมากจนแทบจัดเป็น APT ได้ และความปลอดภัยแทบไม่มีอยู่จริง
    ประเทศตะวันตกมีเหตุผลสมควรที่แบนพวกเขา และซอฟต์แวร์ของผู้ผลิตอุปกรณ์ฝั่งตะวันตกนั้นสุกงอมกว่ามาก แต่ก็ยังล้าหลังจากระดับที่เราจะถือว่าเป็นแนวปฏิบัติด้านความปลอดภัยสมัยใหม่อยู่หลายปี

    • เมื่อไม่กี่ปีก่อน สหราชอาณาจักรซื้อ อุปกรณ์ Huawei และตั้งห้องปฏิบัติการร่วมระหว่างรัฐบาล/Huawei เพื่อวิเคราะห์ซอร์สโค้ดและตรวจสอบความปลอดภัย
      GCHQ มองว่าคุณภาพโค้ดอยู่ในระดับที่ตรวจสอบไม่ได้ และยังไม่สามารถรับประกันได้ด้วยซ้ำว่าซอร์สโค้ดที่ให้มานั้นเป็นโค้ดที่รันอยู่จริงในอุปกรณ์หรือไม่
      เพราะ Huawei สามารถอัปเดตเองได้ และเท่าที่ทราบ อุปกรณ์ดังกล่าวถูกแบนหลังปี 2020: https://www.washingtonpost.com/world/national-security/brita...
    • อยากรู้ว่ามีบทวิเคราะห์สาธารณะเกี่ยวกับอุปกรณ์เฉพาะรุ่นพวกนี้ไหม
      อยากซื้อจาก AliExpress มาสักตัวแล้วแกะดู ลิงก์นี้เป็นจุดเริ่มต้นที่พอใช้ได้ไหม?
      https://vulners.com/search/types/huawei
    • อยากรู้ว่าแฮกเกอร์ทั่วไปจะหาอุปกรณ์แบบนี้มาศึกษาได้อย่างไร
    • พอได้ยินว่าซอฟต์แวร์สแตกของผู้ผลิตอุปกรณ์จากประเทศหนึ่งในเอเชียตะวันออกบางรายแย่มากจนแทบเรียกได้ว่าเป็น APT ก็อดอยากเหน็บไม่ได้ว่า โชคดีจริง ๆ ที่มีผู้ผลิตฮาร์ดแวร์และซอฟต์แวร์จากประเทศหนึ่งในอเมริกาเหนือที่ให้ความสำคัญกับความปลอดภัยอย่างจริงจังมาก

  • ในปี 2025 ก็ยังไม่เข้าใจจริง ๆ ว่าทำไมมาตรฐานเครือข่ายมือถือยังใช้ pre-shared key อยู่
    RSA และ Diffie-Hellman[1] มีมาหลายสิบปีแล้ว ระบบหน่วยงานออกใบรับรองก็มีมานาน แต่ SIM card ก็ยังถูกออกด้วย pre-shared key ที่มีเพียงการ์ดกับผู้ให้บริการโทรคมนาคมเท่านั้นที่รู้ และการยืนยันตัวตนกับการเข้ารหัสหลังจากนั้นทั้งหมดก็อิงกับคีย์นั้น
    ถ้าผู้ให้บริการถูกแฮ็กและคีย์รั่ว ก็ทำอะไรไม่ได้เลย
    ที่แย่กว่านั้นคือผู้ผลิต SIM card ต้องส่งคีย์นั้นให้ผู้ให้บริการ และผู้ผลิตอาจอยู่ในประเทศอื่นจนตกอยู่ภายใต้คำสั่งของรัฐบาลต่างชาติได้ จึงมีโอกาสมากพอทั้งจากการแฮ็กผู้ผลิตหรือการขโมยระหว่างส่ง
    นี่ให้ความรู้สึกเหมือน ช่องโหว่แบบ NOBUS และถ้าผู้ผลิต SIM หรือผู้ผลิตอุปกรณ์ core network สมคบกับ NSA แล้วส่งคีย์ให้ ก็อาจดักฟังทราฟฟิกมือถือทั่วโลกได้ในเชิงศักยภาพ
    [1] รู้ว่าอัลกอริทึมเหล่านี้ไม่ใช่แนวปฏิบัติที่ดีที่สุดแล้ว และ elliptic curve ดีกว่า แต่ถึงอย่างไร RSA ก็ยังดีกว่าสิ่งที่เป็นอยู่ตอนนี้
    [2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...

    • Gemalto ถูกแฮ็กเมื่อ 15 ปีก่อน
      “ตามเอกสารลับสุดยอดของ NSA ที่ Edward Snowden มอบให้ สายลับสหรัฐฯ และสหราชอาณาจักรแฮ็กเข้าไปในเครือข่ายคอมพิวเตอร์ภายในของผู้ผลิต SIM card รายใหญ่ที่สุดของโลก และขโมยคีย์เข้ารหัสที่ใช้ปกป้องความเป็นส่วนตัวของการสื่อสารผ่านโทรศัพท์มือถือทั่วโลก”
      https://theintercept.com/2015/02/19/great-sim-heist/
    • เคยคุยกับวิศวกรโทรศัพท์ พวกเขาบอกว่าเวลาต่อกับสถานีฐานเพื่อดีบัก สามารถ อ่านข้อความ SMS ทั้งหมดที่วิ่งผ่านได้แบบดิบ ๆ
      ไม่รู้ว่าตอนนี้ยังเป็นแบบนั้นไหม แต่สมัยก่อนโทรศัพท์มือถือแทบถือว่าเป็นช่องทางสื่อสารที่ปลอดภัยไม่ได้
      น่าจะต้องคุยกันผ่านการสื่อสารข้อมูลที่เข้ารหัสแบบปลายทางถึงปลายทางระหว่างอุปกรณ์
    • อัลกอริทึมบางตัวต้องรันบน SIM card และอย่างน้อยในอดีต smart card ต้องมี co-processor ที่ทำให้ต้นทุนสูงขึ้นเพื่อรองรับ RSA หรือ Diffie-Hellman แบบไม่ใช่ elliptic curve
      อัลกอริทึมกุญแจสมมาตรก็มีข้อดีตรงที่ปลอดภัยต่อควอนตัมด้วย
      ถึงอย่างนั้น ปี 2025 แล้วก็อยากให้รองรับอย่างน้อย ECC และตอนนี้ smart card ส่วนใหญ่ก็ควรรองรับได้เป็นพื้นฐานแล้ว
      ถ้าเชื่อถือผู้ผลิต SIM card ไม่ได้ ก็แทบไม่มีทางออก
      แม้ในวิธีแบบอสมมาตร เส้นทางโจมตีก็แค่เปลี่ยนไปเล็กน้อยเท่านั้น ถ้าเชื่อถือซอฟต์แวร์ที่รันบนการ์ดไม่ได้ แล้วจะรู้ได้อย่างไรว่ามันไม่รั่วไหล plaintext ผ่านการเลือกเลขสุ่มของอัลกอริทึมแบบไม่กำหนดตายตัว
    • ถ้าสามารถแจกจ่ายคีย์ได้โดยตรง การเข้ารหัสแบบอสมมาตร จะเพิ่มความซับซ้อนเมื่อเทียบกับสิ่งที่ได้มา
      แนวคิดว่าการใส่ RSA ลงในระบบสมมาตรแล้วจะปลอดภัยขึ้นนั้นมีหลักฐานรองรับน้อย และค่อนข้างตรงกันข้ามด้วยซ้ำ
      คำว่า “ช่องโหว่แบบ NOBUS” ก็แปลกเป็นพิเศษ เพราะ root of trust ของระบบแบบนี้คือผู้ให้บริการโทรคมนาคม
      ไม่จำเป็นต้องถามด้วยซ้ำว่าผู้ให้บริการสหรัฐฯ “สมคบ” กับหน่วยข่าวกรองสหรัฐฯ หรือไม่ ควรมองว่าเป็นอย่างนั้นอยู่แล้ว
    • เคยทำงานฝ่ายสนับสนุนทางเทคนิค/บริการลูกค้าที่ผู้ให้บริการโทรคมนาคมรายใหญ่ เห็นปัญหาความปลอดภัยหลายอย่าง และเมื่อยกเรื่องนี้ขึ้นมาพร้อมแนวทางแก้ที่ช่วยปรับปรุงบริการลูกค้า ก็ได้รับคำตอบว่าบริษัทจะเสียเงิน
      มิจฉาชีพคือลูกค้ารายใหญ่ของผู้ให้บริการโทรคมนาคม และเมื่อถูกจับและบล็อก ก็จะกลับมาเปิดสายใหม่ เสียค่าธรรมเนียมเปิดใช้ แล้วทำวงจรเดิมซ้ำ
      มิจฉาชีพยังช่วยให้ขายฟีเจอร์เสริมแบบ upsell ได้ด้วย จึงยังมีกำไรอีกทางจากการไม่แก้ปัญหา

  • ไม่น่าแปลกใจเลยที่ Freeswitch จะไม่เปลี่ยน กำหนดการออก community release ตามบทสรุปของบล็อกโพสต์
    Freeswitch ในอดีตเคยมีจิตวิญญาณชุมชนที่เข้มแข็ง แต่หลังจากถูกทำให้เป็นเชิงพาณิชย์อย่างรุกมากขึ้นเมื่อหลายปีก่อน บรรยากาศก็เปลี่ยนไป
    หลังจากนั้น หากต้องการเข้าถึงสิ่งที่ควรเปิดเผยต่อสาธารณะ ก็ต้องผ่านขั้นตอน “ลงทะเบียน” และเท่าที่จำได้ เหมือนว่า APT repository อะไรสักอย่างถูกซ่อนไว้หลังกำแพงการลงทะเบียน
    ผมไม่อยากลงทะเบียนกับบริษัทเชิงพาณิชย์เพื่อเข้าถึงคอนเทนต์ของชุมชนซอฟต์แวร์เสรี
    เพราะทุกคนในวงการเทคโนโลยีรู้กันดีว่า เมื่อให้ข้อมูลกับบริษัทเชิงพาณิชย์แล้ว พนักงานขายจะมากวนด้วยการ upsell/cross-sell และยัดเราเข้า mailing list ที่ไม่ต้องการ

    • ถ้าจะพูดเข้าข้าง SignalWire บ้าง พออ่าน mailing list เก่า ๆ แล้วรู้สึกว่าพวกเขานำการพัฒนา Freeswitch มาหลายปี แต่ไม่ได้รับค่าตอบแทนที่เหมาะสมจากโปรเจกต์ย่อยต่าง ๆ
      ผมเห็นส่วนอื่น ๆ ของชุมชน VoIP ก็ปรับท่าทีเรื่องความใจกว้างต่อโอเพนซอร์สใหม่เหมือนกัน และพูดตามตรงก็โทษได้ยาก
      ทีม Matrix.org ก็พูดเรื่องคล้ายกันในงานนำเสนอหนึ่งที่ FOSDEM’25 ว่ามีปัญหาผู้ขายเชิงพาณิชย์อาศัยงานพัฒนาแบบฟรี ๆ
    • ถ้าผมเข้าใจผิดก็ช่วยแก้ด้วย แต่ source code ที่แพตช์แล้วไม่ได้เปิดเผยอยู่แล้วหรือ?
      ถ้าพวกเขาอัปเดต APT repository ให้ฟรีด้วยก็คงน่าขอบคุณมาก แต่ก็เป็นเพียง “เรื่องน่าขอบคุณ” เท่านั้น
      ถ้าพึ่งพาโค้ดของพวกเขาแต่ไม่อยากจ่ายค่าสนับสนุน ก็ build แพ็กเกจ APT เองได้
      ผมไม่แน่ใจว่าควรคาดหวังจิตวิญญาณชุมชนแบบไหนจากโปรเจกต์ที่มีบริษัทเดียวดูแลแบบนี้

  • เมื่อพิจารณาถึงผู้คุกคามจากต่างชาติ พันธมิตรตะวันตกอย่าง Five Eyes และแรงกดดันที่ต้องเพิ่มตัวเลขอยู่เรื่อย ๆ ก็น่าจะมองได้ว่าออนไลน์ไม่มี ความไม่ระบุตัวตนที่แท้จริง
    ถ้าพวกเขาต้องการตัวคุณ พวกเขาก็มีวิธีจับคุณ
    ในทางปฏิบัติ มันไม่ได้ต่างจากยุคก่อนอินเทอร์เน็ตมากนัก
    ถ้าไม่อยากถูกดักฟัง ก็ต้องเข้ารหัสด้วยวิธีที่หน่วยงานความมั่นคงขนาดใหญ่เข้าถึงทางอิเล็กทรอนิกส์ได้ไม่ง่าย
    เช่น กระดาษโน้ตจริง การบอกต่อปากต่อปาก หรือภาษามือ
    และเมื่อ actor ระดับรัฐจัดสรรทรัพยากรเพื่อใช้ข้อมูลจริง ๆ ก็ต้องพร้อมรับผลจากสิ่งที่พูดและทำทางออนไลน์

  • จากตัวบทความอย่างเดียว ผมยังไม่เชื่อเต็มที่กับข้อสรุปว่า “ความปลอดภัยด้านโทรคมนาคมในปัจจุบันเละเทะ”
    เพราะมันใกล้เคียงกับการสุ่มเลือก Freeswitch แล้วพบ buffer overflow มากกว่า
    “telecom stack” อาจเปราะบางหรือไม่ก็ได้ แต่หลักฐานที่นำเสนอในที่นี้ค่อนข้างอ่อนมาก
    มีรายงานว่าการโจมตี Salt Typhoon ใช้ช่องโหว่ของ Cisco แต่บรรดานักวิเคราะห์ก็เสนอความเป็นไปได้ว่าผู้โจมตีอาจใช้ credential ที่ถูกต้องตามปกติ: https://cyberscoop.com/cisco-talos-salt-typhoon-initial-acce...
    ดังนั้นจึงไม่เกี่ยวกับ Freeswitch

    • Cisco Unified Call Manager แทบจะแน่นอนว่ามีช่องโหว่ และ Metaswitch ที่ถูกลากต่อมาใน network core แม้ Microsoft จะประกาศฆ่ามันไปแล้วก็เช่นกัน
      Oracle SBC แค่พฤติกรรมพื้นฐานก็มักไม่เสถียรอยู่แล้ว และในความยุ่งเหยิงของ implementation TRouter ที่ Teams ปล่อยออกมาในสัปดาห์นี้ ก็น่าจะมีบั๊ก denial-of-service ที่ยังแยกออกไม่ดีแน่ ๆ
      ยังไม่ต้องพูดถึงความวุ่นวายของ MF Tandem หรือการที่แทบทุกผู้ให้บริการโทรคมนาคมปล่อยทราฟฟิก UDP SIP ดิบแบบไม่เข้ารหัสออกอินเทอร์เน็ตตรง ๆ
      การสร้างระบบที่ปลอดภัยในวงการนี้เป็นไปได้ แต่ความจริงคือผู้ให้บริการรายใหญ่ส่วนใหญ่กำลังใช้งานแพลตฟอร์ม proprietary ที่แก้ไขไม่ได้ของบริษัทหรือโปรเจกต์ที่ตายไปนานแล้วอย่าง Nortel, Metaswitch รวมถึงกองหนี้เทคนิคที่แย่ยิ่งกว่าอุปกรณ์เก่าและไม่ได้แพตช์ที่ประกอบเป็นเครือข่ายเสียอีก
    • หลังจาก SignalWire ละเมิด embargo ผมได้คุยกับ สาย security geek ที่คุ้นเคยกับความปลอดภัยด้านโทรคมนาคมมากกว่า อยู่หลายครั้ง
      คำว่า “ทุกอย่างเละเทะและไม่มีแรงจูงใจจะแก้” เป็นเพียงการสรุปเท่านั้น
      พูดตามตรง บทสนทนาเหล่านั้นตามได้ยากมากถ้าไม่รู้ศัพท์เฉพาะ และผมก็ไม่ได้เข้าใจวงการนี้ดีพอจนอยากอธิบายแบบงุ่มง่าม จึงเขียนไว้แค่นั้น
      ผมไม่เคยคิดเลยว่าบล็อกของผมจะไปโผล่บน Hacker News
    • เคยทำงานกับโค้ดโทรคมนาคมมาแล้ว
      มันเป็นโค้ดที่ parse โปรโตคอลเครือข่ายซับซ้อนซึ่งมี legacy หลายชั่วรุ่น มักเขียนกันแบบปิดลับ และส่วนใหญ่เป็น C/C++
      ของแบบนี้คงไม่มีทางเปราะบางหรอก ใช่ไหมล่ะ
    • telecom stack เต็มไปด้วย การตัดสินใจด้านความปลอดภัยที่น่าสงสัย รวมถึงสิ่งที่มาจากระดับโปรโตคอลเอง
      โปรโตคอลอย่าง SS7 ถูกออกแบบมาโดยไม่มีแนวคิดเรื่องแฮกเกอร์หรือผู้ไม่หวังดี
      จะวางไฟร์วอลล์ทับลงไปก็ได้ แต่จะชนกับฟังก์ชันที่ต้องการ และแม้ไม่ชนก็ต้องลงทุนเพิ่ม
      DIAMETER ดีกว่า แต่ก็ยังมีรูโหว่มาก
      ในช่วงไม่กี่ปีที่ผ่านมา ความปลอดภัยด้านโทรคมนาคมเริ่มเป็นลำดับความสำคัญและมีการปรับปรุงบ้าง แต่ก็ต้องห่อหุ้ม legacy hardware/software/firmware/การออกแบบเครือข่ายที่สะสมมาหลายสิบปี
      ผมไม่คิดว่าจะมีที่ไหนในเครือข่ายโทรคมนาคมที่รัน Freeswitch มาตรฐานตรง ๆ แต่ปัญหาแบบเดียวกับ Freeswitch ในฐานะผลิตภัณฑ์โทรคมนาคมเก่าที่ไม่ได้ถูกตรวจหาด้านความปลอดภัยเท่าที่ควรนั้นมีอยู่ทั่วไป
    • บล็อกโพสต์นี้คือการผสมกันของ “ผมลองทำสิ่งที่ทำเป็นอาชีพ” กับ “ฝ่ายที่ได้รับรายงานจากผมไม่ได้มีค่านิยมร่วมกับผมและวงการความปลอดภัย” แล้วสรุปว่าความปลอดภัยด้านโทรคมนาคมเละเทะ
      การที่ผู้เขียนใช้เวลาว่างดูโค้ด หา bug และรายงานนั้นเป็นเรื่องยอดเยี่ยม และผมไม่อยากขัดขวางเลย
      แต่แค่ข้อเท็จจริงที่ maintainer คนหนึ่งของซอฟต์แวร์หนึ่งตัวไม่ได้ก้มหัวให้ผู้เขียนตาม best practice ของวงการความปลอดภัย ก็ยังเป็นหลักฐานที่อ่อนเกินไปที่จะบอกว่า “ความปลอดภัยด้านโทรคมนาคมในปัจจุบันเละเทะ”
      ถ้ามีคนเอา bug ในโค้ดของคุณมาให้ แต่ไม่ได้อ้างว่ามีการ exploit จริง และไม่ได้ให้ PoC เพื่อยืนยันว่า exploit ได้ ทำไมถึงไม่ควรจัดการมันเหมือน bug ทั่วไป?
      ก็แก้ตอนนี้แล้วใส่ไว้ใน release ถัดไป
      คนอื่นเห็นการเปลี่ยนแปลงได้หรือ? ใช่ การเปลี่ยนแปลงอื่น ๆ ก็เห็นได้เหมือนกัน
      ถ้าหา exploit ได้ก็ขอให้โชคดีแล้วกัน และผู้รายงานก็หาไม่พบ
      ใน Linux distribution ก็เกิดเรื่องแบบเดียวกัน
      มีการรายงาน security bug และบางครั้ง upstream author ไม่ใช่แค่ดื้อ แต่เสียชีวิตไปแล้วจริง ๆ
      ถ้าอยากเปลี่ยนตามตารางของตัวเอง ก็ release เองได้

  • ด้านที่ Freeswitch น่าจะถูกใช้ค่อนข้างบ่อยคือ การติดตั้ง BigBlueButton ในโรงเรียนและมหาวิทยาลัย
    มันเป็นระบบห้องเรียนเสมือน และหลายแห่งน่าจะใช้งานโดยไม่มีสัญญา support ซึ่งฝั่งนี้น่ากังวลกว่าผู้ให้บริการโทรคมนาคม

  • สงสัยเหมือนกันว่ามีคนใช้โมดูล XML RPC จริง ๆ สักแค่ไหน
    โดยค่าเริ่มต้นไม่ได้โหลดขึ้นมา
    แก้ไข: อิงจาก Shodan มี 468 รายการ
    ยังสงสัยด้วยว่า senddirectorydocument ในโมดูล XML RPC ถูกใช้งานจริงหรือเปล่า

    • ลองตรวจต่อแล้ว แต่ไม่สามารถกระตุ้นให้เกิดพฤติกรรมใด ๆ ได้เลย
      curl --show-error --get --request GET --user freeswitch:works "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}";
      มีไอเดียไหมว่าจะทริกเกอร์ได้อย่างไร?
      ถ้ามี PoC ที่อย่างน้อยทำให้เกิด segfault ได้ ก็น่าจะมีโอกาสออก security release มากขึ้น

  • การแฮ็กที่เจ๋งจริง ๆ เกิดขึ้นที่ CAMEL MAP injection
    มันควบคุมของดี ๆ ได้สารพัด ตั้งแต่ SMS, USSD ไปจนถึงอัญมณีมงกุฎอย่างบริการระบุตำแหน่ง
    บริษัท “ส่ง SMS จำนวนมาก” หลายรายในเกาะหรู ๆ แถบแคริบเบียนหรือที่อย่างอินโดนีเซีย ทำอะไรมากกว่าการส่งสแปมเยอะมาก

    • เสริมว่า MAP เป็นเทคโนโลยี 2G และ 3G
      เลยเก่าแล้ว และ 2G ก็ถูกออกแบบมาตั้งแต่ทศวรรษ 1990
      ไม่ค่อยแน่ใจว่าผู้คนคาดหวังอะไรกัน
      พูดตรง ๆ แค่มันยังทำงานได้ก็นับว่าดีแล้ว

  • ผู้ให้บริการโทรคมนาคมรายใหญ่ไม่ได้รัน FreeSwitch หรือ Asterisk ใน core

    • ระบบโทรศัพท์ 911 ราคาประหยัดของ Motorola ชื่อ Emergency CallWorks (ECW) คือ Asterisk ที่รันบน Linux บน Proxmox พร้อมโมดูล proprietary
      แน่นอนว่า Motorola กำลังยุติผลิตภัณฑ์นั้น แต่ในหน้างานก็ยังมีอยู่
      ตัวที่ผมดูแลถูกกั้นด้วย firewall อย่างเข้มงวด แต่คิดว่าไม่ใช่ทุกที่ที่จะเป็นแบบนั้น
    • ถึงจะไม่ใช่ใน core แต่ผู้ให้บริการจำนวนมากที่ประมวลผลข้อมูลการโทร เช่น การบันทึกเสียงสาย, transcription, IVR, การวิเคราะห์เสียง, การเชื่อมกับ CRM, call queue, auto dialer, ฟังก์ชัน SMS/แชต ก็น่าจะรัน FreeSWITCH, Asterisk หรือสิ่งที่คล้ายกันอยู่สักจุดใน stack
      บริษัทที่มี PBX ส่วนใหญ่ที่อยากทำมากกว่าแค่การ route สายพื้นฐานและเชื่อมต่อ PSTN ก็น่าจะใช้เครื่องมือจาก third party
      และเครื่องมือจำนวนไม่น้อยก็สร้างอยู่บน FreeSWITCH, Asterisk หรือของแนวเดียวกัน
    • ขึ้นอยู่กับนิยามของคำว่า “รายใหญ่” มาก

  • ขอแนะนำอย่างยิ่งสำหรับ งานนำเสนอของ P1 Security เกี่ยวกับความปลอดภัยของเครือข่ายมือถือ: https://www.slideshare.net/slideshow/day1-hacking-telcoequip...
    แม้จะเป็นข้อมูลเก่า แต่ก็ไม่มีเหตุผลให้เชื่อว่ามันดีขึ้นแล้ว
    เพราะไม่มีแรงจูงใจให้ปรับปรุงเลย
    อีกทั้งช่องโหว่ด้านความปลอดภัยของซอฟต์แวร์เป็นเพียงส่วนหนึ่งของปัญหาเท่านั้น อีกด้านหนึ่งคือผู้ให้บริการโทรคมนาคมยินดี outsource สิทธิ์ควบคุมและสิทธิ์เข้าถึงแกนหลักให้กับผู้เสนอราคาต่ำสุด: https://berthub.eu/articles/posts/5g-elephant-in-the-room/