เมื่อวันที่ 19 กรกฎาคม 2019 Capital One ได้รับข้อความที่บริษัทสมัยใหม่ทุกแห่งกลัวว่าจะมีการละเมิดข้อมูลเกิดขึ้น ส่งผลกระทบต่อผู้คนมากกว่า 106 ล้านคน หมายเลขประกันสังคมของสหรัฐอเมริกา 140 หมายเลข หมายเลขประกันสังคมของแคนาดาหนึ่งล้านหมายเลข บัญชีธนาคาร 000 แห่ง ไม่พอใจ ไม่เห็นด้วยเหรอ?
น่าเสียดายที่การแฮ็กไม่ได้เกิดขึ้นในวันที่ 19 กรกฎาคม ปรากฎว่า Paige Thompson หรือที่รู้จักในชื่อ เอาแน่ไม่ได้กระทำระหว่างวันที่ 22 มีนาคมถึง 23 มีนาคม 2019 นั่นคือ เกือบสี่เดือนที่แล้ว. ในความเป็นจริง ด้วยความช่วยเหลือจากที่ปรึกษาภายนอกเท่านั้นที่ Capital One สามารถค้นพบว่ามีบางอย่างเกิดขึ้น
อดีตพนักงานของ Amazon ถูกจับและถูกปรับ 250 ดอลลาร์และจำคุก XNUMX ปี... แต่ยังมีเรื่องในแง่ลบอีกมากมาย ทำไม เนื่องจากบริษัทหลายแห่งที่ประสบปัญหาจากการถูกแฮ็กกำลังพยายามละทิ้งความรับผิดชอบในการเสริมความแข็งแกร่งให้กับโครงสร้างพื้นฐานและแอปพลิเคชันของตน ท่ามกลางอาชญากรรมทางไซเบอร์ที่เพิ่มขึ้น
อย่างไรก็ตาม คุณสามารถ Google เรื่องราวนี้ได้อย่างง่ายดาย เราจะไม่เข้าดราม่าแต่พูดถึง ทางเทคนิค ด้านข้างของเรื่อง
ก่อนอื่น เกิดอะไรขึ้น?
Capital One มีบัคเก็ต S700 ที่ใช้งานอยู่ประมาณ 3 อัน ซึ่ง Paige Thompson คัดลอกและดูดออก
ประการที่สอง นี่เป็นอีกกรณีหนึ่งของนโยบายบัคเก็ต S3 ที่กำหนดค่าไม่ถูกต้องหรือไม่
ไม่ใช่เวลานี้. ที่นี่เธอสามารถเข้าถึงเซิร์ฟเวอร์ที่มีไฟร์วอลล์ที่กำหนดค่าไม่ถูกต้องและดำเนินการทั้งหมดจากที่นั่น
เดี๋ยวก่อน เป็นไปได้ยังไง?
เรามาเริ่มด้วยการเข้าสู่เซิร์ฟเวอร์กันดีกว่า แม้ว่าเราจะไม่มีรายละเอียดมากนักก็ตาม เราได้รับแจ้งเพียงว่ามันเกิดขึ้นผ่าน “ไฟร์วอลล์ที่กำหนดค่าไม่ถูกต้อง” ดังนั้น บางสิ่งที่เรียบง่าย เช่น การตั้งค่ากลุ่มความปลอดภัยที่ไม่ถูกต้องหรือการกำหนดค่าไฟร์วอลล์แอปพลิเคชันเว็บ (Imperva) หรือไฟร์วอลล์เครือข่าย (iptables, ufw, shorewall ฯลฯ) Capital One เพียงยอมรับความผิดและบอกว่าได้ปิดช่องโหว่แล้ว
Stone กล่าวว่า Capital One ไม่ได้สังเกตเห็นช่องโหว่ของไฟร์วอลล์ในตอนแรก แต่จะดำเนินการอย่างรวดเร็วเมื่อทราบแล้ว สิ่งนี้ได้รับความช่วยเหลืออย่างแน่นอนจากข้อเท็จจริงที่ว่าแฮ็กเกอร์ถูกกล่าวหาว่าทิ้งข้อมูลระบุตัวตนที่สำคัญไว้เป็นสาธารณสมบัติ Stone กล่าว
หากคุณสงสัยว่าเหตุใดเราไม่เจาะลึกในส่วนนี้ โปรดเข้าใจว่าเนื่องจากมีข้อมูลที่จำกัด เราจึงสามารถคาดเดาได้เท่านั้น สิ่งนี้ไม่สมเหตุสมผลเลยเนื่องจากการแฮ็กนั้นขึ้นอยู่กับรูที่ Capital One ทิ้งไว้ และเว้นแต่พวกเขาจะบอกเรามากกว่านี้ เราจะแสดงรายการวิธีที่เป็นไปได้ทั้งหมดที่เป็นไปได้ที่ Capital One เปิดเซิร์ฟเวอร์ทิ้งไว้ ร่วมกับวิธีที่เป็นไปได้ทั้งหมดที่ผู้อื่นสามารถใช้หนึ่งในตัวเลือกต่างๆ เหล่านี้ ข้อบกพร่องและเทคนิคเหล่านี้อาจมีตั้งแต่การกำกับดูแลที่โง่เขลาไปจนถึงรูปแบบที่ซับซ้อนอย่างไม่น่าเชื่อ เมื่อพิจารณาถึงความเป็นไปได้ต่างๆ มากมาย นี่จะกลายเป็นเรื่องราวที่ยาวนานโดยไม่มีบทสรุปที่แท้จริง ดังนั้นเรามาดูการวิเคราะห์ส่วนที่เรามีข้อเท็จจริงกันดีกว่า
ดังนั้นประเด็นแรกคือ: รู้ว่าไฟร์วอลล์ของคุณอนุญาตอะไรบ้าง
กำหนดนโยบายหรือกระบวนการที่เหมาะสมเพื่อให้แน่ใจว่าจะเปิดเฉพาะสิ่งที่จำเป็นต้องเปิดเท่านั้น หากคุณใช้ทรัพยากร AWS เช่น กลุ่มความปลอดภัยหรือ ACL เครือข่าย แน่นอนว่ารายการตรวจสอบในการตรวจสอบอาจใช้เวลานาน... แต่เช่นเดียวกับทรัพยากรจำนวนมากที่ถูกสร้างขึ้นโดยอัตโนมัติ (เช่น CloudFormation) คุณก็สามารถทำให้การตรวจสอบเป็นอัตโนมัติได้เช่นกัน ไม่ว่าจะเป็นสคริปต์ทำเองที่สแกนออบเจ็กต์ใหม่เพื่อหาข้อบกพร่อง หรือบางอย่างเช่นการตรวจสอบความปลอดภัยในกระบวนการ CI/CD... มีตัวเลือกง่ายๆ มากมายเพื่อหลีกเลี่ยงปัญหานี้
ส่วนที่ "ตลก" ของเรื่องคือถ้าแคปิตอลวันอุดรูตั้งแต่แรก... ก็ไม่มีอะไรเกิดขึ้น พูดตรงๆ เลยเป็นเรื่องน่าตกใจเสมอที่ได้เห็นอะไรบางอย่างจริงๆ ค่อนข้างง่าย กลายเป็นเหตุผลเดียวที่ทำให้บริษัทถูกแฮ็ก โดยเฉพาะอันที่ใหญ่พอๆ กับ Capital One
แฮกเกอร์อยู่ข้างใน - เกิดอะไรขึ้นต่อไป?
หลังจากที่เจาะเข้าไปในอินสแตนซ์ EC2... อาจมีข้อผิดพลาดมากมาย คุณกำลังเดินอยู่บนคมมีดจริงๆ หากคุณปล่อยให้ใครบางคนไปไกลขนาดนั้น แต่มันเข้าไปใน S3 buckets ได้อย่างไร? เพื่อทำความเข้าใจสิ่งนี้ เราจะมาหารือเกี่ยวกับบทบาท IAM กัน
ดังนั้นวิธีหนึ่งในการเข้าถึงบริการของ AWS คือการเป็นผู้ใช้ โอเค อันนี้ค่อนข้างชัดเจน แต่ถ้าคุณต้องการให้บริการ AWS อื่นๆ เช่น แอปพลิเคชันเซิร์ฟเวอร์ เข้าถึงบัคเก็ต S3 ของคุณล่ะ นั่นคือสิ่งที่บทบาท IAM มีไว้เพื่อ ประกอบด้วยสององค์ประกอบ:
- นโยบายความน่าเชื่อถือ - บริการหรือบุคคลใดบ้างที่สามารถใช้บทบาทนี้ได้
- นโยบายการอนุญาต - บทบาทนี้อนุญาตอะไรบ้าง
ตัวอย่างเช่น คุณต้องการสร้างบทบาท IAM ที่จะอนุญาตให้อินสแตนซ์ EC2 เข้าถึงบัคเก็ต S3 ได้ ขั้นแรก บทบาทจะถูกตั้งค่าให้มีนโยบายความน่าเชื่อถือที่ EC2 (บริการทั้งหมด) หรืออินสแตนซ์เฉพาะสามารถ “รับช่วง” บทบาทได้ การยอมรับบทบาทหมายความว่าพวกเขาสามารถใช้สิทธิ์ของบทบาทเพื่อดำเนินการต่างๆ ได้ ประการที่สอง นโยบายการอนุญาตอนุญาตให้บริการ/บุคคล/ทรัพยากรที่ "รับบทบาท" ทำอะไรก็ได้บน S3 ไม่ว่าจะเป็นการเข้าถึงบัคเก็ตเฉพาะหนึ่งบัคเก็ต... หรือมากกว่า 700 ในกรณีของ Capital One
เมื่อคุณอยู่ใน EC2 instance ที่มีบทบาท IAM คุณสามารถรับข้อมูลรับรองได้หลายวิธี:
- คุณสามารถขอข้อมูลเมตาของอินสแตนซ์ได้ที่
http://169.254.169.254/latest/meta-dataเหนือสิ่งอื่นใด คุณสามารถค้นหาบทบาท IAM ด้วยคีย์การเข้าถึงใดก็ได้ตามที่อยู่นี้ แน่นอนเฉพาะในกรณีที่คุณอยู่ในกรณีเท่านั้น
- ใช้ AWS CLI...
หากติดตั้ง AWS CLI แล้ว จะมีการโหลดข้อมูลประจำตัวจากบทบาท IAM หากมี สิ่งที่เหลืออยู่คือการทำงานผ่านอินสแตนซ์ แน่นอนว่าหากนโยบายความน่าเชื่อถือของพวกเขาเปิด Paige ก็สามารถทำทุกอย่างได้โดยตรง
ดังนั้นสาระสำคัญของบทบาท IAM ก็คืออนุญาตให้ทรัพยากรบางอย่างดำเนินการในนามของคุณในทรัพยากรอื่นๆ
เมื่อคุณเข้าใจบทบาทของ IAM แล้ว เราก็มาพูดถึงสิ่งที่ Paige Thompson ทำ:
- เธอสามารถเข้าถึงเซิร์ฟเวอร์ (อินสแตนซ์ EC2) ผ่านช่องโหว่ในไฟร์วอลล์
ไม่ว่าจะเป็นกลุ่มความปลอดภัย/ACL หรือไฟร์วอลล์เว็บแอปพลิเคชันของพวกเขาเอง ช่องโหว่นี้น่าจะเสียบปลั๊กได้ง่ายมาก ตามที่ระบุไว้ในบันทึกอย่างเป็นทางการ
- เมื่ออยู่บนเซิร์ฟเวอร์ เธอสามารถแสดง "ราวกับว่า" เธอเป็นเซิร์ฟเวอร์เองได้
- เนื่องจากบทบาทเซิร์ฟเวอร์ IAM อนุญาตให้ S3 เข้าถึงบัคเก็ตมากกว่า 700 เหล่านี้ จึงสามารถเข้าถึงได้
นับจากนั้นเป็นต้นมา สิ่งเดียวที่เธอต้องทำคือรันคำสั่ง List Bucketsแล้วก็คำสั่ง Sync จาก AWS CLI...
. การป้องกันความเสียหายดังกล่าวคือสาเหตุที่บริษัทต่างๆ ลงทุนอย่างมากในการปกป้องโครงสร้างพื้นฐานคลาวด์ DevOps และผู้เชี่ยวชาญด้านความปลอดภัย และการย้ายไปยังระบบคลาวด์มีคุณค่าและคุ้มค่าเพียงใด? มากเสียจนแม้จะต้องเผชิญกับความท้าทายด้านความปลอดภัยทางไซเบอร์ที่มากขึ้นเรื่อยๆ !
คุณธรรมของเรื่องราว: ตรวจสอบความปลอดภัยของคุณ ดำเนินการตรวจสอบอย่างสม่ำเสมอ เคารพหลักการของสิทธิ์ขั้นต่ำสำหรับนโยบายความปลอดภัย
( คุณสามารถดูรายงานทางกฎหมายฉบับเต็มได้)
ที่มา: will.com