Браузер-шпигун: технічні особливості

Наша взаимовыгодная связь https://banwar.org/

В продовження теми про Chrome , Який, нібито, переправляє в Google контент закритих сторінок з корпоративних інтранет: цікаво подумати, як можна було б влаштувати подібний шпигунський браузер. Зрозуміло, що навряд чи Google щось подібне робить, тому що не ясні стратегічні вигоди: ну чого там цікавого для масового користувача можна знайти в інтранет? Тим більше, що і посилання-то не покажеш: сервер же закритий. У вихідному вкидання, направленому на тематичні ЗМІ, з тієї чи іншої причини не розроблений технічний аспект: тобто немає легенди, як саме Chrome "зливає інфу". А адже це був би самий цікавий шматочок історії.

Що можна придумати? Зрозуміло, що просте віддзеркалення заборонених з "секретного" сайту сторінок на сервер Google - це нецікавий варіант. Хоча б тому, що він виявляється зовсім вже елементарно, за допомогою систем моніторингу трафіку. Використання зашифрованих каналів тут не допоможе, тому що сама наявність каналу з трафіком демаскує "шпигуна". Однак, можна "розмазати" зібрану інформацію з багатьох транзакціях, передаючи всередині кожної лише невеликий фрагмент. Виходить такий повільний і малопомітний канал.

Посудіть самі: звичайний корпоративний користувач ходить не тільки по інтранету і закритим внутрішнім серверам, основну частину його трафіку складають результати перегляду зовнішніх ресурсів. Це означає, що частка трафіку, що формує витік, невелика, і цю частку можна розкласти по розтягнутою у часі серії зовнішніх запитів, приховавши, таким чином, в вихідному трафіку. Основним предметом витоку повинні бути тексти на природній мові (іноді потрібно і графіка, але зосередитися потрібно на текстах). Це дозволяє ще зменшити трафік - тексти добре стискаються при передачі.

Виникає питання: де зберігати тексти сторінок, якщо ми розтягнули передачу і для того, щоб витекло десять кілобайт тексту, потрібно кілька сеансів роботи браузера і великий "легітимний" трафік для прикриття? Дійсно, користувач почитав сторінку і закрив її, а браузеру ще передавати і передавати. Відповідь: є кеш, читати текст сторінки потрібно з нього. Зазвичай браузерні кеш включений. Так, сторінки, отримані по https, не повинні б зберігатися в кеші, але ж наш шпигунський браузер може зробити виняток. Тим більше, не обов'язково кешувати текст сторінки в відкритому вигляді, можна перетворити його в деякий "службовий файл", - попутно стиснувши, так, - і зберегти так.

Інше питання: що взяти за основу для побудови каналу витоку? А тут годяться будь-які сервіси, які беруть якісь персоналізовані налаштування (наприклад, перевірка відвідуваних URL на "фішингових і шкідливість"). Стиснутий текст будемо передавати так: невеликі блоки підмішуються в токени, які браузер генерує при формуванні запиту на сервер. Нехай токен містить 64 байта. Припустимо, що 16 з них - це дані витоку. Тридцять запитів з токенами (не багато) - 480 байт. Хорошим кодуванням можна стиснути сюди приблизно 2500 знаків тексту (можна і помітно більше). Необов'язково підтримувати канал відкритим, поки не переданий весь зібраний текст (див. Нижче). Взагалі, немає ніякої необхідності, створюючи такий браузер, вбудовувати в нього зайву надійність. Механізми забезпечення такої надійності тільки видадуть затію. Центр посіяв багато браузерів в навколишнє кіберпростір. Якісь із них щось приносять, якісь - ні, вони зламалися. Нестрашно, численність джерел компенсує (для центру) ненадійність кожного з них.

Ось ще цікава ідея: ми домовилися, що наш шпигунський браузер - популярний, тобто в корпоративній мережі таких браузерів багато. Тому можна збільшити ширину тільки що описаного "стеганографічного" каналу: змусимо кожен окремий браузер передавати в рамках витоку блоки тексту не послідовно, а вибираючи їх випадковим чином (додамо мітки, - це лише кілька біт, - так що на іншому кінці зможуть відновити послідовність) . Таким чином, коли кілька браузерів "зливають" один і той же текст з інтранету, збільшується "миттєва" ширина каналу, це раз, і поліпшується надійність (резервування), це два. Остання особливість пов'язана з допущенням "дострокового" закриття каналу. При цьому, одночасна передача однієї і тієї ж сторінки все одно неминуча, тому що ми не можемо оперативно управляти браузерами-шпигунами, і центр не знає, що там вони знайдуть в закритих сегментах локальних мереж.

В коментарях до попередньої замітці висловили ще кілька ідей. Jno пропонує використовувати DNS для передачі частини зібраної інформації (як відомо, DNS-трафік добре долає всякі корпоративні брандмауери і рідко моніториться на предмет витоків). А Vlad пише, що не обов'язково передавати всі "внутрішні" сторінки поспіль. Спершу можна порахувати статистику тексту за ключовими словами і запитати центр, чи потрібна така сторінка. Правда, це має на увазі розвинену зворотний зв'язок, що може демаскувати канал витоку. До речі, браузеру добре б питати, чи є вже знайдена тільки що сторінка в базі, наприклад, передаючи хеш її тексту.

Взагалі, завдання визначення "секретних" сторінок - теж цікава (особливо, якщо немає зв'язку з центром). І її щось не взяли до уваги під час обговорення вкидання на тему Chrome.

Втім, все це добре, але залишається одна трудність: як заховати додаткову функціональність браузера всередині його коду. Можна припустити, що більшість користувачів не самі збирають браузер з початкових кодів, а задовольняються "бінарники". Такий розклад трохи простіше. Але ж і "бінарники" підлягають дослідженню. А популярний браузер фахівці розберуть дизассемблером вздовж і впоперек.

( Продовження про ризики і політику .)

()