ความเป็นไปได้ของการรั่วไหลของทราฟฟิก DNS นอกอุโมงค์ VPN บน Android

 (mullvad.net)
2 คะแนน โดย GN⁺ 2024-05-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

DNS อาจรั่วออกนอกอุโมงค์ VPN บน Android

ยืนยันความเสี่ยงการรั่ว DNS หลายรูปแบบ

  • พบว่าใน Android มีความเป็นไปได้ของการรั่ว DNS แบบหลายรูปแบบ
  • เกิดจากบั๊กของ Android เองและส่งผลเฉพาะต่อแอปบางตัว
  • เมื่อวันที่ 22 เมษายน วันจันทร์ เราทราบเรื่องการรั่ว DNS จากรายงานของผู้ใช้บน Reddit
    • ผู้ใช้พบว่าคิวรี DNS รั่วเมื่อปิดและเปิด VPN ในขณะที่เปิดตัวเลือก "Block connections without VPN"
  • เริ่มการสอบสวนภายในทันทีและยืนยันว่าปัญหานี้มีอยู่จริง
  • ผลการตรวจสอบเผยให้เห็นสถานการณ์เพิ่มเติมใน Android ที่อาจทำให้เกิดการรั่ว DNS ได้

ข้อค้นพบ

ระบุกรณีที่อาจเกิดการรั่วทราฟฟิก DNS ใน Android OS ได้ดังนี้:

  • เมื่อ VPN ถูกเปิดใช้งานโดยยังไม่ได้กำหนดค่าเซิร์ฟเวอร์ DNS
  • เกิดขึ้นเป็นช่วงสั้น ๆ ระหว่างที่แอป VPN กำลังรีคอนฟิกท่อ (reconfigure tunnel) หรือถูกบังคับหยุด/ล้มเหลว

การรั่วดูเหมือนจะจำกัดเฉพาะแอปที่เรียกใช้ฟังก์ชัน C getaddrinfo โดยตรง:

  • แอปที่ใช้วิธีนี้เพื่อ resolve ชื่อโดเมนในสถานการณ์ที่ระบุด้านบนเป็นสาเหตุการรั่ว
  • ไม่พบการรั่วในแอปที่ใช้เฉพาะ Android API เช่น DnsResolver
  • ตัวอย่างแอปที่อาจเรียก getaddrinfo โดยตรงคือ Chrome

ผลสังเกตข้างต้นใช้ได้ไม่ว่าคุณจะเปิดใช้งาน Always-on VPN และ Block connections without VPN หรือไม่:

  • เนื่องจากไม่ใช่พฤติกรรมของ OS ที่ควรเป็น จึงควรได้รับการแก้ไขจาก upstream ของ OS

พบว่าการรั่วลักษณะนี้เกิดขึ้นในหลายเวอร์ชันของ Android (รวมถึง Android 14 รุ่นล่าสุด)

การปรับปรุง

ปัจจุบันแอปไม่ตั้งค่าเซิร์ฟเวอร์ DNS เมื่ออยู่ในสถานะบล็อค:

  • หากแอปไม่สามารถตั้งค่า tunnel ได้ในโหมดที่ไม่สามารถกู้คืนได้ จะเปลี่ยนไปยังสถานะบล็อค
  • ในสถานะนี้ทราฟฟิกจากอุปกรณ์จะหยุดออกมา
  • อย่างไรก็ตาม ในสถานะนี้ไม่ได้ตั้งค่า DNS server ทำให้เกิดการรั่ว DNS ตามที่กล่าวไว้ข้างต้นได้
  • ชั่วคราวจะตั้งค่า fake DNS server เพื่อเลี่ยงบั๊กของ OS
  • คาดว่าจะมีการปล่อยเวอร์ชันที่รวมการแก้ไขนี้ได้เร็ว ๆ นี้

การลดผลกระทบการรั่วระหว่างการเชื่อมต่อ tunnel ใหม่จากฝั่งแอปนั้นยากขึ้น:

  • กำลังยังคงมองหาวิธีแก้ไขอยู่อย่างต่อเนื่อง
  • สามารถลดความถี่การรีคอนฟิก tunnel ได้ แต่ในตอนนี้ยังคิดว่าไม่สามารถป้องกันการรั่วนี้ได้อย่างสมบูรณ์

ควรชัดเจนว่ามิใช่ว่าแอป VPN ใดต้องมีการแก้ปัญหานี้เอง:

  • การที่แอปใช้ getaddrinfo เพื่อ resolve ชื่อโดเมนไม่ใช่ความผิด
  • แทนที่จะให้แต่ละแอปต้องแก้ปัญหานี้ OS ควรแก้ไขเพื่อปกป้องผู้ใช้ Android ทุกคนไม่ว่าแอปใดก็ตาม

เราได้รายงานปัญหาให้ Google ทราบและเสนอการปรับปรุง โดยหวังว่าจะได้รับการแก้ไขโดยเร็ว

ขั้นตอนการจำลอง

ขั้นตอนต่อไปนี้เป็นการจำลองฉากที่สองข้างต้น โดยในขั้นตอนนี้ผู้ใช้ VPN จะเปลี่ยนการตั้งค่า tunnel (เช่น สลับไปยังเซิร์ฟเวอร์อื่นหรือเปลี่ยนเซิร์ฟเวอร์ DNS):

  • ใช้แอป WireGuard ซึ่งเป็น implementation อ้างอิงของ Android VPN
  • ควรทราบว่าการรั่วนี้อาจจำลองได้กับแอป VPN ตัวอื่นบน Android ได้ด้วย
  • เนื่องจาก Chrome เป็นหนึ่งในแอปที่ตรวจพบว่ามีการใช้ getaddrinfo จึงใช้ Chrome เพื่อกระตุ้นการรั่ว

  1. ดาวน์โหลดไฟล์ spam_get_requests.html

  2. ติดตั้ง WireGuard และ Chrome

  3. นำเข้า wg1.conf และ wg2.conf เข้า WireGuard

  4. เปิด tunnel wg1 ในแอป WireGuard และอนุญาตสิทธิ์ VPN

  5. ที่การตั้งค่า VPN ของ Android เปิด "Always-on VPN" และ "Block connections without VPN" สำหรับ WireGuard

  6. เริ่มจับข้อมูลบนเราเตอร์ด้วย tcpdump $ tcpdump -i <INTERFACE> host <IP of android device>

  7. แบ่งหน้าจอให้ WireGuard และ Chrome แสดงพร้อมกัน

  8. เปิด spam_get_requests.html ใน Chrome และคลิก "Start"

  9. สลับระหว่าง wg1 และ wg2 ในแอป WireGuard ซ้ำ ๆ จนกระทั่งเห็นการรั่วในขั้นตอนถัดไป

  10. สังเกตทราฟฟิก DNS ต่อไปนี้ที่เราเตอร์:

    11:50:27.816359 IP Pixel-Tablet.lan.53353 > OpenWrt.lan.53: 11200+ A? 307lf5rgn6-19282-11-50-27-519z.mullvad.test.lan. (65)
11:50:27.816359 IP Pixel-Tablet.lan.48267 > OpenWrt.lan.53: 44347+ A? 307lf5rgn6-19284-11-50-27-579z.mullvad.test.lan. (65)
11:50:27.816396 IP Pixel-Tablet.lan.16747 > OpenWrt.lan.53: 44584+ A? 307lf5rgn6-19289-11-50-27-729z.mullvad.test. (61)
11:50:27.816458 IP OpenWrt.lan.53 > Pixel-Tablet.lan.53353: 11200 NXDomain 0/0/0 (65)
11:50:27.816476 IP Pixel-Tablet.lan.45727 > OpenWrt.lan.53: 40503+ A? 307lf5rgn6-19290-11-50-27-759z.mullvad.test. (61)
11:50:27.816542 IP OpenWrt.lan.53 > Pixel-Tablet.lan.48267: 44347 NXDomain 0/0/0 (65)
11:50:27.816588 IP Pixel-Tablet.lan.43821 > OpenWrt.lan.53: 36295+ A? 307lf5rgn6-19291-11-50-27-789z.mullvad.test. (61)
11:50:27.816625 IP OpenWrt.lan.53 > Pixel-Tablet.lan.16747: 44584 NXDomain 0/0/0 (61)

แม้ว่าตั้ง "Block connections without VPN" ไว้ ซึ่งหมายความว่า นอกจากทราฟฟิก WireGuard ที่เข้ารหัสแล้วไม่ควรมีข้อมูลใดออกจากอุปกรณ์ แต่ที่นี่สามารถมองเห็น DNS แบบ plaintext ออกมาจากอุปกรณ์ได้

สรุปและข้อแนะนำ

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

การค้นพบเหล่านี้ชี้ให้เห็นอีกครั้งว่าชื่อ (หรือเอกสาร) ของ "Block connections without VPN" ไม่สอดคล้อง และยังมีจุดบกพร่องหลายจุด:

  • แอปยังคงรั่วทราฟฟิก DNS ได้ภายใต้เงื่อนไขที่กล่าวถึงข้างต้น
  • ตามการรายงานเดิม ยังคงมีการรั่วของทราฟฟิกตรวจสอบการเชื่อมต่ออยู่

ตาม threat model อาจต้องเลือกไม่ใช้ Android สำหรับงานที่อ่อนไหว หรือใช้มาตรการบรรเทาอื่น ๆ เพื่อป้องกันการรั่ว:

  • เพื่อบรรเทาปัญหานี้ในระดับแอป ควรอัปเดตแอปให้เป็นเวอร์ชันล่าสุดเสมอ

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

  • ปัญหานี้เป็นบั๊กของ Android OS โดยตรง จึงควรได้รับการแก้ไขจาก Google เร็ว ๆ นี้ การที่นักพัฒนาแอปที่มีฟังก์ชัน VPN ทั้งหมดพยายามแก้ปัญหานี้ด้วยตัวเองไม่ใช่ทางเลือกที่เหมาะสม
  • ทางเลือก "Block connections without VPN" ไม่ทำงานตามเอกสารและการรั่ว DNS เป็นปัญหาระดับหนึ่งสำหรับผู้ใช้ เพราะหนึ่งในเหตุผลหลักที่ใช้ VPN คือการปกป้องความเป็นส่วนตัว แต่การรั่ว DNS ทำให้ข้อมูลการใช้งานเว็บของผู้ใช้อาจถูกเปิดเผยได้
  • แม้ความปลอดภัยของเทคโนโลยี VPN tunneling เองยังคงสูง แต่เพื่อป้องกันการรั่วที่เกิดโดยไม่ตั้งใจจาก OS อาจพิจารณาใช้โซลูชันความปลอดภัย/ความเป็นส่วนตัวเสริมนอกเหนือจาก VPN ได้ด้วย
  • ในมุมมองนักพัฒนาแอป มีการปรับปรุงชั่วคราวในแอปเพื่อหลีกเลี่ยงบั๊กของ OS อยู่บ้าง แต่ระยะยาวดูเหมือนว่าจำเป็นต้องมีการปรับปรุง OS เพื่อแก้ที่ต้นตอ
  • เมื่อเทคโนโลยี VPN มีความซับซ้อนและเป็นที่รู้จักมากขึ้น ปัญหาด้านความปลอดภัยแบบนี้จึงเด่นชัดขึ้น คาดว่าจะยังต้องมีการตรวจสอบความปลอดภัยและการปรับปรุงต่อเนื่องสำหรับเครือข่ายและฟังก์ชัน VPN ของ OS มือถือต่อไป

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

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

 
GN⁺ 2024-05-04
ความคิดเห็น Hacker News
  • ข้อมูลของ Mullvad ให้คำอธิบายที่ครบถ้วนเกี่ยวกับปัญหา วิธีแก้ไขชั่วคราว แนวทางแก้ไขที่เป็นไปได้ และสิ่งที่ควรแก้ไขใน Android อย่างชัดเจน
  • "Paranoid networking" ของ Android มีข้อยกเว้นสำหรับแอประบบและแอป OEM และนักพัฒนา rethinkdns เห็นว่าการแก้ไขบั๊กส่วนใหญ่คงไม่เปลี่ยนสมมติฐานหลักนี้
  • Android รองรับการ "handover" ระหว่างอุปกรณ์ TUN สองตัวได้อย่างราบรื่น แต่การนำไปใช้งานจริงค่อนข้างซับซ้อน
  • Android มีปัญหานี้มาเนิ่นนานแล้ว คือแม้จะตั้งใจใช้ DNS เซิร์ฟเวอร์ภายในเท่านั้น มันก็อาจสลับไปใช้ข้อมูลเซลลูลาร์และ DNS ภายนอกตามความจำเป็น
  • ในฝั่ง Apple โดยปกติ VPN โหมด "privacy" พยายาม proxy ทุกอย่าง ทำให้เมื่อใช้บริการแข่งขันก็ไม่ได้สถานการณ์ที่ดีขึ้นนัก
  • Android ไม่สามารถกำหนดเซิร์ฟเวอร์ DNS IPv6 ได้เอง และจะเปลี่ยนไปใหม่ทุกครั้งที่มีการเปลี่ยน Wi‑Fi
  • สามารถป้องกันการรั่วไหลของทราฟฟิกได้ด้วยการใช้ไฟร์วอลล์ของ MikroTik เพื่อบล็อกทราฟฟิกทั้งหมดที่ไม่มุ่งไปยัง IP ของเซิร์ฟเวอร์ VPN
  • ระบบทั้งหมดที่ไม่มีสิทธิ์ root ล้วนไม่ปลอดภัยโดยพื้นฐาน และ Android กับ iOS นั้นแทบไม่มีทางปลอดภัยจริง ๆ
  • การตั้งค่าที่ปลอดภัยที่สุดคือปิดข้อมูลมือถือของโทรศัพท์และใช้ฮอตสปอต OpenWRT เพื่อให้ทำ VPN ที่เลเยอร์อัปสตรีม
  • DNS leak สามารถเปิดเผยตำแหน่งการท่องเว็บของผู้ใช้ได้ และแม้กระทั่งตำแหน่งจริง ทำให้จุดประสงค์ของ VPN เสียหาย
  • บน iOS เทรฟฟิก APNS ก็รั่วนอก VPN เช่นกัน (ยกเว้น VPN ที่รองรับโดย OS และติดตั้งผ่าน provisioning profile)
  • ทำให้เกิดข้อสงสัยว่าบั๊กเหล่านี้อาจถูกวางไว้อย่างตั้งใจ และเมื่อพิจารณาว่าบริษัทเทคโนโลยีรายใหญ่ร่วมมือกับหน่วยข่าวกรองแล้ว ก็ยากที่จะเชื่อว่า bug หลายอย่างใน Android เป็นแค่เหตุบังเอิญ