⚠️ หมายเหตุการเผยแพร่: รายงานฉบับนี้จัดทำขึ้นเพื่อสรุปและวิเคราะห์เหตุการณ์ที่ บริษัท ศูนย์รับฝากหลักทรัพย์ (ประเทศไทย) จำกัด (TSD) เปิดเผยต่อสาธารณะแล้ว โดยเสริมรายละเอียดเชิงเทคนิคและตัวเลขที่ทีม TXEC ได้รับมาเพื่อประโยชน์ด้านการเรียนรู้และป้องกันของสมาชิก
บทสรุป
TSD Investor Portal ประสบเหตุการณ์ข้อมูลส่วนบุคคลของนักลงทุนรั่วไหล อันเป็นผลจากช่องโหว่ประเภท IDOR (Insecure Direct Object Reference) บนหน้าฟังก์ชัน "Edit User Profile" ของระบบ ทำให้ผู้ใช้งานสามารถแก้ไขค่า User ID ในคำขอ (Request) แล้วเข้าถึงข้อมูลของผู้ใช้งานรายอื่นได้โดยไม่ได้รับอนุญาต
จากการตรวจสอบพบว่ามีบัญชีที่ได้รับผลกระทบ ประมาณ 200,000 บัญชี จากผู้ใช้งานพอร์ทัลทั้งหมดกว่า 5,000,000 ราย โดยเหตุการณ์ถูกตรวจพบและยืนยันในช่วงวันที่ 25-26 กรกฎาคม 2569
ข่าวดีคือข้อมูลที่รั่วไหลเป็นข้อมูลส่วนบุคคลทั่วไป ไม่ครอบคลุมข้อมูลพอร์ตการลงทุน มูลค่าหลักทรัพย์ ประวัติการทำธุรกรรม หรือสิทธิในการโอน/ซื้อขายหุ้น และไม่สามารถนำไปใช้ทำธุรกรรมซื้อขายหรือแก้ไขสิทธิ์ในระบบได้โดยตรง อย่างไรก็ตาม ข้อมูลที่หลุดออกไปยังมีความเสี่ยงสูงต่อการถูกนำไปใช้ในการโจมตีต่อเนื่อง เช่น Phishing และ Social Engineering ที่แอบอ้างเป็น TSD หรือโบรกเกอร์ของเหยื่อ
1. ไทม์ไลน์และข้อเท็จจริงของเหตุการณ์
- ระบบที่ได้รับผลกระทบ: TSD Investor Portal
- ประเภทช่องโหว่: Business Logic / Access Control (IDOR)
- จุดที่พบช่องโหว่: ฟังก์ชัน "Edit User Profile"
- บัญชีที่ได้รับผลกระทบ: ประมาณ 200,000 บัญชี
- ผู้ใช้งานพอร์ทัลทั้งหมด: ประมาณ 5,000,000 ราย
- วันที่ตรวจพบและยืนยันเหตุการณ์: 25-26 กรกฎาคม 2569
สัดส่วนบัญชีที่ได้รับผลกระทบคิดเป็นประมาณ 4% ของผู้ใช้งานทั้งหมด ซึ่งแม้จะเป็นสัดส่วนที่ไม่สูงมากเมื่อเทียบกับฐานผู้ใช้งานรวม แต่ในเชิงจำนวนสัมบูรณ์ถือว่าเป็นเหตุการณ์ข้อมูลรั่วไหลขนาดใหญ่ระดับประเทศ เนื่องจากเกี่ยวข้องกับข้อมูลนักลงทุนในตลาดทุนไทยโดยตรง
2. รายละเอียดทางเทคนิค: ช่องโหว่ IDOR คืออะไร
Insecure Direct Object Reference (IDOR) คือช่องโหว่ที่เกิดขึ้นเมื่อระบบไม่ตรวจสอบสิทธิ์ในการเข้าถึงข้อมูลอย่างเหมาะสมก่อนดึงข้อมูลตามค่า Identifier (เช่น User ID, Record ID) ที่ส่งมาในคำขอ ทำให้ผู้ใช้งานที่มีเจตนาไม่ดีสามารถแก้ไขค่า ID เหล่านี้เพื่อเข้าถึงหรือแก้ไขข้อมูลของผู้ใช้งานรายอื่นที่ตนไม่มีสิทธิ์ได้
ตัวอย่างรูปแบบการโจมตีทั่วไป: หากระบบเปิดให้เข้าถึงข้อมูลผ่าน URL ลักษณะ https://app.com/profile?user-id=308 และระบบไม่ตรวจสอบว่าผู้ที่ร้องขอเป็นเจ้าของ User ID นั้นจริงหรือไม่ ผู้โจมตีสามารถเปลี่ยนค่าเป็น user-id=309 เพื่อดึงข้อมูลของผู้ใช้งานคนถัดไปได้ทันที โดยไม่ต้องอาศัยการเจาะระบบที่ซับซ้อน
กลไกที่เกิดขึ้นในกรณีของ TSD
- ผู้ใช้งานเข้าสู่หน้า "Edit User Profile" บน TSD Investor Portal ตามปกติ
- ระบบเรียกข้อมูลโปรไฟล์โดยอ้างอิงจากค่า User ID ที่ส่งมาในคำขอ
- เนื่องจากระบบไม่ได้ตรวจสอบว่า User ID ที่ระบุมาตรงกับผู้ใช้งานที่ Login อยู่จริงหรือไม่ (Broken Access Control) ผู้ที่แก้ไขค่า User ID จึงสามารถดึงและเข้าถึงข้อมูลของผู้ใช้งานรายอื่นออกมาได้
- ช่องโหว่นี้จัดอยู่ในหมวด Business Logic / Access Control ไม่ใช่ช่องโหว่ระดับ Infrastructure หรือ Network จึงมักตรวจไม่พบด้วยเครื่องมือสแกนอัตโนมัติทั่วไป และต้องอาศัยการทำ Code Review หรือ Penetration Test ที่เจาะจงตรวจสอบ Business Logic โดยเฉพาะ
3. ข้อมูลที่ได้รับผลกระทบเทียบกับข้อมูลที่ปลอดภัย
ข้อมูลส่วนบุคคลที่รั่วไหล (ได้รับผลกระทบ)
- ชื่อ-นามสกุล, วันเดือนปีเกิด, เลขบัตรประชาชน, ที่อยู่
- เบอร์โทรศัพท์, อีเมล
- ชื่อบริษัทหลักทรัพย์ (โบรกเกอร์) และเลขบัญชีซื้อขายหลักทรัพย์
- ชื่อธนาคารและเลขที่บัญชีธนาคาร
ข้อมูลที่ไม่ได้รับผลกระทบ (ปลอดภัย)
- ข้อมูลการถือครองหลักทรัพย์ (จำนวนหุ้น)
- มูลค่าพอร์ตการลงทุน
- ประวัติการทำธุรกรรมซื้อขาย
- สิทธิในการโอนหรือซื้อขายหุ้น
ประเด็นสำคัญ: ข้อมูลที่รั่วไหลไม่สามารถนำไปใช้ทำธุรกรรมซื้อขายหรือแก้ไขสิทธิ์ในระบบได้โดยตรง เนื่องจากช่องโหว่นี้จำกัดอยู่ที่การเข้าถึงข้อมูลโปรไฟล์ (Read Access) เท่านั้น ไม่ได้เปิดช่องให้แก้ไขธุรกรรมหรือสิทธิ์การถือครองหลักทรัพย์แต่อย่างใด อย่างไรก็ตาม ข้อมูลส่วนบุคคลและข้อมูลบัญชีธนาคาร/หลักทรัพย์ที่หลุดออกไปยังคงมีมูลค่าสูงสำหรับผู้ไม่หวังดีในการนำไปใช้ประกอบการโจมตีรูปแบบอื่นต่อ
4. มาตรการที่ TSD ดำเนินการแล้ว
หลังตรวจพบเหตุการณ์ TSD ดำเนินการตอบสนองในหลายด้านพร้อมกัน:
- ปิดกั้นการเข้าถึงระบบที่มีช่องโหว่ เพื่อยุติความเสี่ยงจากการถูกเข้าถึงเพิ่มเติมทันที
- แจ้งหน่วยงานกำกับดูแล ทั้งสำนักงานคณะกรรมการกำกับหลักทรัพย์และตลาดหลักทรัพย์ (ก.ล.ต.) และสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ตามข้อกำหนดของกฎหมาย PDPA
- ประสานงานกับกองบังคับการปราบปรามการกระทำความผิดเกี่ยวกับอาชญากรรมทางเทคโนโลยี (CCIB) เพื่อดำเนินการสอบสวนเหตุการณ์
- เร่งเสริมความปลอดภัยของแอปพลิเคชันที่เกี่ยวข้อง (เช่น ระบบ wiset) เพื่อลดความเสี่ยงจากช่องโหว่ลักษณะเดียวกันในจุดอื่น
- แจ้งเจ้าของข้อมูลที่ได้รับผลกระทบ ตามข้อกำหนดของกฎหมายคุ้มครองข้อมูลส่วนบุคคล
5. สถานะปัจจุบันของการตรวจสอบ
การตรวจสอบเบื้องต้นดำเนินการเสร็จสิ้นในส่วนของการระบุสาเหตุและขอบเขตผลกระทบแล้ว แต่ยังอยู่ระหว่างรอการยืนยันร่วมกันระหว่าง TSD และสำนักงาน ก.ล.ต. ก่อนสรุปผลขั้นสุดท้ายอย่างเป็นทางการ ระหว่างนี้ TSD ได้เริ่มดำเนินมาตรการเสริมความปลอดภัยชั่วคราว เช่น การทำ IP Whitelist สำหรับการเข้าถึงระบบ ควบคู่ไปก่อน โดยไม่รอผลสรุปขั้นสุดท้าย เพื่อลดความเสี่ยงระหว่างช่วงเปลี่ยนผ่าน
การตรวจสอบและมาตรการทั้งหมดยึดหลักการปกป้องข้อมูลและระบบของ TSD โดยคำนึงถึงความปลอดภัย ความโปร่งใส และการปฏิบัติตามกฎหมายที่เกี่ยวข้องเป็นสำคัญ
6. คำแนะนำสำหรับนักลงทุนที่อาจได้รับผลกระทบ
- ติดตามข่าวสารอย่างใกล้ชิด ผ่านช่องทางทางการของ TSD เท่านั้น อย่าเชื่อข้อมูลจากแหล่งที่ไม่สามารถยืนยันได้
- รักษาความปลอดภัยบัญชีผู้ใช้ เปลี่ยนรหัสผ่านเป็นประจำ ไม่ใช้รหัสผ่านเดียวกันซ้ำกันหลายระบบ และเปิดใช้งาน Two-Factor Authentication (2FA) หากระบบรองรับ
- ระวังอีเมลและลิงก์ปลอม อย่าคลิกลิงก์หรือดาวน์โหลดไฟล์จากแหล่งที่ไม่น่าเชื่อถือ และไม่ให้ข้อมูลส่วนบุคคลผ่านอีเมลหรือข้อความที่ไม่สามารถยืนยันแหล่งที่มาได้
- ตรวจสอบความผิดปกติ เช่น การ Login เข้าระบบที่ไม่รู้จัก หรือการเปลี่ยนแปลงข้อมูลโดยที่ไม่ได้ดำเนินการเอง หากพบให้แจ้ง TSD ทันที
- ติดต่อสอบถาม หากมีข้อสงสัยหรือต้องการข้อมูลเพิ่มเติม ควรติดต่อผ่านช่องทางทางการของ TSD เท่านั้น
7. แนวทางป้องกันช่องโหว่ IDOR สำหรับองค์กร
สำหรับองค์กรที่พัฒนาหรือดูแลระบบที่มีการเข้าถึงข้อมูลผ่าน Identifier ในลักษณะเดียวกับกรณีนี้ TXEC สรุปแนวทางป้องกันหลักไว้ดังนี้:
1. ตรวจสอบสิทธิ์ทุกครั้งก่อนเข้าถึงข้อมูล
ตรวจสอบว่าผู้ใช้งานมีสิทธิ์เข้าถึงข้อมูลนั้นจริงก่อนทุกการเรียกใช้งาน ไม่ควรอนุมัติคำขอเพียงเพราะรูปแบบ Request ถูกต้อง
2. ผูกข้อมูลกับผู้ใช้งานอย่างชัดเจน (Ownership Binding)
ทุกข้อมูลต้องผูกกับเจ้าของ (Owner/User ID) และตรวจสอบความสัมพันธ์ของข้อมูลกับผู้ร้องขอเสมอ ก่อนส่งข้อมูลกลับไป
3. ใช้กลไก Authorization ที่เหมาะสม
นำ Role-Based Access Control (RBAC) หรือ Attribute-Based Access Control (ABAC) มาใช้ควบคุมสิทธิ์การเข้าถึงข้อมูลอย่างเป็นระบบ แทนการพึ่งพา Business Logic แบบ Ad-hoc
4. ใช้ UUID หรือ Token แทน Sequential ID
การใช้ ID แบบเรียงลำดับ (Sequential ID) ทำให้ผู้โจมตีคาดเดาค่า ID ของผู้ใช้งานรายอื่นได้ง่าย ควรเปลี่ยนไปใช้ UUID หรือ Token ที่คาดเดาไม่ได้แทน
5. ตรวจสอบสิทธิ์ที่ฝั่งเซิร์ฟเวอร์เสมอ
ห้ามเชื่อค่าที่ส่งมาจากฝั่ง Client เพียงอย่างเดียว การตรวจสอบและบังคับใช้สิทธิ์ต้องเกิดขึ้นที่ฝั่งเซิร์ฟเวอร์เท่านั้น
6. บันทึกและเฝ้าระวังการเข้าถึงข้อมูลที่ผิดปกติ
ตั้ง Logging และ Alert สำหรับรูปแบบการเข้าถึงข้อมูลที่ผิดปกติ เช่น การเปลี่ยนค่า ID ต่อเนื่องเป็นชุด (Sequential Enumeration)
7. ทดสอบและทบทวนความปลอดภัยอย่างสม่ำเสมอ
ทำ Penetration Test และ Code Review ที่ครอบคลุมการตรวจสอบ Business Logic และ Access Control โดยเฉพาะ ไม่ใช่พึ่งพาเพียง Automated Vulnerability Scanner ซึ่งมักตรวจจับช่องโหว่ประเภทนี้ได้ยาก
8. วิเคราะห์ในมุมมองจาก TXEC
เหตุการณ์นี้เป็นตัวอย่างสำคัญที่แสดงให้เห็นว่าช่องโหว่ที่ดูเหมือนเรียบง่ายอย่าง IDOR สามารถสร้างผลกระทบขนาดใหญ่ได้เมื่อเกิดขึ้นกับระบบที่มีฐานผู้ใช้งานจำนวนมาก โดยเฉพาะระบบโครงสร้างพื้นฐานของตลาดทุนที่จัดเก็บข้อมูลนักลงทุนไว้จำนวนมาก จุดที่ TXEC อยากเน้นย้ำเป็นพิเศษมีดังนี้
1. IDOR เป็นช่องโหว่ที่ตรวจจับด้วยเครื่องมืออัตโนมัติได้ยาก
เนื่องจากเป็นปัญหาด้าน Business Logic ไม่ใช่ช่องโหว่ทางเทคนิคระดับ Infrastructure การป้องกันที่ได้ผลจริงต้องอาศัยกระบวนการ Code Review และ Penetration Test ที่ออกแบบมาเฉพาะเจาะจง ไม่สามารถพึ่งพา Automated Scanner เพียงอย่างเดียวได้
2. การตอบสนองที่รวดเร็วและโปร่งใสของ TSD เป็นตัวอย่างที่ดี
การปิดระบบทันทีที่ตรวจพบ การแจ้งหน่วยงานกำกับดูแลตามกฎหมาย และการประสานงานกับหน่วยงานสอบสวน สะท้อนกระบวนการจัดการเหตุการณ์ที่เป็นมาตรฐาน ซึ่งช่วยจำกัดความเสียหายและสร้างความเชื่อมั่นให้กับผู้ใช้งานได้ในระดับหนึ่ง แม้เหตุการณ์จะยังไม่มีข้อสรุปที่เป็นทางการครบถ้วน
3. ข้อมูลที่รั่วไหลแม้ "ไม่กระทบธุรกรรม" ก็ยังมีความเสี่ยงสูง
แม้ TSD จะยืนยันว่าข้อมูลพอร์ตการลงทุนและธุรกรรมไม่ได้รับผลกระทบโดยตรง แต่ข้อมูลส่วนบุคคลและข้อมูลบัญชีธนาคาร/หลักทรัพย์ที่หลุดออกไปยังเป็นวัตถุดิบสำคัญสำหรับการโจมตีแบบ Phishing และ Social Engineering ที่แนบเนียนมากขึ้น องค์กรและนักลงทุนที่เกี่ยวข้องไม่ควรลดการ์ดลงเพียงเพราะทราบว่าธุรกรรมทางการเงินไม่ได้รับผลกระทบโดยตรง
4. บทเรียนสำหรับองค์กรอื่นในภาคการเงินไทย
องค์กรที่มีระบบ Portal ให้ลูกค้าหรือนักลงทุนเข้าถึงข้อมูลส่วนตัวโดยตรง ควรถือเหตุการณ์นี้เป็นสัญญาณเตือนให้ทบทวนการตรวจสอบสิทธิ์ (Authorization) ในทุกฟังก์ชันที่เกี่ยวข้องกับการเข้าถึงหรือแก้ไขข้อมูลผู้ใช้งาน โดยเฉพาะฟังก์ชันที่ดูเหมือนไม่มีความเสี่ยงสูงอย่าง "Edit Profile" ก็สามารถกลายเป็นช่องทางรั่วไหลข้อมูลขนาดใหญ่ได้เช่นกัน
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
🔒 เนื้อหานี้จัดทำขึ้นเพื่อสมาชิก TXEC โดยเฉพาะ
กรุณาอย่าเผยแพร่นอกแพลตฟอร์ม TXEC โดยไม่ได้รับอนุญาต
ข้อมูลตัวเลขและรายละเอียดเชิงเทคนิคในรายงานนี้สรุปมาจากข้อมูลที่ทีมได้รับ และการเปิดเผยต่อสาธารณะของ TSD ผู้อ่านควรตรวจสอบข้อมูลล่าสุดจากประกาศทางการของ TSD ควบคู่กันเสมอ
ความคิดเห็น