SSRF ขั้นสูง: ทลายกำแพง Whitelist ด้วยลูกเล่น URL
ในโลกไซเบอร์ที่เต็มไปด้วยความซับซ้อน SSRF หรือ Server-Side Request Forgery ถือเป็นหนึ่งในช่องโหว่ที่อันตรายอย่างยิ่ง
โดยพื้นฐานแล้ว SSRF คือการที่เซิร์ฟเวอร์ถูกหลอกให้ส่งคำขอ (request) ไปยังที่อยู่ที่ไม่พึงประสงค์แทนที่จะเป็นตามที่โปรแกรมเมอร์ตั้งใจไว้
สิ่งนี้อาจนำไปสู่การเข้าถึงข้อมูลภายในเครือข่ายที่ไม่ควรถูกเปิดเผย หรือแม้กระทั่งสั่งการบริการภายในอื่น ๆ ได้
เข้าใจภัยของ SSRF และกำแพง Whitelist
เพื่อป้องกันการโจมตีแบบ SSRF นักพัฒนาจึงมักจะใช้กลไกที่เรียกว่า การกรองข้อมูลแบบ Whitelist (Whitelist-based Input Filter)
แนวคิดคือ การกำหนดรายชื่อโดเมนหรือ IP Address ที่ปลอดภัยและอนุญาตให้เซิร์ฟเวอร์ส่งคำขอไปได้เท่านั้น
หากคำขอใดพยายามจะเข้าถึงที่อยู่นอกเหนือจากรายการ Whitelist เหล่านี้ คำขอนั้นก็จะถูกบล็อก
กลไกนี้ดูเหมือนจะเป็นเกราะป้องกันที่แข็งแกร่งและน่าเชื่อถือมากทีเดียว
แต่ในความเป็นจริง กลับมีช่องทางที่ซับซ้อนให้ผู้ไม่หวังดีสามารถเลี่ยงผ่านกำแพงนี้ไปได้
ช่องโหว่ซ่อนเร้นใน “ความเป็นมิตร” ของ URL
ความลับในการเจาะทะลุกำแพง Whitelist อยู่ที่วิธีการตีความ URL ของระบบ
เมื่อแอปพลิเคชันมีการตรวจสอบ URL ที่ป้อนเข้ามา มันมักจะตรวจสอบว่าส่วนต้นของ URL ตรงกับโดเมนที่ได้รับอนุญาตใน Whitelist หรือไม่
แต่เบื้องหลังนั้น ไลบรารีหรือโมดูลที่ใช้ในการสร้างคำขอ HTTP จริง ๆ อาจตีความ URL แตกต่างกันออกไป
ลูกเล่นที่สำคัญคือการใช้สัญลักษณ์ @ ใน URL
ในมาตรฐาน URL สัญลักษณ์ @ ถูกใช้เพื่อระบุข้อมูลผู้ใช้และรหัสผ่านก่อนชื่อโฮสต์ เช่น username:password@hostname
สิ่งที่เกิดขึ้นคือ แอปพลิเคชันอาจตรวจสอบแค่ส่วนแรกของ URL ก่อนสัญลักษณ์ @ ว่าตรงกับ Whitelist หรือไม่
ในขณะที่ระบบที่ทำหน้าที่ส่งคำขอจริง ๆ กลับใช้ส่วนที่อยู่ หลัง สัญลักษณ์ @ เป็น IP Address หรือโดเมนปลายทางที่แท้จริง
สร้าง Payload แสนฉลาดเพื่อเจาะเป้าหมาย
เมื่อเข้าใจถึงกลไกการตีความที่แตกต่างกันนี้ ผู้โจมตีสามารถสร้าง Payload หรือ URL ที่ออกแบบมาเป็นพิเศษได้
สมมติว่ามีโดเมน stock.weliketoshop.net อยู่ใน Whitelist และเป้าหมายคือการเข้าถึงแผงควบคุมผู้ดูแลระบบภายในที่ 192.168.0.1/admin
Payload ที่ใช้ในการโจมตีก็จะเป็นรูปแบบนี้:
https://[email protected]/admin
ในที่นี้ stock.weliketoshop.net ทำหน้าที่เป็นเพียง “เหยื่อล่อ” เพื่อให้ผ่านการตรวจสอบ Whitelist ในช่วงแรก
แต่เมื่อคำขอถูกส่งออกไปจริง ๆ เซิร์ฟเวอร์จะตีความว่าต้องส่งคำขอไปยัง 192.168.0.1 พร้อมกับพาธ /admin แทน
นี่คือการใช้ช่องโหว่จากความไม่สมบูรณ์ของการตีความ URL ระหว่างส่วนหน้าของการตรวจสอบกับส่วนหลังของการประมวลผลคำขอ
การยืนยันผลลัพธ์และความอันตราย
เมื่อ Payload ที่สร้างขึ้นทำงานสำเร็จ ผู้โจมตีจะสามารถเห็นหน้าแผงควบคุมผู้ดูแลระบบภายในได้
จากนั้นก็อาจดำเนินการต่าง ๆ เช่น ลบผู้ใช้ หรือเข้าถึงข้อมูลที่ละเอียดอ่อน ซึ่งไม่ควรมีสิทธิ์เข้าถึงตั้งแต่แรก
ผลลัพธ์ที่ตามมาจากการโจมตี SSRF ที่ประสบความสำเร็จนั้นรุนแรงมาก
มันอาจนำไปสู่การรั่วไหลของข้อมูล การเข้าควบคุมระบบ หรือการใช้เซิร์ฟเวอร์เป็นฐานในการโจมตีระบบอื่น ๆ ต่อไป
บทเรียนสำคัญที่ได้จากกรณีนี้คือ แม้แต่การป้องกันที่ดูเหมือนรัดกุมอย่าง Whitelist ก็ยังคงมีจุดอ่อน
การทำความเข้าใจอย่างลึกซึ้งว่าแต่ละส่วนของระบบประมวลผลข้อมูลอย่างไร เป็นสิ่งจำเป็นสำหรับการสร้างระบบที่ปลอดภัยอย่างแท้จริง