เหตุการณ์แฮ็กบัญชี 700 ล้านบัญชีของ Electronic Arts

 (battleda.sh)
1 คะแนน โดย GN⁺ 2024-11-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เอกสาร Swagger ที่ถูกเปิดเผย ของ API สำหรับการยืนยันตัวตนและเกตเวย์ของ EA ประกอบกับความล้มเหลวในการตรวจสอบสิทธิ์ของการอัปเดต persona ทำให้สามารถกระทบข้อมูลบัญชีและกระบวนการล็อกอินของผู้ใช้อื่นได้
  • ประเด็นสำคัญคือคำขอ PUT ที่ /identity/pids/{pidId}/personas/{personaId} สามารถเข้าถึงได้ด้วยสโคป dp.client.default ของไคลเอนต์ OAuth ปกติของ EA Desktop และมีการตรวจสอบความเป็นเจ้าของของ pidId ในบอดี้กับ personaId ในพาธไม่เพียงพอ
  • ผู้โจมตีสามารถผสมการเปลี่ยนชื่อผู้ใช้ของ persona, ตั้งสถานะ BANNED, ย้าย persona, ค้นหา persona ID ของบัญชีที่ซ่อนอยู่, และบายพาสการล็อกอินด้วย Xbox persona จนไปถึงการล็อกอินหน้าเว็บของบัญชีได้
  • ขอบเขตผลกระทบครอบคลุมถึงการขโมยชื่อผู้ใช้และข้อมูลเกมบางส่วน, การตัดสิทธิ์เข้าเล่นเกมออนไลน์, การหลบเลี่ยงแบนในเกม, ไปจนถึงการล็อกอินบัญชี EA ผ่าน Xbox และถูกประเมินความรุนแรงเป็น CVSS 10.0
  • ช่องโหว่ถูกรายงานต่อ EA เมื่อ 16 มิถุนายน 2024 และ EA จัดเป็น critical เมื่อ 25 มิถุนายน ก่อนทยอยปล่อยแพตช์ตั้งแต่ 8 กรกฎาคมถึง 8 ตุลาคม ซึ่งรวมถึงการตรวจสอบความเป็นเจ้าของ persona และการลบเอกสาร

การเปิดเผยเอกสาร API ที่เริ่มจากสภาพแวดล้อมยืนยันตัวตนของ EA

  • จุดเริ่มต้นคือการทดสอบสภาพแวดล้อมพัฒนา integration ที่พบใน EA Desktop
    • API ยืนยันตัวตนของ production คือ accounts.ea.com
    • โฮสต์ยืนยันตัวตนของ integration คือ accounts.int.ea.com
  • ในสภาพแวดล้อม integration สามารถขอ access token ที่มีสิทธิ์ได้ และจึงเริ่มค้นหาเอกสารที่เปิดเผยอยู่เพื่อดูว่าโทเค็นนี้เข้าถึง API ใดได้บ้าง
  • endpoint สำหรับยืนยันตัวตนอยู่หลัง reverse proxy โดยรูปแบบการตอบกลับ 404 ของพาธ /connect กับพาธ / ปกติแตกต่างกัน และเฮดเดอร์ server คือ istio-envoy
  • /connect/api-docs ส่งกลับ 404 ว่าง ๆ ต่างจากพาธอื่นใต้ /connect จึงชี้ว่ามีความเป็นไปได้ของการ route ไปยังบริการแยก และพบเอกสาร Swagger 1.1 ที่ /connect/api-docs/index.json
  • เอกสาร Swagger ชี้ไปที่ /api-docs/connect และถูกแปลงเป็นสเปก OpenAPI 3.0 ด้วย swagger-codegen-cli เพื่อตรวจสอบใน Swagger UI บนเครื่อง

รายการ API ภายในที่เผยผ่าน Gateway

  • EA Desktop ใช้ GraphQL API ที่เรียกว่า “Service Aggregation Layer” แต่ SAL ในสภาพแวดล้อม integration อยู่หลังไฟร์วอลล์
  • gateway API บน gateway.ea.com ซึ่งดูเหมือนเป็นเวอร์ชันเก่า ใช้ endpoint รูปแบบ proxy/{service}/{route}
  • gateway.int.ea.com/proxy/api-docs/index.json ส่งกลับรายการเอกสารของบริการมากกว่า 80 รายการ
    • รวมถึงบริการอย่าง addresses, agerequirements, billing, commerce เป็นต้น
  • มีการดาวน์โหลดเอกสาร API แต่ละชุดมาแปลงเป็นสเปก OpenAPI รุ่นใหม่ แล้วตรวจสอบฟังก์ชันที่เข้าถึงได้
  • บาง endpoint ส่งคืนข้อมูล “projects” ที่เกี่ยวข้องกับทีมเกมของ EA และต้องใช้สโคป basic.domaindata ซึ่งยังพบไคลเอนต์ใน production ที่มีสโคปนี้ด้วย
    • ข้อมูลตัวอย่างมีรายการของเกม Star Wars ที่ถูกยกเลิก และ Apex Legends ที่แสดงภายใต้ชื่อกลุ่มที่เกี่ยวกับ Titanfall3
  • ในสภาพแวดล้อม integration ยังมีการบันทึกวิธีมอบ entitlement เกมแบบกำหนดเองไว้ด้วย แต่บริการ integration ที่จำเป็นต่อการดาวน์โหลดและเล่นอยู่หลังไฟร์วอลล์ จึงใช้งานจริงได้จำกัด
  • ยังมี endpoint ที่คืนค่า Xbox Live Server Token แต่เนื่องจาก sandbox ID ไม่ใช่ RETAIL จึงไม่ได้ตรวจต่อในเชิงลึก

โครงสร้างข้อมูลบัญชี production และ persona

  • เอกสารของแต่ละ endpoint ระบุสโคปการยืนยันตัวตนที่ต้องใช้ และการตรวจสอบมุ่งไปที่ endpoint ที่เข้าถึงได้ด้วยไคลเอนต์ OAuth ของ production
  • /identity/pids/me ส่งคืนข้อมูลทั่วไปของบัญชี
    • รวมถึงอีเมลแบบปกปิดบางส่วน, สถานะอีเมล, วันเกิดบางส่วน, ประเทศ, ภาษา, สถานะบัญชี, เวอร์ชันข้อตกลง, เวลาในการสร้าง/แก้ไข/ยืนยันตัวตนครั้งล่าสุด, และสถานะเปิดใช้ 2FA
  • /identity/pids/me/personas ส่งคืนรายการ persona ที่เชื่อมกับบัญชี
    • บัญชี EA ปกติใช้ namespace cem_ea_id
    • บัญชีภายนอกที่เชื่อมต่อ เช่น Steam, Xbox ก็จะแสดงเป็น persona เช่นกัน
  • โดยทั่วไปเกมสามารถเก็บข้อมูลอย่างสถิติหรือ inventory ไว้ใต้ persona ทำให้ข้อมูลแยกตามแพลตฟอร์มได้
  • จากนั้นเรียก persona ใน namespace cem_ea_id ว่า persona “Origin”

ช่องโหว่หลัก: การตรวจสอบสิทธิ์อัปเดต persona ล้มเหลว

  • endpoint /identity/pids/{pidId}/personas/{personaId} รองรับคำขอ GET, PUT และ DELETE
  • คำขอ PUT อนุญาตสโคป dp.client.default และ dp.server.default และไคลเอนต์ยืนยันตัวตนปกติของ EA Desktop ก็มี dp.client.default
  • บอดี้ของคำขอรับค่าได้ เช่น displayName, namespaceName, status, statusReasonCode, lastAuthenticated, nickName, pidId เป็นต้น
  • คำขอ PUT เพื่อเปลี่ยน displayName ของ Origin persona ของตัวเองสำเร็จ และชื่อผู้ใช้บนเว็บไซต์บัญชี EA ก็เปลี่ยนตาม
    • คำขอนี้บายพาสคูลดาวน์การเปลี่ยนชื่อผู้ใช้และการยืนยันทางอีเมลสำหรับการเปลี่ยนชื่อผู้ใช้
  • การเปลี่ยน namespaceName ไม่มีผล
  • ค่า status สามารถเป็น ACTIVE, DISABLED, PENDING, DELETED, BANNED และเมื่อเปลี่ยนสถานะ Origin persona ของตัวเองเป็น BANNED ก็ยังใช้ EA Desktop ได้ แต่ล็อกอินเข้าเกมไม่ได้
  • ปัญหาที่ใหญ่กว่าคือสามารถเปลี่ยน pidId ในบอดี้คำขอเป็น ID ของบัญชีอื่นได้
    • คำขอที่ย้าย Steam persona ของตัวเองไปยังบัญชี EA ของเพื่อนสำเร็จ
    • หลังจากนั้นยังย้ายกลับมาบัญชีของตัวเองได้ด้วย

การตรวจสอบการล็อกอินและความพยายาม XSS

  • หลังย้าย Steam persona ของตัวเองไปยังบัญชีเพื่อนแล้ว เมื่อทดลองล็อกอินเว็บไซต์ EA ด้วย Steam ก็พบการยืนยันทางอีเมลตามตำแหน่งใหม่/อุปกรณ์ที่ไม่เชื่อถือ
  • อีเมลบางส่วนที่แสดงไม่ใช่ของตนเอง จึงหมายความว่าไปถึงขั้นตอนการพยายามล็อกอินเข้าบัญชีเพื่อนได้แล้ว แต่ถูกหยุดที่ขั้น 2FA ตามตำแหน่ง
  • คำขอเปลี่ยนชื่อผู้ใช้ของ persona เป็นรูปแบบ BattleDash <script>alert(1)</script> ก็สำเร็จเช่นกัน
  • มีการเรียก alert ในหน้าการเชื่อมบัญชี จึงทำให้เกิด XSS ได้
    • หากหลอกให้ผู้ใช้ที่ล็อกอินบัญชี EA อยู่แล้วเข้าไปยังหน้าการเชื่อมบัญชีนั้น ก็อาจรันโค้ดในเบราว์เซอร์เพื่อดึง session ได้

การจัดการ persona ของบัญชีอื่นโดยตรง

  • เพื่อดูว่า personaId ในพาธมีการตรวจสอบความเป็นเจ้าของไม่เพียงพอด้วยหรือไม่ จึงลองเปลี่ยนชื่อผู้ใช้โดยใช้ persona ID ที่ตนไม่ได้เป็นเจ้าของ
  • หลังได้ persona ID ของบัญชีทดสอบใหม่ ก็สามารถส่งคำขอเปลี่ยนชื่อผู้ใช้ของบัญชีนั้นได้สำเร็จโดยไม่ต้องยืนยันตัวตนของเหยื่อ
  • เช่นเดียวกัน ยังเปลี่ยน status เป็น BANNED ได้ ทำให้บัญชีนั้นล็อกอินเข้าเกมไม่ได้
  • /identity/personas ใช้ค้นหา persona ด้วย displayName และส่งคืน persona ID, account ID, วันที่สร้าง, และเวลาล็อกอินล่าสุด
    • แต่จะไม่แสดงผู้ใช้ที่ซ่อนบัญชีไว้
  • /identity/namespaces/{namespace}/personas ใช้ค้นหาใน namespace ที่กำหนด และส่งคืนเพียงชื่อผู้ใช้กับ persona ID แต่รวมถึงบัญชีที่ซ่อนอยู่ด้วย
    • เพียง endpoint นี้ก็เพียงพอที่จะได้ persona ID ที่ต้องใช้

ข้อจำกัดของการย้าย persona และการยึดบัญชีบางส่วน

  • เมื่อพยายามย้าย Origin persona ของผู้ใช้อื่นมาไว้ในบัญชีตัวเอง จะได้ข้อผิดพลาด TOO_MANY_PERSONAS_FOR_NAMESPACE
    • เพราะบัญชีตัวเองมี Origin persona อยู่แล้ว
  • มีการสังเกตว่าบัญชีที่สมัครผ่านคอนโซลอาจมีเฉพาะ persona ของแพลตฟอร์มนั้น และไม่มี Origin persona จึงใช้บัญชีคอนโซลเพื่อหลบการชนกันของ namespace
  • สามารถย้าย Origin persona ของบัญชีทดสอบไปยังบัญชีคอนโซลก่อน แล้วค่อยย้าย Origin persona ของเหยื่อมาไว้ในบัญชีตัวเอง
  • เมื่ออยู่ในสถานะนี้ หากล็อกอินจะเห็นชื่อผู้ใช้ของเหยื่อ, สถิติของเกมที่ไม่รองรับ cross-platform, และรายละเอียดบัญชีอื่นบางส่วน
  • เมื่อล็อกอินเป็นบัญชีเหยื่อ จะปรากฏ flow “Finish setting up my account” ที่ให้เลือกชื่อผู้ใช้ราวกับเพิ่งสร้างบัญชีใหม่
  • entitlement, รายชื่อเพื่อน, และข้อมูลเซฟของเกม cross-platform รุ่นใหม่อย่าง Battlefield 2042 ถูกเก็บไว้ที่ตัวบัญชี EA ไม่ใช่ที่ persona จึงไม่ถูกย้ายตามมา
  • ถึงอย่างนั้น ผู้โจมตียังสามารถแบนผู้ใช้, หลบเลี่ยงแบนเกม, ยึดชื่อผู้ใช้, และจับข้อมูลบัญชีเป็นตัวประกันได้

บายพาสการล็อกอินด้วย Xbox persona

  • ในสถานะเดิม สิ่งที่ทำได้คือย้าย linked account persona ของตัวเองไปยังบัญชี EA ใดก็ได้, ย้าย persona ใดก็ได้มาไว้ในบัญชีตัวเอง, และแบน/เปลี่ยนชื่อผู้ใช้ของ persona
  • หากย้าย persona ของตัวเองเพื่อพยายามล็อกอินเป็นบัญชีของผู้อื่น ก็ยังเจอการยืนยันทางอีเมล
  • จึงตั้งข้อสังเกตว่าเวลาบนคอนโซลเล่นเกม EA ไม่เคยเห็นพรอมป์ต์ 2FA และเริ่มตรวจสอบการล็อกอินด้วยโทเค็น Xbox/PSN
  • เอกสาร Nexus Connect API มีวิธีส่งโทเค็น Xbox/PSN และจาก flow การล็อกอิน PSN ของเว็บไซต์ EA ก็สามารถหา PSN client ID แล้วลองล็อกอินด้วยโทเค็น PSN ได้
  • การล็อกอินด้วยโทเค็น PSN จะสร้าง persona ใน namespace ps3 และสามารถล็อกอินบัญชีได้โดยไม่มี 2FA แต่ไคลเอนต์ที่มี dp.client.default ไม่สามารถจัดการ namespace ps3 ได้
  • เมื่อเพิ่มเฮดเดอร์ X-Include-Namespace ไปยัง /connect/tokeninfo ก็พบว่ามีรายการ namespace ของ persona ที่แต่ละ OAuth client สามารถจัดการได้
    • ตัวอย่าง JUNO_PC_CLIENT มี namespace cem_ea_id, steam, epic, xbox
  • namespace ของ Xbox ได้รับอนุญาต แต่เนื่องจากไม่สามารถสร้าง Microsoft XSTS token ที่ใช้ได้เองแบบแมนนวล จึงทดสอบบน Xbox จริง
  • มีการสร้างบัญชี Microsoft ใหม่และเชื่อม Xbox persona เข้ากับบัญชี EA ทดสอบ จากนั้นย้าย Xbox persona นั้นไปยังบัญชีเหยื่อ
  • เมื่อล็อกอินเว็บไซต์ EA ด้วยบัญชี Xbox จะยังมีการยืนยันอีเมลตามตำแหน่งใหม่ แต่เมื่อไปติดตั้ง Battlefield 2042 บน Xbox แล้วล็อกอินเข้าเกม ก็สามารถเข้าบัญชีเหยื่อได้
  • หลังจากนั้น เมื่อล็อกอินเว็บไซต์ EA ด้วยบัญชี Xbox เดิมอีกครั้ง ก็สำเร็จถึงขั้นล็อกอินหน้าเว็บของบัญชีเหยื่อได้โดยไม่ต้องยืนยันอีเมล

ขอบเขตผลกระทบและความรุนแรง

  • เส้นทางโจมตีหลักที่ผู้โจมตีใช้ได้มีสองแบบ
    • ย้ายข้อมูล persona ของผู้อื่นออกจากบัญชีเพื่อขโมย ชื่อผู้ใช้และข้อมูลเกม
    • ย้าย Xbox persona ของตัวเองไปยังบัญชีเหยื่อ แล้วล็อกอินเกม EA บน Xbox เพื่อให้เครือข่ายอยู่ในสถานะที่เชื่อถือ ก่อนล็อกอินเว็บไซต์ EA ด้วยบัญชี Xbox
  • ผลกระทบเพิ่มเติมก็รุนแรงมาก
    • สามารถแบน persona ของผู้อื่นเพื่อขัดขวางการเล่นเกมออนไลน์ส่วนใหญ่ได้
    • สามารถเปลี่ยนชื่อผู้ใช้ของผู้อื่นแล้วเอามาใช้เองได้
    • เนื่องจากการแบนเกมทำโดยปิด entitlement เกมทั้งบัญชี จึงสามารถย้าย persona ไปยังบัญชีใหม่เพื่อหลบแบนเกมได้
  • flow นี้ทำได้โดยแทบไม่ต้องอาศัยการโต้ตอบจากผู้ใช้ และส่วนใหญ่ผ่าน API endpoint เดียว
  • ความรุนแรงถูกประเมินเป็น CVSS 10.0 ตามเกณฑ์ AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

ไทม์ไลน์การแก้ไขและความเห็นภายหลัง

  • ช่องโหว่ถูกรายงานต่อ EA เมื่อ 16 มิถุนายน 2024
  • EA ส่งการยืนยันเมื่อ 25 มิถุนายน 2024 และจัดระดับความรุนแรงเป็น critical
  • กำหนดการแพตช์เป็นดังนี้
    • 8 กรกฎาคม 2024: ปล่อย Patch 1, persona ownership check
    • 18 กรกฎาคม 2024: ปล่อย Patch 2, ไม่ทราบรายละเอียด
    • 6 กันยายน 2024: ปล่อย Patch 3, ไม่ทราบรายละเอียด
    • 10 กันยายน 2024: ปล่อย Patch 4, ลบเอกสาร
    • 8 ตุลาคม 2024: ปล่อย Patch 5, ไม่ทราบรายละเอียด
  • เดิม EA ประเมินว่าอาจใช้เวลาถึงปลายปีในการแก้ไข และมีความเห็นว่าในกรณีที่ปัญหาหลักอยู่ที่เอกสารที่เปิดเผยกับ endpoint ที่ไม่ปลอดภัยเพียงจุดเดียว ควรมีแพตช์ชั่วคราวที่เร็วกว่านี้
  • EA ยังไม่มีโปรแกรม bug bounty และยังมีความกังวลว่าหากไม่มีรางวัลตอบแทนที่เป็นรูปธรรม อาจมีคนเลือกเก็บช่องโหว่ไว้ไม่เปิดเผย
  • บัญชีเพื่อนที่ใช้ในการทดสอบช่วงแรกเป็นบัญชีที่ได้รับความยินยอมแล้ว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-11-06
ความคิดเห็นจาก Hacker News

  • EA ชอบใช้ ระบบร่วมกัน ในหลายเกม ตอนที่ลองขุดดู Madden ก็พบว่ามีแบ็กเอนด์ร่วมชื่อ blaze และมีเอนด์พอยต์เว็บ/TCP แบบทั่วไปอยู่
    ผมทำเครื่องมือสำหรับเรียกเอนด์พอยต์นี้ขึ้นมา แต่ต้องอัปโหลด XML แล้วภายหลังถึงรู้ว่าทุกครั้งที่เรียก เซิร์ฟเวอร์ของ EA กำลังล่มอยู่
    เพราะแต่ละคำขอไปจับเซิร์ฟเวอร์ตัวใหม่ ทำให้เซิร์ฟเวอร์ Madden ค่อย ๆ แครชทีละตัวจนหมด และสุดท้าย EA ก็ทำ API ขึ้นมาเพื่อไม่ให้คนไปคุ้ยกันเอง

    • Blaze คือชื่อเฟรมเวิร์ก/บริการ C++ สำหรับสร้างแบ็กเอนด์แบบกำหนดเองสำหรับเกมออนไลน์ ช่วยให้ทีมเกมพัฒนาฟีเจอร์ออนไลน์ด้วยวิธีมาตรฐาน และมี MySQL อยู่เบื้องหลัง
      เท่าที่จำได้ ต้องมีอินสแตนซ์ Blaze ประมาณหนึ่งตัวต่อผู้เล่น 5,000–10,000 คน
    • ผมเป็นคนเขียนโพสต์นั้นเอง และเมื่อปีที่แล้วก็เขียนบทความที่พูดถึง ช่องโหว่ของ Blaze จำนวนมากที่ผมพบไว้ด้วย แต่ไม่ได้เผยแพร่
      ตอนนี้ดูเหมือนพวกเขาใช้ฟอร์แมตเฉพาะของตัวเอง และค่อนข้างวางใจอยู่กับความปลอดภัยแบบอาศัยความคลุมเครือ คือสมมติว่าไม่มีใครจะค้นพบวิธีอินเทอร์เฟซได้
      สักวันผมอยากกลับไปทำบทความนั้นต่อ และอย่างน้อยมันก็มีเนื้อหาที่น่าสนใจทีเดียว
    • ช่วงนี้ผมเหมือนเคยเห็น API นี้ในเกมอื่นด้วย ใช่ GraphQL ฟรอนต์เอนด์ ไหม? ปิด introspection ไว้ก็จริง แต่ข้อความผิดพลาดกลับใจดี แนะนำชื่อฟิลด์ที่สะกดผิดให้ด้วย
      เคล็ดลับเวลา reverse engineer API ของบริการดัง ๆ แบบนี้คือใช้ GitHub code search ลองใส่ชื่อเอนด์พอยต์ที่มีเอกลักษณ์ลงไป มักเจอคนที่คล้าย ๆ กันซึ่งแฮ็กไคลเอนต์ API เล็ก ๆ ของตัวเองขึ้นมา และช่วยงานสืบของผมในแบบที่คาดไม่ถึง
    • ถ้ากวาดค่าซ้ำของ PSN client ID แล้วลองล็อกอินกับพร็อกซีเกตเวย์ของ EA จะได้ค่า namespacename ที่ดึงมาจากข้อมูลส่วนตัวกลับมา ข้อมูลโทเคน 2FA ต้องถูกแฮชจากเอนด์พอยต์ /tokeninfo/ ที่ดึงมาจาก JUNO
      เมื่อพยายามรวมระบบย้อนหลัง โครงสร้างพื้นฐานสำหรับ C++ API มักจะคืนค่า PSN user ID กลับมา

  • อย่างที่คนปกติคงทำกันแน่นอน ผมสั่ง Xbox แบบส่งวันถัดไป ติดตั้ง Battlefield 2042 แล้วรอจังหวะสำคัญ และก็เข้าไปได้จริง
    รักแฮ็กเกอร์จริง ๆ <3

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

  • สิ่งที่แปลกที่สุดในเรื่องทั้งหมดนี้คือ EA เคยอ้างมาหลายปีว่า การยกเลิกการเชื่อมต่อบัญชี Xbox เดิมแล้วเชื่อมต่อใหม่กับบัญชีใหม่เป็นสิ่งที่ เป็นไปไม่ได้ทางเทคนิค ดูโพสต์อย่าง https://www.reddit.com/r/XboxGamePass/comments/12gsy4i/ea_xb... และโพสต์จำนวนมากในฟอรัม EA ได้
    ผมเองก็เจอกำแพงนี้เหมือนกัน คุยกับฝ่ายสนับสนุน EA เป็นชั่วโมง ๆ แต่พวกเขาเชื่อมบัญชี Xbox ที่เก่ามากของผมให้ไม่ได้ ทำให้ผมล็อกอินเข้าเกม EA ใด ๆ บน Xbox ไม่ได้ และเล่นส่วนใหญ่บนแพลตฟอร์มแทบไม่ได้
    แต่กรณีนี้กลับแสดงให้เห็นว่ามันทำได้พอสมควร

    • นึกถึงช่วงปี 2004–2005 ตอนบัญชี Hotmail ของผมมี พื้นที่เก็บข้อมูล 4MB ตามปกติ และ Microsoft กำลังทยอยแจกอัปเกรดฟรีเป็น 250MB ให้ทุกคน
      แปลกตรงที่บัญชีผมใช้เวลานานมาก ตลอด 1–2 ปีผมส่งอีเมลหาฝ่ายสนับสนุนหลายครั้ง แต่ทุกครั้งได้คำตอบว่ากำลังอัปเกรดบัญชีให้เร็วที่สุดเท่าที่ทำได้ ทว่างานใหญ่มากจึงอาจใช้เวลาหลายปี
      ต่อมาผมเห็นทริกในฟอรัมว่า ถ้าปิดบัญชีชั่วคราวแล้วเปิดใหม่ จะเพิ่มเป็น 25MB ได้ แต่ก็ยังไม่ใช่ 250MB ตามที่สัญญาไว้
      สภาพตอนนั้นคือบัญชีเดิม 2–4MB, บัญชีใหม่ 25MB และการทยอยแจก 250MB ที่กินเวลาหลายปี ทำให้รู้สึกว่า Microsoft คงลำบากมากในการหาพื้นที่เก็บข้อมูลเหลือ ๆ แต่ไม่กี่เดือนต่อมา เมื่อพวกเขาต้องแข่งกับ Gmail ก็เลือกแจก 2GB ให้ทุกคน และปล่อยให้บัญชี Hotmail ทุกบัญชี รวมถึงของผม พร้อมกันในครั้งเดียว เอเลี่ยนคงเอา UFO ที่อัดแน่นด้วยฮาร์ดดิสก์มาส่งให้แน่ ๆ
      [1] ตัวอย่างโพสต์ฟอรัมเก่าเกี่ยวกับทริกนั้น พร้อมคอมเมนต์ตอบที่ชม GMail ซึ่งเพิ่งเปิดตัว: https://bimmersport.co.nz/topic/5232-hotmail-upgrade-2mb-to-...
    • การโจมตีนี้แสดงให้เห็นว่า การเปลี่ยนการเชื่อมต่อและเล่นเกมนั้นทำได้ แต่เราไม่รู้ว่าจะมี ผลข้างเคียง อะไรเกิดขึ้นนอกเหนือจากสถานการณ์ที่บทความตรวจสอบได้ง่าย
      การเปลี่ยนการเชื่อมต่ออาจทำให้ข้อมูลที่เก็บไว้ในระบบเรียกเก็บเงินใช้ไม่ได้ ทำให้รายงานรายเดือนที่ส่งไปยังแผนก Microsoft Xbox พัง หรือทำให้หน้าแอดมินภายในแครชระหว่างโหลดก็ได้
      ไม่ได้จะปกป้อง EA แต่ถ้าเคยรับมือกับระบบไมโครเซอร์วิสที่ซับซ้อนมามาก จะรู้ว่าการเปลี่ยนโครงสร้างข้อมูลในที่หนึ่งไม่ได้ง่ายเสมอไป
    • บางทีพวกเขาอาจกำลังเพิ่มฟังก์ชันนี้เพื่อแก้ปัญหานั้นอยู่ แต่โชคร้ายที่มันถูกนำไปใช้ในทางที่ผิดก่อนเปิดตัว
    • น่าเสียดายที่ในเกมข้ามแพลตฟอร์มรุ่นใหม่อย่าง Battlefield 2042 สิทธิ์การเล่นเกม เพื่อน และข้อมูลเซฟ ถูกเก็บไว้ที่บัญชี EA เอง ไม่ใช่ persona ดังนั้นข้อมูลเหล่านั้นจึงไม่ถูกย้ายตามไป
    • ไม่ใช่ว่าเป็นไปไม่ได้ทางเทคนิค แต่อาจเป็นไปได้มากกว่าแค่ว่า ฝ่ายซัพพอร์ตลูกค้าจัดการให้ไม่ได้

  • การแบนทุกบัญชีแล้วหวังว่าไม่มีแบ็กอัป DB ก็น่าจะสนุกดีเหมือนกัน

    • อยากเห็นบริษัทระดับ 1 พันล้านดอลลาร์ทุกแห่งที่ไม่มี โปรแกรม Bug Bounty เจอเรื่องแบบนี้บ้าง ถ้าไม่มีรางวัลใด ๆ สำหรับการรายงานช่องโหว่ ก็เท่ากับยุยงให้แฮ็กเกอร์นำไปใช้หาประโยชน์ส่วนตัวหรือสร้างความวุ่นวาย
      ในฐานะลูกค้าที่จ่ายเงิน ผมคาดหวังท่าทีที่ดีกว่านี้จากบริษัทเหล่านี้ และถ้าไม่มีโปรแกรมแบบนี้ ส่วนตัวผมก็จะไม่ตำหนิแฮ็กเกอร์หากพวกเขาเอาสิ่งที่ค้นพบไปใช้ประโยชน์
    • ช่วงสั้น ๆ อาจจะสนุกก็ได้ แต่พวกเขาต้องมีแบ็กอัปอยู่แล้วแน่นอน
      ไม่มีใครเก็บเรคคอร์ด 400 ล้านรายการไว้ในเครื่องเดียวหรอก สุดท้ายก็แค่ทำให้บริการล่มไปทั้งบ่าย แล้วต้องไปอยู่ เรือนจำกลาง 15 ปี เท่านั้น
    • นี่แหละเหตุผลที่โลกหันหลังให้วงการเทคโนโลยี
      เพราะปฏิกิริยาแรก หรืออย่างน้อยก็โพสต์ที่ได้คะแนนสูงสุดตอนนี้ คือความคิดที่ว่า “น่าจะสนุกดี” ถ้าทำให้คนหลายล้านคนเดือดร้อนเพื่อสอนบทเรียนให้บริษัทที่พวกเขาทำธุรกรรมด้วย
    • การเปิดใช้งานเกมทั้งหมดให้ทุกบัญชีน่าจะสนุกกว่านี้มาก ทุกเกมจริง ๆ จินตนาการแคบไปหน่อย
    • ผมก็เคยคิดเรื่องนี้เหมือนกัน ถ้าตั้งใจแกล้งโดยไม่รายงานจริง ๆ ผลจะออกมาเป็นอย่างไร? จะถูกตามตัวเจอไหม? EA จะล่มไปหลายสัปดาห์ไหม?

  • ในบทความมีท่อนนี้:
    I had found a way to obtain a privileged access token within the environment (a story for another day, but a certain game's executable had hardcoded credentials!), but I wasn't sure what I could do with it.
    ช่วยอธิบายส่วนนี้เพิ่มเติมหน่อยได้ไหม? ผมคิดว่าไม่ควรอ่านข้อมูลรับรองแบบนั้นจากไบนารีที่รันได้อย่างง่ายดาย และก็ไม่ค่อยแน่ใจว่าถ้าไฟล์รันเกมจำเป็นต้องยืนยันตัวตนกับเซิร์ฟเวอร์ระยะไกล นักพัฒนาควรทำอย่างอื่นอย่างไร

    • ข้อมูลรับรองถูกเก็บเป็นสตริง ดังนั้นถ้าค้นหารูปแบบที่ดูเหมือนข้อมูลรับรองในไบนารี ก็จะอยู่ที่ไหนสักแห่ง
      ในสถาปัตยกรรมไคลเอนต์-เซิร์ฟเวอร์ ไคลเอนต์ไม่น่าเชื่อถือเสมอ ไฟล์รันไม่ควรต้องยืนยันตัวตนของตัวมันเองกับเซิร์ฟเวอร์ ไฟล์รันควรยืนยันตัวตนเป็นผู้ใช้หรือบัญชีด้วยข้อมูลที่ผู้ใช้ให้มา
      สำหรับกรณีอย่าง telemetry เอนด์พอยต์แบบนี้มักรับข้อมูลที่ไม่มีการยืนยันตัวตนหรือมีการยืนยันตัวตนแบบอ่อน และทำการตรวจสอบหลายขั้นเพื่อป้องกันการใช้งานเกินขอบเขต ส่วนใหญ่ก็มักเป็นแบบเขียน/เพิ่มข้อมูลเท่านั้น
    • ไม่รู้ว่าทำไมถึงสมมติว่าไบนารีจะอ่านได้ยาก บนแพลตฟอร์มที่ไม่ได้ล็อกไว้ ไบนารีอ่านได้ค่อนข้างง่าย
      คงต้องมีระบบที่เข้ารหัสไฟล์รัน แล้วให้พื้นที่ปลอดภัยในได CPU จัดการถอดรหัสด้วย private key แต่ถึงอย่างนั้นก็น่าจะเป็นเพียงเรื่องของเวลาก่อนที่จะมีคน delid ชิปเพื่อเอาคีย์ออกมา
    • ถ้าคอมพิวเตอร์อ่านได้ และคุณควบคุมคอมพิวเตอร์เครื่องนั้นได้เต็มที่ คุณก็อ่านได้เช่นกัน ถ้ามีการเข้าถึงทางกายภาพก็จบ
      ต่อให้เข้ารหัสแล้วใส่กุญแจเข้ารหัสไว้ใน HSM ก็อาจเป็นไปไม่ได้อยู่ดีบนเครื่องไคลเอนต์ทั่วไป และไม่ช้าก็เร็ว เกมก็ต้องถอดรหัสสตริงนั้นขึ้นมาไว้ในหน่วยความจำอยู่ดี แล้วหน่วยความจำนั้นก็อ่านได้
    • ถ้าโปรแกรมเข้าถึงข้อมูลรับรองได้ และโปรแกรมนั้นรันอยู่บนคอมพิวเตอร์ของผม ไม่ว่าจะทำ obfuscation อย่างไร ผมก็เข้าถึง ข้อมูลรับรอง นั้นได้เช่นกัน
      สิ่งที่นักพัฒนาเกมควรทำคือมีระบบบัญชีอยู่ที่แบ็กเอนด์ แล้วให้ผู้เล่นป้อนข้อมูลรับรองของตัวเองในเกม จากนั้นเกมจึงระบุตัวเองกับเซิร์ฟเวอร์แบ็กเอนด์ในฐานะผู้เล่นคนนี้ได้
      การทำแบบนี้ทำให้สามารถผูกการกระทำในแบ็กเอนด์กับผู้เล่นรายใดรายหนึ่งได้ และเป็นพื้นฐานที่ดีสำหรับการตัดสินใจด้านความปลอดภัย
    • การหาข้อมูลรับรองแบบนั้นในไบนารีที่รันได้ยาก แต่ไม่ใช่ว่าเป็นไปไม่ได้ ยุ่งยากกว่าการดึงสตริงออกจากไฟล์ JavaScript ที่ถูก minify แต่ห่างไกลจากคำว่าเป็นไปไม่ได้อย่างแน่นอน
      มีเครื่องมืออย่าง IDA อยู่ จึงไม่ใช่การไล่ดูด้วยตาเปล่าท่ามกลางทุกอย่างที่ดูเหมือนสตริงเพื่อหาข้อมูลรับรอง
      ปัญหาไม่ได้อยู่ที่ตัวข้อเท็จจริงว่ามีข้อมูลรับรอง hardcode อยู่ในไบนารีเท่านั้น แต่อยู่ที่ข้อมูลรับรองนั้นมี สิทธิ์พิเศษ ต่างหาก

  • ในฐานะวิศวกรของบริษัทแบบนี้ บางทีก็สงสัยว่าความรู้สึกจะเป็นอย่างไรเมื่อ API ภายใน บั๊กแปลก ๆ และเรื่องสกปรกภายในถูกเปิดเผยในรายงานการเจาะระบบสาธารณะ
    อย่างไรก็ดี ในกรณีแบบนี้มีโอกาสน้อยที่บุคคลคนเดียวจะเป็นผู้รับผิดชอบช่องโหว่นั้น น่าจะมีสัก 5–6 ทีมที่เป็นเจ้าของส่วนต่าง ๆ ที่ถูกนำไปใช้โจมตี และนั่นแหละคือเหตุผลที่ exploit นี้มีอยู่ตั้งแต่แรก เพราะมันเป็นระบบขนาดใหญ่และซับซ้อนที่ทุกคนเข้าใจแค่ส่วนเล็ก ๆ ของตัวเอง

    • ถ้าคุณผูกพันกับทีมในเชิงอารมณ์ หรือแม้แค่ในเชิงการเงิน ก็คงรู้สึกแย่ แต่ตอนที่ผมอยู่ EA มันแทบจะดูเหมือนพวกเขาพยายามทำให้ผูกพันทางอารมณ์ได้ยาก
      ในบริษัทขนาดอย่าง EA เรื่องนี้แทบจะแน่นอนว่าจะถูกใช้ใน การเมืองภายใน และถึงแม้จะเป็นผลเสียต่อทั้งบริษัท ผู้คนก็จะใช้มันเพื่อให้ได้อำนาจควบคุมมากขึ้นเหนือบริษัทที่เล็กลง
    • ในองค์กรยักษ์ใหญ่ขนาดนั้น ไม่มีใครสนใจหรอก มันก็แค่งานที่ทำเพื่อรับเงินเดือน
      ทุกคนเป็นทรัพยากรที่ทดแทนกันได้ แล้วทำไมถึงต้องผูกพันทางอารมณ์กับงานด้วย
    • ในฐานะคนที่เมื่อราว 10 ปีก่อนเคยทำงานอยู่ในทีมที่น่าจะเป็นทีมเดียวกับทีมที่ยังดูแลโค้ดชุดนี้อยู่ ผมอ่านบทความคร่าว ๆ แล้วต้องเช็กว่ามันเป็นโค้ดที่ผมเขียนหรือส่วนที่ผมเคยแตะหรือเปล่า
      ตอนนั้นทีมชื่อ Nucleus และนั่นจึงเป็นเหตุผลที่หนึ่งใน response ในบทความมี refType เป็น NUCLEUS ทีมนี้สร้างและดูแล API แบ็กเอนด์สำหรับสิทธิ์การเข้าถึง บัญชี และการชำระเงิน
      ตอนนั้นเป็นการฝึกงานภาคฤดูร้อน และหนึ่งปีต่อมาผมได้รับข้อเสนอให้เริ่มทำงานกับทีมนั้น ตอนนั้นทีมเปลี่ยนชื่อเป็น EADP แล้ว และกำลังค่อย ๆ รวมเข้ากับ Origin ผมจำได้เลือนรางว่า DP คือ Data Platform หรือไม่ แต่นั่นจึงเป็นเหตุผลที่หนึ่งในเอนด์พอยต์ขึ้นต้นด้วย dp.
      ตอนนั้นยังไม่มีฐานข้อมูล GraphQL ทุกอย่างเป็น Enterprise Java, OCI, Spring, Hibernate ฯลฯ และก่อนที่ผมจะออก ก็มี Groovy/SpringBoot ที่ใหม่กว่าบางส่วนด้วย มันรันบนเซิร์ฟเวอร์ในดาต้าเซ็นเตอร์ ไม่ใช่บนคลาวด์
      ถึงอย่างนั้นผมก็ได้ทำงานที่สนุก และแม้จะลาออกหลังเกิดเหตุใหญ่ไป 2–3 ปี ผมก็ได้เรียนรู้การพัฒนาแบ็กเอนด์มากมายจากวิศวกรที่เก่ง
      ตอนนี้ผมไม่รู้เลยว่าทีมเป็นอย่างไร วิศวกรเป็นใคร หรือเกิดอะไรขึ้น แต่เห็นเรื่องแบบนี้แล้วก็รู้สึกเศร้า ตอนนั้นเราใส่ใจเรื่องความปลอดภัยมาก และยังทำระบบตรวจจับและจัดการความพยายาม brute force หน้าเข้าสู่ระบบด้วย
      ผมไม่รู้ว่ายังใช้งานอยู่หรือกำลังรันอยู่ไหม แต่การตรวจสอบ/รีวิวความปลอดภัยเพื่อลดความเป็นไปได้ในการถูกเจาะและลดพื้นผิวการโจมตีเป็นส่วนหนึ่งของงานใน sprint
    • โดยเฉพาะถ้าไม่ได้ทำงานในแผนกนั้น จึงไม่มีอำนาจควบคุม แต่รู้ว่าตัวเองทำได้ดีกว่าแผนกนั้น ก็จะรู้สึกแย่
    • ถ้าอ่านบทความแบบนั้นทั้งที่รู้ว่า API นั้นเป็นสิ่งที่ผม implement เอง คงใจหายวาบแน่

  • ถ้าอ่านบทความนี้แล้วสนุก สามารถดูเนื้อหาแบบนี้ได้อีกมากบนแพลตฟอร์ม bug bounty อย่าง Hacktivity ของ HackerOne: https://hackerone.com/hacktivity

    • มีอีกเยอะที่นี่: https://pentester.land/writeups/
      อัปเดตทุก ๆ ไม่กี่สัปดาห์หรือไม่กี่เดือน

  • มีคู่มือแนวทางปฏิบัติที่ดีสำหรับการตั้งค่า โปรแกรม bug bounty อยู่ที่ไหนบ้างไหม?

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

  • ดูจากส่วนนี้ของบทความ:
    It's also disappointing that EA has yet to start a bug bounty program. Without any real incentive to report vulnerabilities, I know people who have instead chosen to keep them to themselves. I would love to see EA follow the rest of the industry's lead here.
    แปลว่าผู้เขียนรายงานเรื่องนี้ไปแล้วแต่ ไม่ได้อะไรเลย งั้นหรือ?

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