Pull to refresh

Comments 69

Ну зачем же, просто проапдейтят СОРМы )) По крайней мере, вряд дадут использовать эту технологию, если не будет хоть какого-нибудь контроля
Что-то я не уловил. Если за обычными пакетами TCP следят, то почему не могут следить и за ретрансмиссией? Они же принципиально ничем не отличаются.
Они просто не смогут разобрать где какие, как я понял
Ага, когда ретрансмиссия используется в обычном режиме, то клиент прекрасно разбирает все. Но при этом количество ретрансмиссий несравнимо меньше с количеством обычных сообщений, поэтому уж их то можно не напрягаясь отследить.
Теоретически можно поймать и на пересылке в ретрансмиссии. Но практически это сделать очень сложно. Через даже среднего провайдера в секунду проходит столько пакетов, что всех их проинспектировать очень затруднительно в плане вычислительных ресурсов. Если бы целиком все TCP соединение представляло собой тайную переписку, то достаточно было бы поймать и проанализировать всего лишь несколько пакетов. Но как было правильно подмечено, ретрасмиссия происходит достаточно редко поэтому поймать становится еще во много раз сложнее чем случае с целым TCP соединением.
Ну почему же, на очень низкой скорости вполне можно сделать такой скрытый канал, а для передачи шифровки одного байта в секунду вполне хватит.
Тем, что ретрансмиссии пока не логируют.
Ух, достаточно интересная, но сложная в реализации вещь
Да, сами авторы даже и не стали реализовывать — ограничились симуляцией. А вообще тема интересная, но что-то хабронарод не впечатлила. Видимо сложноват материал для среднего хабраюзера.
Я думаю, впечатлила бы больше, если бы была реальная реализация этого метода, который можно было бы попробовать.
Это, разумеется, не в к Вам претензия :)
Ничего сложного, строго говоря, вопрос только в том, что таки вещи не стоит афишировать. Можно-же инкаспулировать информацию в ICMP пакеты, причем когда я это упоминаю, даже не все ай-тишники понимают как это может быть.
icmp — это уже старая песня. когда приложение, которое не хочет чтобы его обнаружили, тихо шлет пинги куда надо и в них передает скрытую информацию. а вот посылать тихо битые пакеты — это уже интересный случай.
другой момент меня заинтересовал а не проходит ли проверка целостности передаваемой информации на маршрутизаторах? т.е. уйдет ли битый пакет дальше первого умного роутера?
А куда спешить? Борцуны только начали читать RFC, толи еще будет.
Любой JS у тоталитарных спецслужб вызовет подозрение, да и стеганография на JS и без переписывания TCP/IP стека не впечатляет.
UFO just landed and posted this here
Хм, метод действительно интересный, а при использовании в купе с криптографией так и подавно… но как быть с маршрутизацией таких пакетов? Они ведь должны не отличатся от других пакетов данной сессии иначе сразу станут видимыми, и как же они дойдут до нужного получателя и нужного порта?
Все верно, а зачем им отличаться? Они выглядят как обычная ретрансмиссия для этого соединения — те же порт, IP, правильные sequence number и так далее. Просто вместо «обычных» данных вставляем «тайные».
Можно информацию передавать самим фактом повторной передачи пакета.
Перехватить и расшифровать непросто, а вот «глушилку» поставить вполне реально. Кто мешает проксировать пакеты TCP и заниматься сборкой данных на устройстве-глушилке, а затем их пересылать получателю имитируя отправку от адресата? Поскольку данные проходят спецоборудование до того, как пойдут в сторону получателя (или, наоборот, сразу же после того, как попадут в подсеть назначения), то никакие ложные ретрансмиссии не помогут. На запрос ретрансмиссии «глушилка» честно ответит полученными данными.
Ну в общем да, как только такой метод упомянули в широкой аудитории, им уже нельзя пользоваться. :)
Резонно, но отсутствие глушилки легко установить: если стеганографические сообщения Бобу поступают, значит её нет. И Алиса может пока продолжать пользоваться этим методом.
UFO just landed and posted this here
Нет, не отменили. Но все дело в том, что при помощи сокетов нельзя полностью контролировать работу TCP. Например нельзя «заказать» ретрансмиссию когда захочется. Если исходный пакет был получен корректно, то ядро не будет посылать запрос на ретрансмиссию — зачем? И, кстати, если все-таки «тайная» ретрансмиссия будет иметь место, то обычное ядро будет отбрасывать такие пакеты считая их дубликатами, ведь sequence number у них будет совпадать с уже полученными пакетами. Кратко говоря, для этого метода нужно иметь возможность контролировать работу TCP/IP стэка на уровне ядра, уровень raw socket'ов слишком высок для этого.
Но менять стек не надо все равно. Сниферы ведь работают и получают все пакеты включая ретранслированные. А это обычные программы пользовательского уровня.
Имеется в виду изменение стэка не для перехвата и анализа, а для реализации самого метода.
Дык! для реализации метода потребуется raw-сокет на отсылку и libpcap-снифер захватывающий все пакеты для приема.
Ну, в принципе можно попытаться это сделать и так, но несовсем понятно как именно. Вам тогда придется все TCP соединение реализовывать при помощи raw-сокетов. Потому что в противном случае вы не будете знать когда именно посылать «тайный» пакет. Он же не наобум посылается, а когда приниматель просит это.
В сети масса полуготовых приложений на libpcap и даже полноценные библиотеки реализующие tcp.
Но я слишком давно этим интересовался чтобы вспомнить названия.
Ну а изучить и модифицировать такую библиотеку не сложнее чем TCP/IP стэк в ядре, поскольку они делают фактически тоже самое.
И все-таки, ковыряние и отладка в ядре осложнены низкоуровневой спецификой, а библиотечные интерфейсы вполне по силам толковому прикладному программисту.
Ну, можно просто опустить IP-стек на нужном интерфейсе и/или не отдавать пакеты ядру, дропая их где-нибудь в файрволе.
Если «норма» потерянных пакетов составляет 0.1%, тогда и скорость передачи такой информации составит одну тысячную от нормальной скорости канала (то есть от 2 мбит останется 2 кбита), иначе этот канал просекут в момент по подозрительно большому количеству ретрансмиссий
Совершенно верно подмечено, это действительно один из недостатков метода.
А точнее одну десятитысячную — чтобы норму потяренных пакетов не нарушать )
Верно, письма посылать можно будет, а фотки и видео — уже нет.
Провайдер не всегда знает норму последней мили, особенно в случае слабого сигнала от wi-fi-роутера, который раздаёт интернет по квартире :-)
что этим методом хотят скрыть? факт установки соединения остается. факт передачи данных тоже. чисто статистически «тайные» данные лучше передавать в обычных пакетах, ведь таких пакетов гораздо больше, чем ретрансмиссионных.
Все верно. Но при этом в статье также рассматриваются случаи когда отправитель оригинальных пакетов, получатель оригинальных пакетов или же оба не знают о факте передачи скрытых данных. Т.е. в этих случаях стороны, обменивающиеся стеганограммой частично или полностью «паразитируют» на существующих соединениях. В этих сценариях факт установки соединения и факт передачи данных роли не играют, поскольку конечные узлы — не участники «тайной» передачи. Само собой в этих сценариях есть недостаток — паразитирующие узлы должны иметь возможность перехватывать все пакеты в соединении.
>Суть предложенного метода состоит в том, чтобы в пересылаемом сообщении отправлять не то, что было в первичном пакете…

Отловить такие пакеты элементарно, сам факт различия является признаком того, что пора готовить паяльник.

Кстати, понятие «пакет» не применимо к TCP (в отличие от UDP).
Кстати, понятие «пакет» не применимо к TCP (в отличие от UDP).

любопытно. почему?
Да, мне тоже любопытно.
Кажется человек просто придирается к словам, вот перечитал RFC — «Термин пакет в данном документе используется в основном для обозначения одной транзакции между хостом и его сетью». Так что в TCP есть пакеты и это понятие вполне применимо
Возможно, хотя мне кажется, что предложение «The term packet is used generically here to mean the data of one transaction between a host and its network» можно понимать и по-другому. А если точнее, то «transaction», как мне кажется — это акт единичной передачи порции данных, т.е. фактически один пакет. Хотя даже если я заблуждаюсь, то с 1981 года многое молго измениться и сейчас, я совершенно уверен, употребляют выражение «TCP пакет».
TCP оперирует байтами и ориентирован на поток данных.
Программно нельзя просто так заведомо передать пакет. Операционная система будет складировать все в буфер и выдавать в сеть сегменты информации по своему усмотрению. То же самое может произойти на особо умных маршрутизаторах и уж тем более на прокси. На приеме операционка опять все складирует в буфер и выдает программе.

Т.е. приняв сегмент TCP нельзя точно сказать что программа на другой стороне передала именно такой кусок.

Например, поток данных 123456789 программа передавала следующим образом: 1 234 56 789, на приеме можно получить, например, 1234 56789.

Есть, конечно, PUSH, но опять-таки не гарантируется что на выходе получим сегмент нужного размера. Да и смысла в этом нет. PUSH сделан для ускорения доставки, чтоб информация поменьше залеживалась в буферах.
UFO just landed and posted this here
Чем же так TCP отличается UDP? Святым духом, что ли, передаётся?
Без установления соединения и всеми вытекающими отсюда последствиями.
Впринципе интересный способ, но есть смысл его слегка развить. Например записывать в резервные 6 бит некую мета-информацию… или в опциональные байты заголовка…
в качестве мета-информации можно например взять порядок следования пакетов или частоту их следования относительно обычных ретрансмиссий
Отличные предложения. На самом деле, если Вам интересно, то в статье авторы разбирают многие из техник, которые Вы предложили (и придуманы они уже давно). Всего авторы приводят 3 типа стеганографии при помощи TCP: (i) модификация пакетов и хедеров, (ii) модификация свойств соединения (изменение порядка следования пакетов, варьирование времени между пакетами и т.д.) и (iii) гибридные. Свой метод авторы относят к последней категории.
Такие вещи уже давно используются.
я знаю что используются;) я предложил что можно добавить к данному методу
Более чем уверен, что хорошие IDS, использующие поиск аномалий в трафике распознают эту стеганографию с полпинка.
Эффективней тогда уж тогда обычной стеганографией пользоваться в образах DVD-фильмов или в авишках, косяк в 1 пикселе на фрейме вряд-ли кто заметит, а даже если и заметит — извиняйте хреново пожалось. Опять же при закрытом алгоритме размещения пикселя в кадре — замучаешься доказывать и расшифровывать.
И никто не докапается — а почему у тебя потери пакетов выше нормы? ;)
Я так понимаю, посылатся обычный пакет и ретрансмиссия.
Тогда передача обнаруживается простым сравнением этих пакетов. Не так ли?

Хотя идея хороша, еее только нужно хорошенько обдумать, покурить TCP/IP.
имхо, проще секретный документ запаковать в шифрованный файл siski_podrugi.rar и отправить обычным smtp :)

чем не точно такая же стеганография — нельзя, ведь, быть точно уверенным — что именно было в архиве :)
Проще придумать свой или использовать какой-нить «мертвый» язык, на котором никто не говорит кроме вас и ващего адресата. В таком случае сообщения можно даже не шифровать, а писать прямым текстом, пусть дядечки читают смысл все равно им будет не понятен :)

Н ыпра нчог ыдганду :)
В топике не про шифрование данных, а про сокрытие факта передачи.
Если вы выйдете в центр города и начнете кричать бессмыслицу вроде «Н ыпра нчог ыдганду», думаете, милиция вас не услышит? ;-)
Помимо того, что пропускная способность этого метода чудовищно низкая (как уже заметили в каментах выше), у этого метода ещё один существенный минус. Передача не защищена от ошибок на уровне TCP, т.к. сам этот метод паразитирует на средстве защиты.
Или я ничего не понял, или одно из двух. Этим методом вы пытаетесь скрыть сам факт передачи данных? Это при том, что в IP пакете явно прописан IP адрес получателя пакета, а в TCP — номер порта получателя. Таким образом, явно видно, что некие данные (не важно какие именно) пересылаются из токи А в точку Б. Ну и где здесь скрытая передача данных?
в том что порт этот может быть портом http. из цепочки пакетов сниффер покажет что пользователь просто ходил по сайту. а на самом же деле между хостами среди пакетов запросов ответов HTTP шел обмен данными другого рода.
Между какими хостами? Между клиентом и сайтом? Да, шел обмен данными, среди которых были конфиденциальные данные. Где здесь сокрытие факта передачи данных, я вас спрашиваю?
Подобный вопрос уже был выше, под ним и ответ. Повторюсь, во-первых можно пытаться скрыть факт передачи тайной информации. Тогда факт наличия соединения не играет роли — мы не пытаемся его скрыть. Во-вторых если все-таки нежелательно чтобы вообще знали о факте хоть какой-нибудь передачи, то как я писал выше, отправитель и получатель «нормальных» данных может вообще и не знать о факте тайной переписки.
Не знаю что там используют Специально Обученные Люди, но повторно переданные пакеты подсвечивает другим цветом наиболее известный бесплатный софт для анализа — wireshark. Если у обьекта наблюдения на фоне остального нормального трафика пакеты по конкретному адресу постоянно красные, это тут же наведет аналитика на мысли.
Все верно, вопрос тут в том куда смотреть. Если у вас в секунду более 1000 TCP соединений в каждом из которых по 1000 пакетов, то Wireshark тут не помощник — в ручную перелопатить такой объем данных нереально.
Один человек столько не генерирует. Специально Обученные Люди действуют по решению суда или по секретному приказу начальника ( ну это в теории). В этот момент за кем наблюдать уже известно и трафика не так уж много.
Не вижу проблемы.
Верно, если знать куда смотреть, то проблемы нету. Весь смысл метода и заключается в том, чтобы скрыть тайную пересылку в куче пакетов и соединений.
Sign up to leave a comment.

Articles