Витік WebRTC

Витік WebRTC – це вразливість у браузерах, яка дозволяє вебсайту виявити реальну IP-адресу користувача, обходячи проксі-сервери або VPN шляхом прямого запиту до мережевих інтерфейсів через механізми STUN/TURN WebRTC. Це розкриття відбувається тому, що WebRTC, розроблений для зв'язку в реальному часі, часто використовує UDP-з'єднання до STUN (Session Traversal Utilities for NAT) та TURN (Traversal Using Relays around NAT) серверів для встановлення прямих однорангових з'єднань, і ці запити можуть не маршрутизуватися через налаштований проксі-сервер браузера.

Розуміння WebRTC та його архітектури

WebRTC (Web Real-Time Communication) – це проєкт з відкритим вихідним кодом, що забезпечує голосовий, відео- та обмін даними в реальному часі безпосередньо між браузерами та іншими клієнтськими програмами. Він дозволяє передавати дані за принципом "точка-точка" без необхідності використання проміжних серверів, значно зменшуючи затримку та навантаження на сервер для таких програм, як відеоконференції, обмін файлами та прямі трансляції.

Ключові компоненти встановлення з'єднання WebRTC включають:

• Сервер сигналізації (Signaling Server): Використовується для обміну метаданими (наприклад, повідомленнями керування сесією, мережевою конфігурацією, можливостями медіа) між одноранговими вузлами до встановлення прямого з'єднання. Сам процес сигналізації не стандартизований WebRTC і може використовувати різні протоколи (наприклад, WebSocket).
• ICE (Interactive Connectivity Establishment): Фреймворк, який дозволяє одноранговим вузлам виявляти та встановлювати прямі з'єднання. ICE використовує STUN та TURN сервери для пошуку найкращого можливого шляху зв'язку.
• STUN Server: Допомагає одноранговим вузлам виявити їхню публічну IP-адресу та тип NAT, за яким вони знаходяться. Коли клієнт за NAT надсилає запит до STUN-сервера, сервер відповідає публічною IP-адресою та портом клієнта, як їх видно з Інтернету.
• TURN Server: Використовується, коли пряме однорангове з'єднання неможливе (наприклад, через обмежувальні NAT або брандмауери). TURN-сервер діє як ретранслятор, пересилаючи весь трафік між одноранговими вузлами.

Критичним аспектом для витоку IP є те, як ICE збирає "кандидатів" – потенційні мережеві адреси та порти, які можуть бути використані для зв'язку. Ці кандидати включають:

• Кандидати хоста (Host Candidates): Локальні IP-адреси (наприклад, 192.168.1.100, 10.0.0.5) машини користувача.
• Серверні рефлексивні кандидати (Server Reflexive Candidates): Публічна IP-адреса та відображення порту, виділені NAT-маршрутизатором, виявлені через STUN-сервер.
• Ретрансльовані кандидати (Relayed Candidates): IP-адреси та порти на TURN-сервері, що використовуються, коли пряме з'єднання неможливе.

Механізм витоку WebRTC

Коли браузер ініціює WebRTC-з'єднання, він використовує JavaScript API для запиту операційної системи щодо локальних мережевих інтерфейсів, а потім виконує STUN-запити для виявлення своєї публічної IP-адреси. Ці STUN-запити зазвичай базуються на UDP і часто виконуються безпосередньо браузером або базовою бібліотекою WebRTC, обходячи налаштування проксі HTTP/SOCKS, сконфігуровані для загального вебтрафіку.

Об'єкт RTCPeerConnection браузера безпосередньо перераховує локальні IP-адреси та надсилає STUN-запити на прив'язку. Відповіді від STUN-серверів включають публічну IP-адресу клієнта. Ця інформація, включаючи як локальні, так і публічні IP-кандидати, потім стає доступною віддаленому одноранговому вузлу (або, що важливо, вебсайту, що розміщує WebRTC-додаток) через процес обміну ICE-кандидатами.

Навіть якщо використовується проксі або VPN, механізм WebRTC браузера все ще може здійснювати ці прямі, непроксійовані з'єднання до STUN-серверів або безпосередньо запитувати локальні мережеві інтерфейси, розкриваючи справжню IP-адресу користувача.

Приклад: Розкриття IP за допомогою JavaScript

Шкідливий або діагностичний вебсайт може використовувати кілька рядків JavaScript для ініціації WebRTC-з'єднання та вилучення цих ICE-кандидатів.

// This is a simplified example for illustrative purposes.
// Real-world exploitation involves more complex candidate gathering.

function getWebRTCIPs() {
    return new Promise((resolve, reject) => {
        const pc = new RTCPeerConnection({
            iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
        });
        const candidates = [];

        pc.onicecandidate = (event) => {
            if (event.candidate) {
                const candidate = event.candidate.candidate;
                // Example candidate string:
                // "candidate:4234997380 1 udp 2043278322 192.168.1.100 50000 typ host" (local IP)
                // "candidate:4234997380 1 udp 2043278322 203.0.113.45 50000 typ srflx" (public IP via STUN)

                const ipMatch = /(?:[0-9]{1,3}\.){3}[0-9]{1,3}/.exec(candidate);
                if (ipMatch && ipMatch[0] && candidates.indexOf(ipMatch[0]) === -1) {
                    candidates.push(ipMatch[0]);
                }
            } else {
                // All ICE candidates have been gathered
                if (candidates.length > 0) {
                    resolve(candidates);
                } else {
                    reject(new Error('No WebRTC IP candidates found.'));
                }
            }
        };

        pc.createDataChannel(''); // Need a data channel to trigger candidate gathering
        pc.createOffer()
            .then(offer => pc.setLocalDescription(offer))
            .catch(reject);
    });
}

// Usage:
// getWebRTCIPs().then(ips => console.log('Discovered IPs:', ips)).catch(error => console.error(error));

Цей JavaScript-код ініціює RTCPeerConnection та прослуховує події onicecandidate. Кожна подія містить рядок кандидата, який включає IP-адресу (локальну, публічну через STUN або ретрансльовану через TURN). Вебсайт може розібрати цих кандидатів, щоб витягти реальні IP-адреси.

Виявлення витоку WebRTC

Щоб визначити, чи вразлива конфігурація проксі до витоків WebRTC, можна використовувати онлайн-інструменти:

1. Відвідайте службу тестування IP: Перейдіть на сайти, такі як ipleak.net або browserleaks.com/webrtc, підключившись через проксі.
2. Порівняйте повідомлені IP-адреси:
   • Proxy IP: Це IP-адреса, яку проксі-сервіс повинен представляти Інтернету.
   • WebRTC IP: У цьому розділі будуть перелічені IP-адреси, виявлені через WebRTC.
   • Your Real IP: Це ваша фактична публічна IP-адреса, яка в ідеалі повинна бути прихована.

Якщо в розділі "WebRTC IP" відображається ваша фактична публічна IP-адреса, присутній витік WebRTC. Якщо він відображає вашу локальну мережеву IP (наприклад, 192.168.x.x або 10.x.x.x), це вказує на те, що браузер перераховує локальні інтерфейси, що може не розкривати вашу публічну IP-адресу безпосередньо, але все ж розкриває внутрішню мережеву конфігурацію.

Стратегії пом'якшення

Пом'якшення витоків WebRTC вимагає конкретних дій, оскільки стандартні конфігурації проксі часто недостатні.

Конфігурація браузера та розширення

Різні браузери пропонують різні рівні контролю над WebRTC:

• Mozilla Firefox:

  • Введіть about:config в адресний рядок.
  • Знайдіть media.peerconnection.enabled та встановіть його значення на false. Це повністю вимкне WebRTC, що може порушити роботу деяких легітимних вебдодатків.
  • Альтернативно, знайдіть media.peerconnection.ice.no_host_candidates та встановіть його на true. Це запобігає розкриттю браузером локальних IP-адрес.
  • Знайдіть media.peerconnection.ice.default_obfuscate_host_addresses та встановіть його на true. Це обфускує локальні IP-адреси, повідомлені WebRTC.

• Google Chrome / Браузери на базі Chromium:

  • Chrome не пропонує прямих прапорців конфігурації в chrome://flags для повного вимкнення WebRTC без впливу на інші функції браузера.
  • Розширення: Встановіть розширення для браузера, призначене для блокування витоків WebRTC, наприклад "WebRTC Network Limiter" або "uBlock Origin" зі спеціальними фільтрами. Ці розширення зазвичай змінюють поведінку WebRTC API браузера, щоб запобігти прямому розкриттю IP.
  • Розширення "WebRTC Network Limiter" працює шляхом налаштування Chrome на використання лише "mDNS host candidates" або "proxy-only ICE candidates", ефективно обмежуючи типи зібраних та спільних кандидатів.

• Opera:

  • Вбудована функція VPN Opera іноді включає захист від витоків WebRTC. При ввімкненні вона маршрутизує WebRTC-трафік через VPN. Перевірте налаштування в Налаштування > Конфіденційність та безпека > VPN.

Елементи керування на рівні операційної системи

Хоча менш точні, елементи керування на рівні ОС можуть обмежувати трафік WebRTC:

• Правила брандмауера: Блокуйте вихідний UDP-трафік на загальних портах STUN/TURN (наприклад, 3478, 19302-19309). Це може запобігти досягненню STUN-запитів зовнішніх серверів, але також може порушити легітимну функціональність WebRTC.
• Керування мережевими інтерфейсами: У деяких сценаріях вимкнення певних мережевих адаптерів може запобігти перерахуванню їхніх IP-адрес, але це, як правило, непрактично для повсякденного використання.

Проксі проти VPN для захисту від витоків WebRTC

Фундаментальна різниця в роботі проксі та VPN впливає на їхню здатність запобігати витокам WebRTC.

VPN шифрує та маршрутизує весь мережевий трафік з пристрою через безпечний тунель, включаючи UDP-трафік, що генерується STUN-запитами WebRTC. Це гарантує, що єдина IP-адреса, розкрита зовнішнім STUN-серверам, – це IP-адреса VPN-сервера, ефективно запобігаючи витоку WebRTC. Проксі на рівні браузера, навпаки, працюють на вищому рівні і можуть маршрутизувати лише TCP-трафік, залишаючи UDP WebRTC-з'єднання для встановлення безпосередньо.

Для надійного захисту від витоків WebRTC та комплексної конфіденційності повне системне рішення VPN, як правило, ефективніше, ніж проксі для конкретного браузера. При використанні проксі обов'язковими є спеціальні конфігурації браузера або розширення для запобігання розкриттю WebRTC реальної IP-адреси.