เครื่องมือค้นหาถูกสร้างขึ้นเพื่อจัดทำดัชนีเนื้อหา อย่างไรก็ตาม ผู้โจมตีใช้มันเพื่อจัดทำดัชนีข้อผิดพลาดของคุณ การค้นหา allintext:login ประเภทไฟล์:บันทึก อาจดูเหมือนไม่มีอันตรายอะไร แต่ในความเป็นจริงแล้ว มันเป็นหนึ่งในวิธีที่ง่ายที่สุดในการค้นหาไฟล์บันทึกข้อมูลที่ถูกเปิดเผย ซึ่งมีข้อมูลเกี่ยวกับการตรวจสอบสิทธิ์ ข้อมูลประจำตัว โทเค็น และข้อมูลโครงสร้างพื้นฐานภายใน
หาก Google สามารถเข้าถึงบันทึกเหล่านั้นได้ ผู้โจมตีก็สามารถเข้าถึงได้เช่นกัน เมื่อข้อมูลถูกจัดทำดัชนีแล้ว การรั่วไหลของข้อมูลก็เป็นสิ่งที่หลีกเลี่ยงไม่ได้ ยิ่งไปกว่านั้น เมื่อข้อมูลประจำตัวปรากฏในไฟล์ที่เข้าถึงได้โดยสาธารณะ การละเมิดก็เริ่มขึ้นแล้ว
1. เหตุใดจึงใช้ allintext:login ไฟล์ประเภท log นั้นอันตรายกว่าที่คิด
Google dork คือคำค้นหาที่ใช้ตัวดำเนินการขั้นสูงเพื่อค้นหาเนื้อหาที่ละเอียดอ่อนหรือตั้งค่าไม่ถูกต้องซึ่งจัดทำดัชนีโดยเครื่องมือค้นหา มันไม่ได้โจมตี Google แต่เป็นการใช้ประโยชน์จากความเสี่ยงที่คุณก่อขึ้นต่างหาก
คำสั่งค้นหานี้เป็นการรวมตัวดำเนินการสองตัวเข้าด้วยกัน:
- allintext: ส่งคืนหน้าเว็บที่เงื่อนไขทั้งหมดปรากฏอยู่ในเนื้อหาหลัก
- ประเภทไฟล์:บันทึก จำกัดผลลัพธ์ไว้ที่
.logไฟล์
ดังนั้น:
วิธี: "แสดงไฟล์บันทึกที่มีคำว่า "Record" ให้ฉันดู login".
มองเผินๆ แล้วดูเหมือนเรื่องเล็กน้อย แต่ในทางปฏิบัติแล้วมักจะส่งผลดังนี้:
- บันทึกเซิร์ฟเวอร์เว็บที่เปิดเผยต่อสาธารณะ
- CI/CD บันทึกต่างๆ ถูกอัปโหลดเป็นไฟล์อ้างอิง
- บันทึกการแก้ไขข้อผิดพลาดโดยไม่ได้ตั้งใจ committed ไปยังที่เก็บข้อมูล
- บันทึกการใช้งานแอปพลิเคชันพร้อมข้อมูลประจำตัวแบบข้อความธรรมดา
นี่ไม่ใช่ข้อผิดพลาดของเครื่องมือค้นหา แต่เป็น... ช่องโหว่ด้านการรั่วไหลของข้อมูล เกิดจากการตั้งค่าที่ไม่ถูกต้อง Google เพียงแค่จัดทำดัชนีสิ่งที่สามารถเข้าถึงได้จากสาธารณะเท่านั้น
2. สิ่งที่ผู้โจมตีค้นพบจริง ๆ ในไฟล์บันทึกที่ถูกเปิดเผย
เมื่อผู้โจมตีวิ่ง allintext:login ประเภทไฟล์:บันทึกพวกเขาไม่ได้เข้ามาดูแบบสุ่มสี่สุ่มห้า พวกเขากำลังมองหาร่องรอยการยืนยันตัวตนอยู่
2.1 ข้อมูลประจำตัวแบบข้อความธรรมดา
ไฟล์บันทึกข้อมูลมักมีข้อความต่างๆ เช่น:
or
หรือแม้แต่ข้อมูลประจำตัว SMTP:
การบันทึกข้อมูลการตรวจสอบสิทธิ์เป็นหนึ่งในวิธีที่เร็วที่สุดในการรั่วไหลของข้อมูลประจำตัวในการใช้งานจริง ดังนั้น ไฟล์บันทึกเพียงไฟล์เดียวที่ถูกเปิดเผยก็อาจทำให้ระบบควบคุมการเข้าถึงทั้งหมดของคุณใช้การไม่ได้
2.2 โทเค็นเซสชันและ JWT
แม้ว่าจะไม่มีการบันทึกรหัสผ่าน แต่โดยทั่วไปแล้วจะมีการบันทึกโทเค็นไว้
ตัวอย่างเช่น:
คุกกี้ JWT หรือคุกกี้เซสชันที่ถูกต้องภายใน .log ไฟล์นี้สามารถเปิดใช้งาน:
- เซสชั่นการหักหลัง
- การเพิ่มระดับสิทธิ์
- การเคลื่อนที่ด้านข้างข้ามระบบภายใน
กล่าวอีกนัยหนึ่ง โทเค็นในบันทึกข้อมูลจะเปลี่ยนผลลัพธ์การดีบักให้กลายเป็นช่องทางในการหลีกเลี่ยงการตรวจสอบสิทธิ์
2.3 CI/CD ศิลปวัตถุ
ไฟล์บันทึกการสร้าง (Build logs) นั้นอันตรายเป็นพิเศษ ที่จริงแล้ว CI/CD ระบบมักจะแสดงค่าตัวแปรสภาพแวดล้อมระหว่างขั้นตอนการสร้าง
ผู้โจมตีมักค้นพบสิ่งต่อไปนี้:
ประกอบด้วยบรรทัดต่างๆ เช่น:
If CI/CD เมื่อสิ่งประดิษฐ์เป็นที่เปิดเผยต่อสาธารณะแล้ว ความลับก็กลายเป็นสิ่งที่เปิดเผยต่อสาธารณะเช่นกัน เครื่องมืออย่าง Google dork เป็นเพียงตัวช่วยเร่งกระบวนการค้นพบเท่านั้น
2.4 ข้อมูลระบบคลาวด์และโครงสร้างพื้นฐาน
ไฟล์บันทึกข้อมูลที่ถูกเปิดเผย มักจะแสดงให้เห็นถึง:
- คีย์การเข้าถึง AWS
- สตริงการเชื่อมต่อพื้นที่จัดเก็บข้อมูล Azure
- URL บริการภายใน
- ข้อมูลประจำตัวฐานข้อมูล
- เอนด์พอยต์ Redis
แม้ว่าจะมีการเปลี่ยนข้อมูลประจำตัวในภายหลัง ผู้โจมตีก็ยังคงมีข้อมูลดังต่อไปนี้:
- การทำแผนที่โครงสร้างพื้นฐาน
- แบบแผนการตั้งชื่อ
- กำหนดเป้าหมายข่าวกรองสำหรับการโจมตีในอนาคต
ดังนั้น บันทึกข้อมูลที่ถูกเปิดเผยจึงให้ทั้งการเข้าถึงและการสอดแนม
3. บันทึกเหล่านี้กลายเป็นข้อมูลสาธารณะได้อย่างไรตั้งแต่แรก
บันทึกข้อมูลไม่ได้ปรากฏใน Google โดยอัตโนมัติ แต่จะถูกจัดทำดัชนีก็เพราะว่ามันสามารถเข้าถึงได้จากสาธารณะ
3.1 เซิร์ฟเวอร์เว็บที่ตั้งค่าไม่ถูกต้อง
รูปแบบทั่วไปได้แก่:
/logs/ไดเร็กทอรีที่สามารถเข้าถึงได้โดยไม่ต้องมีการตรวจสอบสิทธิ์- เปิดใช้งานการแสดงรายการในไดเร็กทอรี
- Nginx หรือ Apache ที่ให้บริการข้อมูลดิบ
.logไฟล์
หากสามารถเข้าถึงไฟล์บันทึกผ่าน HTTP ได้ ก็จะสามารถสร้างดัชนีได้
3.2 CI/CD การเปิดเผยสิ่งประดิษฐ์
ข้อผิดพลาดทั่วไป:
- สิ่งประดิษฐ์สาธารณะที่เปิดใช้งานใน การกระทำของ GitHub
- บันทึกข้อมูลที่อัปโหลดไปยัง S3 bucket แบบเปิด
- Pipeline ร่องรอยต่างๆ สามารถเข้าถึงได้โดยไม่ต้องมีการตรวจสอบสิทธิ์
A pipeline การจัดเก็บบันทึกไว้ในที่เก็บข้อมูลสาธารณะเท่ากับเป็นการเผยแพร่ความลับของระบบนั้น
3.3 โหมดดีบักในสภาพแวดล้อมการใช้งานจริง
ค่าเริ่มต้นของเฟรมเวิร์กอาจเป็นอันตรายได้:
นอกจากนี้ การบันทึกคำขอมากเกินไปอาจแสดงข้อความดังต่อไปนี้:
- ส่วนหัว
- ราชสกุล
- คำขอเต็มรูปแบบ
การบันทึกข้อมูลการแก้ไขข้อผิดพลาดในสภาพแวดล้อมการใช้งานจริงจะเปลี่ยนแอปพลิเคชันของคุณให้กลายเป็นเครื่องมือส่งออกข้อมูลรับรอง
3.4 บันทึก Docker และคอนเทนเนอร์
สภาพแวดล้อมแบบคอนเทนเนอร์นำมาซึ่งช่องทางการเปิดเผยข้อมูลใหม่ๆ:
- ไฟล์บันทึกถูกติดตั้งลงในไดรฟ์ที่ใช้ร่วมกัน
- ไซด์คาร์ที่ส่งออกบันทึกไปยังปลายทางที่ไม่ปลอดภัย
- เข้าสู่ระบบ dashboardที่เปิดให้ประชาชนเข้าถึงได้
หากไฟล์บันทึกของคอนเทนเนอร์ถูกเปิดเผยผ่าน HTTP หรือพื้นที่จัดเก็บข้อมูลแบบเปิด ไฟล์เหล่านั้นจะสามารถค้นหาได้ และในที่สุดก็จะถูกจัดทำดัชนี
4. ขั้นตอนการโจมตีที่สมจริง: จากผู้บุกรุกไปจนถึงการเจาะระบบ
ลำดับการโจมตีโดยทั่วไปจะมีลักษณะดังนี้:
ผู้โจมตีรัน:
- พบว่ามีการเปิดเผยข้อมูล
.logไฟล์ - สารสกัด:
- โทเค็น JWT
- ส่วนหัวการตรวจสอบสิทธิ์พื้นฐาน
- สตริงการเชื่อมต่อฐานข้อมูล
พยายามตรวจสอบสิทธิ์กับ:
- จุดสิ้นสุด API
- แผงควบคุมผู้ดูแลระบบ
- บริการภายใน
หากการตรวจสอบสิทธิ์สำเร็จ ผู้โจมตีสามารถทำสิ่งต่อไปนี้ได้:
- ยกระดับสิทธิพิเศษ
- เลื่อนไปด้านข้าง
- ทางเข้า CI/CD
- ทำให้ห่วงโซ่อุปทานเสียหาย
สิ่งที่เริ่มต้นจากการค้นหาข้อมูล กลายเป็น:
- เซสชั่นการหักหลัง
- การยัดข้อมูลประจำตัวภายใน
- Pipeline การครอบครอง
- การวางยาพิษสิ่งประดิษฐ์
ทั้งหมดนี้มาจากไฟล์บันทึกข้อมูลที่เปิดเผยต่อสาธารณะ
5. เหตุใดการบันทึกข้อมูล “มากเกินไป” จึงเป็นปัญหาด้านความปลอดภัยของแอปพลิเคชัน
การบันทึกข้อมูลไม่ใช่เรื่องที่เป็นกลาง แต่กลับสร้าง... ที่เก็บข้อมูลรอง.
หากคุณบันทึกข้อมูลที่ละเอียดอ่อน คุณก็เท่ากับสร้างสำเนาข้อมูลลับของคุณขึ้นมาอีกชุดหนึ่ง
อย่างไรก็ตาม บันทึกข้อมูลมักถูกยกเว้นจากการสร้างแบบจำลองภัยคุกคาม ภายใต้ STRIDE สิ่งนี้หมายความถึงสิ่งต่อไปนี้อย่างชัดเจน:
การเปิดเผยข้อมูล
ดังนั้น จึงปลอดภัย SDLC แนวปฏิบัติควรจัดการกับบันทึกข้อมูลดังนี้:
- สิ่งประดิษฐ์ที่เกี่ยวข้องกับความปลอดภัย
- สินทรัพย์ที่อ่อนไหว
- ส่วนประกอบโครงสร้างพื้นฐานที่ต้องการการปกป้อง
หากแบบจำลองภัยคุกคามของคุณละเลยบันทึกข้อมูล แสดงว่าแบบจำลองนั้นไม่สมบูรณ์
6. วิธีป้องกันการรั่วไหลของข้อมูลประจำตัวในไฟล์บันทึก
6.1 หยุดการบันทึกความลับ
ห้ามบันทึกข้อมูล:
- รหัสผ่าน
- ราชสกุล
- คีย์ API
- รหัสเซสชัน
- ส่วนหัวการอนุญาต
แม้ในโหมดดีบักก็ตาม
ควรใช้ระบบปกปิดข้อมูลอัตโนมัติทุกครั้งที่เป็นไปได้
6.2 การบันทึกข้อมูลอย่างเป็นระบบและปลอดภัย
ใช้การบันทึกข้อมูลแบบมีโครงสร้างร่วมกับการปิดบังและการกรองข้อมูล
ตัวอย่าง (Node.js):
ตัวอย่าง (Python):
หลักการสำคัญนั้นง่ายมาก: ความลับจะต้องไม่ไปถึงระบบจัดเก็บข้อมูลบันทึก (log sink) เด็ดขาด
6.3 การจัดเก็บบันทึกการล็อกดาวน์
มาตรการรักษาความปลอดภัยควรประกอบด้วย:
- ปิดใช้งานการแสดงรายการไดเร็กทอรี
- ป้องกัน
/logs/เส้นทางที่มีการตรวจสอบสิทธิ์ - จำกัดการเข้าถึงถัง
- นำนโยบายการเก็บรักษาข้อมูลมาใช้
- เข้ารหัสไฟล์บันทึกข้อมูลขณะจัดเก็บ
ไฟล์บันทึกข้อมูลจะต้องไม่สามารถเข้าถึงได้จากภายนอกผ่านทาง HTTP
6.4 CI/CD Guardrails
การตรวจสอบด้วยตนเองนั้นไม่เพียงพอ ควรใช้ระบบควบคุมอัตโนมัติแทน:
- การสแกนบันทึกข้อมูลลับก่อนการเผยแพร่ผลงาน
- ยกเลิกการสร้างหากตรวจพบโทเค็น
- ป้องกันการอัปโหลดไฟล์ที่มีข้อมูลประจำตัว
- การตรวจสอบความถูกต้องของแฮชสำหรับอาร์ติแฟกต์
CI/CD ควรบล็อกการเปิดเผยข้อมูลก่อนที่จะมีการจัดทำดัชนี
7. วิธีที่ Xygeni ป้องกัน allintext:login ประเภทไฟล์:บันทึกเหตุการณ์
ปัญหาไม่ได้อยู่ที่ Google dork แต่ปัญหาอยู่ที่การเปิดเผยข้อมูล ดังนั้น การป้องกันจึงต้องเกิดขึ้นก่อนการจัดทำดัชนี
7.1 การตรวจจับความลับในบันทึกและหลักฐาน
การสแกน Xygeni:
- แอปพลิเคชันบันทึก
- CI/CD การติดตามงาน
- สร้างสิ่งประดิษฐ์
- เลเยอร์ Docker
- เอาต์พุตแบบอนุกรม
หากข้อมูลประจำตัว โทเค็น หรือค่าที่มีความละเอียดอ่อนปรากฏอยู่ใน .log Xygeni จะตรวจจับไฟล์เหล่านั้นทันที
7.2 CI/CD Guardrails การป้องกันการเปิดเผยข้อมูล
แทนที่จะพึ่งพาการตรวจสอบด้วยตนเอง Xygeni บังคับใช้มาตรการรักษาความปลอดภัยที่ pipeline ระดับ:
นี้:
- การสร้างล้มเหลวเมื่อพบข้อมูลลับในบันทึก
- การเผยแพร่สิ่งประดิษฐ์บล็อก
- ป้องกันการเปิดเผยต่อสาธารณะโดยไม่ตั้งใจ
- หยุดการรวมที่ไม่ปลอดภัยก่อนที่จะถึงส่วนหลัก
หากงาน CI พิมพ์โทเค็นออกมา แสดงว่า pipeline ล้มเหลว
ไม่มีการจัดทำดัชนี
ไม่มีการสัมผัสเชื้อ
ไม่มีเหตุการณ์ใดๆ เกิดขึ้น
7.3 การป้องกันการกด Shift-Left ก่อนที่ Google จะเห็น
เรื่องเวลาเป็นเรื่องสำคัญ
แทนที่จะตอบสนองต่อ:
Xygeni แก้ปัญหานี้ได้แล้ว:
- At commit เวลา
- ในระหว่าง pull request การตรวจสอบ
- ในระหว่าง pipeline การปฏิบัติ
- ก่อนการเผยแพร่สิ่งประดิษฐ์
หากบันทึกข้อมูลนั้นไม่เคยถูกเปิดเผยต่อสาธารณะ Google ก็จะไม่ทำการจัดทำดัชนีข้อมูลนั้น
บทสรุปสุดท้าย: ถ้า Google สามารถจัดทำดัชนีได้ ผู้โจมตีก็ทำไปแล้วเช่นกัน
ไฟล์บันทึกข้อมูลไม่ใช่เรื่องไร้พิษภัย อันที่จริงแล้ว ไฟล์บันทึกข้อมูลมักจะไม่ใช่ไฟล์ชั่วคราว และโดยปกติแล้วจะไม่ใช่ไฟล์ส่วนตัว ดังนั้น ไฟล์บันทึกข้อมูลทุกไฟล์จึงควรได้รับการปฏิบัติเสมือนเป็นสินทรัพย์ที่มีความสำคัญต่อความปลอดภัย ไม่ใช่แค่เพียงข้อมูลสำหรับการแก้ไขข้อผิดพลาดเท่านั้น
หากข้อมูลที่ละเอียดอ่อนตกไปอยู่ในมือของ... .log ไฟล์และเปิดให้บุคคลทั่วไปเข้าถึงได้ มันจะกลายเป็นช่องโหว่ให้โจมตีได้ทันที ยิ่งไปกว่านั้น เมื่อเว็บไซต์ค้นหาจัดทำดัชนีแล้ว การเผยแพร่ก็จะขยายตัวอย่างที่คุณควบคุมไม่ได้
วิธีแก้ปัญหาไม่ใช่การหยุดบันทึกข้อมูล แต่เป็นการบันทึกข้อมูลอย่างมีความรับผิดชอบและบังคับใช้มาตรการควบคุมที่เข้มงวดเกี่ยวกับการจัดเก็บและการเผยแพร่ กล่าวอีกนัยหนึ่ง ความปลอดภัยต้องขยายไปไกลกว่าตัวแอปพลิเคชันเองและไปถึงชั้นการตรวจสอบด้วย
แทนที่:
- หยุดบันทึกความลับ
- ล็อกดาวน์การจัดเก็บท่อนซุง
- บังคับใช้ pipeline guardrails
- ทำการตรวจจับและบังคับใช้นโยบายโดยอัตโนมัติ
ในที่สุด, การป้องกันนั้นขึ้นอยู่กับจังหวะเวลา เพราะเมื่อป้องกันแล้วจึงค่อยจัดการ allintext:login ประเภทไฟล์:บันทึก หากส่งคืนโดเมนของคุณ เหตุการณ์ดังกล่าวได้เริ่มต้นขึ้นแล้ว
