Capital One Data Breach: Analysis & Recommendation

จากเหตุการณ์ที่ข้อมูลของ Capital One รั่วไหล กระทบลูกค้ากว่า 106 ล้านคน ในวันนี้ทีมตอบสนองการโจมตีและภัยคุกคาม (Intelligent Response) จากบริษัท ไอ-ซีเคียว จำกัด จะมาวิเคราะห์เหตุการณ์ข้อมูลรั่วไหลของ Capital One รวมถึงแนวทางในการรับมือค่ะ โดยจะประกอบไปด้วยหัวข้อดังนี้

  1. Executive Summary
  2. Incident Timeline
  3. Possible Vulnerabilities and Flaws
  4. Recommendation
  5. References
  6. AWS Case Study by Security Researcher

Executive Summary

Capital One Financial Corporation announced today that on July 19, 2019, it determined there was unauthorized access by an outside individual who obtained certain types of personal information relating to people who had applied for its credit card products and to Capital One credit card customers.

Capital One Announces Data Security Incident

สถาบันการเงิน Capital One ออกประกาศเมื่อวันที่ 29 กรกฏาคม 2019 ที่ผ่านมาแจ้งเหตุการณ์ถูกแฮกกระทบลูกค้าประมาณ 100 ล้านคนในสหรัฐอเมริกาและกระทบลูกค้าในแคนาดาประมาณ 6 ล้านคนที่สมัครหรือใช้บริการ Capital One credit card ตั้งแต่ปี 2005 ถึงช่วงต้นปี 2019 โดยข้อมูลที่รั่วไหลประกอบไปด้วย ชื่อ ที่อยู่ รหัสไปรษณีย์ เบอร์โทร อีเมล วันเกิด รายได้ต่อปี ข้อมูลการใช้จ่าย สถานะเครดิต หมายเลขบัญชีธนาคาร หมายเลขประกันสังคม และข้อมูลอื่นๆ ที่ใช้ประกอบการสมัครบัตรเครดิต

Capital One ทราบเหตุการณ์นี้จากช่องทางที่เปิดให้นักวิจัยรายงานช่องโหว่ในวันที่ 17 กรกฏาคม 2019 มีผู้ใช้งาน GitHub พบการโพสข้อมูลที่น่าจะเป็นของ Capital One บน GitHub ข้อมูลดังกล่าวประกอบด้วย IP ของเซิร์ฟเวอร์และคำสั่งที่ใช้ดึงข้อมูลออกจากเซิร์ฟเวอร์ของ Amazon ที่ Capital One ใช้บริการ

เมื่อสถาบันการเงิน Capital One ได้ทำการตรวจสอบไฟล์ดังกล่าว จึงพบการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาตโดยใช้คำสั่งเหล่านั้นเมื่อวันที่ 22 ถึง 23 มีนาคม 2019 และได้แจ้งไปยัง FBI

FBI จับกุมผู้ต้องสงสัยในคดีนี้แล้วชื่อ Paige A. Thompson ซึ่งรายงานการจับกุมระบุว่าเป็นผู้โพสข้อมูลลงใน GitHub เกี่ยวกับข้อมูลที่ถูกขโมยจาก Capital One และมีการพูดคุยเกี่ยวกับการเข้าถึงข้อมูลของ Capital One ใน Slack และ Twitter

ทั้งนี้ Paige A. Thompson มีประวัติว่าเคยเป็นพนักงานของ Amazon ในช่วงปี 2015-2016 แต่ยังไม่มีการระบุแน่ชัดว่าใช้ความรู้จากการทำงานในการโจมตีหรือไม่

Incident Timeline

การโจมตีที่เกิดขึ้นต่อ Capital One สามารถเรียงลำดับเหตุการณ์ได้ตามรายละเอียดดังต่อไปนี้

  • 22-23 มีนาคม 2019 ผู้โจมตีใช้ช่องโหว่ซึ่งเป็นการตั้งค่า Web Application Firewall (WAF) ที่ไม่ดีพอเพื่อเข้าถึงบัญชีผู้ใช้งานบน Amazon ชื่อบัญชี ISRM-WAF-Role ของ Capital One จากนั้นผู้โจมตีใช้บัญชีดังกล่าวในการเรียกดูรายการ Bucket ของ Capital One เพื่อดูว่า Capital One มี Bucket อะไรบ้าง จากนั้นใช้คำสั่ง Sync เพื่อคัดลอกข้อมูลออกไป โดยต้นตอการโจมตีมาจาก IP ของ Tor exit node และ IP ของบริการ VPN ชือ IPredator
  • 21 เมษายน 2019 ผู้โจมตีโพสต์ข้อมูลลงบน Github ประกอบด้วยข้อมูล IP ของ Capital One คำสั่งที่ใช้เข้าถึงบัญชี ISRM-WAF-Role คำสั่งเรียกดูรายการ Bucket และคำสั่ง Sync เพื่อคัดลอกข้อมูล
  • 17 กรกฏาคม 2019 มีผู้ใช้งาน GitHub พบข้อมูลที่ผู้โจมตีโพส จึงแจ้งไปยัง Capital One ผ่านช่องทางรับแจ้งช่องโหว่ (Responsible Disclosure Program)
  • 19 กรกฏาคม 2019 Capital One ทำการตรวจสอบข้อมูลที่มีผู้รายงานมา พบว่ามีการใช้คำสั่งเหล่านั้นจริงใน log และได้แจ้งไปยัง FBI
  • 29 กรกฏาคม 2019 Capital One ประกาศออกประกาศแจ้งลูกค้า FBI จับกุมผู้ต้องสงสัยในคดีและเผยแพร่รายงานการจับกุม

Possible Vulnerabilities and Flaws

จากรายงานการจับกุม วิธีการเข้าถึงบัญชี ISRM-WAF-Role ถูกระบุแค่ว่าเกิดจากตั้งค่า Web Application Firewall (WAF) ที่ไม่ดีพอเท่านั้น

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

  1. บัญชี ISRM-WAF-Role มีสิทธิมากกว่าที่ควร โดยสามารถใช้คำสั่งเรียกดูรายการ Bucket ได้ ซึ่ง Capital One แจ้ง FBI ว่าตามปกติแล้วบัญชีนี้ไม่เกี่ยวข้องกับการเรียกดูรายการ Bucket
  2. ไม่มีการแจ้งเตือนการเข้าถึงอย่างผิดปกติจาก IP ของ Tor exit node ซึ่งสามารถเฝ้าระวังและตรวจจับได้
  3. มีการ Tokenization หรือเข้ารหัสข้อมูลแค่บางส่วน ทำให้ข้อมูลส่วนบุคคลหลายส่วนยังสามารถอ่านได้ ซึ่งในรายงานการจับกุมระบุว่า Capital One มีการทำ Tokenization บนหมายเลขประกันสังคม แต่ไม่มีการทำบนชื่อ ที่อยู่ และข้อมูลส่วนบุคคลอื่นๆ ที่เก็บไว้ ทำให้ผู้โจมตีที่เข้าถึงข้อมูลได้ยังสามารถใช้ประโยชน์จากข้อมูลส่วนบุคคลได้
  4. เป็นไปได้ที่จะมีการใช้งานฟังก์ชันบริการเรียกดู Security Credentials จาก Metadata เพื่อเข้าถึงบัญชี ซึ่งสามารถเฝ้าระวังและตรวจจับได้

Recommendations

  1. องค์กรควรมีการเปิดช่องทางให้รายงานช่องโหว่และควรตรวจสอบรายงานที่ได้รับ โดยแนวคิดการเปิดช่องทางในการรายงานช่องโหว่ที่น่าสนใจแนวหนึ่ง คือ การใส่ security.txt ระบุอีเมลสำหรับรับเรื่องเกี่ยวกับความปลอดภัยไว้ในเว็บไซต์ โดยสามารถศึกษาได้จาก
    1. What's security.txt and why you should have one
    2. https://securitytxt.org/
  2. เปิดการใช้ Server Access Logging ของ AWS S3 Bucket
  3. จำกัดความสามารถของบัญชีตามหลัก Least Privilege เช่น
    1. ไม่ให้บัญชีเกี่ยวกับ WAF เรียกดูรายการ Bucket
    2. ให้สิทธิการเขียน log กับบัญชีเกี่ยวกับ WAF แต่ไม่ให้สิทธิ์ในการอ่านไฟล์อื่น เป็นต้น
  4. เปิดการแจ้งเตือน AWS GuardDuty เฝ้าระวังและตรวจจับการเข้าถึงระบบที่ผิดปกติ เช่น มีการเข้าถึงอย่างผิดปกติจาก IP ของ Tor exit node
  5. เสริมการป้องกันให้กับการเรียกใช้ Amazon Metadata Service โดยสามารถอ่านรายละเอียดได้จาก Netflix Information Security: Preventing Credential Compromise in AWS
  6. ใช้บริการที่สามารถแจ้งเตือนเมื่อมีข้อมูลรั่วไหลเกิดขึ้น เช่น บริการในกลุ่มผลิตภัณฑ์ Digital Risk Protection

References

AWS Case Study by Security Researcher

ขอปิดท้ายบทความนี้ด้วยกรณีศึกษาเกี่ยวกับการโจมตี AWS โดยนักวิจัยด้านความปลอดภัยที่น่าสนใจสองบทความ ซึ่งการโจมตีเหล่านี้สามารถทำได้โดยใช้ความรู้พื้นฐานเกี่ยวกับ AWS คือ

  1. Abusing the AWS metadata service using SSRF vulnerabilities
    เป็นการโจมตีโดยใช้ AWS metadata service เพื่อเข้าถึงบัญชีผ่านหน้าเว็บที่อนุญาตให้รัน python code และ
  2. HOW I HACKED A WHOLE EC2 NETWORK DURING A PENETRATION TEST
    ผู้ทดสอบระบบสามารถเข้าถึงบัญชีที่มีสิทธิ์ต่ำได้ แต่เนื่องจากบัญชีดังกล่าวมีสิทธิ์ในการสร้างบัญชีอื่นได้ ผู้ทดสอบระบบจึงทำ Privilege escalation ด้วยการสร้างบัญชีใหม่ที่มีสิทธิ์มากขึ้น