Мир цензуры
Дело в том, что в последнее время началось активное распространение роскомнадзоров, СОРМов, золотых щитов, корневых сертификатов, черных фургонов ФБР и прочих методов прослушки/ограничения/подмены трафика во всеми любимой сети Интернет.
На фоне этого, у многих началась болезнь, прекрасно описываемая фразой «у стен есть уши». И было бы это без повода — но все ваши данные идут через маршруты, вам неизвестные, через черные коробки, вам не принадлежащие, сервера, вами не контролируемые, а скоро это все будет еще и сохраняться. Ну как тут не занервничать?
Говорят, шифрование всех спасет. Но так ли это? Опуская проблемы классической и современной криптографии, так или иначе, шифрованный трафик всегда можно относительно просто обнаружить и банально прикрыть канал передачи. И тут на помощь приходит стеганография.
Чтобы проникнуться и понять, зачем оно нам, посмотрим на классическую схему передачи трафика от Алисы к Бобу в интернете:
Учтем, что интернет и каналы связи в нем нам неподконтрольны и уязвимы 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
Комментарии (42)
ton1
09.01.2017 14:58+1А почему бы не прикидываться видеопотоком? А в нем белым шумом. Так и трафика можно больше завернуть. Т.е. для прослушивающего чтоб выглядело как трансляция с древнего аналогового телика не настроенного на канал. Обычный mpeg поток, до некоторого градуса ***комнадзора вполне должно работать.
Labunsky
09.01.2017 15:25И так можно, это все варианты реализации одной и той же схемы. Разве что проблемой будет повышенное требование к скорости кодирования скрываемой информации внутрь кадров, но это решаемо
DrZlodberg
09.01.2017 17:58Кодеки «с потерями» очень не любят шум. Будет или огромный размер на выходе, или вся весь «шум» превратится в кашу.
Не силён в теме, однако напрашивается вариант использовать не один, а два хитро собранных потока, чтобы низкие частоты в обоих при сдвиге добавляли сумме потоков высоких частот. Сходу, правда, оценить работоспособность идеи не в состоянии.
gurux13
09.01.2017 19:19Правильно ли я понимаю, что хочется сделать так, чтобы всякие MITMы не поняли, что идёт обмен сообщениями? Тогда как только они находят Ваш алгоритм, они запускают его на всех подряд картинках и смотрят, получается ли из них HTML. Тем более, что такой поток картинок сам по себе слегка подозрителен.
Кажется, это заработает только если данные, которые стеганографией включаются в картинку, шифровать и делать неотличимыми от шума. Иначе, если будут отличия, методами ТРКА алгоритм шифрования и ключ получат.
Ну и да, ещё можно закосить под существующий протокол с шифрованием. Кажется, что простой ssh на удалённый хост будет менее подозрителен. С проверкой серверного и клиентского сертификатов, конечно.Labunsky
09.01.2017 19:38Тогда как только они находят Ваш алгоритм, они запускают его на всех подряд картинках и смотрят, получается ли из них HTML.
Проблема в том, что помимо моего алгоритма, есть сотни других. Более того, придется брутфорсить ключ (тот, что реализован в контексте статьи имеет симметричный ключ).
Уже это требует слишком больших мощностей, чтобы одновременно проверять весь проходящий траффик. А шифрование скрываемой информации — почти стандарт де-факто, обязательно добавлю со следующим пушем
Тем более, что такой поток картинок сам по себе слегка подозрителен.
На это я и сам указываю в статье:Но, это не совсем стеганография. Для Вилли вполне очевидно, что обмен картинками на нестандартных портах — неспроста.
Пока что все это работает исключительно в виде Proof of Concept того, что такое прокси в принципе можно написать и оно будет комфортно работать. Понятное дело, что многое еще стоит доработать, но об этом я уже буду писать в будующих статьях :)gurux13
09.01.2017 19:58+2Раздавать каждому свой алгоритм — это security through obscurity. То есть, надо упирать на неотличимость сообщений от шума. Поток картинок в одно и то же место в любом случае отличим от шума. Не так много народу постоянно спамит картинками.
Да, и ещё — если бы я был всесильным MITMом и знал хоть что-то про картиночную стеганографию, я бы во все картинки добавлял свой шум.
ИМХО, реальный способ маскировать трафик — это делать его очень похожим на трафик живого человека или какой-нибудь автоматики. Например, шуметь в IP-камерном видео. Куча камер же наружу трафик выдаёт. Или, скажем, под вирусню косить. Или ещё что-то, главное, чтобы не было нетрадиционного трафика, даже если он со всех сторон законный.Labunsky
09.01.2017 20:14Раздавать каждому свой алгоритм — это security through obscurity.
Никто не спорит, но при реалистичной оценке стоит учитывать и этот очевидный фактор. Я не ставлю его во главу угла, но считаю, что и игнорировать не стоит
Да, и ещё — если бы я был всесильным MITMом и знал хоть что-то про картиночную стеганографию, я бы во все картинки добавлял свой шум.
Не картинками едиными, они были выбраны для примера только потому, что под рукой был готовый алгоритм с ними в основе. Но да, против нынешней реализации (но не против всех, есть алгоритмы, устойчивые к шуму) это сработает
Со всем остальным полностью согласен, разве что нет смысла маскироваться под трафик живого человека — там скорости будут явно не для проксирования трафика
il--ya
10.01.2017 14:44Очень хорошее возражение — про то, что MITM может слегка «портить» данные. Причём и предлагаемое вами видео тоже можно «портить». Но это уже при очень большом градусе.
Labunsky
10.01.2017 15:08Задача порчи данных «на лету» не самая простая. Особенно это касается классической текстовой стеганографии — «портить» текстовые сообщения, передающиеся в какую-нибудь социальную сеть — это уже нечто запредельное
vadimr
11.01.2017 00:15Насколько я понимаю, сотовые операторы уже сейчас автоматически детектируют и пережимают передающееся через них видео.
rPman
11.01.2017 11:58как!?
vadimr
11.01.2017 12:05Ну как? Видят, что абонент обращается за видеопотоком, и вклиниваются посередине. Пока что, как я понимаю, это происходит только в случае без шифрования соединения.
rPman
11.01.2017 19:12даже не знаю как спросить
ладно забудем про как (отдельный разговор сколько это будет стоить при пересчете на ОДНОГО клиента, мои скромные прикидки говорят что на порядок дороже выгоды с трафика)
давайте задам вопрос — зачем?vadimr
11.01.2017 19:16Я за них не отвечаю, поэтому не могу удовлетворить Ваше любопытство. Считается, что они таким образом сокращают трафик в своей сети.
Labunsky
11.01.2017 19:33мои скромные прикидки говорят что на порядок дороже выгоды с трафика
Так или иначе, система DPI есть сейчас почти у любого провайдера в том или ином виде -> окупается каким-то образом, что не особо весело
давайте задам вопрос — зачем?
Если исходящий — чтобы меньше трафика гнать на магистрали. Если входящий — снижать нагрузку на сеть (меньше трафика на устройство — лучше)
К сожалению, достоверно неизвестно (по крайней мере, мне), при передаче по каким протоколам мегафон делает такие пакости
VT100
09.01.2017 22:37Несколько лет назад видел статью о достаточно простой детекции стеганографии в картинках. Маскируя в 0 старшие биты цветов считают энтропию(?) оставшихся младших. По крайней мере, картинки до и после, сформированные только из младших бит, — отлично отличимы визуально.
Labunsky
10.01.2017 00:44Схожим образом работают библиотеки и программы вроде StegExpose. Такие методы довольно хорошо работают против простых алгоритмов. Но нельзя сказать, что они универсальны и работают в 100% случаев.
Из интереса сейчас прогнал ею большую выборку стегоконтейнеров, полученных в результате работы прокси. В качестве подозрительных она пометила 133 из 439 стегоконтейнера при их размере 200х45 и embedding rate ~25%.
Но дело в том, что я специально стремился уменьшить избыточность при передаче данных из-за медленной скорости в первом тесте. Для интереса, хардкорно заставил использовать прокси изображения 500х500 (цифра с неба). И все, программа больше не видит в получившихся стегоконтейнерах ничего подозрительного — 0/364.
Более того, сразу вскрывается минус такого анализа — при увеличении размера стегоконтейнеров время обработки их анализатором возрастает нелинейно — я успел заварить чай, пока ноутбук переварил сотню стегоконтейнеров
semen-pro
10.01.2017 12:45Кстати, сейчас можно за 50 рублей в месяц безлимитно передавать трафик в вк, через мобильную сеть. Было бы оптимально для интернета вещей.
Labunsky
10.01.2017 12:45А подробностей можно? Не слышал об этом ранее
semen-pro
10.01.2017 13:16У красного оператора есть соответствующая услуга. Вк, фейсбук и одноклассники за 50 руб в месяц. Она входит в стоимость популярных пакетов, типа смарт (трафик не считается), но можно и отдельно подключить. В общих чертах, есть идея написать бота, и управлять устройством через вк. Ну или для каких других целей… Можно ребёнку на телефоне фаерволом всё, кроме вк вырубить...
MrRitm
11.01.2017 19:41Помнится где-то лет около 10 назад читал обсуждение возможности организации тотальной слежки за трафиком пользователей. Тогда как раз кто-то и сказал, что до такого маразма не доживем, а если уж вдруг доживем, то будем маскировать под битые файлы картинок свой трафик, передавать будем по псевдослучайным портам, с шифрованием и т.п. Tor тогда вроде только зарождался как и прочие VPN. Дожили…
А на счет «ребенку вырубить и чтоб бота написал» — идея более чем здравая. Я вот своему (как подрастет) разрешу играть в любые игры на компьютере с Linux. К тому моменту как он запустит и в полной красе увидит современную игрушку, он уже будет специалистом :-)
SunX
12.01.2017 15:01При всем моем уважении, Вы ту же Убунту давно запускали? Steam давно пришел на Линукс и игрушки в нем теперь «просто работают» (Ну естественно те, что поддерживают Linux). Т.е. это не сделает ребенка специалистом ну совсем никак. Максимум — научит гуглить, где переключить опенсорсные дрова для видюхи на проприетарные.
Или Вы планируете выдать ребенку гугл и LiveCD+stage3 от генты, а дальше уже пусть сам? :)MrRitm
12.01.2017 15:10Вот именно! Про генту как-то не подумал, хотя идея интересная. В планах была OpenSuse + wine
Что, реально стим и игры на линухах есть?! Не, ну вы что, серьезно?! Я вот как-то Quake 2 под вайном пускал. Не скажу, что это очень сложно. Но повозиться пришлось. Еще какой-то кризис для теста пускал. Сравнить линуховые проприетарные драйверы под Нвидиа с виндовыми. Дальше заставки правда не заходил. Свое субъективное мнение сложившееся после эксперимента оставлю при себе.
Да-а-а… Дожили… Кругом слушают и подглядывают и игрушки под Linux! Реально не верится! Просто офигеть!SunX
12.01.2017 18:26Честно говоря не совсем распознаю, стебетесь Вы или как-то умудрились пропустить много новостей о Steam'е, но: http://store.steampowered.com/search/?os=linux
Если верить выдачЕ, то есть примерно 6267 игр под Linux. Wine, конечно, тоже никто не отменял, если нужна Windows-only игра (хотят тут уже могут быть, и скорее всего будут, особенности)
А так же стим сделал свою приставку на базе StemOS (Читать: Линукса) и Steam.
Не скажу за OpenSuse, но на Ubuntu, Debian и Gentoo все замечательно работает, ровно так же, как и в винде: Зашли в Стим, нажали установить, вжух и игра скачана и запускается.MrRitm
12.01.2017 18:35+1Не, я честно не стебусь. Просто про стим последнее что помню — они какое-то отношение к первому халф-лайф имели. Тогда еще были компьютерные клубы и диал-ап модемы. Играть толком никогда не играл (после Doom2 как-то не особо интересовало). А вот запустить игру под Linux — это меня забавляло. Чтож… Надо будет как-то скрыть от подрастающего поколения, что есть нативные версии игр под Линукс. Я то хотел, чтобы он как подрастет сначала узнал бы, что такое ОС, библиотеки, драйвера и прочее. А потом глядишь и уже не надо будет ему игрушки. Консоль — лучшая игра на свете! Сюжет пишется по ходу, квесты всегда новые да еще и денег за решение дают! Последние лет 10 играю — пока не надоело ;-)
rPman
Есть замечание, картинки необходимо использовать исключительно уникальные, дабы не было возможности получить доказательство их 'не целевого' использования путем сравнения с оригиналом.
Например видеотрансляция.
unxed
Или из google image search по запросам про котиков. Ну, например.
unxed
Ну, кстати, вот вопрос: насколько возможно достоверно идентифицировать стеганоконтейнер в отличие от, скажем, просто пережатой картинки?
rPman
элементарно, пережимаем картинку и сравниваем итог с подозрительной, при должном старании можно прогнать большое количество параметров пережатия, отличных от дефолтных (что не обязательно), сам факт отсутствия комбинации параметров, приводящих к идентичному с подозрительной картинкой результату уже само по себе доказательство.
Обнаружить сами скрытые данные в картинке — в общем случае, невозможно.
Klukonin
WAT?!
Отсутствие возможности повторить рандомную картинку с использованием других рандомных картинок, предположительно, являющихся оригиналом, является ДОКАЗАТЕЛЬСТВОМ?!
Да вы сбрендили, сударь.
Попробуйте в нормальном суде втирать подобную дичь.
Любой, даже самый неквалифицированный адвокат достаточно быстро проведет вам ликбез по основам права, заодно и по основам логики.
rPman
я говорю про автоматическое детектирование а не о доказательной базе, само собой сам факт наличия 'похожей' картинки ничего не доказывает.
icoz
вы при этом забываете, что Вилли видел какую картинку вы качали, а какую отправляли…
Romiro_Orimor
Делайте фото ковра.
Labunsky
В таких случаях обычно используют подобные ковры
icoz
А много раз пересланный ковёр тоже не внушает никаких подозрений
vadimr
Сам факт систематического размещения пережатых картинок вызывает подозрение, что не всё с ними так просто.
Labunsky
Какие контейнеры и как использовать — зависит от ситуации, алгоритмов и кучи других факторов.
В общем случае да, стоит использовать только уникальные. Лично я использовал во время второго теста этот сайт (не реклама, просто первая ссылка из гугла)
il--ya
Несколько десятков раз обновил картинку 400x200, получил очень много повторов. Судя по всему, там около сотни картинок, которые выдаются рандомом. Одна из картинок — чёрный прямоугольник. Наверно, не лучший исходный материал для стеганографирования.
Labunsky
Да, сам заметил, когда брал выборку для комментария ниже. Исправим, заранее об этом не знал, что поделать