เหตุการณ์แฮ็กบริษัทประกันจากการนำเครื่องคำนวณเบี้ยประกันไปใช้ในทางที่ผิด
(eaton-works.com)- มีการเปิดเผย ข้อมูลรับรอง Microsoft enterprise cloud จากซับโดเมนเครื่องคำนวณเบี้ยประกันของ Eicher Motors ทำให้สามารถล็อกอินบัญชีอีเมล noreply ของ TTIBI ได้
- API ส่งอีเมลที่เป็นปัญหาส่งเมลได้โดยไม่ต้องยืนยันตัวตน และ ล็อกการส่ง ในการตอบกลับข้อผิดพลาดของเซิร์ฟเวอร์ได้เผยรหัสผ่านที่เข้ารหัสแบบ base64 ออกมา
- ในบัญชีที่รั่วไหลมี อีเมล 657,000 ฉบับ ที่ส่งถึงลูกค้า รวมถึงไฟล์ PDF กรมธรรม์ประกัน ข้อมูลลูกค้า ลิงก์รีเซ็ตรหัสผ่าน และ OTP รวมขนาดราว 25GB
- บัญชีดังกล่าวไม่มี การยืนยันตัวตนสองขั้นตอน และยังเข้าถึงทรัพยากรคลาวด์อื่น ๆ ของ Microsoft ได้ เช่น enterprise directory, SharePoint และ Teams
- หลังการแจ้งเตือนผ่านไปมากกว่า 2 เดือน API ที่มีช่องโหว่ถูกแก้ให้ต้องยืนยันตัวตน และ ณ วันที่ 27 มกราคม 2024 รหัสผ่านบัญชีอีเมลก็ถูกเปลี่ยนแล้วจึงไม่สามารถล็อกอินได้อีก
การเจาะระบบ TTIBI ที่เริ่มต้นจากเครื่องคำนวณเบี้ยประกันของ Eicher
- ระหว่างตรวจสอบระบบของ Eicher Motors พบว่าบัญชีอีเมล Microsoft
noreplyeicher@ttibi.co.inของ Toyota Tsusho Insurance Broker India หรือ TTIBI ถูกเปิดเผย - TTIBI เป็นโบรกเกอร์ประกันในอินเดียภายใต้ Toyota Tsusho Insurance Management Corporation ของญี่ปุ่น ก่อตั้งในปี 2008
- Eicher Motors เป็นผู้ผลิตยานยนต์ของอินเดีย ผลิตรถจักรยานยนต์ของ Royal Enfield Motors และรถเพื่อการพาณิชย์ของ VE Commercial Vehicles ซึ่งเป็นบริษัทร่วมทุนกับ Volvo Group
- ทั้งสองบริษัทมีความร่วมมือด้านประกัน และในเว็บไซต์ของ TTIBI มี ซับโดเมนเฉพาะสำหรับ Eicher อยู่
เส้นทางการค้นพบช่องโหว่
- ระหว่างวิเคราะห์แอป Android MY EICHER พบ URL ของเครื่องคำนวณเบี้ยประกันในคลาส Java ของอินเทอร์เฟซ API
- ในซอร์สโค้ดของเว็บไซต์เครื่องคำนวณเบี้ยประกันมี กลไกส่งอีเมลฝั่งไคลเอนต์ รวมอยู่
- ในโค้ดมีร่องรอยการใช้ Bearer Authorization จึงดูเหมือนว่าต้องมีการยืนยันตัวตน แต่เมื่อประกอบคำขอ API โดยตรง กลับส่งอีเมลได้จริงแทนที่จะได้
401 Unauthorized - การตอบกลับข้อผิดพลาดของเซิร์ฟเวอร์ส่งคืนล็อกการส่งอีเมลมาด้วย และภายในนั้นมี รหัสผ่านที่เข้ารหัสแบบ base64 อยู่
ข้อมูลที่ยังคงอยู่ในบัญชี noreply
noreplyeicher@ttibi.co.inเป็นบัญชี noreply สำหรับส่งอีเมลอัตโนมัติ แต่ใน TTIBI เป็นบัญชีที่สามารถล็อกอินใช้งานได้จริง- ในบัญชีดังกล่าวมีบันทึกอีเมลทั้งหมดที่ส่งถึงลูกค้าอยู่
- อีเมลรวม 657,000 ฉบับ
- ขนาดรวมประมาณ 25GB
- ข้อมูลลูกค้า
- PDF กรมธรรม์ประกัน
- ลิงก์รีเซ็ตรหัสผ่าน
- OTP
- เนื่องจากสามารถเห็นทั้ง OTP และลิงก์รีเซ็ตรหัสผ่าน จึงมีข้อมูลที่อาจถูกนำไปใช้ยึดบัญชีประกันของลูกค้าได้
- บัญชีเดียวกันนี้ยังใช้เข้าถึงทรัพยากรคลาวด์ของ Microsoft ได้ด้วย
- enterprise directory
- SharePoint
- Teams
ความล้มเหลวด้านความปลอดภัยที่ทำให้ช่องโหว่รุนแรงขึ้น
-
ฟีเจอร์ส่งอีเมลฝั่งไคลเอนต์
- ฟังก์ชันส่งอีเมลที่ให้ไคลเอนต์ควบคุมหัวข้อ เนื้อหา และผู้รับ อาจถูกนำไปใช้ส่งอีเมลอันตรายได้
- เพราะเป็นการส่งจากบัญชีจริง จึงอาจกระทบชื่อเสียงอีเมลและนำไปสู่ฟิชชิงได้
-
การขาดการยืนยันตัวตนของ API
- ฝั่งฟรอนต์เอนด์มีร่องรอยการใช้โทเคนยืนยันตัวตน แต่เซิร์ฟเวอร์ไม่ได้ตรวจสอบโทเคนนั้นจริง
- หากเซิร์ฟเวอร์ตรวจสอบโทเคน การโจมตีนี้อาจถูกป้องกันได้
-
การตอบกลับข้อผิดพลาดของ API มากเกินไป
- เมื่อเกิดข้อผิดพลาดระหว่างประมวลผล API เซิร์ฟเวอร์ส่งข้อมูลกลับไปให้ไคลเอนต์มากเกินควร
- ในกรณีนี้ การตอบกลับข้อผิดพลาดได้เปิดเผยรหัสผ่านโดยตรง
-
การไม่มีการยืนยันตัวตนสองขั้นตอน
- ตอนล็อกอินบัญชี Microsoft ไม่มีทั้งการยืนยันตัวตนสองขั้นตอนหรือพรอมป์ตตรวจสอบการเข้าสู่ระบบแบบอื่น
- หากมีการยืนยันตัวตนสองขั้นตอน การล็อกอินสำเร็จอาจทำได้ยากขึ้น
-
การเก็บรักษาอีเมล
- อีเมลทั้งหมดที่บัญชีรับส่งถูกเก็บรักษาไว้ ทำให้เข้าถึงข้อมูลลูกค้าจำนวนมากได้ง่าย
- หากมีนโยบายเก็บรักษาข้อมูล ก็อาจลดผลกระทบจากการเปิดเผยข้อมูลลูกค้าได้
การรับมือและสถานะปัจจุบัน
- ณ วันที่ 17 มกราคม 2024 TTIBI ทราบถึงช่องโหว่มานานกว่า 5 เดือนแล้ว แต่รหัสผ่านบัญชีอีเมลยังไม่ได้ถูกเปลี่ยน
- ตามอัปเดตวันที่ 27 มกราคม 2024 รหัสผ่านบัญชีอีเมลถูกเปลี่ยนแล้ว จึงไม่สามารถล็อกอินเข้าบัญชีนั้นได้อีก
- API ที่มีช่องโหว่ถูกแก้ไขในที่สุดให้ต้องยืนยันตัวตน
- ไม่สามารถยืนยันได้ว่ามีการแจ้งเตือนการล็อกอิน Microsoft ที่ผิดปกติหรือไม่ และหากมี ก็อาจถูกมองข้ามหรือไม่ได้รับการตรวจสอบ
ไทม์ไลน์การแจ้งรายงาน
- TTIBI ไม่ได้อยู่ในขอบเขตของ โครงการเปิดเผยช่องโหว่ผ่าน HackerOne ของ Toyota จึงมีการรายงานไปยัง CERT-In ของอินเดีย
- 7 สิงหาคม 2023: ส่งรายงานรายละเอียดช่องโหว่ไปยัง CERT-In
- 8 สิงหาคม 2023: CERT-In ออก case ID และตอบว่าจะติดต่อ TTIBI
- 1 กันยายน 2023: ขออัปเดตความคืบหน้า
- 6 กันยายน 2023: CERT-In ตอบว่าได้ส่งต่อช่องโหว่ให้ TTIBI แล้ว และจะแชร์ความคืบหน้าเพิ่มเติม
- 8 ตุลาคม 2023: เว็บไซต์ที่ได้รับผลกระทบถูกปิดลง แต่ API ที่มีช่องโหว่ยังอยู่ จึงแจ้ง CERT-In
- 11 ตุลาคม 2023: CERT-In ตอบว่า TTIBI ได้แก้ไขช่องโหว่แล้ว แต่เมื่อตรวจสอบพบว่าช่องโหว่ยังคงอยู่
- 18 ตุลาคม 2023: API ส่งอีเมลถูกเปลี่ยนให้ต้องยืนยันตัวตน ทำให้ช่องโหว่ได้รับการแก้ไข
- หลังจากนั้นมีการสนทนาต่อเพื่อสอบถามเรื่องค่าตอบแทน bug bounty แต่ TTIBI ไม่ตอบ และเคสถูกปิดเมื่อวันที่ 22 ธันวาคม 2023
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
แม้ผมจะไม่ใช่คนอินเดีย แต่ในฐานะคนที่ทำงานอยู่ใน บริษัทไอทีขนาดใหญ่แนว Tata เรื่องนี้ให้ความรู้สึกสมจริงมาก
วัฒนธรรมการบริหารที่ให้รางวัลกับการทำให้จบแบบถูก ๆ และวัฒนธรรมที่กดทับความริเริ่มหรือการเติมเต็มตัวเองของนักพัฒนา มีบทบาทอย่างมาก
ถ้าเจอแบบนี้ในสหรัฐฯ ผมคงลาออกทันที แต่คนเหล่านี้แทบไม่มีทางเลือก เพราะถ้าลาออกจะถูก เรียกคืนเงินเดือน 90 วัน
ผู้จัดการส่วนใหญ่ไม่ได้มาจากสายเทคนิค จึงฟังเฉพาะสิ่งที่อยากได้ยิน และไม่อยากฟังเรื่องที่ผิดพลาด
การมองว่านี่เป็นผลงานของทีมเดียวกันหรือบริษัทเดียวกันก็อาจผิดได้ เพราะนักพัฒนาถูกแยกเป็นไซโลอย่างหนัก แบ่งย่อยเป็นนักพัฒนา API, นักพัฒนา Office 365, นักพัฒนาฟรอนต์เอนด์ และจะไม่แตะงานที่ตัวเองไม่ได้ “ได้รับการรับรอง”
แม้แต่ในการประชุมโครงการมูลค่า 100 ล้านดอลลาร์ ก็ยังเถียงกันจริงจังเรื่องค่าใช้จ่ายของ SendGrid สุดท้ายก็กลายเป็นว่านักพัฒนาคนหนึ่งบอกว่าทำด้วย Office 365 ได้ เพราะไม่มี “ประสบการณ์ SendGrid”
งบของทีมความปลอดภัยถูกตัดเป็นอันดับแรกด้วยเหตุผลว่า “ก็ควรจะปลอดภัยอยู่แล้ว” และต่อให้ไปคุยกับคนรุ่นหลานที่ถูกจ้างมาเป็นฝ่ายความปลอดภัย ท่าทีก็จะเป็นว่าแล้วจะไปวุ่นวายทำไม ในเมื่อรัฐบาลหรือใครสักคนก็ไม่น่าจะฟ้อง
นักพัฒนาไม่ได้รับการส่งเสริมให้พัฒนา แต่ถูกสอนให้ปิดตั๋วงานและอย่าถามคำถาม
ผมทำงานกับนักพัฒนาอินเดียที่ฉลาดมาก ๆ แต่สิ่งนี้ไม่ใช่วัฒนธรรมนวัตกรรม มันคืองานที่ถูกปฏิบัติเหมือนคอลเซ็นเตอร์ อย่าออกนอกสคริปต์ อยู่ในขอบเขตปัญหาแคบ ๆ และตราบใดที่ไม่ล้มเหลวก็ถือว่ากำลังชนะ
เรื่องแบบนี้อาจมาถึงพวกเราในไม่ช้า
ช่วงกลางถึงปลายทศวรรษ 2000 ดีลเลอร์รถยนต์ในเครือ Honda ที่ผมเคยติดต่อด้วยเก็บใบสมัครไฟแนนซ์โดยใช้ ID ตัวเลขที่เพิ่มขึ้นเรื่อย ๆ
ผมไม่ได้รายงาน แต่สามารถดูข้อมูลอ่อนไหวของผู้อยู่อาศัยในนิวเจอร์ซีย์ได้หลายรายการ เช่น SSN วันเกิด ชื่อ และที่อยู่
ตอนนั้นแทบไม่มี bug bounty และมี CFAA อยู่แล้ว ผมจึงไม่ได้รายงาน
ผมให้เขาลบใบสมัครของผม แต่ช่องโหว่นั้นยังอยู่ต่ออีกหลายปีจนกว่าจะเปลี่ยนเป็นระบบใหม่ และระบบใหม่ก็ดูเหมือนจะยังเปราะบาง
หลังจากนั้นผมไม่ทำธุรกิจกับดีลเลอร์รายนั้นอีก และทุกวันนี้ก็ยังระวังดีลเลอร์รถยนต์กับใบสมัครไฟแนนซ์มาก ต่อให้แพงขึ้นนิดหน่อย ผมมักจะไปขอไฟแนนซ์จากที่อื่น
https://eaton-works.com/2023/06/06/honda-ecommerce-hack/
ที่ https://cerebrum.com กำลังทำงานในอีกด้านหนึ่งคือการตรวจสอบตัวตน และคอมเมนต์นี้ทำให้ผมได้ไอเดียมากมาย
ความผิดพลาดด้านความปลอดภัยเองนั้นเลวร้ายมาก แต่ก็พออธิบายได้ระดับหนึ่งว่าเป็นการมอบหมายงานที่เกินขอบเขตความเข้าใจของนักพัฒนาที่ไม่มีประสบการณ์ไปมาก
แต่ผมไม่เข้าใจเลยว่าอนุมัติให้เก็บ เอกสารลูกค้าที่เป็นความลับ ไว้ในบัญชีอีเมลได้อย่างไร
นั่นหมายความว่าไม่มีผู้รับผิดชอบคนใดรู้วิธีดำเนินธุรกิจนี้ และถ้าเป็นบริษัทลูกหรือพาร์ตเนอร์เอาต์ซอร์ส ก็หมายความว่าไม่เคยมีใครตรวจสอบเลย
ทั้งเจ้าของบริษัทและฝ่ายที่มอบหมายงานนี้ทำเรื่องที่ใกล้เคียงกับความประมาททางอาญา
น่าจะมีฟีเจอร์เก็บเมลที่ส่งแล้วของเซิร์ฟเวอร์อีเมล และเกิดเป็นผลพลอยได้จากการตัดสินใจโง่ ๆ ที่ใช้บัญชีจริงกับที่อยู่ “noreply” มากกว่า
มันทำหน้าที่เป็นทั้งบันทึก audit log, เครื่องมือดีบัก และแบ็กอัปฐานข้อมูลไปพร้อมกัน
เพิ่งเปลี่ยนก็ตอนที่รู้ว่าพนักงานเอาข้อมูลลูกค้าทั้งหมดติดตัวไปที่งานใหม่
ถ้า “ผ่านไปกว่า 5 เดือนแล้ว TTIBI ยังรู้ช่องโหว่แต่ไม่เปลี่ยนรหัสผ่านบัญชีอีเมล” อย่างน้อยก็หวังว่าจะเอา รหัสผ่าน Base64 ออกจาก error log แล้ว
คงทำแล้วแน่ ๆ ใช่ไหม?
ผลกระทบใหญ่โตถึงระดับเข้าถึง SharePoint และ Outlook ได้ทั้งหมดอย่างแท้จริง แต่เส้นทางโจมตีเป็นแค่การดู JavaScript ฝั่งไคลเอนต์ จึงเป็นช่องโหว่ที่ค่อนข้างแปลก
ข้อเล็กน้อยอย่างหนึ่งคือ ผมคิดว่าสำหรับข้อมูลอ่อนไหวในภาพหน้าจอ การปิดด้วย บล็อกสีดำ ดีกว่าการเบลอ ระวังไว้ไม่เสียหาย
โครงสร้างที่จบลงด้วย “จดหมายขอบคุณ” ทำให้ช่องโหว่ส่วนใหญ่แบบนี้ไม่ได้ถูกรายงานหรือเปิดเผยโดย white hat แต่ถูกแฮกเกอร์นำไปใช้โจมตีอย่างจริงจัง
ควรมีกรอบกฎหมายที่ให้บริษัทรับผิดชอบต่อ การบริหารจัดการความปลอดภัยที่บกพร่อง เกินระดับหนึ่งในเรื่องข้อมูลส่วนบุคคลของลูกค้า
อินเดียมีปัญหาที่ใหญ่กว่าข้อมูลรั่วไหล
หนึ่งในนั้นคือการจ่ายไฟฟ้าที่เสถียร
ผมกำลังรอวันที่อินเดียมีไฟฟ้าเพียงพอจนการแฮ็กกลายเป็นเรื่องหลักที่ต้องกังวล
ตอนนี้กำลังปูไฟเบอร์ออปติกเดือนละ 100,000 กม. และตั้งสถานีฐาน 5G วันละ 350 แห่ง
ต้องมองด้วยว่าอีเมล endpoint สำหรับมอนิเตอร์นี้ถูกออกแบบแทบจะเหมือน worker/agent/runner สำหรับงานสื่อสาร แล้วถูกปล่อยทิ้งไว้จนพองตัวขึ้นเรื่อย ๆ
นั่นหมายความว่าไม่มีการมอนิเตอร์ปริมาณการใช้อีเมล และไม่มีมาตรการเสริมในการหา behavior ผิดปกติอย่าง “ทำไมนามแฝงอีเมลนี้ถึงมีค่า storage สูงกว่าของอื่นหลายเท่า?”
ประเด็นสำคัญคือคำพูดที่ว่า “บัญชี noreply อาจเป็นบัญชีที่สำคัญที่สุดในองค์กร เพราะอาจมีบันทึกทั้งหมดที่ส่งถึงลูกค้า”
ถ้า “โบรกเกอร์ประกันชั้นนำทั่วอินเดีย” ไม่มีเงินจ้างนักพัฒนาที่มีความสามารถ อย่างน้อยก็ควรจ่ายเงินสักเล็กน้อยให้คนที่ค้นพบปัญหาร้ายแรงหลายอย่างซึ่งทำให้ลูกค้าเสี่ยง และแจ้งอย่างรับผิดชอบ
แต่กลับไม่ทำ และยิ่งไม่น่าเชื่อที่แม้แต่ รหัสผ่านบัญชีอีเมลที่ถูกเจาะ ก็ยังไม่ได้รีเซ็ต
จะเชื่อบริษัทที่ทำตัวแบบนี้ให้ทำอะไรอย่างถูกต้องได้อย่างไร
Toyota Tsusho Insurance Broker India ดูเหมือนเป็นบริษัทที่ควรหลีกเลี่ยงเหมือนโรคระบาด
นี่ไม่ใช่กรณีที่ใครบางคนจงใจเพิกเฉยต่อคำเตือนด้านความปลอดภัยสำคัญ แต่เป็นสภาพที่พวกเขาไม่เข้าใจว่าคุณกำลังพูดอะไร
พวกเขาไม่เข้าใจพื้นฐานของสภาพแวดล้อมที่ตัวเองดูแลหรือโจทย์ที่เผชิญอยู่ และศัพท์เฉพาะที่คุณใช้ไม่มีความหมายต่อเขาหรือทีมของเขา จึงแค่อยากให้คุณหายไป
ท่าทีประมาณว่า “หยุดส่งอีเมลที่ทำให้สับสนพวกนี้ได้แล้ว เรามีเรื่องสำคัญต้องทำ”
จะแก้ได้ต้องมี การเปลี่ยนผู้นำระดับบน ในระดับองค์กร และหัวหน้า IT กับทุกอย่างที่เขาเคยแตะต้องต้องออกไป
ส่วนหนึ่งของปัญหาคือพวกเขาใช้กล่องขาเข้านี้แทบจะเป็น บัญชี SMTP “ฟรี” เพื่อเลี่ยงค่าใช้จ่ายอีเมลขาออก
ถ้าใช้บริการอย่าง SES กล่องจดหมายส่งแล้ว/กล่องขาเข้าของบัญชีนี้คงไม่มีข้อมูลอ่อนไหวมากขนาดนี้
SES ถูกมาก แค่ 0.10 ดอลลาร์ต่อ 1,000 ฉบับ
ต้องเก็บอีเมลทั้งหมดที่ส่งออกไป และสร้างอินเทอร์เฟซให้ผู้รับผิดชอบงานที่ไม่ใช่นักพัฒนาสามารถดูและค้นหาข้อความเก่าได้
ถ้าใช้ฟังก์ชันทั้งหมดของแนวทาง SMTP “ฟรี” นี้อยู่จริง ต้นทุนการพัฒนาและการบำรุงรักษาก็ค่อนข้างสูง