RangeAmp - ชุดของการโจมตี CDN ที่จัดการกับส่วนหัวของ Range HTTP

ทีมนักวิจัย จากมหาวิทยาลัยปักกิ่งมหาวิทยาลัย Tsinghua และมหาวิทยาลัยเท็กซัสที่ดัลลัส ปล่อยข้อมูลเกี่ยวกับ งานของคุณทำเพื่อให้สามารถระบุได้ คลาสใหม่ของการโจมตี DoS ซึ่งพวกเขาตั้งชื่อว่า "RangeAmp" ซึ่งขึ้นอยู่กับการใช้ส่วนหัว Range HTTP เพื่อจัดระเบียบการขยายการรับส่งข้อมูลผ่านเครือข่ายการจัดส่งเนื้อหา (CDN)

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

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

ส่วนหัวของช่วงช่วยให้ไคลเอ็นต์กำหนดช่วงของตำแหน่งในไฟล์ ซึ่งควรโหลดแทนที่จะส่งคืนทั้งไฟล์

ตัวอย่างเช่นไคลเอ็นต์สามารถระบุ "Range: bytes = 0-1023" และเซิร์ฟเวอร์จะส่งเฉพาะข้อมูล 1024 ไบต์แรกเท่านั้น คุณลักษณะนี้เป็นที่ต้องการสูงเมื่อดาวน์โหลดไฟล์ขนาดใหญ่: ผู้ใช้สามารถหยุดการดาวน์โหลดชั่วคราวแล้วดำเนินการต่อจากตำแหน่งที่ถูกขัดจังหวะ เมื่อระบุ "bytes = 0-0" มาตรฐานจะกำหนดให้ไบต์แรกในไฟล์ "bytes = -1" - ตัวสุดท้าย "bytes = 1-" - ตั้งแต่ 1 ไบต์จนถึงจุดสิ้นสุดของไฟล์ คุณสามารถโอนหลายช่วงในส่วนหัวเดียวเช่น "Range: bytes = 0-1023.8192-10240"

นอกจากนี้ มีการเสนอตัวเลือกการโจมตีครั้งที่สอง (เรียกว่าการโจมตี RangeAmp Overlapping Byte Ranges (OBR)ออกแบบมาเพื่อเพิ่มภาระเครือข่าย เมื่อการรับส่งข้อมูลถูกส่งต่อผ่าน CDN อื่นซึ่งใช้เป็นพร็อกซี (ตัวอย่างเช่นเมื่อ Cloudflare ทำหน้าที่เป็นส่วนหน้า (FCDN) และ Akamai ทำหน้าที่เป็นแบ็กเอนด์ (BCDN)) วิธีนี้คล้ายกับการโจมตีครั้งแรก แต่มีการแปลเป็นภาษาท้องถิ่นภายใน CDN และช่วยให้คุณสามารถเพิ่มปริมาณการใช้งานเมื่อเข้าถึงผ่าน CDN อื่น ๆ เพิ่มภาระในโครงสร้างพื้นฐานและลดคุณภาพของบริการ

แนวคิดคือให้ผู้โจมตีส่งหลายช่วงไปยังคำขอช่วง CDN เช่น "bytes = 0-, 0-, 0 - ... ", "bytes = 1-, 0-, 0 - ... " หรือ "ไบต์ = - 1024,0-, 0 - …«.

คำขอมีช่วง "0-" จำนวนมาก ซึ่งหมายถึงการส่งคืนไฟล์ตั้งแต่ต้นจนจบ เนื่องจากการแยกวิเคราะห์ช่วงที่ไม่ถูกต้องเมื่อ CDN แรกอ้างถึงไฟล์ที่สองไฟล์ที่สมบูรณ์จะถูกส่งกลับไปยังแต่ละแบนด์ "0-" (ช่วงจะไม่รวม แต่เรียงลำดับตามลำดับ) หากมีการทำซ้ำและการตัดกันของช่วงในคำขอโจมตีที่ส่งมาครั้งแรก ระดับการขยายการรับส่งข้อมูลในการโจมตีดังกล่าวมีตั้งแต่ 53 ถึง 7432 ครั้ง

การศึกษาได้ตรวจสอบพฤติกรรมของ CDN 13 รายการ ได้แก่ Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath และ Tencent Cloud

"น่าเสียดายที่แม้ว่าเราจะส่งอีเมลถึงพวกเขาหลายครั้งและพยายามติดต่อฝ่ายบริการลูกค้าของพวกเขา แต่ StackPath ก็ไม่ได้ให้ข้อเสนอแนะใด ๆ " ทีมวิจัยกล่าว

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

การตรวจสอบ CDN ทั้งหมดอนุญาตให้มีการโจมตีประเภทแรกบนเซิร์ฟเวอร์เป้าหมาย. การโจมตี CDN เวอร์ชันที่สองกลายเป็นการเปิดเผยกับ 6 บริการซึ่งสี่บริการสามารถทำหน้าที่เป็นอินเทอร์เฟซในการโจมตี (CDN77, CDNsun, Cloudflare และ StackPath) และอีกสามรายการในบทบาทของแบ็คเอนด์ (Akamai, Azure และ StackPath)

ได้รับสูงสุดใน Akamai และ StackPath ซึ่งช่วยให้คุณสามารถระบุตำแหน่งได้มากกว่า 10 อันดับในหัวข้อ Rank

เจ้าของ CDN ได้รับแจ้งเกี่ยวกับ ของช่องโหว่ ประมาณ 7 เดือนที่แล้ว และในช่วงเวลาของการเปิดเผยข้อมูลต่อสาธารณะ CDN 12 ใน 13 แห่งได้แก้ไขปัญหาที่ระบุหรือแสดงความเต็มใจที่จะแก้ไข

Fuente: https://www.liubaojun.org


แสดงความคิดเห็นของคุณ

อีเมล์ของคุณจะไม่ถูกเผยแพร่ ช่องที่ต้องการถูกทำเครื่องหมายด้วย *

*

*

  1. รับผิดชอบข้อมูล: AB Internet Networks 2008 SL
  2. วัตถุประสงค์ของข้อมูล: ควบคุมสแปมการจัดการความคิดเห็น
  3. ถูกต้องตามกฎหมาย: ความยินยอมของคุณ
  4. การสื่อสารข้อมูล: ข้อมูลจะไม่ถูกสื่อสารไปยังบุคคลที่สามยกเว้นตามข้อผูกพันทางกฎหมาย
  5. การจัดเก็บข้อมูล: ฐานข้อมูลที่โฮสต์โดย Occentus Networks (EU)
  6. สิทธิ์: คุณสามารถ จำกัด กู้คืนและลบข้อมูลของคุณได้ตลอดเวลา