ผู้โจมตีอาจเปิดเผยการใช้งาน VPN ที่อาศัยการกำหนดเส้นทางได้

 (leviathansecurity.com)
3 คะแนน โดย GN⁺ 2024-05-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • VPN เป็นเทคโนโลยีที่สร้างอุโมงค์สำหรับทราฟฟิกเครือข่ายระหว่างอุปกรณ์ของผู้ใช้กับเซิร์ฟเวอร์บนเครือข่ายอื่น ส่งผลให้เครือข่ายเสมือนที่สร้างขึ้นทำงานได้เหมือนเครือข่ายจริงโดยไม่ถูกจำกัดด้วยตำแหน่งทางภูมิศาสตร์
  • ไคลเอนต์ VPN ทำหน้าที่สร้างอินเทอร์เฟซเครือข่ายเสมือน เข้ารหัส/ถอดรหัสทราฟฟิก แล้วส่งต่อไปยังอินเทอร์เฟซเครือข่ายจริง
  • VPN ถูกออกแบบมาให้ใช้งานง่ายที่สุดสำหรับผู้ใช้ และโดยทั่วไปแทบไม่ต้องทำอะไรมากไปกว่าการล็อกอินและกดปุ่ม
  • เนื่องจาก VPN ส่งทราฟฟิกเครือข่ายระดับล่างออกสู่อินเทอร์เน็ต จึงทำให้พื้นผิวการโจมตีของโฮสต์เพิ่มขึ้นจริง VPN ห่อหุ้มทราฟฟิก LAN ไว้บนอินเทอร์เน็ต จนเสมือนสร้างเครือข่ายท้องถิ่น (LAN) บนอินเทอร์เน็ตขึ้นมา
  • VPN ใช้มาตรการชดเชย เช่น การเข้ารหัสแพ็กเก็ต เพื่อลดความเสี่ยงจากพื้นผิวการโจมตีของ LAN ที่ขยายออกไป แต่ VPN ไม่ได้ปกป้องผู้ใช้จากการโจมตีเครือข่ายท้องถิ่นบน LAN จริง

DHCP และ DHCP ตัวเลือก 121

  • DHCP เป็นโปรโตคอลที่ใช้จัดสรร IP address แบบไดนามิก และมีตัวเลือกสำหรับปรับแต่งการตั้งค่าอุปกรณ์จากระยะไกล
  • DHCP ตัวเลือก 121 เป็นตัวเลือกที่ช่วยให้ผู้ดูแลระบบเพิ่มเส้นทางแบบคงที่ลงในตาราง routing ของไคลเอนต์ได้
  • คุณสมบัติที่น่าสนใจของ DHCP ตัวเลือก 121 คือเซิร์ฟเวอร์ DHCP ไม่สามารถระบุอุปกรณ์อินเทอร์เฟซเครือข่ายที่จะใช้ติดตั้งเส้นทางได้ แทนที่จะเป็นเช่นนั้น ไคลเอนต์ DHCP จะเลือกโดยนัยว่าอินเทอร์เฟซเครือข่ายที่ใช้สื่อสารกับเซิร์ฟเวอร์ DHCP คืออินเทอร์เฟซที่จะใช้ติดตั้งกฎ routing สำหรับตัวเลือกนี้

เงื่อนไขและขั้นตอนของการโจมตี Decloaking

  • โฮสต์เป้าหมายต้องยอมรับ DHCP lease จากเซิร์ฟเวอร์ DHCP ที่ผู้โจมตีควบคุม
  • ไคลเอนต์ DHCP ของโฮสต์เป้าหมายต้องรองรับ DHCP ตัวเลือก 121
  • ผู้โจมตีรันเซิร์ฟเวอร์ DHCP บนเครือข่ายเดียวกับผู้ใช้ VPN และตั้งค่าตัวเองให้เป็น gateway ในการตั้งค่า DHCP
  • ใช้ DHCP ตัวเลือก 121 เพื่อตั้งค่าเส้นทางในตาราง routing ของผู้ใช้ VPN
  • เมื่อมีการตั้งค่าเส้นทางแล้ว ทราฟฟิกเครือข่ายจะถูกส่งผ่านอินเทอร์เฟซเครือข่ายที่ใช้สื่อสารกับเซิร์ฟเวอร์ DHCP แทนที่จะผ่านอินเทอร์เฟซเสมือนของ VPN
  • ทราฟฟิกจะถูกส่งออกไปนอกอุโมงค์ที่เข้ารหัสของ VPN แต่ช่องทางควบคุมของ VPN ยังคงอยู่ ทำให้ VPN ยังแสดงสถานะว่าเชื่อมต่ออยู่

ระบบที่ได้รับผลกระทบ

  • ระบบปฏิบัติการส่วนใหญ่ เช่น Windows, Linux, iOS, MacOS ที่ติดตั้งไคลเอนต์ DHCP ตามสเปก RFC และรองรับเส้นทางของ DHCP ตัวเลือก 121 ได้รับผลกระทบ (Android ไม่ได้รับผลกระทบเพราะไม่รองรับ DHCP ตัวเลือก 121)
  • VPN ที่อาศัยเพียงกฎ routing เพื่อปกป้องทราฟฟิกของโฮสต์มีความเปราะบาง
  • หากโฮสต์เซิร์ฟเวอร์ VPN เอง ก็อาจมีความเสี่ยงหากไม่ได้เพิ่มความเข้มงวดให้การตั้งค่าไคลเอนต์ VPN
  • ได้รับผลกระทบโดยไม่ขึ้นกับโปรโตคอล VPN พื้นฐาน (WireGuard, OpenVPN, IPsec เป็นต้น) เพราะเป็นการกำหนดค่าใหม่ให้กับ OS network stack ที่ VPN พึ่งพาอยู่

แนวทางบรรเทาและข้อจำกัด

  • การใช้ network namespace ของ Linux สามารถแก้ปัญหานี้ได้อย่างสมบูรณ์ แต่โดยทั่วไปยังไม่มีการนำไปใช้อย่างแพร่หลาย
  • พบว่าผู้ให้บริการ VPN บางรายใช้กฎไฟร์วอลล์เพื่อบล็อกทราฟฟิกขาเข้า/ขาออกบนอินเทอร์เฟซจริง แต่เป็นเพียงมาตรการบรรเทาบางส่วน
  • การเพิกเฉยต่อ DHCP ตัวเลือก 121 ก็เป็นอีกแนวทางหนึ่ง แต่มีความเสี่ยงที่การเชื่อมต่อเครือข่ายจะหลุด
  • การใช้ hotspot หรือ VM อาจช่วยได้ เพราะทำให้ผู้โจมตีเข้าถึงเครือข่ายท้องถิ่นได้ยากขึ้น
  • หากต้องการความลับของทราฟฟิกแบบสูงสุด การหลีกเลี่ยงการใช้เครือข่ายที่ไม่น่าเชื่อถือคือแนวป้องกันที่ดีที่สุด

ความเห็นของ GN⁺

  • เนื่องจาก VPN ไม่ได้ถูกออกแบบมาเพื่อบรรเทาการโจมตี LAN บนเครือข่ายจริง คำกล่าวทางการตลาดของผู้ให้บริการ VPN ที่อ้างว่า VPN ปกป้องลูกค้าบนเครือข่ายที่ไม่น่าเชื่อถือจึงอาจเป็นเรื่องอันตราย ผู้ให้บริการ VPN ควรจัดทำเอกสารสาธารณะเกี่ยวกับแนวทางบรรเทาหรือการแก้ไขสำหรับ TunnelVision และแจ้งให้ผู้ใช้ทราบ
  • VPN สำหรับองค์กรถูกใช้งานบ่อยในร้านกาแฟ โรงแรม สนามบิน ฯลฯ ดังนั้นผู้ดูแลเครือข่ายควรแจ้งพนักงานถึงความเสี่ยงของการทำงานในสถานที่เหล่านี้และแนะนำให้หลีกเลี่ยงเท่าที่ทำได้ นอกจากนี้ควรใช้โปรโตคอลเข้ารหัส เช่น HTTPS กับทรัพยากรภายใน เพื่อป้องกันข้อมูลรั่วไหลจากผู้ใช้ VPN ที่เชื่อมต่อผ่านเครือข่ายที่ไม่น่าเชื่อถือ
  • เนื่องจากทราฟฟิกอินเทอร์เน็ตส่วนใหญ่ได้รับการปกป้องด้วย HTTPS แม้ VPN จะถูกทำให้ไร้ผล ข้อมูลผู้ใช้ส่วนใหญ่ก็มักจะไม่ถูกเปิดเผยต่อผู้โจมตีบนเครือข่ายท้องถิ่น แต่ทราฟฟิกที่มีความอ่อนไหวยังคงต้องมีการเตือน
  • ผู้ดูแลรักษา OS นอกเหนือจาก Linux ควรตรวจสอบว่าสามารถเพิ่มหรือปรับปรุงความสามารถที่เกี่ยวข้องกับ network namespace ได้หรือไม่
  • แม้จะไม่ได้ละเมิดคุณสมบัติด้านความปลอดภัยของเทคโนโลยี VPN เอง แต่ก็ขัดแย้งกับสิ่งที่ผู้ให้บริการ VPN รับประกัน จึงอาจถือเป็นช่องโหว่ได้ นักวิจัยคาดว่าเทคนิคนี้น่าจะใช้ได้มาตั้งแต่ปี 2002 และตัดสินใจเผยแพร่ผลการวิจัยเพื่อแจ้งให้ผู้มีส่วนเกี่ยวข้องรับทราบอย่างกว้างขวาง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-07
ความเห็นจาก Hacker News

สรุป:

  • การโจมตีนี้คล้ายกับการโจมตี "Poison Tap" ของ Samy Kamkar ในปี 2016 โดยใช้อะแดปเตอร์เครือข่าย USB/Thunderbolt เพื่อประกาศเส้นทางที่เฉพาะเจาะจงกว่าสองเส้นทาง และดักจับทราฟฟิกทั้งหมดโดยให้มีลำดับความสำคัญเหนืออินเทอร์เฟซอื่นของระบบ
  • พาดหัวระบุว่าส่งผลกระทบต่อไคลเอนต์ VPN ทุกตัว แต่ไคลเอนต์จำนวนมากตั้งค่ากฎไฟร์วอลล์เพื่อบล็อกทราฟฟิกกับอินเทอร์เฟซทางกายภาพ การจัดทำเอกสารว่าสัดส่วนของโซลูชัน VPN ส่วนบุคคล/เชิงพาณิชย์และระดับองค์กรรายใหญ่ที่เปิดใช้ฟีเจอร์นี้เป็นค่าเริ่มต้นมีมากน้อยเพียงใด น่าจะเป็นประโยชน์มากกว่า
  • เมื่อใช้ DHCP option 121 เซิร์ฟเวอร์ DHCP สามารถตั้งกฎการกำหนดเส้นทางสำหรับช่วง CIDR ที่ระบุได้ ซึ่งจะมีลำดับความสำคัญสูงกว่ากฎเริ่มต้น 0.0.0.0/0 เพราะมี prefix ที่ยาวกว่า
  • "การโจมตี" นี้คือการใช้ DHCP option 121 อย่างชาญฉลาด หากต้องการแยกอย่างถูกต้อง ควรใช้ policy-based routing ที่เหมาะสม (เช่น Linux network namespaces, FreeBSD vnet, OpenBSD rdomains)
  • บน Linux สามารถบรรเทาปัญหานี้ได้โดยนำอินเทอร์เฟซ VPN ไปไว้ใน VRF ซึ่ง systemd-networkd รองรับสิ่งนี้อยู่แล้ว
  • แบบจำลองภัยคุกคามที่ผู้โจมตีสามารถกลายเป็นเซิร์ฟเวอร์ DHCP บน LAN ได้ อาจมีโอกาสไม่สูง แต่ก็ไม่ใช่ว่าเป็นไปไม่ได้
  • สถาปัตยกรรมที่อิงกับ virtual machine ก็สามารถแก้ปัญหานี้ได้เช่นกัน QubesOS ทำให้การกำหนดค่าลักษณะคล้ายกันนี้ทำได้ง่ายมาก
  • ทางเลือกที่น่าสนใจสำหรับ network namespaces คือการข้าม kernel networking ทั้งหมดและใช้ user-space network stack
  • สิ่งที่น่ากังวลกว่าคือการใช้บริการ VPN ที่รองรับเฉพาะ IPv4 ขณะเดียวกันก็เปิดใช้งาน IPv6 บนระบบ ซึ่งอาจก่อให้เกิดปัญหาร้ายแรงได้