การตรวจจับการรั่วไหลของ IP ผ่าน WebRTC: จากบั๊กสู่ฟีเจอร์

WebRTC — Web Real-Time Communication — ถูกออกแบบมาเพื่อรองรับการสนทนาผ่านวิดีโอ การแชร์ไฟล์ และการถ่ายโอนข้อมูลแบบ peer-to-peer โดยตรงในเบราว์เซอร์ การสร้างการเชื่อมต่อเหล่านี้ทำให้เบราว์เซอร์ต้องค้นหาอินเทอร์เฟซเครือข่ายของตนเองและเจรจาความสามารถในการเชื่อมต่อกับ peer ปลายทาง กระบวนการนี้เกี่ยวข้องกับเซิร์ฟเวอร์ STUN (Session Traversal Utilities for NAT) และ TURN (Traversal Using Relays around NAT) ที่ช่วยให้เบราว์เซอร์ค้นหาที่อยู่ IP สาธารณะของตนเองและผ่านทะลุไฟร์วอลล์ NAT ได้

ผลข้างเคียงนั้นทรงพลัง: แม้ผู้ใช้จะเชื่อมต่อผ่าน VPN สแตก WebRTC ของเบราว์เซอร์ก็ยังอาจเผยที่อยู่ IP จริงที่ซ่อนอยู่หลัง tunnel ได้ สาเหตุก็เพราะ ICE (Interactive Connectivity Establishment) candidate ของ WebRTC มีที่อยู่ของอินเทอร์เฟซเครือข่ายภายในเครื่องรวมอยู่ด้วย ซึ่ง VPN ไม่ได้ปกปิดไว้

การรั่วไหลเกิดขึ้นอย่างไร

เมื่อเบราว์เซอร์สร้าง RTCPeerConnection และรวบรวม ICE candidate มันจะสอบถามเซิร์ฟเวอร์ STUN เพื่อค้นหา IP สาธารณะที่หันออกสู่ภายนอก แต่ในขณะเดียวกันมันก็แจกแจงอินเทอร์เฟซเครือข่ายภายในเครื่องด้วย — รวมถึง IP ส่วนตัวของอะแดปเตอร์ทางกายภาพ หาก VPN ทำ tunnel ให้กับทราฟฟิกเฉพาะที่ชั้น IP เท่านั้น แต่ไม่ได้ตั้งค่าให้สแตก WebRTC ของเบราว์เซอร์ใช้อินเทอร์เฟซของ tunnel แต่เพียงอย่างเดียว IP จริงก็จะรั่วไหลออกมาผ่าน host candidate

ที่ tracio.ai เรา probe พฤติกรรมนี้อย่างระมัดระวัง ระบบ IP Intelligence ของเราสร้างคำขอ STUN แบบมีการควบคุมและวิเคราะห์ ICE candidate ที่เบราว์เซอร์ตอบกลับมา เมื่อ IP สาธารณะจาก STUN ต่างจาก IP ที่เราเห็นที่เซิร์ฟเวอร์ของเรา เราจะติดธงว่ามี VPN หรือ proxy และเมื่อ IP ของอินเทอร์เฟซภายในเผยช่วงเครือข่ายส่วนตัวที่ขัดแย้งกับตำแหน่งทางภูมิศาสตร์ที่อ้างไว้ เราจะเพิ่มคะแนนความน่าสงสัย

จากบั๊กสู่สัญญาณตรวจจับ

เบราว์เซอร์ที่ให้ความสำคัญกับความเป็นส่วนตัวส่วนใหญ่ได้แพตช์การรั่วไหลนี้แล้ว — Chrome กำหนดให้ผู้ใช้อนุญาต WebRTC อย่างชัดเจน และ Firefox มีการตั้งค่าให้ปิด UDP ที่ไม่ผ่าน proxy ได้ แต่การแข่งขันด้านนี้ยังดำเนินต่อไป: ไคลเอนต์ VPN บางตัวตั้งค่า WebRTC ไม่ถูกต้อง เบราว์เซอร์เวอร์ชันเก่ายังคงมีช่องโหว่ และรูปแบบพฤติกรรมของการตอบสนอง WebRTC แบบ "แพตช์แล้ว" กับ "ยังรั่ว" ก็เป็นสัญญาณที่มีประโยชน์ในตัวเอง

แนวทางของเราปฏิบัติต่อการตอบสนอง WebRTC เสมือนเป็นสัญญาณเชิงประกอบ: การมี host candidate จำนวน ICE candidate ที่ตอบกลับมา ชนิดของ candidate (host, srflx, relay) และจังหวะเวลาการตอบสนอง ล้วนมีส่วนร่วมในการสร้าง fingerprint ของอุปกรณ์ แม้ไม่มี IP รั่วไหลเลย รูปแบบพฤติกรรมของ WebRTC ก็ยังโดดเด่น

การ probe เซิร์ฟเวอร์ TURN

นอกเหนือจาก STUN เรายัง probe พฤติกรรมของเซิร์ฟเวอร์ TURN ด้วย TURN relay มักถูกใช้เมื่อการเชื่อมต่อ peer-to-peer โดยตรงล้มเหลว — พบได้บ่อยในเครือข่ายองค์กรที่อยู่หลังไฟร์วอลล์ที่เข้มงวด การตอบสนองของการจัดสรร TURN เผยข้อมูลเกี่ยวกับเส้นทางของ relay ได้แก่ โปรโตคอลการรับส่ง (UDP กับ TCP กับ TLS) ที่อยู่ของ relay และอายุการจัดสรร (allocation lifetime)

ระบบ SignalProbe ของเราส่งคำขอจัดสรร TURN ที่ประดิษฐ์ขึ้นอย่างพิถีพิถันไปยังเซิร์ฟเวอร์ relay ของเราเอง เวลาในการตอบสนอง โปรโตคอลการรับส่งที่รองรับ และรูปแบบความสำเร็จ/ล้มเหลวของการจัดสรร จะแตกต่างกันไปตามสภาพแวดล้อมเครือข่าย และให้ความหลากหลายของสัญญาณเพิ่มเติมสำหรับการทำ fingerprint ของอุปกรณ์

ข้อพิจารณาด้านความเป็นส่วนตัว

เราขอชี้แจงให้ชัดเจน: tracio.ai ไม่ได้ใช้ประโยชน์จากการรั่วไหลของ WebRTC เพื่อระบุตัวตนผู้ใช้ที่ไม่เปิดเผยตัว ระบบของเราตรวจจับว่ามีการใช้ VPN อยู่หรือไม่ และรายงานสิ่งนี้เป็นสัญญาณความเสี่ยง เราไม่เคยเก็บหรือเปิดเผยที่อยู่ IP ที่รั่วไหล สัญญาณนี้เป็นแบบไบนารี: "ตรวจพบ VPN พร้อมความไม่สอดคล้องของ WebRTC" หรือ "พฤติกรรม WebRTC สอดคล้องกับการเชื่อมต่อโดยตรง"

แนวทางนี้มอบข้อมูลที่ทีมป้องกันการฉ้อโกงต้องการ — ผู้เข้าชมกำลังปกปิดตำแหน่งจริงของตน — โดยไม่ละเมิดความเป็นส่วนตัวของแต่ละบุคคล สัญญาณนี้ช่วยตรวจจับการโจมตีฉ้อโกงแบบประสานงานกัน ที่หลายบัญชีมีต้นทางมาจากตำแหน่งที่ซ่อนไว้แห่งเดียวกัน