Що робити, якщо у кабелів є вуха, або стеганографічне проксі

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

image
Світ цензури
Справа в тому, що останнім часом почалося активне поширення роскомнадзоров, СОРМов, золотих щитів, кореневих сертифікатів, чорних фургонів ФБР та інших методів прослушки/обмеження/підміни трафіку під всіма улюбленої мережі Інтернет.

На тлі цього, у багатьох почалася хвороба, чудово описується фразою «у стін є вуха». І було б це без приводу — але все ваші дані йдуть через маршрути, вам невідомі, через чорні коробки, вам не належать, сервера, вами не контрольовані, а скоро це все буде ще й зберігатися. Ну як тут не занервувати?

Кажуть, шифрування всіх врятує. Але чи це так? Опускаючи проблеми класичної та сучасної криптографії, так чи інакше, шифрований трафік завжди можна відносно легко виявити і банально прикрити канал передачі. І тут на допомогу приходить стеганографія.

Щоб відчути і зрозуміти, навіщо воно нам, поглянемо на класичну схему передачі трафіку від Аліси до Бобу в інтернеті:


Врахуємо, що інтернет і канали зв'язку в ньому нам непідконтрольні і вразливі by design. Більш того, між Алісою і Бобом є хтось, контролюючі середу передачі і що обмежують прослуховуючі/вставити своє слово) їх обмін повідомленнями.

Насправді, передача даних через через інтернет все більше нагадує проблему ув'язнених.

А схема виглядає так:


Де Віллі — не садівник, як здається на перший погляд, а охоронець, обмежує передачу будь-яких повідомлень до Бобу. Аліса ж — вільна людина (або укладений в іншій камері), з яким Боб хоче спілкуватися в обхід охоронця.

Відповідно, завдання стеганографії в тому, щоб охоронець просто не помічав обміну повідомленнями. А хто саме є охоронцем — ркп або фургончик фбр — приватні випадки.

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

Стеганографічний канал тоді буде створюватися просто поверх заздалегідь відомого каналу, підконтрольного Віллі. Розглянемо в якості прикладу реалізацію з використанням звичайних сокетів.

Стегоканал створюється підключенням Боба до Аліси через сокет на заздалегідь встановленому порту.


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

А тепер уявімо, що Віллі заборонив обмінюватися Бобу повідомленнями з Алісою. Взагалі.

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


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

А тепер про саму реалізації і те, що вийшло
Боб реалізований у вигляді звичайного проксі-ретранслятора типу [Socket-Stegochanel], слухача певний порт. Всі дані, що надходять на нього, він ховає в стегоконтейнеры з використанням заздалегідь обговоренного алгоритму і посилає по стегоканалу Алісі. Всі операції запису і вилучення проводяться за встановленим заздалегідь секретом (в стеганографії, в принципі, можна і без нього, обмежень на реалізацію немає).

Аліса типу [Stegochanel-Socket] приймає весь трафік від Боба по стегоканалу, витягує його з стегоконтейнеров і перенаправляє на справжній проксі сервер, який ви хочете використовувати, виділяючи для кожного екземпляра стегоканала окреме підключення до проксі (щоб не було плутанини). Адже хто знає заздалегідь, що за трафік і навіщо знадобиться пересилати, вірно?

І як воно працює?

Для тестування, в якості проксі-сервера я орендував дешевий ARM-сервер у франції, розгорнув на ньому Ubuntu 16.10 і на ній Squid разом з ретранслятором. Всі виміри проводилися з дому з інтернетом на 5 Мбіт/с через ADSL национальнейшего російського провайдера. Якщо хтось хоче перевірити на нормальній швидкості — в кінці залишу посилання на GitHub.

Як proof of concept я реалізував стегоканал поверх сокетів. Якщо буде інтерес — аналогічне тестування проведу і для реалізації з VK в якості середовища обміну. В якості алгоритму — свій власний варіант методу LSB з максимальною ємністю приблизно в чверть байт від загального числа пікселів, працює із зображеннями без стиснення, про який, можливо, напишу пізніше. В якості контейнера спочатку використовувалося одне єдине зображення Че Гевари в png дозволом 518х587.

Результати тестування як проксі в firefox без будь-яких плагінів і доп. параметрів:

  • wikipedia.org — 1:13;
  • en.wikipedia.org — 2:01, після цього спілкування з сервером триває, але весь контент вже завантажений;
  • google.com (.fr) — ~2м, підказки не працюють, пошукова видача вантажиться по хвилині;
  • duckduckgo.com — так і не завантажився протягом 10 хвилин;
  • txti.es — ~3с на сторінку. І правда, fast web pages;
  • garfield.vexer.ru — 1:35. Реклама при цьому не завантажилася (і адблок не потрібен);
  • reddit.com — вантажиться дуже довго (більше 10 хвилин), то завантажує, але терпіння у вас навряд чи вистачить;
  • bing.com — 1:45 на повне завантаження. ~50 секунд на сторінку пошукової видачі;
  • jcgonzalez.com — не завантажився;
  • minergate.com — 4м;
  • vk.com — ~1м, зображення довантажуються)) довше, діалоги працюють шустро;
  • linkedin.com — ~50c, але величезне зображення-фон буде ще довго грузиться;
  • weather.com — не завантажився;
Варто зауважити, що подібні швидкості (дуже скромні, особливо, якщо подивитися на календар) пояснюються не тільки тим, що стеганографія передає надмірну кількість інформації, але і накладними витратами на сам стеганографічний алгоритм. А очікувати від ARM-сервера за 3 зелених президента чогось незвичайного в плані продуктивності було б дивно. Оренда більш швидкого сервера дає сильне прискорення (в 2 рази на старому слабкому х86 сервері).

Відключивши зображення та медіа-елементи, включивши адблок, швидкість можна підвищити. Перемістившись таки методом на 10 років (15?) тому, отримуємо відповідну того ж часу швидкість завантаження сторінок. Але в цілому, висновок залишається тим же — таке стеганографічне проксі годиться тільки для екстрених випадків.

Враження від такого інтернету далеко не позитивні. Можливо, з іншими методами стеганографії, або просто оптимізуючи мій, можна досягти великих результатів. Однак, поки що, отриманий Proof of Concept говорить лише про те, що таке проксі годиться тільки для екстрених випадків. Що, насправді, не дивно. Або несподівано. Більша частина проблем із затримками — таймінги при рукостисканні у ssl. Ось вам і повсюдне насадження https.

Подумавши, було вирішено замінити бідного статичного Че Гевару на випадкові зображення з мінімальною надлишковістю. Адже якщо передавати не в 16 разів більше інформації, а у 4, то теоретично, отримаємо приємний бонус до швидкості. Благо, генераторів випадкових зображень заданого розміру в інтернеті повно.

Результати при повторному тестуванні:

  • wikipedia.org — 21с;
  • en.wikipedia.org — 21с;
  • google.com (.fr) — 23с до працездатності, 45с до повної завантаження, 3с на видачу;
  • duckduckgo.com — 45с до працездатності, 55с до повного завантаження;
  • txti.es — миттєво;
  • garfield.vexer.ru — 1:10 разом з рекламою, наступні стрипи вантажаться секунд на 10, так як все найтяжче вже в кеші;
  • reddit.com — 44с без вмісту, 1:20 з його превью;
  • bing.com — 13с повне завантаження, 5с на видачу з картинками;
  • jcgonzalez.com — упав, але 404 видає швидко;
  • minergate.com — 1м;
  • vk.com — 23c, сторінки з повідомленнями за секунд 10 і більше, в залежності від вмісту;
  • linkedin.com — 40c;
  • weather.com — не завантажився;
З таким інтернетом жити вже можна, особливо, якщо мало альтернатив. Стеганографічна стійкість падає з підвищенням відносини шум/корисна інформація, жертвувати чи ні — вирішувати не мені.
На цьому вважаю експеримент завершеним. Исходники, бінарники, інструкції по застосуванню і допомоги знаходяться на гітхабі нижче. Якщо будуть додаткові запитання — буду чекати в коментарях.

GitHub
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.