เลิกฝืนใช้ Burp Suite: เบื้องหลังการสร้างเครื่องมือดักจับทราฟฟิกเองระหว่างทำ Pentest
เมื่อ Burp Suite และ Caido ใช้งานไม่ได้ดั่งใจในงาน Pentest ระบบกู้ยืมเงิน นักทดสอบระบบรายนี้จึงตัดสินใจหยุดเป็นตัวกลาง แล้วสร้าง Listener ขึ้นมาเอง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Burp Suite และ Proxy อื่นๆ ล่มและหมดเวลาบ่อยครั้งขณะทดสอบระบบเครือข่ายภายใน
- นักทดสอบจึงหันมาสร้างเบราว์เซอร์เอ็กเทนชันร่วมกับโปรแกรม Listener ส่วนตัว
- แก้ไขปัญหา CORS และหลีกเลี่ยงการขัดขวางทราฟฟิกได้อย่างราบรื่น
- ค้นพบช่องโหว่สำคัญด้านความปลอดภัยหลังเปรียบเทียบ Endpoint ระหว่างบัญชี Sales และ Super Admin
ระหว่างการทำเพนเทสต์ (Pentest) แอปพลิเคชันเว็บประเภทระบบกู้ยืมเงินนักศึกษา (Student Loan Servicing) ภายในองค์กรที่มีการกรองไอพีและใช้งานผ่าน VPN นักทดสอบระบบรายหนึ่งต้องเผชิญกับอุปสรรคสำคัญ โดยเขาได้รับบัญชีสำหรับทดสอบมา 2 บัญชี ได้แก่ บัญชีพนักงานขาย (Sales) และบัญชีผู้ดูแลระบบสูงสุด (Super Admin) แต่ตั้งแต่วันแรกที่เริ่มงาน โปรแกรมดักจับทราฟฟิกยอดนิยมอย่าง Burp Suite กลับใช้งานไม่ได้เลย แม้จะไม่ใช่เพราะความช้าหรือบั๊ก แต่มันไม่ยอมทำงานตามที่ควรจะเป็น
เขาใช้เวลาตรวจสอบทุกอย่าง ตั้งแต่แล็ปท็อปเครื่องใหม่ ใบรับรองความปลอดภัย (Certs) ไปจนถึงซอฟต์แวร์ความปลอดภัยอย่าง SeroPOS ที่ทางไอทีติดตั้งไว้บนเครื่องบริษัท โดยขอให้ยกเลิกการทำงานในส่วนดังกล่าวเพราะคิดว่ามันอาจจะดักจับทราฟฟิกไปก่อนที่ Burp จะมองเห็น แต่ปัญหาก็ยังคงอยู่ ไม่ว่าจะเป็นบน Burp, Caido หรือแม้แต่บน Firefox และ IE ที่ไม่ได้ผ่านพร็อกซี่ก็ตาม
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
หลังจากนั้นรูปแบบบางอย่างก็ปรากฏขึ้น คำขอ (Requests) ประมาณ 4 ถึง 5 รายการแรกสามารถส่งผ่านไปได้ด้วยดี ก่อนที่ระบบจะหยุดชะงักและเกิดอาการหมดเวลา (Timeout) จากนั้นผ่านไป 15 ถึง 30 นาที หรือบางครั้งอาจนานถึงหนึ่งชั่วโมง มันก็จะกลับมาใช้งานได้อีกครั้งสำหรับคำขออีกเพียงไม่กี่รายการแล้วหยุดไปอีก ที่แปลกไปกว่านั้นคือ หากเขาส่งคำขอเดิมซ้ำอีกครั้งทันทีมันจะทำงานได้ แต่หากมีการเปลี่ยนแปลงใดๆ เช่น เพิ่มเครื่องหมายคำพูด แท็กสคริปต์ หรือสิ่งผิดปกติ ระบบจะนิ่งเงียบไปทันทีไม่มีการตอบกลับใดๆ ส่งผลให้เวลาผ่านไป 3 วันโดยแทบไม่ได้ทราฟฟิกที่ใช้งานได้เลย ซึ่งสร้างความบั่นทอนความมั่นใจอย่างมากโดยเฉพาะกับผู้ที่ยังใหม่ในวงการ
ในทางเทคนิคแล้ว เครื่องมือประเภท Proxy เช่น Burp Suite มีหน้าที่ถอดรหัสและส่งต่อทุกคำขอ (Decrypt and Resend) ซึ่งหากระบบเครือข่ายต้นทางหรือแอปพลิเคชันมีความไม่เสถียรอยู่แล้ว การแทรกเครื่องมือระดับกลางนี้เข้าไปยิ่งเพิ่มภาระและทำให้การเชื่อมต่อล่มได้ง่ายขึ้น แนวคิดการ "เฝ้าดูแทนที่จะขวางกั้น" จึงเป็นทางออกทางสถาปัตยกรรมที่ช่วยลดจุดพังของระบบได้อย่างมีประสิทธิภาพ
ในระหว่างที่ติดขัดกับการใช้พร็อกซี่ เขาจึงเปลี่ยนไปอ่านโค้ด JavaScript ของแอปพลิเคชันแทน ซึ่งทำให้เขาเข้าใจกระบวนการสมัครสินเชื่อ บทบาทหน้าที่ และวิธีที่หน้าบ้านสื่อสารกับหลังบ้าน โดยไม่ต้องพึ่งพาพร็อกซี่เลย จากจุดนั้นทำให้เขาตระหนักว่าปัญหาไม่ได้อยู่ที่การตั้งค่าของตนเอง แต่เป็นเพราะพร็อกซี่ที่ทำหน้าที่เป็นตัวกลางคอยตัดสินใจว่าคำขอใดจะรอดชีวิต ซึ่งหากการเชื่อมต่อระหว่างตัวเขากับแอปพลิเคชันมีปัญหาอยู่แล้ว การใช้เครื่องมือที่ถอดรหัสและส่งต่อทราฟฟิกทุกอย่างยิ่งทำให้อาการแย่ลง
เขาจึงตัดสินใจเลิกพยายามทำตัวเป็นคนกลาง และหันมาใช้วิธี "เฝ้าดู" แทน เนื่องจากเบราว์เซอร์มองเห็นทุกคำขอที่ถูกส่งออกไปอยู่แล้วในแท็บ Network เขาจึงสร้างเบราว์เซอร์เอ็กเทนชันขนาดเล็กขึ้นมาเพื่อดึงข้อมูลทราฟฟิกเหล่านั้นและบันทึกลงใน localStorage ทันที แม้ในตอนแรกวิธีนี้จะใช้งานได้ แต่เนื่องจาก localStorage ไม่ได้ถูกออกแบบมาให้รองรับข้อมูลคำขอนับพันรายการ จึงทำให้เบราว์เซอร์เริ่มช้าลงอย่างเห็นได้ชัดเมื่อทดสอบกับแอปที่มีกว่า 200 Endpoint
บทเรียนสำคัญที่ได้คือ เบราว์เซอร์เป็นสถานที่ที่ดีในการเฝ้าดูทราฟฟิก แต่เป็นที่แย่มากในการจัดเก็บข้อมูล เขาจึงแยกงานออกจากกันอย่างเด็ดขาด โดยให้เอ็กเทนชันทำหน้าที่เพียงแค่มองเห็นคำขอ ส่งออกทันทีแล้วลืมมันไป ไม่เก็บข้อมูลไว้ในแท็บ จากนั้นเขาจึงสร้างโปรแกรม Listener บนเครื่องของตัวเองเพื่อเปิดพอร์ตรับคำขอที่ /capture และบันทึกข้อมูลลงไป ทำให้เอ็กเทนชันไม่เกิดอาการหน่วงไม่ว่าจะรันนานแค่ไหนก็ตาม
อุปสรรคแรกที่พบคือเรื่อง CORS (Cross-Origin Resource Sharing) เมื่อเอ็กเทนชันพยายามส่งข้อมูลไปยัง Listener ซึ่งอยู่คนละแอตเดรสกับหน้าเว็บ เบราว์ซอร์ตจะส่งคำขอตรวจสอบล่วงหน้า (Preflight request) ไปก่อน แต่เนื่องจาก Listener ของเขายังไม่ได้เขียนรองรับคำตอบในส่วนนี้ ทุกคำขอจึงล้มเหลวตั้งσόงยังไม่เริ่ม เมื่อเขาเพิ่มการตอบสนองที่ถูกต้องสำหรับคำขอนั้น ระบบก็เริ่มทำงานได้ทันที
แนวคิดนี้ไม่ใช่เรื่องใหม่ เพราะมีพื้นฐานเดียวกับเครื่องมืออย่าง mitmproxy หรือเครื่องมือขนาดเล็กชิ้นเดียวที่นักวิจัยมักสร้างขึ้นและนำมาเชื่อมต่อกัน ความแตกต่างเดียวคือเขาเลิกพยายามทำตัวเป็นพร็อกซี่ แต่เปลี่ยนเป็นเฝ้าดู บันทึกอย่างเรียบง่าย และส่งออกในรูปแบบที่ต้องการ เมื่อทราฟฟิกไหลลื่นไม่มีอาการหมดเวลาเพราะไม่มีอะไรขวางกั้น เขาก็เริ่มกระบวนการที่น่าเบื่อแต่มีประโยชน์ นั่นคือการคอยเคาะเรียก (Crawl) แอปพลิเคชันด้วยบัญชี Sales และส่งออกทุก Endpoint ที่เข้าถึง จากนั้นทำซ้ำด้วยบัญชี Super Admin แล้วนำรายการทั้งสองมาเปรียบเทียบกัน
ผลลัพธ์คือ Endpoint จำนวนมากในรายการแอดมินสามารถใช้งานได้โดยตรงด้วยบัญชี Sales โดยไม่มีการตรวจสอบฝั่งหลังบ้านว่าผู้ใช้งานคือใครจริงๆ ซึ่งส่งผลกระทบรุนแรงในแอปพลิเคชันทางการเงิน เช่น การเปลี่ยนรหัสผ่านของผู้ใช้อรายอื่น การเปลี่ยนอีเมล การปิดระบบยืนยันตัวตนสองชั้น (2FA) การเปลี่ยนเบอร์โทรศัพท์ หรือการสร้างบัญชีและบันทึกธนาคารใหม่ที่บัญชีพนักงานขายไม่ควรเข้าถึงได้ แม้เขาจะไม่เปิดเผยรายละเอียดคำขอจริงเพื่อรักษาความลับของลูกค้า แต่รูปแบบปัญหาที่ว่า "หน้าบ้านตรวจสอบบทบาท แต่หลังบ้านไม่ตรวจสอบ" ยังคงเกิดขึ้นซ้ำซ้อนและสร้างความเสียหายมากที่สุดในการทดสอบระบบ
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น