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

 (leviathansecurity.com)
3 คะแนน โดย GN⁺ 2024-05-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • TunnelVision(CVE-2024-3661) ใช้ฟีเจอร์เดิมของ DHCP ในทางที่ผิดเพื่อบังคับให้ทราฟฟิกของผู้ใช้อ้อมออกไปนอกอุโมงค์ VPN โดยแพ็กเก็ตจะไม่ถูกเข้ารหัสผ่าน VPN
  • ผู้โจมตีสามารถใช้ DHCP option 121 แทรกเส้นทางที่เจาะจงกว่า เพื่อสร้างเส้นทางที่มีลำดับความสำคัญเหนือกว่าอินเทอร์เฟซเสมือนของ VPN และส่งทราฟฟิกออกทางอินเทอร์เฟซจริงได้
  • การโจมตีทำได้เมื่อเป้าหมายยอมรับ lease ของ DHCP ที่ผู้โจมตีควบคุม และไคลเอนต์รองรับ option 121; ในการทดสอบ Windows, Linux, iOS, macOS ได้รับผลกระทบ ส่วน Android ไม่ได้รับผลกระทบ
  • ช่องทางควบคุมของ VPN ยังคงเชื่อมต่ออยู่ ผู้ใช้จึงเห็นว่ายังเชื่อมต่ออยู่ และในกรณีที่สังเกตพบ kill switch ก็ไม่สามารถหยุดการรั่วไหลของทราฟฟิกได้
  • network namespace บน Linux อาจเป็นวิธีแก้ที่แข็งแรง แต่การบรรเทาด้วยไฟร์วอลล์อาจทำให้เกิดการปฏิเสธบริการแบบเลือกได้และ side channel สำหรับอนุมานปลายทางของทราฟฟิก

การ decloaking VPN ที่ TunnelVision สร้างขึ้น

  • TunnelVision เป็น เทคนิคเครือข่าย ที่เลี่ยงการห่อหุ้มของ VPN และบังคับให้ทราฟฟิกของผู้ใช้ออกไปนอกอุโมงค์
  • ผู้โจมตีสามารถใช้ DHCP(Dynamic Host Configuration Protocol) ทำให้แพ็กเก็ตของเป้าหมายถูกส่งออกไปโดยไม่ได้เข้ารหัสผ่าน VPN
  • ช่องทางควบคุมของ VPN ยังคงอยู่ ผู้ใช้จึงดูเหมือนว่ายังเชื่อมต่อกับ VPN อยู่ และผลลัพธ์นี้เรียกว่า decloaking
  • เทคนิคนี้อาจเป็นไปได้ย้อนหลังไปถึงปี 2002 และหลังการเปิดเผย มีการยืนยันข้อมูลว่างานวิจัยก่อนหน้าที่เกี่ยวกับ DHCP option 121 และผลกระทบต่อ VPN มีอย่างน้อยตั้งแต่ปี 2015

เหตุใดการกำหนดเส้นทางของ VPN จึงกลายเป็นพื้นผิวโจมตี

  • VPN สร้าง อุโมงค์ สำหรับทราฟฟิกระหว่างอุปกรณ์โฮสต์กับเซิร์ฟเวอร์ในเครือข่ายอื่น และไคลเอนต์ VPN จะเข้ารหัส·ถอดรหัสทราฟฟิกบนอินเทอร์เฟซเครือข่ายเสมือน
  • การตั้งค่าที่ส่งทราฟฟิกทั้งหมดผ่าน VPN เรียกว่า full-tunnel VPN ส่วนการตั้งค่าที่มีข้อยกเว้น เช่น เครือข่ายท้องถิ่น เรียกว่า split-tunnel VPN
  • VPN ต้องรักษาการเชื่อมต่อกับเซิร์ฟเวอร์ไว้ จึงต้องมีเส้นทางยกเว้นที่ส่งทราฟฟิกไปยัง IP ของเซิร์ฟเวอร์ VPN ผ่านอินเทอร์เฟซจริง
  • ตาราง routing กำหนดเส้นทางของทราฟฟิกตามปลายทาง และใน network stack ส่วนใหญ่ CIDR prefix length ที่เจาะจงกว่าจะมีลำดับความสำคัญสูงกว่า
    • route /32 มีลำดับความสำคัญเหนือกว่า /24 หรือ /0
    • full-tunnel VPN จำนวนมากส่งทราฟฟิกไปยังอินเทอร์เฟซ VPN ด้วย 0.0.0.0/0 หรือ route /1 สองรายการ

การแทรกเส้นทางด้วย DHCP option 121

  • DHCP มอบ lease ของที่อยู่ IP ให้กับอุปกรณ์ในเครือข่ายท้องถิ่นแบบไดนามิก และยังส่งการตั้งค่าอย่าง default gateway และ DNS server ผ่าน options ด้วย
  • โฟลว์ทั่วไปคือไคลเอนต์ broadcast DHCPDISCOVER และเซิร์ฟเวอร์เสนอ lease ที่มีเวลาจำกัดด้วย DHCPOFFER
  • DHCP option 121 ที่ถูกนำเข้ามาใน RFC 3442 เป็นฟีเจอร์ classless static routes ซึ่งทำให้เซิร์ฟเวอร์ DHCP เพิ่ม static route ลงในตาราง routing ของไคลเอนต์ได้
  • option 121 ไม่สามารถให้เซิร์ฟเวอร์ DHCP ระบุอุปกรณ์อินเทอร์เฟซเครือข่ายของ route ที่จะติดตั้งได้โดยตรง
    • เซิร์ฟเวอร์ DHCP ระบุช่วง CIDR และ router
    • ไคลเอนต์จะเลือกอินเทอร์เฟซที่กำลังสื่อสารกับเซิร์ฟเวอร์ DHCP โดยนัยให้เป็นอินเทอร์เฟซของ route นั้น
  • จากพฤติกรรมนี้ ทราฟฟิกของ route ที่ถูกแทรกอาจออกทาง อินเทอร์เฟซเครือข่ายจริง ที่สื่อสารกับเซิร์ฟเวอร์ DHCP แทนที่จะเป็นอินเทอร์เฟซเสมือนของ VPN

เงื่อนไขและวิธีดำเนินการโจมตี

  • การโจมตี TunnelVision ต้องมีเงื่อนไขสองข้อ
    • โฮสต์เป้าหมายต้องยอมรับ lease จากเซิร์ฟเวอร์ DHCP ที่ผู้โจมตีควบคุม
    • DHCP client ของโฮสต์เป้าหมายต้องรองรับ DHCP option 121
  • ผู้โจมตีที่อยู่ในเครือข่ายเดียวกันสามารถกลายเป็นเซิร์ฟเวอร์ DHCP ของเป้าหมายได้หลายวิธี
    • ทำ DHCP starvation attack กับเซิร์ฟเวอร์ DHCP จริง แล้วตอบกลับไคลเอนต์ใหม่
    • ตอบ DHCPDISCOVER broadcast ก่อน เพื่อใช้ประโยชน์จากพฤติกรรมของ DHCP client ที่เลือกข้อเสนอแรก
    • ใช้ ARP spoofing ดักทราฟฟิกระหว่างเซิร์ฟเวอร์ DHCP จริงกับไคลเอนต์ แล้วรอการต่ออายุ lease
  • ผู้โจมตีรันเซิร์ฟเวอร์ DHCP บนเครือข่ายเดียวกับผู้ใช้ VPN เป้าหมาย และตั้งตัวเองเป็น gateway
  • จากนั้นใช้ DHCP option 121 เพิ่ม route ตามต้องการลงในตาราง routing ของผู้ใช้ VPN และใส่ route ที่เจาะจงกว่า /0 ของ VPN เพื่อให้มีลำดับความสำคัญเหนือกว่าอินเทอร์เฟซเสมือนของ VPN
    • สามารถตั้ง route /1 หลายรายการเพื่อจำลองกฎทราฟฟิกทั้งหมด 0.0.0.0/0 ที่ VPN ส่วนใหญ่ใช้
    • ผู้โจมตีเลือกได้ว่า IP address ใดจะไปทางอุโมงค์ VPN และ address ใดจะไปทางอินเทอร์เฟซที่สื่อสารกับเซิร์ฟเวอร์ DHCP ของผู้โจมตี
  • ใช้ได้แม้กับการเชื่อมต่อ VPN ที่ตั้งค่าไว้แล้ว และหากตั้งเวลา lease ของ DHCP ให้สั้น ก็สามารถกระตุ้นให้ตาราง routing อัปเดตบ่อยขึ้นได้

PoC และสถานการณ์ทดลอง

  • เอกสารที่เผยแพร่มีดังนี้
  • สภาพแวดล้อมทดลองถูกจัดทำเพื่อแทนสถานการณ์โจมตีหลายแบบ
    • กรณีผู้โจมตีเจาะเซิร์ฟเวอร์ DHCP หรือ access point ได้
    • กรณีผู้ดูแลระบบที่ประสงค์ร้ายเป็นเจ้าของและตั้งค่าโครงสร้างพื้นฐานเอง
    • กรณีผู้โจมตีติดตั้ง wireless AP แบบ evil twin ในสถานที่จริง เช่น คาเฟ่หรือสำนักงาน
    • หลังจาก ArcaneTrickster ถูกเผยแพร่ในอนาคต จะสามารถจำลองผู้โจมตีที่เป็นโฮสต์ข้างเคียงใน LAN เดียวกัน แต่ไม่ได้อยู่ในตำแหน่งเครือข่ายที่มีสิทธิพิเศษได้ด้วย

ระบบปฏิบัติการและ VPN ที่ได้รับผลกระทบ

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

การแก้ไขและแนวทางบรรเทา

  • network namespace บน Linux สามารถแก้พฤติกรรมนี้ได้อย่างสมบูรณ์
    • เอกสาร WireGuard แสดงวิธีประมวลผลทราฟฟิกของแอปพลิเคชันที่ต้องใช้ VPN ใน namespace แยกต่างหาก แล้วส่งต่อไปยัง namespace อื่นที่มีอินเทอร์เฟซจริง
    • ยังไม่ชัดเจนว่า Windows, macOS และระบบปฏิบัติการอื่นมีวิธีแก้ที่แข็งแรงในระดับเดียวกันหรือไม่
  • ผู้ให้บริการ VPN บางรายใช้การบรรเทาโดยบล็อกทราฟฟิกขาเข้า·ขาออกทั้งหมดของอินเทอร์เฟซจริงด้วยกฎไฟร์วอลล์
    • ต้องมีข้อยกเว้นสำหรับ DHCP และ IP ของเซิร์ฟเวอร์ VPN เพื่อคงการเชื่อมต่อกับ LAN และเซิร์ฟเวอร์ VPN ไว้
    • อาจอนุญาตเฉพาะ DHCP และโปรโตคอล VPN ด้วย deep packet inspection ได้ แต่มีแนวโน้มว่าจะมีผลเสียต่อประสิทธิภาพ
  • การบรรเทาด้วยไฟร์วอลล์สร้าง การปฏิเสธบริการแบบเลือกได้ ต่อทราฟฟิกที่ใช้ DHCP route และเพิ่ม side channel
    • ผู้โจมตีสามารถวิเคราะห์การเปลี่ยนแปลงของปริมาณทราฟฟิก VPN ที่เข้ารหัส เพื่อพิสูจน์ทางสถิติได้ว่าผู้ใช้เป้าหมายส่งทราฟฟิกไปยังปลายทางใดปลายทางหนึ่งหรือไม่
    • สามารถเทียบกับรายการที่กำหนดไว้ล่วงหน้า ใช้การบล็อกแบบเลือกได้เป็นกลไกเซ็นเซอร์ หรือใช้การบล็อกพื้นที่ IP คล้าย binary search เพื่อค้นหาการเชื่อมต่อปัจจุบันในเวลาแบบลอการิทึมได้
  • อีกวิธีคือเพิกเฉย option 121 ขณะใช้ VPN แต่ฟีเจอร์นี้อาจจำเป็นสำหรับการเชื่อมต่อเครือข่ายที่ถูกต้องตามปกติ จึงอาจทำให้เชื่อมต่อไม่ได้
    • หากการบรรเทานี้เป็นตัวเลือก ผู้โจมตีอาจปฏิเสธการเข้าถึงเครือข่ายเพื่อชักจูงให้ VPN หรือผู้ใช้เปิด option 121 กลับมาอีกครั้ง
  • hotspot หรือ VM ก็ช่วยบรรเทาได้เช่นกัน
    • LAN ที่ล็อกด้วยรหัสผ่านและควบคุมโดยอุปกรณ์เซลลูลาร์ช่วยป้องกันไม่ให้ผู้โจมตีเข้าถึงเครือข่ายท้องถิ่นได้
    • VM จะทำงานคล้ายกันหาก network adapter ไม่ได้อยู่ใน bridged mode

สิ่งที่ผู้ใช้และผู้ดูแลระบบควรทำ

  • สำหรับทราฟฟิกที่อ่อนไหว ควรหลีกเลี่ยงการใช้เครือข่ายที่ไม่น่าเชื่อถือ และหากหลีกเลี่ยงไม่ได้ ควรใช้ผู้ให้บริการ VPN ที่มีมาตรการบรรเทาที่มีผลต่อ TunnelVision
  • แม้เกิด VPN decloak ขึ้น เมื่อเข้าถึงเว็บไซต์ HTTPS ข้อมูลผู้ใช้ส่วนใหญ่จะไม่ปรากฏต่อผู้โจมตีในเครือข่ายท้องถิ่น แต่ ปลายทางและโปรโตคอล อาจถูกเปิดเผยได้
  • หากใช้ VPN ขององค์กรในคาเฟ่ โรงแรม สนามบิน ฯลฯ ผู้ดูแลเครือข่ายควรแจ้งความเสี่ยงและแนะนำให้หลีกเลี่ยงเท่าที่ทำได้
    • หากไม่สามารถทำได้จริง ควรแนะนำให้ใช้ VPN ที่มีการบรรเทาหรือการแก้ไขแล้ว
    • อีกวิธีคือใช้ hotspot ที่เชื่อถือได้แล้วค่อยเชื่อมต่อ VPN หรือรัน VPN ภายใน VM ที่รับ lease จากเซิร์ฟเวอร์ DHCP เสมือน
  • บริษัทที่ดูแลเครือข่ายของตนเองหรือ site-to-site VPN ควรตรวจสอบสวิตช์และเปิดใช้การป้องกัน Layer 2 เช่น DHCP snooping และการป้องกัน ARP
    • การป้องกันเหล่านี้ช่วยลด rogue DHCP server ได้ แต่ไม่สามารถกำจัดสถานการณ์ผู้ดูแลระบบประสงค์ร้ายได้
    • การใช้ HTTPS หรือโปรโตคอลเข้ารหัสอื่นกับทรัพยากรภายในช่วยป้องกันข้อมูลรั่วของผู้ใช้ VPN ที่เชื่อมต่อจากเครือข่ายที่ไม่น่าเชื่อถือ
  • ผู้ให้บริการ VPN สามารถเพิ่มฟีเจอร์ไฟร์วอลล์ในไคลเอนต์เพื่อบล็อกแพ็กเก็ตขาออกที่ออกทางอินเทอร์เฟซเครือข่ายได้ แต่ผู้ใช้จะไม่สามารถโต้ตอบกับทรัพยากรในเครือข่ายท้องถิ่นได้
  • full-tunnel VPN client สำหรับ Linux ควรพิจารณาการแยกด้วย network namespace
  • ผู้ดูแลรักษาระบบปฏิบัติการควรพิจารณาเพิ่มหรือเสริมความสามารถที่เกี่ยวข้องกับ network namespace ในระบบปฏิบัติการอื่นนอกเหนือจาก Linux
  • กำลังมีการพัฒนาไลบรารี adversarial infrastructure ชื่อ ArcaneTrickster สำหรับการวิจัยความปลอดภัย LAN และการสาธิตการโจมตีจริง และมีแผนจะเผยแพร่ในภายหลัง

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

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

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

  • นี่เป็นการดัดแปลงเล็กน้อยจากการโจมตี PoisonTap ของ Samy Kamkar ในปี 2016 ทำสิ่งเดียวกันได้ด้วยอะแดปเตอร์เครือข่าย USB/Thunderbolt โดยเสียบเข้ากับอุปกรณ์ของเหยื่อ แล้วประกาศเส้นทางที่เฉพาะเจาะจงกว่า 2 เส้นทาง เช่น 0.0.0.0/1 และ 128.0.0.0/1 ก็จะสามารถมีลำดับความสำคัญเหนือกว่าอินเทอร์เฟซระบบอื่น ๆ โดยไม่ขึ้นกับลำดับอินเทอร์เฟซ และดึงทราฟฟิกทั้งหมดไปได้: https://github.com/samyk/poisontap
    น่าจะมีกรณีก่อนหน้ากรณีอื่น ๆ ด้วย แต่นี่เป็นตัวอย่างที่รู้จักกันดีมาก แม้หัวข้อบทความจะบอกว่าไคลเอนต์ VPN ทั้งหมดได้รับผลกระทบ แต่ตามที่เนื้อหายอมรับเอง ไคลเอนต์ VPN จำนวนมากตั้งกฎไฟร์วอลล์เพื่อบล็อกทราฟฟิกที่เข้าออกผ่านอินเทอร์เฟซกายภาพ
    VPN ที่ชูเรื่องการปกปิดตัวตน หรือที่การปกปิดเช่นนั้นมีความสำคัญ มักจะมีการทำสิ่งนี้อยู่แล้ว แม้คงมีหลายการตั้งค่าที่ไม่ได้เปิดเป็นค่าเริ่มต้น แต่ถ้ามีการจัดทำเอกสารว่าโซลูชัน VPN หลัก ๆ สำหรับบุคคล/เชิงพาณิชย์/องค์กร มีกี่เปอร์เซ็นต์ที่เปิดสิ่งนี้เป็นค่าเริ่มต้น น่าจะเป็นประโยชน์กว่านี้
    คำอธิบายสำหรับผู้อ่านทั่วไปถือว่าดี แต่เมื่อมีไคลเอนต์จำนวนมากที่ป้องกันการรั่วไหลของข้อมูลส่วนใหญ่ได้ด้วยกฎไฟร์วอลล์ลักษณะนี้ และบทความไม่ยอมรับงานก่อนหน้าในสาขานี้ หัวข้อจึงดูเกินจริงไปหน่อย

    • ชี้ได้ถูกแล้ว ถ้าไม่นับ VPN ที่อาจรั่วไปมากอยู่แล้วเพราะไม่มีแม้แต่ กฎไฟร์วอลล์ พื้นฐาน นี่ก็ไม่ใช่ช่องโหว่อะไรมาก
      ตอนเห็นคำว่า “การโจมตีผ่านช่องทางข้างเคียง” ผมแทบพ่นเครื่องดื่มออกมา
      แก้ไข: ดูเหมือนว่าอย่างน้อยบน mac นั้น NordVPN ไม่มีกฎไฟร์วอลล์พื้นฐานแบบนั้น จึงน่าจะเสี่ยงต่อการโจมตีนี้

  • ไม่เข้าใจว่าทำไมบทความนี้ถึงยาวขนาดนี้
    DHCP Option 121 อนุญาตให้เซิร์ฟเวอร์ DHCP ตั้งกฎ routing สำหรับช่วง CIDR ที่กำหนดได้ และเพราะมี prefix ที่ยาวกว่า จึงมีลำดับความสำคัญสูงกว่ากฎพื้นฐาน 0.0.0.0/0

    • ผมเป็นหนึ่งในผู้เขียนบทความนี้ ตั้งใจจะอธิบายหัวข้อที่เกี่ยวข้องก่อน เพราะคิดว่าจะมีผู้อ่านที่ไม่ใช่สายเทคนิคเข้ามาด้วย
      ข้อมูลเกี่ยวกับ VPN บนอินเทอร์เน็ตครึ่งหนึ่งเขียนโดยผู้ให้บริการ VPN และมักไม่ถูกต้องหรือไม่ลงรายละเอียดทางเทคนิคพอที่จะอธิบายว่ามันทำงานจริงอย่างไร
      ตั้งใจจะใส่ประโยคในบทนำเป็นลิงก์ว่า “ถ้ารู้อยู่แล้ว ให้ข้ามไปยังส่วน POC” แต่จะอัปเดตให้เห็นชัดขึ้น
    • และถ้าผู้โจมตีจะก่อการโจมตีนี้ ก็ต้องอยู่ใน เครือข่ายเลเยอร์ 2 เดียวกับเหยื่อ
      เดาจากคอมเมนต์ข้างบนเท่านั้น ยังไม่ได้อ่านบทความ

  • ผมเหมือนเคยอ่านเรื่องการโจมตีนี้จากผู้เขียนคนอื่นมาก่อน เลยลองค้นดู และฝ่ากองสแปมจากบริษัท VPN ในผลการค้นหา จนเจองานก่อนหน้า [1]
    บทความนี้ลงลึกกว่าในวิธีใช้ประโยชน์จากข้อบกพร่อง และมีโค้ดที่ช่วยทำ proof of concept ด้วย
    1: https://www.usenix.org/conference/usenixsecurity23/presentat...

    • บทความอ้างถึงเปเปอร์นั้นไว้ในภาคผนวก
      อย่างไรก็ตาม เทคนิคทั้งสองในเปเปอร์เดือนสิงหาคม 2023 ไม่ได้ push เส้นทางด้วย DHCP option 121 การ push เส้นทางผ่าน DHCP ทำให้ผลกระทบมากขึ้นมากจากตำแหน่งผู้โจมตีเดียวกัน เช่น ตำแหน่งที่แจก lease IP ในช่วงที่ไม่ใช่ RFC1918 หรือปลอมแปลงคำตอบ DNS ได้
    • “การโจมตี” นี้เป็นที่รู้จักกันกว้างขวาง และยังถูกใช้ผ่านออปชันการตั้งค่าของไคลเอนต์ OpenVPN อย่าง redirect-gateway def1 ด้วย

  • threat model คือผู้โจมตีรายใดก็ได้สามารถกลายเป็น เซิร์ฟเวอร์ DHCP ใน LAN ของผมได้ไม่ทางใดก็ทางหนึ่ง ซึ่งโอกาสต่ำแต่ก็ไม่ใช่เป็นไปไม่ได้
    ในทางกลับกัน ถ้าใช้เกตเวย์ที่ ISP ให้มา เรื่องก็เปลี่ยนไป

    • ถ้าหมายถึง “ผู้โจมตีรายใดก็ได้กลายเป็นเซิร์ฟเวอร์ DHCP ใน LAN ของผม” ว่าโอกาสต่ำแต่ไม่ใช่เป็นไปไม่ได้ นั่นไม่ใช่สถานการณ์ของ Wi‑Fi ร้านกาแฟพอดีหรือ?
      จุดขายอันดับ 1 ของผลิตภัณฑ์ VPN ส่วนใหญ่ก็คือเรื่องนั้น
      ในกรณีนี้ การรับมือที่ถูกต้องคือใช้การเชื่อมต่อ 4G/5G และอย่าเชื่อมต่อกับเครือข่ายน่าสงสัยที่ไม่น่าเชื่อถือ
    • การใช้คำว่า “เซิร์ฟเวอร์ DHCP นั้น” ตั้งสมมติฐานว่ามีอุปกรณ์พิเศษบางอย่างอยู่ในเครือข่าย ซึ่งสมมติฐานนั้นผิด DHCP เป็นโปรโตคอลแบบ broadcast และอุปกรณ์จะรับข้อเสนอแรก
      ในบ้านทั่วไป DHCP มาจากเราเตอร์ และโดยปกติมันจึงตอบกลับก่อน นั่นเป็นเรื่องรอง อุปกรณ์ประสงค์ร้ายใด ๆ ในเครือข่ายก็ใช้ช่องโหว่นี้ได้
    • หนึ่งใน use case ใหญ่ ๆ ของ VPN ไม่ใช่ตอนที่เราเชื่อถือเครือข่ายที่เชื่อมต่ออยู่ไม่ได้หรือ?
    • หรือกรณีที่กลายเป็นเซิร์ฟเวอร์ DHCP บน Wi‑Fi ของบุคคลที่สามที่เราเชื่อมต่ออยู่ก็ได้
    • การปกป้องบนเครือข่าย Wi‑Fi ที่ไม่น่าเชื่อถือเป็นหนึ่งในเหตุผลที่ VPN มักนำมาโฆษณา

  • บน Linux สามารถบรรเทาได้ด้วยการใส่อินเทอร์เฟซ VPN เข้าไปใน VRF เช่น systemd-networkd รองรับสิ่งนี้โดยค่าเริ่มต้น
    สิ่งที่ต้องระวังคือเมื่อเปิด VRF แล้ว รายการ ip rule สำหรับ l3mdev จะถูกตั้งเป็น 1000 แต่กฎทราฟฟิก local ถูกตั้งเป็น 0 ต้องย้ายกฎ local ไปที่ 1000 หรือสูงกว่า

    • เดี๋ยวนี้มีวิธีรันแอปใน VRF ที่กำหนดแล้วหรือยัง?

  • “การโจมตี” นี้เป็นเพียงการใช้ DHCP option 121 อย่างชาญฉลาดเท่านั้น เป็นการโจมตีที่ใช้ได้กับการตั้งค่าไคลเอนต์ที่พังหนัก
    วิธีเปลี่ยน default route หรือเขียนทับด้วยเส้นทาง /1 สองเส้น แล้วเพิ่ม host route ไปยัง endpoint ของ VPN นั้นไม่ปลอดภัย หากต้องการแยกทราฟฟิกที่ถูก encapsulate ออกจากเครือข่ายชั้นล่างอย่างถูกต้อง ต้องใช้ policy-based routing เช่น Linux network namespace, FreeBSD vnet, OpenBSD rdomains เป็นต้น
    วิธีพยายามจับ packet filter กับ “kill switch” ฝั่ง user space มาผูกกันแบบฝืน ๆ นั้นเสียมาตั้งแต่การออกแบบ และแสดงให้เห็นว่าผู้ให้บริการ VPN ทั่วไปไม่เข้าใจหรือไม่ใส่ใจแม้แต่เรื่องที่ควรเป็นความเชี่ยวชาญหลักของตนเองแค่ไหน เป็นปัญหาเก่าแบบ “ไล่แจกแจงสิ่งที่ไม่ดี” อีกครั้ง

  • ไม่ใช่เรื่องใหม่อะไรเลย
    ผมกังวลมากกว่ากับคนที่เปิด IPv6 ไว้ในระบบ แต่ใช้ บริการ VPN ที่รองรับเฉพาะ IPv4
    เรื่องนั้นพลาดหนักได้จริง ๆ

  • มีวิธีข้าม VPN บนอุปกรณ์ไคลเอนต์มากมาย ดังนั้นเวลาที่จำเป็นต้องใช้ VPN ผมจึงชอบวางเราเตอร์ไว้ระหว่างไคลเอนต์กับอินเทอร์เน็ต ให้เป็นตัวจบ VPN tunnel และไม่มีเส้นทางอื่นให้ไป
    เราเตอร์สำหรับพกพา แบบนี้ตั้งค่าได้ง่ายมากและพกไปได้ทุกที่ ซึ่งผมก็ทำแบบนั้นจริง ๆ

    • ที่บ้าน ผมแนะนำอย่างยิ่งให้ใช้ เราเตอร์ VPN เฉพาะ โดยให้แต่ละเราเตอร์มีเครือข่าย Wi‑Fi ของตัวเอง ผมมองว่าเชื่อมต่อได้ง่ายกว่าและเสถียรกว่าการรันซอฟต์แวร์ VPN แบบโลคัลบนอุปกรณ์แต่ละเครื่อง
      เช่น มีเราเตอร์ Wi‑Fi ชื่อ “work” ที่คงการเชื่อมต่อ VPN ไปยังอินทราเน็ตของที่ทำงานไว้ตลอด, มี Wi‑Fi ชื่อ “Australia” ที่เชื่อม VPN ไปยังเซิร์ฟเวอร์ออสเตรเลียทุกครั้งที่อยากดูทีวีออสเตรเลีย และสุดท้ายคือ Wi‑Fi อินเทอร์เน็ตบ้านทั่วไป
      แค่มีเราเตอร์ Wi‑Fi เก่า ๆ สักไม่กี่ตัวก็ทำได้ง่ายมาก และดูเหมือนว่าเราเตอร์บ้านราคาถูกสมัยนี้ก็รองรับ VPN ได้ในระดับหนึ่ง นอกจากการรวมศูนย์การตั้งค่า VPN เพื่อลดโอกาสผิดพลาดแล้ว ข้อดีใหญ่คืออุปกรณ์ใด ๆ ก็ใช้ VPN ได้ เพียงแค่เชื่อมต่อกับ Wi‑Fi นั้น
      ตอนนี้ผมใช้เราเตอร์เก่า ๆ หลายตัวทำแบบนี้อยู่ แต่จริง ๆ แล้วน่าจะมีตลาดสำหรับผลิตภัณฑ์เราเตอร์บ้านตัวเดียวที่ทำ VPN ไปยังหลายตำแหน่งทั่วโลก และให้เครือข่าย Wi‑Fi แยกตามตำแหน่งได้ จุดประสงค์คือให้ TV/Roku/iPad ดูเหมือนเชื่อมต่อจากภูมิภาคอื่นได้ง่าย ๆ
    • การโจมตีนี้ทำได้เฉพาะเมื่อมีอุปกรณ์ที่ไม่น่าเชื่อถืออยู่ใน LAN ภายในเท่านั้น ถ้าคุณพกเกตเวย์ที่เปิด VPN ไว้แล้วไปด้วยเอง อุปกรณ์ LAN ที่ไม่น่าเชื่อถือก็น่าจะไม่ใช่เรื่องน่ากังวลมากนัก
      แต่ถ้าใน LAN มีอุปกรณ์ที่ไม่น่าเชื่อถือและใช้ DHCP อุปกรณ์นั้นสามารถใช้เทคนิคนี้แอบดูทราฟฟิกที่ไม่ได้เข้ารหัส* ได้ อย่างไรก็ตาม มันยังหา IP จริงไม่เจอ เพราะเกตเวย์ช่วยซ่อนไว้
      สถานที่ที่การโจมตีนี้เป็นไปได้จริงมากที่สุดคือสถานการณ์อย่าง Wi‑Fi ในคาเฟ่ ซึ่งคุณคงไม่ค่อยมีแนวโน้มจะพกเราเตอร์ของตัวเองไป
      ในที่นี้ “ทราฟฟิกที่ไม่ได้เข้ารหัส” หมายถึงทราฟฟิกที่ไม่ได้ถูก encapsulate เพื่อส่งไปยังผู้ให้บริการ VPN ทุกวันนี้ส่วนใหญ่เป็น HTTPS ดังนั้นเนื้อหาของทราฟฟิกนั้นเองก็น่าจะยังถูกเข้ารหัสอยู่
    • ถ้ามีการลิสต์ฮาร์ดแวร์และซอฟต์แวร์ที่ใช้ได้สักสองสามตัว ก็น่าจะช่วยลดภาระได้
    • เราเตอร์สำหรับพกพาส่วนใหญ่ก็น่าจะยังเสี่ยงต่อปัญหานี้อยู่

  • สำหรับคนสายเทคนิค เรื่องนี้น่าจะค่อนข้างชัดเจนอยู่แล้ว แต่ก็เป็นคำอธิบายเบื้องต้นเรื่อง networking และ VPN ที่ดี ผมเคยตั้งค่า VM ที่เป็น Linux VPN gateway อยู่หลายครั้ง และสถาปัตยกรรมที่ พึ่งพาแค่ routing table อย่างเดียวมักให้ความรู้สึกเปราะบางเสมอ โดยเฉพาะเมื่อมันรันอยู่บนเครื่องเดียวกันกับที่ใช้การเชื่อมต่อนั้น
    นอกจาก network namespace และเราเตอร์ VPN gateway แบบกายภาพแล้ว สถาปัตยกรรมแบบ VM ก็แก้ปัญหานี้ได้เช่นกัน ในโฮมแล็บของผม ไฟร์วอลล์จะบล็อกทราฟฟิกที่ไม่คาดคิดซึ่งออกมาจาก VM ที่เป็น VPN gateway อุปกรณ์ใน VPN VLAN ไม่สามารถเชื่อมต่อออกไปภายนอกโดยตรงได้ และ VM เกตเวย์มี VLAN แยกสำหรับการเชื่อมต่อออกภายนอก
    สำหรับโซลูชันส่วนบุคคล QubesOS ช่วยตั้งค่าคอนฟิกที่คล้ายกันได้ค่อนข้างราบรื่น แต่ก็ยังต้องใช้ความรู้ทางเทคนิคมากกว่า OS ทั่วไป

  • ส่วนที่ว่า “Android เป็นระบบเดียวที่ไม่ได้รับผลกระทบ เพราะไม่ได้ implement การรองรับ DHCP option 121” น่าสนใจ
    สงสัยว่า Google รู้ปัญหานี้และตัดสินใจแบบนั้นโดยตั้งใจ หรือเป็นเรื่องบังเอิญล้วน ๆ

    • จาก https://issuetracker.google.com/issues/117544989 ดูเหมือนว่า Google จะเพิกเฉยต่อคำขอฟีเจอร์นี้เป็นส่วนใหญ่โดยไม่ให้เหตุผล ผมก็สงสัยประเด็นเดียวกัน พนักงาน Google ที่เข้าถึง Buganizer ภายในได้อาจรู้มากกว่านี้
      ถ้าให้เดา ทีม networking ของ Android เป็นมิตรกับ IPv6 มาก ดูเหมือนไม่ค่อยสนใจฟีเจอร์ปลีกย่อยของ IPv4 ที่ขาดหายไปนัก และสำหรับ IPv6 เองก็มีวิสัยทัศน์เฉพาะว่าควรใช้งานอย่างไร ซึ่งนำไปสู่ผลลัพธ์อย่างการจงใจไม่รองรับฟีเจอร์บางอย่าง เช่น stateful DHCPv6
    • DHCP option มีจำนวนมาก ดังนั้นในกรณีอย่าง Android กลยุทธ์ที่สมเหตุสมผลคือเริ่มจากรองรับให้น้อยที่สุด และเปิดการรองรับเพิ่มเติมเฉพาะเมื่อมีความต้องการสำหรับ option ใด ๆ เข้ามา
      DHCP option นี้ไม่ได้ถูกใช้กันทั่วไป ดังนั้นถ้าใช้กลยุทธ์แบบนั้น ก็มีความเป็นไปได้สูงที่จะไม่ได้รับการรองรับอยู่แล้ว ไม่เกี่ยวกับความกังวลด้านความปลอดภัย
    • Android ยังไม่ได้ implement แม้แต่ DHCP เวอร์ชันใหม่ที่นิยามครั้งแรกเมื่อ 21 ปีก่อน: https://www.rfc-editor.org/rfc/rfc3315
      ดังนั้นจึงไม่ใช่เรื่องน่าแปลกใจนัก