การแฮ็ก CSRF Tokens โดยใช้ CSS History Hack

ปรับปรุง: นักวิจัยด้านความปลอดภัย Sirdarckcat และ Gareth ใจดีพอที่จะแบ่งปันรหัสสำหรับ CSS token finder ที่ใช้ CSS บริสุทธิ์ นี่คือ stealthier กว่า PoC ของฉันด้านล่างซึ่งใช้ทั้ง JS และ CSS ดังนั้นมันจะยังคงทำงานแม้ว่าคุณจะปิดการใช้งานจาวาสคริปต์และคุณจะไม่ปลอดภัยอีกต่อไป :(:( . ในการทำให้ PoC นี้ตอบสนองต่อไคลเอนต์ได้ดีขึ้นคุณต้องใช้หลาย CSS สไตล์ชีตโดยใช้คำสั่งนำเข้า ปัญหาเดียวที่ฉันเห็นด้วยวิธีการตาม CSS บริสุทธิ์นี้คือจะมีเวลาแฝงเครือข่ายที่เกี่ยวข้องกับพื้นที่คีย์ขนาดใหญ่เพราะสไตล์ชีต CSS ขนาดใหญ่ของคุณจะต้องดาวน์โหลดโดยเบราว์เซอร์ของคุณ.


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

ในตอนนี้มันถูกพิจารณาว่าเป็นไปไม่ได้ที่ผู้โจมตีจะค้นพบโทเค็น CSRF ของคุณโดยใช้ Brute Force Attacks บนเซิร์ฟเวอร์.

เหตุผลที่เป็น:

  1. มันสร้าง มีเสียงรบกวนมากมายบนเครือข่ายและช้า. ดังนั้นส่วนใหญ่อาจเป็น IDS หรือ Web App Firewall จะรับพฤติกรรมที่เป็นอันตรายและบล็อก ip ของคุณ ตัวอย่างเช่นโทเค็น Base16 CSRF ที่มีความยาว 5 ตัวอักษร (เริ่มต้นด้วยตัวอักษร) จะสร้างคำขอประมาณ 393,216 รายการ.
  2. แอปพลิเคชั่นหลายตัวถูกตั้งโปรแกรมให้ ทำให้เซสชั่นของคุณไม่ถูกต้อง หลังจากตรวจพบมากกว่าจำนวนคำขอที่มีค่าโทเค็นไม่ถูกต้อง เช่น. 30.

ฉันจะเปลี่ยนความเชื่อนี้โดยแสดงเทคนิคเพื่อค้นหาโทเค็น csrf อย่างรวดเร็วโดยไม่สร้างการเตือน เทคนิคนี้คือ การโจมตีฝั่งไคลเอ็นต์, ดังนั้นแทบจะไม่มีการสร้างทราฟฟิกเครือข่ายและด้วยเหตุนี้เซิร์ฟเวอร์และไฟร์วอลล์ IDS / Web App ของคุณจึงชนะ’ไม่แจ้งให้ทราบเลย การโจมตีนี้ขึ้นอยู่กับการแฮ็ค CSS History ยอดนิยมที่พบโดย Jeremiah Grossman เมื่อ 3 ปีที่แล้ว.

ในการหาประโยชน์นี้เราค้นพบโทเค็น csrf ด้วยการเดรัจฉานบังคับ url ชุดต่าง ๆ ในประวัติเบราว์เซอร์ เราจะพยายามฝังค่าโทเค็น csrf ที่แตกต่างกันเป็นส่วนหนึ่งของ url และตรวจสอบว่าผู้ใช้ได้เยี่ยมชม url นั้นหรือไม่ ถ้าใช่มีโอกาสที่ดีที่ผู้ใช้อาจใช้โทเค็น CSRF เดียวกันในเซสชันที่ใช้งานอยู่ในปัจจุบันหรืออาจใช้โทเค็นนั้นในเซสชันก่อนหน้า เมื่อเรามีรายการของโทเค็นดังกล่าวทั้งหมดเราสามารถลองโจมตี csrf ของเราบนเซิร์ฟเวอร์โดยใช้รายการเล็ก ๆ นั้น ปัจจุบันการโจมตีนี้เป็นไปได้สำหรับโทเค็นที่มีความยาว 5 ตัวอักษรหรือสั้นกว่า ฉันลองบนสตริง 16 ฐานยาว 5 และสามารถบังคับพื้นที่คีย์ทั้งหมดได้ในเวลาไม่ถึง 2 นาที.

ข้อกำหนดเบื้องต้นบางอย่างสำหรับการโจมตีนี้เพื่อทำงาน

  1. โทเค็น CSRF ยังคงเหมือนเดิมสำหรับเซสชันผู้ใช้เฉพาะ เช่น. csrf token = hash (session_id) หรือ
  2. CSRF โทเค็นที่ส่งในแบบฟอร์มที่เก่ากว่าสำหรับเซสชันเดียวกันนั้นได้รับการยอมรับ หลายครั้งนี่เป็นกรณีที่ช่วยเพิ่มประสบการณ์ผู้ใช้และอนุญาตให้ใช้ปุ่มเบราว์เซอร์ไปข้างหน้าและย้อนกลับ.

พิสูจน์แนวคิด มีอยู่ที่นี่.
ก่อนเรียกใช้ PoC คุณต้องเปลี่ยนค่าพารามิเตอร์ url และ csrftoken.

สำหรับการทดสอบโดยใช้ค่าเริ่มต้นคุณต้องไปที่ URL ใดรายการหนึ่งต่อไปนี้ก่อนเช่น.

  1. https://securethoughts.com/?param1=val1&csrftoken = b59fe [เปลี่ยน b59fe เป็นสตริง 16 ฐาน 5 หลักใด ๆ ที่ขึ้นต้นด้วยตัวอักษร i.e.greater กว่า a0000]
  2. http://tinyurl.com/l2lwgd [ซึ่งเป็น 301 เปลี่ยนเส้นทางไปยัง URL ก่อนหน้านี้].

บันทึก: http://www.secure Thoughts.com และ https://secure Thoughts.com นั้นได้รับการปฏิบัติต่างกันในขณะที่จัดเก็บในประวัติเบราว์เซอร์.

การรันตัวอย่างจะมีลักษณะเช่นนี้ -

โทเค็นการแฮ็ก csrf โดยใช้การแฮ็คประวัติ cssโทเค็นการแฮ็ก csrf โดยใช้การแฮ็คประวัติ css

สำหรับการโจมตีครั้งนี้ทำไม่ได้,

โซลูชันฝั่งเซิร์ฟเวอร์ (สำหรับนักพัฒนา):

  • ทำให้ CSRF โทเค็นของคุณยาวพอ (8 ตัวอักษรหรือมากกว่า) เพื่อให้ไม่สามารถทำการโจมตีฝั่งลูกค้าได้ พลังการประมวลผลที่เพิ่มมากขึ้นจะทำให้การโจมตีนี้เป็นไปได้สำหรับโทเค็นที่ยาวขึ้นเช่นกัน.
  • เก็บโทเค็น CSRF ของคุณเป็นส่วนหนึ่งของเขตข้อมูลฟอร์มที่ซ่อนอยู่แทนที่จะใส่ใน URL.
  • ใช้โทเค็นแบบสุ่มที่แตกต่างกันสำหรับการส่งแบบฟอร์มทุกครั้งและไม่ยอมรับโทเค็นที่ล้าสมัยใด ๆ แม้แต่ในเซสชันเดียวกัน.

โซลูชันฝั่งไคลเอ็นต์ (สำหรับลูกค้า / ผู้ใช้ของคุณ):

  • ใช้ปลั๊กอินของเบราว์เซอร์เช่น SafeHistory ซึ่งป้องกันจากเทคนิคการติดตามบนลิงก์ที่เยี่ยมชม.
  • ใช้โหมดการเบราส์ส่วนตัวในเบราว์เซอร์ของคุณ.

และสุดท้าย แต่ไม่ใช่อย่างน้อยที่สุด XSS กำจัดการปกป้อง CSRF ที่เป็นไปได้ทั้งหมด ดังนั้นกำจัด XSS ก่อน.

ฉันขอขอบคุณเยเรมีย์ที่ให้ข้อเสนอแนะที่ลึกซึ้งเกี่ยวกับโพสต์นี้

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me