การวิเคราะห์การตรวจสอบข้อมูลรั่วไหลของ Oracle Cloud เพิ่มเติมโดย CloudSEK

เมื่อวันที่ 21 มีนาคม 2025 ผู้ใช้งานที่ใช้ชื่อ 'rose87168' ได้โพสต์ข้อความบนเว็บไซต์ BreachForums โดยอ้างว่าสามารถเข้าถึงเซิร์ฟเวอร์การเข้าสู่ระบบของ Oracle Cloud ได้ และได้เสนอขายข้อมูลสำคัญ เช่น ข้อมูล Credentials ของระบบ SSO และ LDAP, คีย์ OAuth2 และข้อมูลของลูกค้าในแต่ละ tenant

CloudSEK ซึ่งใช้แพลตฟอร์ม CloudSEK Nexus และ Cyber HUMINT เป็นรายแรกที่ตรวจสอบข้อมูลดังกล่าว และได้ยืนยันความถูกต้องของข้อมูล จากนั้นได้แจ้งเตือนต่อสาธารณะ และลูกค้าของบริษัท

เนื่องจากข้อมูลที่รั่วไหลสามารถถูกนำไปใช้ในการโจมตีแบบ Supply Chain ในวงกว้างได้ บริษัทจึงได้จัดทำรายงาน TLP Green เพื่อเตือนชุมชนความปลอดภัยทางไซเบอร์ พร้อมทั้งแจ้ง Oracle อย่างเป็นทางการในวันเดียวกันผ่านรายงาน TLP RED นอกจากนี้ บริษัทยังได้พัฒนาเครื่องมือตรวจสอบฟรี เพื่อให้องค์กรสามารถตรวจสอบได้ว่ามีรายชื่ออยู่ในกลุ่มของเหยื่อที่ถูกเปิดเผยโดยผู้ไม่หวังดีหรือไม่ สามารถตรวจสอบได้ที่ Link

ต่อมาในวันเดียวกัน Oracle ได้ออกแถลงการณ์ปฏิเสธอย่างชัดเจนว่า "ไม่มีเหตุการณ์ข้อมูลรั่วไหลเกิดขึ้นกับ Oracle Cloud"

‍‍เนื่องจาก CloudSEK เป็นผู้เปิดเผยภัยคุกคามนี้เป็นรายแรก จึงมีผู้ติดต่อสอบถามเข้ามาเป็นจำนวนมาก ซึ่งบริษัทได้รวบรวมคำถามเหล่านั้นพร้อมคำตอบไว้แล้วที่ Link

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

ข้อมูลเบื้องหลัง

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

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

ข้อมูลจากการวิเคราะห์

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

เพื่อให้ได้ข้อสรุปที่ชัดเจน นักวิจัยได้ตรวจสอบข้อมูลจากแหล่งข่าวกรองนับพันรายการ และได้ข้อสรุปดังต่อไปนี้

หลักฐานที่ 1 : วัตถุประสงค์ของ login.us2.oraclecloud.com

นักวิจัยพบที่ archived สาธารณะบน GitHub repository ซึ่งอัปโหลดโดย oracle-quickstart (ซึ่งเป็นองค์กรทางการของ Oracle บน GitHub) และพบการกล่าวถึง "login.us2.oraclecloud.com" ในข้อมูลดังกล่าว

วัตถุประสงค์ของสคริปต์

  1. OAuth2 Authentication : สคริปต์ใช้ "client credentials grant" ในการยืนยันตัวตนสำหรับ API requests
  2. Token Generation : สคริปต์จะส่ง POST request ไปยัง URL ดังกล่าวพร้อมกับ client_id และ secret_key (ที่เข้ารหัส Base64)
  3. Authorization Header : Access token ที่ได้รับจะถูกใช้ใน API requests ต่อไปในรูปแบบของ Bearer token

สคริปต์ใน GitHub repo ที่ชื่อ 'mpapihelper.py' อ้างอิงโดยตรงไปยัง login.us2.oraclecloud.com สำหรับการสร้าง OAuth2 Access token

โดย token ที่ได้รับจะถูกใช้ในการโต้ตอบกับ Oracle Cloud Marketplace API ซึ่งช่วยในการจัดการรายการต่าง ๆ ใน Oracle Cloud Marketplace

หลักฐานที่ 2 : โดเมนของลูกค้าจริงตรงกับในรายการของผู้ไม่หวังดี

GitHub repositories หลายรายการ พบว่าได้มีการฝังข้อมูล Credentials หรือการตั้งค่าที่ชี้ไปยัง login.us2.oraclecloud.com เช่น

1. https://github.com/BhavaniPericherla/Selenium/blob/master/config.properties

  • Domain: sbgtv.com‍
  • Status: อยู่ในรายการโดเมนที่ถูกเปิดเผยโดยผู้ไม่หวังดี

2. https://github.com/Ejazkhan42/React-UI/blob/9f0b5e36f34c80d514b72af27e9d6973ff3fedf1/queries.js#L284

  • Domain: nexinfo.com‍
  • Status: อยู่ในรายการโดเมนที่ถูกเปิดเผยโดยผู้ไม่หวังดี

3. https://pdfslide.net/embed/v1/manual-del-portal-de-proveedor-supplier-portal-manual-del-portal-de-proveedor.html [ปัจจุบัน Inactive]

เอกสารนี้ทำหน้าที่เป็นแหล่งข้อมูลที่ละเอียดเกี่ยวกับพอร์ทัลผู้จัดหาของบริษัท โดยมีคำแนะนำให้ผู้ใช้งานเข้าสู่ระบบผ่านทาง Oracle Login endpoint ที่กล่าวถึง (ehbm.login.us2.oraclecloud.com)

  • Domain:  nucor-jfe.com‍
  • Status: อยู่ในรายการโดเมนที่ถูกเปิดเผยโดยผู้ไม่หวังดี

4. https://github.com/juju/go-oracle-cloud/pull/1/commits/4200f51ee63563ab07bac3c038b29d294b6c81b8

  • Domain:  cloudbasesolutions.com‍
  • Status: อยู่ในรายการโดเมนที่ถูกเปิดเผยโดยผู้ไม่หวังดี

5. เอกสารที่ใช้เป็น "คู่มือผู้ใช้งาน" สำหรับ Oracle บน rapid4cloud CDN ซึ่งเป็นพันธมิตรของ Oracle มีการระบุ URL ของ OAM (Oracle Access Manager) ในส่วนของการแก้ไขปัญหา

  • Domain:  rapid4cloud.com‍
  • Status: อยู่ในรายการโดเมนที่ถูกเปิดเผยโดยผู้ไม่หวังดี

หลักฐานที่ 3 : "login.us2.oraclecloud.com" เป็นการตั้งค่า SSO ในระบบ Production

1. OneLogin ซึ่งเป็นผู้ให้บริการโซลูชัน IAM (Identity and Access Management) มีบทความใน knowledge-base เกี่ยวกับ Oracle Fusion โดยอธิบายวิธีการกำหนดค่า OneLogin เพื่อให้บริการ SSO สำหรับ Oracle Fusion โดยใช้ SAML (Security Assertion Markup Language)

2. Rainfocus ซึ่งเป็นพันธมิตรของ Oracle Cloud สำหรับการติดตั้ง และการย้ายข้อมูล ได้เผยแพร่ไฟล์ดังต่อไปนี้บนเว็บไซต์ของพวกเขา

จากที่เห็นข้างต้น คู่มือแนะนำให้ผู้ใช้งานเข้าสู่ระบบที่ <identity-domain>.login.us2.oraclecloud.com/fed/idp/metadata เพื่อลงข้อมูล Metadata ของ Identity Provider ซึ่งยืนยันว่า <identity-domain>.login.us2.oraclecloud.com ถูกใช้งานในระบบ Production

อัปเดต : 25 มีนาคม 2025

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

  1. ผลกระทบวงกว้างต่อองค์กรต่าง ๆ : ตัวอย่างข้อมูลที่ได้รับมีข้อมูลจากองค์กรมากกว่า 1,500 แห่ง ซึ่งแสดงให้เห็นถึงการรั่วไหลของข้อมูลขนาดใหญ่
  2. ความถูกต้องของข้อมูล : ปริมาณ และโครงสร้างของข้อมูลที่รั่วไหลทำให้ยากที่จะปลอมแปลง ซึ่งยืนยันความน่าเชื่อถือของเหตุการณ์การรั่วไหล
  3. สัญญาณการเข้าถึงระบบ Production : หลายองค์กรที่ได้รับผลกระทบมี tenantIDs ในรูปแบบ {tenant}-dev, {tenant}-test และ {tenant} ซึ่งชี้ให้เห็นว่า ผู้ไม่หวังดีอาจเข้าถึงระบบ Production
  4. การเปิดเผยอีเมลส่วนตัว : ชุดข้อมูลนี้มีอีเมลส่วนตัวจำนวนมาก ซึ่งน่าจะเกิดจากการที่องค์กรอนุญาตให้มีการยืนยันตัวตนผ่าน SSO สำหรับผู้ใช้งาน และลูกค้า
  5. ความพยายามในการตรวจสอบข้อมูลอย่างต่อเนื่อง : นักวิจัยอิสระที่ได้รับไฟล์นี้จากผู้ไม่หวังดีสามารถยืนยันความถูกต้องของการรั่วไหล และยืนยันว่าเป็นเหตุการณ์การรั่วไหลจริง

นักวิจัยจะยังคงติดตามสถานการณ์ และจะให้ข้อมูลอัปเดตเพิ่มเติมเมื่อเราได้ข้อมูลใหม่ ๆ

ผลกระทบ

  • การเปิดเผยข้อมูลจำนวนมาก : การโจมตีครั้งนี้ทำให้ข้อมูล 6 ล้านรายการรั่วไหล รวมถึงข้อมูลสำคัญเกี่ยวกับการยืนยันตัวตน ซึ่งเพิ่มความเสี่ยงในการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต และการหลอกลวงข้อมูลทางธุรกิจเพิ่มขึ้น
  • การโจมตีข้อมูล Credential : รหัสผ่านที่เข้ารหัสของระบบ SSO และ LDAP หากถูกถอดรหัสได้ อาจทำให้เกิดการโจมตีเพิ่มเติมในสภาพแวดล้อมของ Oracle Cloud
  • การข่มขู่ และเรียกร้องค่าไถ่ : ผู้ไม่หวังดีกำลังบีบบังคับให้บริษัทที่ได้รับผลกระทบจ่ายเงินเพื่อให้ข้อมูลถูกลบ ซึ่งเพิ่มความเสี่ยงทางการเงิน และชื่อเสียงของบริษัท
  • ความเสี่ยงด้าน Supply Chain : การเปิดเผยไฟล์ JKS และคีย์ อาจช่วยให้ผู้ไม่หวังดีสามารถกำหนดเป้าหมาย และโจมตีระบบองค์กรที่เชื่อมต่อกันหลายระบบ

การแก้ไขปัญหา

  • เปลี่ยนข้อมูล Credential : เปลี่ยนข้อมูล Credential ทั้งหมดของ SSO, LDAP และข้อมูล Credential ที่เกี่ยวข้อง โดยใช้มาตรการนโยบายรหัสผ่านที่เข้มงวด และบังคับใช้การยืนยันตัวตนหลายปัจจัย (MFA)
  • การตอบสนองต่อเหตุการณ์ และการตรวจสอบทางนิติวิทยาศาสตร์ : ดำเนินการตรวจสอบอย่างละเอียดเพื่อระบุการเข้าถึงที่ไม่ได้รับอนุญาต และลดความเสี่ยงเพิ่มเติม
  • การติดตามข่าวภัยคุกคาม : ติดตามข้อมูลจาก Dark web และฟอรัมของผู้ไม่หวังดีอย่างต่อเนื่อง เพื่อตรวจสอบการสนทนาที่เกี่ยวข้องกับข้อมูลที่รั่วไหล

ที่มา : cloudsek