การรั่วไหลของความลับ: ก้าวหนึ่งสู่การเปิดเผยความจริงsaster

การมอบกุญแจบ้านให้โจรนั้นไม่ใช่ความคิดที่ดีอย่างแน่นอน แต่สิ่งนี้มักเกิดขึ้นในองค์กรส่วนใหญ่ที่พัฒนาซอฟต์แวร์สมัยใหม่

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

โอ้พระเจ้า! ฉันอัปโหลดคีย์การเข้าถึงระบบคลาวด์ของฉันไปยังที่เก็บข้อมูลสาธารณะแล้ว

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

เมื่อมองย้อนกลับไปแล้ว มันเป็นเรื่องที่น่ากังวล บ่อยแค่ไหนที่ความผิดพลาดเล็กน้อยเพียงนิดเดียวอาจนำไปสู่การละเมิดความปลอดภัยอย่างร้ายแรง ลองค้นหาใน Google ดูสิ “การรั่วไหลของคีย์ AWS","การรั่วไหลของโทเค็นการเข้าถึง GitHub“และอื่นๆ อย่าเอาตัวอย่างเหล่านี้ไปตีความว่าเป็นคำแนะนำแอบแฝงสำหรับผู้ขายรายใดรายหนึ่ง ใช้แหล่งข้อมูลของคุณเอง!”

ตัวอย่างเช่น บุคคลที่มีชื่อเสียง (ในทางที่ไม่ดี) การโจมตีโคเดคอฟ เหตุการณ์ในเดือนเมษายน 2021 เกิดขึ้นได้เนื่องจากอิมเมจ Docker ของ Codecov มีข้อมูลรับรอง Git ที่อนุญาตให้ผู้โจมตีเข้าถึงที่เก็บ Git ส่วนตัวของ Codecov และเพิ่มบรรทัดเดียวในสคริปต์อัปโหลด Bash ของ Codecov เพื่อรวบรวมตัวแปรสภาพแวดล้อมและ URL ของที่เก็บ Git

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

ปัญหาคือว่า การเข้ารหัสลับแบบตายตัวเป็นเรื่องปกติในเดือนมีนาคม 2022 กลุ่ม Lapsus$ APT ได้ก่อตั้งขึ้น รั่วไหล 189GB ของซอร์สโค้ดของซัมซุงและไฟล์สำคัญอื่นๆ การวิเคราะห์พบว่ามีบางส่วนอยู่ภายใน ความลับที่ถูกกำหนดไว้ตายตัว 6,600 รายการ: 90% สำหรับระบบภายใน แต่ 10% สำหรับบริการและเครื่องมือภายนอก เช่น GitHub, AWS หรือ Google ข้อมูลลับเหล่านั้นรวมถึงคีย์ API ของ AWS/Twilio/Google, สตริงการเชื่อมต่อฐานข้อมูล และข้อมูลสำคัญอื่นๆ นี่คือระดับความล้ำสมัยในฐานโค้ดส่วนใหญ่

การรั่วไหลของข้อมูลลับเป็นช่องทางที่ง่ายที่สุดในการโจมตีห่วงโซ่อุปทาน

ปัจจุบัน การพึ่งพาแพ็กเกจเป็นเป้าหมายที่พบบ่อยที่สุด แม้จะไม่ใช่เป้าหมายเดียวของการโจมตีห่วงโซ่อุปทานก็ตาม ผู้ร้ายอาจสร้างแพ็กเกจใหม่ที่ติดตั้งลงในซอฟต์แวร์ของเหยื่อ (โดยใช้...) การพิมพ์ผิด และเทคนิคอื่นๆ) แต่โดยทั่วไปแล้ว พวกเขาพยายามแพร่เชื้อไปยังแพ็กเกจที่มีอยู่แล้ว โดยการเพิ่มการแก้ไขลงในซอร์สโค้ดในที่เก็บซอฟต์แวร์ (SCMเช่น GitHub, GitLab หรือ BitBucket หรือโดยการเพิ่มเวอร์ชันที่เป็นอันตรายลงในรีจิสทรีสาธารณะ เช่น NPM, PyPI, RubyGems, Maven Central

แต่การแทรกโค้ดที่เป็นอันตรายหรือการพึ่งพาที่เป็นอันตรายซึ่งซ่อนอยู่ในแผนผังการพึ่งพาที่ซับซ้อนนั้น จำเป็นต้องใช้... login ข้อมูลประจำตัว เช่น ชื่อผู้ใช้/รหัสผ่าน โทเค็น หรือคีย์การเข้าถึง (เราจะเรียกสิ่งเหล่านี้ว่า “กุญแจ(เรียกสั้นๆ ว่า “แหล่งเก็บซอร์สโค้ดเป้าหมาย”) หรือทะเบียนสาธารณะ ตามลำดับ 

บางครั้งพวกคนร้ายก็ได้กุญแจมาด้วยวิธีใดวิธีหนึ่ง วิศวกรรมทางสังคมส่วน การโจมตีไปยัง event-stream แพ็กเกจ NPM ยอดนิยมให้ตัวอย่างที่ดี แต่การค้นหาข้อมูลที่รั่วไหล login ข้อมูลประจำตัวหรือรหัสการเข้าถึงเป็นเทคนิคการโจมตีที่พบบ่อยที่สุดในการโจมตีห่วงโซ่อุปทานซอฟต์แวร์

คลังเก็บซอร์สโค้ดและทะเบียนแพ็กเกจเป็นระบบสำคัญสองระบบในการสร้างซอฟต์แวร์ pipelineแต่ใน DevOps มีเครื่องมือมากมาย: CI/CD ระบบ เครื่องมือสำหรับการทดสอบ การกำหนดค่าและการจัดเตรียมแบบอัตโนมัติ หรือการปรับใช้สำหรับการเผยแพร่ ทั้งหมดนี้สามารถถูกนำไปใช้ในทางที่ผิดเพื่อแทรกโค้ดที่เป็นอันตรายในซอฟต์แวร์ การรั่วไหลของคีย์ที่ถูกต้องสำหรับเครื่องมือเหล่านี้จะนำไปสู่ความทุกข์ยากและความเจ็บปวดโดยตรง ลองนึกภาพการรั่วไหลของคีย์การเข้าถึงระดับรูทซึ่งมีอำนาจควบคุมทรัพยากรคลาวด์สาธารณะของคุณอย่างเต็มที่…

คำแนะนำทั่วไป

เราไม่ได้พูดอะไรใหม่ ทุกคนรู้เรื่องนี้อยู่แล้ว แต่ลงมือทำเถอะ! จำไว้ว่าบอทกำลังสแกนพื้นที่สาธารณะทั้งหมดอยู่เป็นประจำ SCM แหล่งเก็บข้อมูล คำแนะนำบางส่วน โดยไม่มีลำดับความสำคัญ

• หากคุณมีหน้าที่รับผิดชอบด้านการจัดการความปลอดภัยด้านไอที กำหนดวิธีการจัดการความลับ ในนโยบายความปลอดภัย แต่ประสิทธิภาพของนโยบายนั้นขึ้นอยู่กับการบังคับใช้: ตรวจสอบให้แน่ใจว่ามีการบังคับใช้แนวทางการจัดการความลับในองค์กรของคุณ ซึ่งรวมถึงไม่เพียงแต่ทีม DevOps เท่านั้น แต่ยังรวมถึงซัพพลายเออร์ซอฟต์แวร์ของคุณด้วย และแผนการรับมือเหตุการณ์ขององค์กรของคุณมีข้อกำหนดสำหรับเหตุการณ์การรั่วไหลของความลับ
• การดำเนินการและบังคับใช้ การตรวจสอบหลายปัจจัย (MFA, 2FA หรือตัวย่อใดก็ตาม) และไม่มีการลดทอนด้านความปลอดภัย: คีย์ความปลอดภัย USB คุ้มค่ากับเงินไม่กี่บาทที่จ่ายไป คุณเพียงแค่ต้องอัปโหลดข้อมูลประจำตัวนับพันของคุณ (ง่ายมาก) แล้วก็ไปดื่มเหล้าจนเมาและทิ้งคีย์ไว้ในบาร์ที่มีอะไรบางอย่างเชื่อมโยงกับคุณ (โอกาสน้อยลงเล็กน้อย โดยเฉพาะถ้าคุณไม่ดื่มแอลกอฮอล์)
• ใช้โปรแกรมจัดการรหัสผ่านที่มีรหัสผ่านที่ปลอดภัยและไม่บันทึกไว้ สำหรับการจัดการข้อมูลลับในระบบ ให้ใช้... ห้องนิรภัยลับ. CI/CD ระบบ, ผู้ให้บริการคลาวด์, SCMและเครื่องมือ DevOps อื่นๆ มีบริการนี้ แต่คุณอาจเลือกใช้โซลูชัน Secret Vault ทั่วไปก็ได้
• ชอบ อายุสั้น โทเค็นจะถูกเปลี่ยนเป็นคีย์การเข้าถึงที่มีอายุการใช้งานยาวนาน การยกเลิกโทเค็นทำได้ง่ายกว่า และเปิดโอกาสให้ผู้ไม่ประสงค์ดีเข้าถึงได้น้อยกว่า
• จำกัดการใช้ข้อมูลประจำตัวซ้ำผู้โจมตีจะนำข้อมูลประจำตัวที่ขโมยมาไปใช้ซ้ำในระบบอื่นๆ ซึ่งเป็นอีกเหตุผลหนึ่งที่ควรใช้โปรแกรมจัดการรหัสผ่าน โปรแกรมจัดการรหัสผ่านและที่เก็บข้อมูลลับควรทำให้การนำข้อมูลประจำตัวไปใช้ซ้ำเป็นเรื่องในอดีต
• จำกัดและตรวจสอบการใช้งาน ผู้ดูแลระบบ รหัสผ่านนั้นมีความสำคัญมากพอที่จะต้องได้รับการติดตามเป็นพิเศษ
• Implement การแฮชและการเข้ารหัสที่แข็งแกร่งกลับมาที่เรื่องคีย์ USB (เข้ารหัสลับ) ขั้นตอนที่เข้มงวดในการส่งข้อมูลประจำตัวกับคู่ค้าและเพื่อนร่วมงาน และอื่นๆ
• ใช้ เครื่องสแกนความลับตัวอย่างเช่น รันใน pre-commit เบ็ด เพื่อป้องกันการรั่วไหลในระบบควบคุมเวอร์ชัน เปรียบเสมือนด่านรักษาความปลอดภัย ก่อนสิ่งนั้น สิ่งสำคัญในที่นี้คือ การใช้การสแกนภายหลังเพื่อตรวจจับความลับที่รั่วไหล เช่น การตรวจสอบก่อน pull request การรวมข้อมูล หมายเหตุ: แพลตฟอร์ม Xygeni ของเรามีเครื่องสแกนความลับที่ช่วยให้สามารถใช้งานได้ทั้งสองโหมด 
• ทางเลือกแบบแมนนวลในการใช้ การตรวจสอบโค้ด การค้นหาความลับที่ถูกกำหนดไว้ตายตัวนั้นมีต้นทุนสูงกว่าและต้องดำเนินการภายหลังcommit (แต่หวังว่าอย่างน้อยที่สุดก็จะรู้ก่อนที่ความลับจะถูกเปิดเผยต่อบุคคลภายนอก) อย่างไรก็ตาม การตรวจสอบอาจตรวจพบความลับที่ไม่ธรรมดาซึ่งอาจหลบเลี่ยงเครื่องสแกนความลับได้       
• หลีกเลี่ยงอุบัติเหตุ commitการเชื่อมโยงไฟล์ทั่วไปที่มีข้อมูลลับเข้ากับการควบคุมเวอร์ชันด้วยวิธีการที่เหมาะสม ไม่รวมรูปแบบ (เช่น เทมเพลต `gitignore`) โดยคำนึงถึงไฟล์ต่างๆ เช่น .env, .npmrc, .pypircไฟล์ชั่วคราว... นับเป็นอีกชั้นหนึ่งของระบบรักษาความปลอดภัยอย่างแท้จริง
• และข้อสุดท้ายในรายการยาวเหยียดนี้: ให้ผู้ให้บริการคลาวด์ทำการสแกนหาการรั่วไหลของคีย์ของตนเอง เมื่อสามารถทำได้ อย่างน้อยที่สุดก็คือข้อนี้ อาจ จะแจ้งให้คุณทราบเกี่ยวกับการรั่วไหลเมื่อเกิดขึ้น แต่ความปลอดภัยเป็นสิ่งจำเป็นอย่างยิ่งสำหรับผู้ให้บริการคลาวด์ โพสต์-hoc การสแกนแบบลับๆ นั้นไม่ค่อยโปร่งใสนักในเรื่องสถานที่และจำนวนครั้งที่ทำการสแกน และมักต้องมีการตั้งค่าอย่างชัดเจน แต่แน่นอนว่ามันเป็นทางเลือกสุดท้ายเมื่อวิธีการอื่นๆ ล้มเหลวทั้งหมด

โอ้พระเจ้า! ฉันอัปโหลดคีย์การเข้าถึงระบบคลาวด์ไปยังที่เก็บข้อมูลสาธารณะเรียบร้อยแล้ว ครั้งที่ 2

เรื่องแบบนี้เกิดขึ้นได้กับทุกคน แม้แต่คนเก่งที่สุด เตรียมตัวให้พร้อม!

ต่ออายุ/เพิกถอน/ปิดใช้งานรหัสลับที่รั่วไหลทันที! หากบัญชีมีการตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) ที่ดี ความเสี่ยงก็จะต่ำลงมาก อาจทำได้ยากกว่าในกรณีของรหัสส่วนตัวในเว็บไซต์ (คุณต้องออกใบรับรองใหม่สำหรับรหัสส่วนตัวใหม่และเพิกถอนใบรับรองที่มีอยู่) แต่เครื่องมือสมัยใหม่มีวิธีที่รวดเร็วในการต่ออายุข้อมูลประจำตัวหรือเพิกถอนโทเค็น 

ปฏิบัติตามขั้นตอนที่ผู้ให้บริการแนะนำเมื่อมีข้อมูลให้ เช่น ในตัวอย่างนี้คือ AWS.

ระบุสาเหตุของการรั่วไหล การทราบว่าเหตุการณ์เกิดขึ้นได้อย่างไรเป็นสิ่งสำคัญสำหรับการเปิดเผยข้อมูล การวิเคราะห์ การควบคุม และการเรียนรู้บทเรียนที่ได้รับ

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

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

การเขียนทับประวัติ (การควบคุมเวอร์ชัน) มันซับซ้อน แม้แต่รัฐเผด็จการก็ยังพยายามทำแบบนี้แต่ก็ไม่สำเร็จ (เล่นคำนะ) และอาจจะไม่เกี่ยวข้องกัน: แฮกเกอร์หรือบอทในคลังเก็บข้อมูลสาธารณะอาจคัดลอกคลังเก็บข้อมูลหรือดึงข้อมูลที่มีค่าออกมาแล้ว โดยเฉพาะอย่างยิ่งหากช่วงเวลาที่เปิดเผยข้อมูลนั้นยาวนานพอ 

หากคุณเป็นคนชอบผจญภัยและอยากลองดูด้วยตัวเองว่าบอทใช้เวลานานแค่ไหนในการตรวจจับความลับที่รั่วไหล ลองใช้กับดักอย่างเช่น... โทเค็น Canary ให้คุณได้ทดลอง โปรดจำไว้ว่า บอทจะบล็อกค่าเริ่มต้น canarytokens.org โดเมน…