- ผู้เขียนซึ่งเป็นทั้งครูสอนดำน้ำและแพลตฟอร์มเอนจิเนียร์ พบช่องโหว่ด้านความปลอดภัยร้ายแรงในพอร์ทัลสมาชิกของบริษัทประกันดำน้ำ
- พอร์ทัลใช้รหัสผู้ใช้แบบเรียงลำดับและรหัสผ่านเริ่มต้นแบบเดียวกัน ทำให้ใครก็ตามสามารถเข้าถึงข้อมูลส่วนบุคคลของสมาชิกคนอื่นได้ด้วยการผสมค่าธรรมดา ๆ
- แม้จะแจ้ง CSIRT Malta และหน่วยงานที่เกี่ยวข้องพร้อมกัน แต่แทนที่จะได้รับคำขอบคุณ หน่วยงานกลับเตือนถึงความเป็นไปได้ในการรับผิดทางอาญาผ่านตัวแทนทางกฎหมาย
- ผู้เขียนปฏิเสธการลงนามข้อตกลงการรักษาความลับ (NDA) และเสนอคำประกาศการแก้ไขที่ยืนยันเพียงการลบข้อมูล แต่หน่วยงานก็ยังข่มขู่อีกครั้งโดยอ้างความเป็นไปได้เรื่องการหมิ่นประมาท
- กรณีนี้สะท้อนให้เห็นทั้งความสำคัญของกระบวนการเปิดเผยช่องโหว่อย่างรับผิดชอบ และความจริงที่ว่าภัยคุกคามทางกฎหมายบั่นทอนการคุ้มครองนักวิจัย
การค้นพบช่องโหว่
- ระหว่างทริปดำน้ำที่เกาะโคโคส ประเทศคอสตาริกา ผู้เขียนพบข้อบกพร่องเชิงโครงสร้างของพอร์ทัลสมาชิกบริษัทประกันดำน้ำ
- เมื่อครูลงทะเบียนนักเรียน ระบบจะสร้างรหัสตัวเลขแบบเรียงลำดับและรหัสผ่านเริ่มต้นที่ไม่ถูกเปลี่ยน
- ผู้ใช้จำนวนมากไม่ได้เปลี่ยนรหัสผ่าน ทำให้เข้าถึงข้อมูลส่วนบุคคลทั้งหมดของสมาชิกคนอื่นได้ เช่น ชื่อ ที่อยู่ วันเกิด ข้อมูลติดต่อ เป็นต้น
- ไม่มีมาตรการความปลอดภัยพื้นฐานใด ๆ เลย เช่น การบังคับเปลี่ยนรหัสผ่าน การจำกัดการเข้าสู่ระบบ หรือ MFA
- บางบัญชียังมีข้อมูลของผู้เยาว์ (อายุ 14 ปี) รวมอยู่ด้วย
- ผู้เขียนยืนยันปัญหาด้วยการเข้าถึงให้น้อยที่สุด จากนั้นหยุดทันที และลบข้อมูลทั้งหมดที่เก็บรวบรวมอย่างถาวร
การตรวจสอบและการพิสูจน์
- ลองใช้ Python
requests แต่โครงสร้างเซสชันซับซ้อน จึงใช้การทำงานอัตโนมัติของเบราว์เซอร์ด้วย Selenium เพื่อตรวจสอบ
- เพียงกรอกรหัสผู้ใช้และรหัสผ่านเริ่มต้นก็สามารถล็อกอินได้
- สคริปต์อัตโนมัติถูกเผยแพร่เป็นโค้ดตัวอย่างที่ใช้งานจริงไม่ได้ และลบตัวระบุจริงทั้งหมดออกแล้ว
- ตัวอย่างผลลัพธ์มีข้อมูลโปรไฟล์ครบถ้วน เช่น ชื่อ อีเมล ที่อยู่ วันเกิด เป็นต้น
- ในกระบวนการนี้ยังยืนยันได้ว่าบัญชีของผู้เยาว์หลายบัญชีถูกเปิดเผยด้วยวิธีเดียวกัน
ขั้นตอนการเปิดเผยช่องโหว่
- รายงานช่องโหว่อย่างเป็นทางการเมื่อ28 เมษายน 2025 และกำหนดระยะเวลาผ่อนผัน 30 วันเพื่อแก้ไข
- แจ้งทั้งCSIRT Malta และหน่วยงานที่เกี่ยวข้องพร้อมกันทางอีเมล
- ในรายงานมีสรุปปัญหา ความเป็นไปได้ในการละเมิด GDPR ภาพหน้าจอ และลิงก์ PoC ที่เข้ารหัสไว้
- ขอให้ยืนยันการรับเรื่องภายใน 7 วัน และแก้ไขภายใน 30 วัน
- นี่เป็นขั้นตอนมาตรฐานที่สอดคล้องกับนโยบายการเปิดเผยช่องโหว่ระดับชาติ (NCVDP)
การตอบสนองของหน่วยงาน
- สองวันถัดมา คำตอบกลับไม่ได้มาจากทีมไอที แต่เป็นทนายที่รับผิดชอบด้านการคุ้มครองข้อมูล (สำนักงานกฎหมาย DPO)
- แม้จะกล่าวถึงการรีเซ็ตรหัสผ่านและการนำ 2FA มาใช้ แต่กลับตั้งปัญหาว่าทำไมจึงแจ้งหน่วยงานรัฐก่อน
- พร้อมเตือนว่าการกระทำของผู้เขียนอาจเข้าข่ายความผิดตามประมวลกฎหมายอาญาของมอลตา และอาจต้องรับผิดทางกฎหมาย
- หน่วยงานขอให้ลงนามคำประกาศการรักษาความลับ พร้อมกำหนดให้ส่งสำเนาหนังสือเดินทางและลงนามภายในวันเดียวกัน
- ในคำประกาศมีข้อกำหนดว่า “ให้เก็บเนื้อหาของคำประกาศนี้เป็นความลับ” ซึ่งโดยสาระแล้วเป็นNDA (ข้อตกลงไม่เปิดเผยข้อมูล)
- หลังจากนั้นยังมีการทวงให้ลงนามซ้ำ ๆ เช่น “การแจ้งเตือนด้วยความกรุณา” และ “การแจ้งเตือนด่วน”
การปฏิเสธและโต้แย้งของนักวิจัย
- ผู้เขียนปฏิเสธการลงนามในข้อกำหนดการรักษาความลับ และเสนอคำประกาศการแก้ไขที่มีเพียงการยืนยันการลบข้อมูล
- พร้อมระบุว่าการแจ้ง CSIRT Malta เป็นส่วนหนึ่งของขั้นตอนทางการ และการเผยแพร่บทวิเคราะห์หลังการเปิดเผยเป็นแนวปฏิบัติมาตรฐานของอุตสาหกรรมความปลอดภัย
- หน่วยงานอ้างถึงมาตรา 337E แห่งประมวลกฎหมายอาญา (การใช้คอมพิวเตอร์ในทางที่ผิด) และเตือนว่าการกระทำที่เกิดขึ้นในต่างประเทศก็อาจถือเป็นอาชญากรรมในมอลตาได้
- นอกจากนี้ยังแจ้งว่า หากกล่าวถึงชื่อหน่วยงานในบล็อกหรือการประชุม ก็อาจถูกฟ้องในข้อหาหมิ่นประมาทและเรียกค่าเสียหาย
- ปัจจุบันช่องโหว่ได้รับการแก้ไขแล้ว และกำลังดำเนินการรีเซ็ตรหัสผ่านเริ่มต้นและนำ 2FA มาใช้
- อย่างไรก็ตาม ยังไม่สามารถยืนยันได้ว่ามีการแจ้งผู้เสียหายตาม GDPR มาตรา 33 และ 34 หรือไม่
การผลักภาระและการละเมิด GDPR
- หน่วยงานอ้างว่า “การเปลี่ยนรหัสผ่านเป็นความรับผิดชอบของผู้ใช้”
- แต่ตามGDPR มาตรา 5(1)(f) และ มาตรา 24(1) นั้น ผู้ควบคุมข้อมูลต้องใช้มาตรการด้านเทคนิคและการบริหารที่เหมาะสม
- การใช้รหัสผ่านเริ่มต้นเดียวกันและรหัสแบบเรียงลำดับถือเป็นมาตรการความปลอดภัยที่ไม่เหมาะสมอย่างชัดเจน
รูปแบบที่เกิดซ้ำ
- เมื่อผู้วิจัยด้านความปลอดภัยเปิดเผยช่องโหว่อย่างรับผิดชอบ ก็มักยังเผชิญ “ผลสะเทือนเชิงยับยั้ง (Chilling Effect)” จากภัยคุกคามทางกฎหมาย
- การตอบโต้ทางกฎหมายยิ่งทำลายชื่อเสียงมากขึ้น และปัญหาไม่ใช่ตัวช่องโหว่ แต่คือวิธีที่องค์กรตอบสนอง
ขั้นตอนการตอบสนองที่ถูกต้อง
- รับรายงานและแก้ไข
- แสดงความขอบคุณต่อนักวิจัย
- จัดทำนโยบายCVD (Coordinated Vulnerability Disclosure)
- แจ้งผู้ใช้ที่ได้รับผลกระทบ โดยเฉพาะการคุ้มครองผู้เยาว์
- ห้ามใช้ NDA เพื่อบังคับให้เงียบ
คำแนะนำสำหรับองค์กรและนักวิจัย
- องค์กรควรมีขั้นตอนการเปิดเผยที่ชัดเจน เช่น security.txt และควรขอบคุณนักวิจัย
- นักวิจัยควรให้ CSIRT ระดับชาติมีส่วนร่วม เก็บบันทึกทุกอย่างไว้ทั้งหมด และปฏิเสธการรักษาความลับหลังลบข้อมูลแล้ว
- ข้อกำหนด NIS2 สนับสนุนการเปิดเผยช่องโหว่อย่างรับผิดชอบภายในสหภาพยุโรป
- แม้ในปี 2026 ก็ยังมีความจริงที่ว่าการแจ้งช่องโหว่ง่าย ๆ อาจนำไปสู่ภัยคุกคามทางกฎหมาย
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
มีกรณีที่คนอื่นพบว่า user ID เพิ่มขึ้นแบบลำดับต่อเนื่อง แล้วลองทดสอบจนถึงขั้นติดคุกมาแล้ว
ทันทีที่ทดสอบในลักษณะนั้น ก็มีความเสี่ยงจะเข้าข่าย ละเมิด CFAA
ถ้ารู้อยู่แล้วว่า ID เพิ่มขึ้นแบบลำดับและมีการตั้งรหัสผ่านเริ่มต้นไว้ ก็ควรรายงานช่องโหว่ทันทีตั้งแต่ตอนนั้น
พอรันทดสอบ ก็อาจถือว่าทำผิดกฎหมายแล้ว
การมาเขียนเรื่องนี้ตอนนี้ก็แทบไม่ต่างจากการรับสารภาพ จึงควรจ้างทนายและศึกษากฎหมายที่เกี่ยวข้อง
ผมไม่มีความเชี่ยวชาญทางกฎหมาย แต่มีอยู่สามความคิด
หน่วยงานอย่างบริษัทประกันควรถูกบังคับตามกฎหมายให้ผ่านการตรวจสอบด้านไซเบอร์ ต้องคุ้มครองแฮ็กเกอร์สาย white hat และต้องเปิดทางให้ผู้ใช้ฟ้องแบบกลุ่มได้
ถ้าเป็นแบบนั้น ช่องโหว่พื้นฐานจะหายไป และวิศวกรซอฟต์แวร์จะกลายเป็นทรัพยากรที่คุ้มค่ากว่าทนายความ
ผมสงสัยว่าสาขา CS จะมุ่งไปทางนี้ในยุค AI หรือไม่
วิศวกรมืออาชีพทำหน้าที่อนุมัติแบบและตรวจสอบ และมีบทบาทสำคัญในการรับประกันความปลอดภัย
อำนาจและความรับผิดชอบจึงสูงตามไปด้วย และค่าตอบแทนก็สูง
ผมไม่ได้อยากขัดขวางกิจกรรมโอเพนซอร์สของนักพัฒนามือใหม่ แต่คิดว่าเว็บไซต์ที่จัดการข้อมูลส่วนบุคคลจำนวนมากหรือเงินจำนวนมาก ควรต้องมี วิศวกรซอฟต์แวร์ที่ได้รับการรับรอง ลงนามกำกับ
แบบนั้นจึงจะมีอำนาจพอจะต้านคำสั่งที่เกินเหตุจากฝ่ายบริหารได้
แน่นอนว่าเมื่อดูกรณีของ Boeing หรือ Volkswagen นี่ก็ไม่ใช่ทางแก้ที่สมบูรณ์แบบ
หมายความว่าการรายงานต่อหน่วยงานกับการเปิดเผยต่อสื่อเป็นคนละเรื่องกันโดยสิ้นเชิง
โดยเฉพาะในที่อย่าง มอลตา ซึ่งมีอาชญากรรมองค์กรและคอร์รัปชันรุนแรง คนที่เปิดโปงเรื่องแบบนี้อาจประสบ “อุบัติเหตุ” โดยบังเอิญก็ได้
ผมใช้อีเมลคนละที่สำหรับแต่ละบริการ
เมื่อราว 15 ปีก่อน ผมเริ่มได้รับสแปมที่ส่งมาที่อยู่ diversalertnetwork
พอแจ้ง DAN เรื่องการรั่วไหล ก็ได้รับแค่อีเมลให้เปลี่ยนรหัสผ่าน
ผมยังคิดว่าอย่างน้อยก็โชคดีที่ไม่ถูกแจ้งความอาญา
การที่ผู้เขียนกลัวจะเปิดเผยชื่อองค์กร แปลว่า การข่มขู่ทางกฎหมายได้ผล
สำหรับคำขอให้ “ลงนามรับรองการลบข้อมูล” ก็สงสัยว่าทำไมถึงยอมเซ็น
ดูเหมือนบริษัทต้องการ การควบคุม มากกว่าความร่วมมือ
รูปแบบที่นักวิจัยความปลอดภัยรายงานช่องโหว่แล้วกลับถูก ข่มขู่ทางกฎหมาย นั้นเกิดซ้ำมาหลายสิบปีแล้ว
รัฐบาลและบริษัทต่างพูดถึงความสำคัญของความมั่นคงปลอดภัยไซเบอร์ แต่ในความเป็นจริงกลับเป็นปฏิปักษ์ต่อนักวิจัย
เราจำเป็นต้องมี กฎหมาย เพื่อหยุดการตอบสนองที่ไม่เป็นธรรมแบบนี้
ตัวอย่างกรณีที่เกี่ยวข้องดูได้ที่ลิงก์นี้
ผมสงสัยว่าเป้าหมายของกรณีนี้คือ DAN Europe กับบริษัทลูกอย่าง IDA Insurance Limited หรือไม่
ในเยอรมนี การรันสคริปต์ลักษณะนี้เพื่อเข้าถึงข้อมูลของคนอื่นถือว่า ผิดกฎหมาย
มันไม่ต่างจากการเห็นว่าประตูรถคนอื่นไม่ได้ล็อก แล้วเข้าไปนั่งสตาร์ตรถ
ดูคำอธิบายทางกฎหมายที่เกี่ยวข้องได้ในบทความนี้
การแคปหน้าจอและรายงานภายในขอบเขตการใช้งานเว็บไซต์ตามปกติยังพอรับได้ แต่ถ้า ใช้สคริปต์ Python เก็บข้อมูล ก็ถือว่าข้ามเส้นแล้ว
มันเหมือนกับเห็นประตูธนาคารเปิดอยู่ แล้วแทนที่จะโทรแจ้งตำรวจก็เดินเข้าไปข้างใน
ปีที่แล้วผมพบช่องโหว่ในระบบตั๋วของงานใหญ่แห่งหนึ่ง
ลิงก์ตั๋วที่ส่งมาทางอีเมลคือ การเข้ารหัส base64 ของหมายเลขคำสั่งซื้อแบบลำดับต่อเนื่อง
นั่นหมายความว่าสามารถดาวน์โหลดตั๋วของคนอื่นได้ง่ายมาก
ผมส่งอีเมลไปทั้งผู้จัดงานและบริษัทผู้พัฒนาแล้ว แต่ไม่มีการตอบกลับใด ๆ และจนถึงตอนนี้ก็ยังเปิดอยู่เหมือนเดิม
ปีนี้พอถึงงาน ผมจะคอยดูว่าพวกเขาแก้หรือยัง
ถ้า user ID เป็นแบบลำดับต่อเนื่อง และรหัสผ่านเริ่มต้นก็เหมือนกันหมด ช่องโหว่ที่แท้จริงก็คือ “การสมมติว่ามีเจ้าหน้าที่ความปลอดภัยอยู่จริง”
ทุกวันนี้ “การเปิดเผยอย่างรับผิดชอบ” สุดท้ายก็เป็นแค่ การซื้อเวลาให้บริษัทไปจ้างทนาย เท่านั้น