แอปแชตที่อ้างว่า “ปลอดภัยสุดๆ” ทำหมายเลขโทรศัพท์ของผู้ใช้ทั้งหมดรั่วไหล

 (ericdaigle.ca)
1 คะแนน โดย GN⁺ 2025-12-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • พบช่องโหว่ร้ายแรงในแอปแชตธีม MAGA (ฝ่ายอนุรักษนิยมสหรัฐฯ) ชื่อ Freedom Chat ที่เปิดเผย หมายเลขโทรศัพท์และรหัส PIN ของผู้ใช้
  • แอปนี้เป็นภาคต่อของโปรเจกต์ก่อนหน้าชื่อ Converso ซึ่งในอดีตก็เคยมีปัญหาเรื่องการติดตั้งใช้งานระบบเข้ารหัสผิดพลาดและข้อมูลรั่วไหลมาแล้ว
  • จากการวิเคราะห์พบว่า ผ่านฟีเจอร์ช่องแชนแนล รหัส PIN ของสมาชิกทุกคนถูกส่งไปยังผู้ใช้อื่น และผ่าน API สำหรับซิงก์รายชื่อผู้ติดต่อก็สามารถ จับคู่หมายเลขโทรศัพท์กับ UID ได้
  • นักวิจัยยืนยันว่าไม่มี การจำกัดอัตรา (rate limiting) เลย ทำให้สามารถ รวบรวมหมายเลขโทรศัพท์ของผู้ใช้ Freedom Chat ทั้งหมดได้ภายในวันเดียว
  • เหตุการณ์นี้ถูกชี้ว่าเป็นตัวอย่างของแอปที่ “เน้นความปลอดภัย” แต่กลับ ล้มเหลวแม้แต่ในการปกป้องข้อมูลส่วนบุคคลขั้นพื้นฐาน

การเปลี่ยนผ่านจาก Converso สู่ Freedom Chat

  • Converso ที่เปิดตัวในปี 2023 อ้างว่าเป็น “โครงสร้างแบบกระจายศูนย์ไร้เซิร์ฟเวอร์” และ “E2EE รุ่นล่าสุด” แต่การวิเคราะห์ของนักวิจัย crnković เปิดเผยว่า คำกล่าวอ้างทั้งหมดเป็นเท็จ
    • ในความเป็นจริง แอปใช้ เซิร์ฟเวอร์กลางและบริการเข้ารหัสของบุคคลที่สาม (Seald) และสามารถอนุมานคีย์เข้ารหัสได้จากข้อมูลสาธารณะ
    • ข้อความทั้งหมดถูก อัปโหลดไปยัง Firebase bucket แบบสาธารณะ ทำให้ใครก็สามารถเปิดดูได้
  • หลังจากนั้น CEO Tanner Haas ได้ถอนแอปออก และรีแบรนด์เป็น Freedom Chat โดยให้เหตุผลว่าเป็นเพราะ “ความกังวลด้านความเป็นส่วนตัวของฝ่ายอนุรักษนิยม”
    • เขาเคยกล่าวถึงบทเรียนว่า “จงรับฟังคำวิจารณ์และปรับปรุง” แต่ปัญหาด้านความปลอดภัยก็ยังเกิดซ้ำ

โครงสร้างและฟังก์ชันของ Freedom Chat

  • แอปใช้ การสมัครสมาชิกด้วยหมายเลขโทรศัพท์ และ การยืนยันด้วยรหัส 2FA โดยการตั้งค่า PIN เป็นทางเลือก
  • ฟังก์ชันหลักคือ แชต 1:1 และ Channels ซึ่งมีโครงสร้างคล้าย Telegram
  • แอปโปรโมต ฟีเจอร์บล็อกการแคปหน้าจอ เป็น “ฟีเจอร์ความปลอดภัย” แต่ในทางปฏิบัติไม่ได้เกี่ยวข้องกับความปลอดภัยจริง

การรั่วไหลของรหัส PIN

  • ผลลัพธ์จากการเรียก API /channel แสดงว่าใน user object ของสมาชิกแชนแนล 1,519 คน มี ฟิลด์ PIN รวมอยู่ด้วย
    • พร้อมกับ UID, คีย์ Seald, วันที่สร้างบัญชี และ รหัส PIN 6 หลักที่ถูกเปิดเผยแบบข้อความล้วน
  • เมื่อลองสร้างบัญชีใหม่และตรวจสอบ ก็พบว่า PIN ของตัวเองถูกรวมอยู่ในข้อมูลตอบกลับตามเดิม
  • นั่นหมายความว่า PIN ของผู้ใช้ทุกคนที่ยังอยู่ในแชนแนลเริ่มต้นจะถูกเปิดเผยต่อผู้ใช้อื่น

ช่องโหว่การจับคู่หมายเลขโทรศัพท์

  • API /user/numbers ทำงานแบบเดียวกับ WhatsApp โดยใช้เพื่อตรวจสอบว่า มีผู้ใช้อยู่ในรายชื่อติดต่อหรือไม่
    • หากหมายเลขที่ส่งไปเป็นผู้ใช้ Freedom Chat ระบบจะส่งกลับ UID และคีย์ Seald
  • นักวิจัยยืนยันว่า API นี้ ไม่มีการจำกัดอัตราเลย จึงสามารถทดสอบหมายเลขโทรศัพท์ทั้งหมดในสหรัฐฯ แบบเรียงลำดับได้
    • ผลคือสามารถ จับคู่หมายเลขโทรศัพท์กับ UID ได้ และเมื่อนำไปรวมกับข้อมูล UID-PIN ที่รั่วไหลก่อนหน้า ก็จะได้ ตารางจับคู่หมายเลขโทรศัพท์กับ PIN สมบูรณ์

การทดลองรั่วไหลของข้อมูลผู้ใช้ทั้งหมด

  • นักวิจัยเขียนสคริปต์ Python เพื่อส่งคำขออัตโนมัติไปยัง หมายเลขโทรศัพท์ทั้งหมดในอเมริกาเหนือ (ชุดตัวเลข 7 หลัก × รหัสพื้นที่)
    • ในแต่ละคำขอจะส่งหมายเลข 40,000 หมายเลข โดยมีเวลาตอบกลับเฉลี่ยราว 1.5 วินาที
    • ภายใน 27 ชั่วโมง คำขอทั้งหมดถูกประมวลผลสำเร็จ ทำให้ รวบรวมหมายเลขโทรศัพท์ของผู้ใช้ Freedom Chat ได้ทั้งหมด
  • เซิร์ฟเวอร์ตอบสนองโดย ไม่มีการจำกัดอัตราหรือมาตรการบล็อกใดๆ ทำให้ข้อมูลอยู่ในสภาพ ที่เปิดให้อ่านได้ทั้งหมด

การตอบสนองและมาตรการติดตามผล

  • 2025-11-23: พบช่องโหว่
  • 2025-12-04: นักข่าว TechCrunch Zack Whittaker แจ้ง Freedom Chat เกี่ยวกับช่องโหว่
  • 2025-12-05: ฝั่ง Freedom Chat ชี้แจงว่า “PIN ไม่ได้ใช้สำหรับกู้คืนข้อความ” และกำลังอยู่ระหว่างกระบวนการตรวจสอบ
  • 2025-12-09: แจ้งว่าการแก้ไขปัญหาเสร็จสิ้น
  • 2025-12-11: รายงานฉบับนี้และบทความของ TechCrunch เผยแพร่พร้อมกัน

บทเรียนสำคัญ

  • Freedom Chat อ้างว่าเป็น “ความปลอดภัยระดับสุดยอด” แต่กลับ ไม่มีทั้งการออกแบบด้านการยืนยันตัวตน การจำกัดอัตรา และการปกป้องข้อมูลขั้นพื้นฐาน
  • ผลลัพธ์คือ หมายเลขโทรศัพท์และ PIN ของผู้ใช้ทั้งหมดรั่วไหล ทำให้ฟีเจอร์ความปลอดภัยแทบไม่มีความหมาย
  • กรณีนี้ถูกมองว่าเป็นตัวอย่างชัดเจนของ ช่องว่างระหว่างการตลาดด้านความปลอดภัยกับการพัฒนาจริง

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

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

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

  • ระบบค้นหาเบอร์โทรศัพท์แบบเข้ารหัส ของ Signal น่าสนใจ
    เซิร์ฟเวอร์ค้นหาเบอร์โดยใช้การคำนวณ XOR ระดับบิตใน RAM ที่เข้ารหัสด้วยฮาร์ดแวร์ ดังนั้นแม้จะตรวจสอบระบบในระดับล่างสุดก็จะไม่สามารถรู้ได้ว่าเบอร์โทรที่ร้องขอมีอยู่หรือไม่
    แน่นอนว่า rate limiting ก็เป็นอีกประเด็นสำคัญแยกต่างหาก เวลาออกแบบระบบความปลอดภัยจะมี edge case จำนวนมากที่ต้องครอบคลุม

    • ฉันไม่คิดว่าวิธีนี้เจ๋งนัก ตั้งแต่แรกแล้วถ้าเป็น secure messenger ก็ไม่ควรบังคับใช้หมายเลขโทรศัพท์ซึ่งเป็นข้อมูลระบุตัวตนส่วนบุคคล
    • สงสัยว่าถ้ารัฐบาลส่งคำขอค้นหาสำหรับทุกหมายเลขโทรศัพท์ Signal จะสามารถป้องกันได้หรือไม่
      ในแพลตฟอร์ม ไม่แสวงหากำไรและเน้นความเป็นส่วนตัว อย่าง Matrix ควรทำให้การแมปแบบนี้เป็นไปไม่ได้ตั้งแต่แรก
      ตัวอย่างเช่น เสนอให้ผู้ใช้อัปโหลดค่าแฮชของหมายเลขโทรศัพท์ของผู้ใช้แต่ละคู่ในรายชื่อติดต่อ เพื่อให้มีเพียงคนที่อยู่ในรายชื่อของตนเท่านั้นที่ค้นหาตนเองเจอ
      ข้อดีคือพื้นที่ของแฮชมีขนาดใหญ่ ทำให้ย้อนกลับได้ยาก และผู้ใช้สามารถกำหนด ขอบเขตการอนุญาตให้ค้นพบ ได้เอง
      ข้อเสียคือผู้โจมตีอาจสร้างทุกชุดค่าผสมของหมายเลขโทรศัพท์เพื่อดึงความสัมพันธ์ในรายชื่อติดต่อออกมาได้ และรัฐบาลก็อาจดัก SMS ยืนยันตัวตนเพื่อนำไปใช้ในทางที่ผิดได้เช่นกัน
    • ส่วนที่บอกว่าเซิร์ฟเวอร์ใช้ XOR บน RAM ที่เข้ารหัสด้วยฮาร์ดแวร์นั้นน่าสนใจ อยากรู้ว่ามี ข้อมูลเพิ่มเติม เกี่ยวกับเรื่องนี้หรือไม่
    • ยังรู้สึกเสียดายที่ยังต้องใช้หมายเลขโทรศัพท์ เพิ่งมีการเพิ่ม ฟีเจอร์ username ไม่นานนี้เพื่อหลีกเลี่ยงการเปิดเผยเบอร์ แต่การที่บัญชียังผูกกับ SIM ก็ยังน่ากังวลอยู่ดี
    • แต่เพราะเราไม่สามารถ คอมไพล์และรันเซิร์ฟเวอร์ Signal เอง ได้ จึงไม่อาจมั่นใจได้จริง ๆ ว่าเซิร์ฟเวอร์ทำงานแบบนี้หรือไม่

  • ฟิลด์ pin ในอ็อบเจ็กต์ผู้ใช้ดูน่าสงสัย
    เป็นไปได้ว่านี่เกิดจากการใช้ ไลบรารี serialization แบบ opt-out โดยปกติแล้วมันจะ serialize ทั้งอ็อบเจ็กต์เป็นค่าเริ่มต้น ดังนั้นถ้านักพัฒนาลืมตั้งค่าให้ยกเว้นบางฟิลด์ ข้อมูลนั้นก็จะถูกเปิดเผยออกมาตรง ๆ
    หรือไม่ฝั่งเซิร์ฟเวอร์อาจใช้ JS dictionary ธรรมดา แล้วไม่ได้ลบฟิลด์ออกก่อนส่ง response
    ช่องโหว่นี้เป็นปัญหาเก่าที่ถูกกล่าวถึงใน งานวิจัยของทีมนักวิจัยมหาวิทยาลัยเวียนนา และในปี 2016 ก็เคยถูกใช้โจมตี Telegram แบบเดียวกันจนรัฐบาลอิหร่านเก็บหมายเลขโทรศัพท์ผู้ใช้ได้ 15 ล้านราย
    ลิงก์ที่เกี่ยวข้อง: บล็อก Telegram

    • ที่ทำงานเก่าฉันเคยตรวจสอบโค้ดแล้วพบ ช่องโหว่จากการ serialization แบบนี้อยู่ทั่วทุกแห่ง นักพัฒนาควรเลิกใช้ไลบรารีประเภทนี้ได้แล้ว
    • ปัญหาแบบนี้พบได้บ่อยมาก มีการส่ง ฟิลด์ที่มีความอ่อนไหว ไปยังไคลเอนต์ แต่ใน UI มองไม่เห็น เลยไม่มีใครสังเกต
    • การที่ PIN หลุดออกมาก็แย่แล้ว แต่การ เก็บเป็นข้อความธรรมดา นั้นร้ายแรงยิ่งกว่า ควรจัดการด้วยอัลกอริทึมแฮชที่แข็งแกร่งเหมือนรหัสผ่าน

  • ทุกวันนี้ช่องโหว่ความปลอดภัยส่วนใหญ่เกิดจากการ เรียก HTTP endpoint ในวิธีที่ไม่คาดคิดอย่างง่าย ๆ
    เวลาพูดถึงการแฮ็กในปี 2025 คนมักนึกถึงเทคนิคซับซ้อน แต่ความจริงคือยังมีคนปล่อย API ที่ไม่มีแม้แต่ rate limiting อยู่เลย ทั้งที่เป็นปัญหาที่แก้ได้ด้วยการตั้งค่า Nginx แค่บรรทัดเดียว

    • พอเห็นคำว่า “แก้ได้ด้วยการตั้งค่า Nginx แค่บรรทัดเดียว” ก็ทำให้นึกถึงปฏิกิริยาแบบ “มันไม่ได้อยู่ใน Docker tutorial เลยไม่รู้ว่าคืออะไร”
    • การพัฒนาซอฟต์แวร์ก้าวหน้าไปมาก แต่ หลักการพัฒนาด้านความปลอดภัย แทบไม่ได้เติบโตตาม
      เป้าหมายส่วนใหญ่คือการลดแรงเสียดทานของผู้ใช้และเพิ่ม ประสิทธิภาพเชิงพาณิชย์ นักพัฒนาจำนวนมากยังไม่รู้จักช่องโหว่พื้นฐานอย่าง XSS หรือ SSRF แต่ก็รีบทำฟีเจอร์ให้เสร็จ
    • ถึงจะเป็นการตั้งค่าธรรมดา ก็ต้อง รู้ก่อนว่ามันมีอยู่ ถึงจะนำไปใช้ได้
    • เมื่อก่อนฉันคิดว่าการสแกนความปลอดภัยภายในแบบอัตโนมัติไม่มีประโยชน์ แต่พอเห็นกรณีพลาดการตั้งค่าพื้นฐานจริง ๆ ก็รู้สึกว่ามันจำเป็นมาก
      ความผิดพลาดด้านความปลอดภัยขั้นพื้นฐาน เช่นตั้งค่า Docker port mapping ผิด หรือไม่มี CSP นั้นพบได้บ่อยเกินไป
    • แต่แค่ rate limiting อย่างเดียวก็ยังไม่พอ ผู้โจมตีสามารถ กระจาย IP เพื่อส่งคำขอแบบขนานได้

  • พอเห็นประโยคที่ว่า “เราอยากมอบเฉพาะบทความบล็อกที่ดีที่สุดให้ผู้อ่าน” ก็รู้สึกเหมือนได้เจอ คนที่มีนิสัยคล้ายตัวเอง

  • สงสัยว่า Freedom Chat® มีฟีเจอร์ที่ทำให้นักข่าวเข้าร่วมแชตกลุ่มไม่ได้หรือไม่ ถามแบบเล่น ๆ ปนจริงจังเพื่อ เพื่อนที่อยู่ DoD

  • แค่ปีนี้ปีเดียวก็มีหลายกรณีที่ “แอปความปลอดภัย” จัดการข้อมูลผู้ใช้แล้วเกิด ข้อมูลรั่วไหล
    เท่าที่นึกออกก็ประมาณ 20 เซนต์ (=4 กรณี) แต่คงมีมากกว่านั้นอีก
    กรณีที่เกี่ยวข้อง: 1, 2, 3

    • ฉันคิดว่าเหตุการณ์นี้ยิ่งตอกย้ำความสำคัญของการ ย้ายออกจาก Facebook Messenger
    • และสิ่งที่เรารู้ก็เป็นเพียงบางส่วนเท่านั้น

  • ปีที่แล้วฉันบังเอิญเห็น บอร์ดประกาศรับสมัครงานของ GOP ซึ่งเก็บใบสมัครไว้ในดัชนีค้นหาเดียวกับประกาศงาน
    พอค้นหาคำว่า “bob” ก็เจอ เรซูเม่และคำตอบของผู้สมัคร โผล่ออกมาตรง ๆ จนน่าตกใจ

    • อยากรู้ว่าเป็นเว็บไซต์ไหน

  • หลังเหตุการณ์ Anom รู้สึกว่าควรมีคำที่เหมาะกว่า honeypot
    แอปส่งข้อความที่ปลอดภัยจริง ๆ คงไม่เกิดขึ้นด้วยวิธีแบบนี้ แต่การตลาดก็ยังดำเนินต่อไป และทุกครั้งก็ยังมีผู้ใช้หน้าใหม่ถูกดึงเข้ามา

    • ทุกวันนี้เป็นโลกที่ ความล้มเหลวกลายเป็นฟีเจอร์ ไปแล้ว
      ข้อมูลรั่วไหลเกิดขึ้นบ่อยจนผู้คนเริ่มชาชิน แม้แต่ค่าชดเชยจากการฟ้องแบบกลุ่มก็ยังกลายเป็นกระบวนการที่ต้อง ให้ข้อมูลส่วนตัวเพิ่มอีก
      ตลาดพยากรณ์, คริปโต ฯลฯ ก็ให้ความรู้สึกเหมือนเป็นการนำ ความล้มเหลวเชิงโครงสร้างที่ทำให้ผู้เข้าร่วมเสียประโยชน์ มาห่อเป็นภาพของ “ความสำเร็จ”
    • มีคนเสนอคำใหม่ว่า “Petepot”

  • Freedom Chat ประกาศว่า “แก้ปัญหาเสร็จแล้ว” แต่ก็ยัง น่าสงสัยว่าจริง ๆ แก้แล้วหรือยัง

  • ถ้าประโยคที่ว่า “ผมไม่มีประสบการณ์พัฒนาแอปมือถือ แต่คิดว่าตัวเองฉลาดพอคงไม่ยาก” เป็นคำพูดจริง มันแทบจะเหมือน มุกในสแตนด์อัปคอมเมดี้ เลย