สรุปสั้น

บริษัท Trezor ผู้ผลิตกระเป๋าเงินคริปโตเคอร์เรนซีแบบฮาร์ดแวร์ เปิดเผยเมื่อวันศุกร์ว่ามีลูกค้าจากสหรัฐอเมริกาอีก 67,000 รายที่ได้รับผลกระทบจากเหตุเจาะระบบที่บริษัท ShipMonk ซึ่งเป็นผู้ให้บริการขนส่งของตน ข้อมูลที่ถูกเปิดเผยประกอบด้วยชื่อลูกค้า ที่อยู่อีเมล หมายเลขโทรศัพท์ ที่อยู่จัดส่ง และหมายเลขคำสั่งซื้อ ของคำสั่งซื้อในช่วงระหว่างเดือนพฤศจิกายน 2562 ถึงสิงหาคม 2564 ทั้งนี้เหตุการณ์ไม่กระทบต่อความปลอดภัยของกระเป๋าเงินฮาร์ดแวร์ของบริษัทแต่อย่างใด

จุดที่ทำให้เรื่องนี้หนักกว่าเหตุข้อมูลรั่วทั่วไปคือข้อมูลชุดนี้ไม่ควรจะยังมีอยู่ตั้งแต่แรก “ตลอดความสัมพันธ์ระหว่างเรากับ ShipMonk เราร้องขอและได้รับคำยืนยันเป็นลายลักษณ์อักษรซ้ำแล้วซ้ำเล่าว่าข้อมูลถูกลบแล้ว ตามสัญญา นโยบายข้อมูล และการสื่อสารที่ผ่านมาของเรา” Trezor ระบุ “เราผิดหวังอย่างยิ่งที่แม้จะได้รับคำยืนยันดังกล่าวแล้ว ข้อมูลกลับไม่ได้ถูกลบออกจากระบบของพวกเขา”

ตัวเลขล่าสุดนี้เพิ่มเติมจากลูกค้า 13,689 รายที่บริษัทเปิดเผยไปเมื่อเดือนก่อนว่าข้อมูลหลุดทั้งหมดหรือบางส่วน ซึ่งเราเคยรายงานไว้ในโพสต์ 2026/08/086 โดยตอนนั้นบริษัทระบุว่าเหตุการณ์จำกัดอยู่ในกรอบนโยบายเก็บข้อมูล 90 วันของตน แต่รอบนี้ปรากฏว่ามีข้อมูลย้อนหลังไปถึงห้าถึงเจ็ดปีอยู่ในระบบของผู้ให้บริการ

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 5 กันยายน 2569 ว่า Trezor เปิดเผยเมื่อวันศุกร์ว่ามีลูกค้าจากสหรัฐฯ อีก 67,000 รายที่ได้รับผลกระทบจากเหตุเจาะระบบที่ผู้ให้บริการขนส่ง ShipMonk

Trezor ระบุว่า ShipMonk แจ้งบริษัทเรื่องการถูกเจาะเมื่อวันที่ 10 สิงหาคม 2569 หลังมีการเข้าถึงระบบของตนโดยไม่ได้รับอนุญาต ต่อมาจึงเปิดเผยเพิ่มเติมว่าลูกค้า 1,947 รายที่ข้อมูลหลุดจำกัดอยู่เพียงชื่อ เมือง และที่อยู่อีเมล โดยไม่รวมที่อยู่จัดส่งนั้น อาจรวมถึงคำสั่งซื้อเก่ากว่าที่เคยระบุไว้ด้วย

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

ประเด็นสำคัญจึงอยู่ตรงช่องว่างระหว่างนโยบายกับความเป็นจริง นโยบายของ Trezor คือลบภายใน 90 วัน แต่ข้อมูลที่หลุดจาก ShipMonk เป็นคำสั่งซื้อระหว่างเดือนพฤศจิกายน 2562 ถึงสิงหาคม 2564 นั่นคือข้อมูลที่ควรถูกลบไปแล้วตั้งแต่ปลายปี 2564 กลับยังคงอยู่ในระบบของผู้ให้บริการภายนอกจนถึงกลางปี 2569 ทั้งที่มีคำยืนยันเป็นลายลักษณ์อักษรว่าลบแล้ว

ในฝั่งของ ShipMonk บริษัทยังไม่ได้ยอมรับเหตุการณ์นี้ต่อสาธารณะ โดยมีรายงานว่าบริษัทโลจิสติกส์รายนี้ได้ปิดช่องโหว่ในระบบที่ได้รับผลกระทบและปรับปรุงความปลอดภัยหลังการบุกรุกทางดิจิทัลแล้ว ซึ่งเหตุการณ์ดังกล่าวเกี่ยวข้องกับการใช้ช่องโหว่ zero-day รหัส CVE-2026-72898 คะแนน CVSS 10.0 ซึ่งเป็นช่องโหว่ SQL injection ระดับวิกฤตใน Metabase

ตามข้อมูลของบริษัทด้านความปลอดภัยบล็อกเชนระดับองค์กร Halborn ระบุว่ากลุ่มรีดไถ ShinyHunters อยู่เบื้องหลังการเจาะครั้งนี้ ส่วน Trezor ระบุว่าได้แจ้งลูกค้าที่ได้รับผลกระทบโดยตรงแล้ว

วิธีการโจมตี

ห่วงโซ่ของเหตุการณ์นี้เริ่มจากซอฟต์แวร์ที่ไม่ใช่ของทั้ง Trezor และ ShipMonk โดยตรง Metabase เป็นแพลตฟอร์มวิเคราะห์ข้อมูลแบบบริการตนเองที่องค์กรใช้เชื่อมเข้ากับฐานข้อมูลของตัวเองเพื่อทำแดชบอร์ดและรายงาน ลักษณะการใช้งานเช่นนี้หมายความว่าอินสแตนซ์ของ Metabase มักถือสิทธิ์อ่านฐานข้อมูลระดับที่กว้างมาก

เมื่อผู้โจมตีพบและใช้ช่องโหว่ SQL injection ระดับ CVSS 10.0 ในตัว Metabase ก่อนที่จะมีแพตช์ออกมา สิ่งที่ได้จึงไม่ใช่แค่การเข้าถึงตัวเครื่องมือวิเคราะห์ แต่เป็นการเข้าถึงข้อมูลปลายทางที่เครื่องมือนั้นเชื่อมอยู่ Halborn อธิบายว่า “การเจาะ Trezor เป็นผลจากการโจมตีซัพพลายเชนที่เริ่มต้นจากช่องโหว่ zero-day การค้นพบและใช้ช่องโหว่ SQL injection ใน Metabase ทำให้ผู้โจมตีสามารถโจมตีลูกค้าของ Metabase ได้หลายราย ขโมยข้อมูลอ่อนไหวและรีดไถองค์กรเหล่านั้น” และ “ในกรณีของ Trezor นั่นหมายถึงการเปิดเผยรายละเอียดคำสั่งซื้อของลูกค้าที่ถูกเก็บไว้ในอินสแตนซ์ Metabase โดย ShipMonk”

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

Halborn ระบุว่าการโจมตีซัพพลายเชนซอฟต์แวร์ลักษณะนี้ตอกย้ำความจำเป็นที่องค์กรต้องมองเห็นความเสี่ยงจากบุคคลที่สามของตนได้ครบถ้วน เพื่อบริหารสถานะความปลอดภัยโดยรวมได้จริง

ผลกระทบ

ผู้ได้รับผลกระทบคือลูกค้า Trezor ในสหรัฐฯ อีก 67,000 รายที่สั่งซื้อระหว่างเดือนพฤศจิกายน 2562 ถึงสิงหาคม 2564 ซึ่งเมื่อรวมกับ 13,689 รายที่เปิดเผยไปเมื่อเดือนก่อน ทำให้ยอดรวมขยับขึ้นเป็นราว 80,000 ราย และตัวเลขนี้อาจยังไม่ใช่ตัวเลขสุดท้าย เนื่องจากยอดรอบนี้ปรากฏขึ้นจากข้อมูลที่ทุกฝ่ายเข้าใจว่าถูกลบไปแล้ว

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

ในทางปฏิบัติ ผู้ใช้กลุ่มนี้จะเจอความพยายามสวมรอยเป็น Trezor ที่น่าเชื่อถือสูงกว่าปกติมาก เพราะผู้โจมตีสามารถอ้างอิงหมายเลขคำสั่งซื้อจริง ที่อยู่จัดส่งจริง และวันที่จริงได้ ซึ่งเป็นข้อมูลที่ตามความเข้าใจของเหยื่อควรมีเฉพาะบริษัทเท่านั้นที่รู้ รูปแบบการหลอกลวงที่ตามมามักเป็นการอ้างว่าอุปกรณ์มีปัญหาแล้วขอให้กรอกวลีกู้คืน หรือการส่งอุปกรณ์ทดแทนปลอมทางไปรษณีย์

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

คำแนะนำ

ลูกค้า Trezor ที่สั่งซื้อในช่วงปี 2562 ถึง 2564 ควรถือว่าที่อยู่บ้าน เบอร์โทรศัพท์ และอีเมลของตนอยู่ในมือผู้ไม่หวังดีแล้ว และเพิ่มความระมัดระวังกับการติดต่อทุกช่องทางที่อ้างว่ามาจากบริษัท

ห้ามกรอกวลีกู้คืนหรือ seed phrase ลงในเว็บไซต์ แอปพลิเคชัน อีเมล หรือแบบฟอร์มใด ๆ ไม่ว่าผู้ติดต่อจะรู้รายละเอียดคำสั่งซื้อของคุณแม่นยำเพียงใด เพราะผู้ผลิตอุปกรณ์ไม่มีเหตุผลใดที่ต้องขอข้อมูลนี้

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

สำหรับองค์กรที่ส่งข้อมูลลูกค้าให้คู่ค้าประมวลผล ให้ตรวจสอบว่าข้อกำหนดเรื่องการลบข้อมูลในสัญญามีกลไกพิสูจน์รองรับหรือไม่ เช่น สิทธิ์ในการตรวจสอบ รายงานการลบที่ตรวจสอบย้อนกลับได้ หรือการยืนยันจากผู้ตรวจสอบอิสระ แทนการรับคำยืนยันเป็นลายลักษณ์อักษรเพียงอย่างเดียว

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

องค์กรที่ใช้ Metabase ควรตรวจสอบว่าอินสแตนซ์ของตนได้รับแพตช์ที่ปิด CVE-2026-72898 แล้วหรือยัง จำกัดการเข้าถึงจากอินเทอร์เน็ต และทบทวนว่าบัญชีที่ Metabase ใช้เชื่อมฐานข้อมูลมีสิทธิ์กว้างเกินความจำเป็นหรือไม่

แหล่งอ้างอิง