Пользователь
0,0
рейтинг
28 мая 2009 в 16:25

Разработка → TCP стеганография или как скрыть передачу данных в интернете

image

Польские исследователи предложили новый способ сетевой стеганографии основанный на особенностях работы широко распространенного протокола транспортного уровня TCP. Авторы работы считают, что их схема, к примеру, может применяться для пересылки скрытых сообщений в тоталитарных странах вводящих жесткую интернет цензуру. Попробуем разобраться в чем, собственно, состоит нововведение и насколько оно действительно полезно.



В первую очередь нужно определить что такое стеганография. Так вот, стеганография — это наука о скрытой передаче сообщений. То есть используя ее методы стороны пытаются скрыть сам факт передачи. В этом и состоит отличие этой науки от криптографии, которая пытается сделать недоступным для прочтения содержание сообщения. Стоит отметить, что профессиональное сообщество криптографов достаточно презрительно относится к стеганографии в силу близости ее идеологии к принципу «Security through obscurity» (не знаю как это правильно звучит по-русски, что-то вроде «Безопасность через незнание»). Этим принципом, к примеру, пользуются в компании Skype Inc. — исходный код популярной звонилки закрыт и никто толком не знает как именно осуществляется шифрование данных. Недавно, кстати, об этом сетовали в NSA, о чем известный специалист Брюс Шнайер написал у себя в блоге.

Возвращаясь к стеганографии, ответим на вопрос а зачем она вообще нужна, если есть криптография. Действительно, ведь можно зашифровать сообщение при помощи какого-либо современного алгоритма и при использовании достаточного длинного ключа никто это сообщение прочитать не сможет если только вы этого не пожелаете. И тем не менее, иногда бывает полезнее скрыть сам факт тайной передачи. К примеру, если соответствующие органы перехватили ваше зашиврованное сообщение, расшифровать не могут, но очень хочется, то в конце концов есть и некомпьютерные методы воздействия и добычи информации. Звучит антиутопично, но, согласитесь, такое в принципе возможно. Поэтому лучше бы сделать так, чтобы те кому неположено вообще не знали, что передача имела место. Польские исследователи как раз и предложили такой метод. Причем сделать они это предлагают при помощи протокола, который каждый пользователь интернета использует по тысяче раз на дню.

Тут мы вплотную подошли к Transmission Control Protocol (TCP). Объяснять все его детали, разумеетется, не имеет смысла — длинно, скучно, те кому надо и так знают. Вкратце же можно сказать, что TCP — это протокол транспортного уровня (т.е. работает «над» IP и «под» протоколами уровня приложений, к примеру HTTP, FTP или SMTP), который обеспечивает надежную доставку данных от отправителя к получателю. Надежная доставка означает, что если какой-то пакет потерялся или пришел с изменениями, то TCP позаботится о том, чтобы переслать этот пакет. Отметим, что под изменениями в пакете тут подразумевается не умышленное искажение данных, а ошибки в передаче возникающие на физическом уровне. К примеру, пока пакет шел по медным проводам пару бит поменяли свое значение на противоположное или вообще затерялись среди шума (кстати для Ethernet значение Bit Error Rate обычно принимают равным порядка 10-8). Потеря пакетов в пути также относительно частое явление в интернете. Происходить она может, к примеру, из-за загруженности маршрутизаторов, которая приводит к переполнения буферов и как следствие отбросу всех вновь прибывающих пакетов. Обычно доля потерянных пакетов составляет около 0.1%, а при значении в пару процентов TCP вообще перестает нормально работать — у пользователя все будет жутко тормозить.

Таким образом мы видим, что пересылка (ретрансмиссия) пакетов явление для TCP частое и в общем-то нужное. Так почему бы не использовать его для нужд стеганографии при том что TCP, как уже отмечалось выше, используется повсеместно (по разным оценкам на сегодняшний день доля TCP в интернете достигает 80-95%). Суть предложенного метода состоит в том, чтобы в пересылаемом сообщении отправлять не то, что было в первичном пакете, а те данные, которые мы пытаемся скрыть. При этом обнаружить такую подмену не так-то просто. Ведь нужно знать куда смотреть — количество одновременных TCP соединений, проходящих через провайдера просто огромно. Если знать примерный уровень ретрансмиссии в сети, то можно подстроить механизм стеганографической пересылки так, что ваше соединение ничем не будет отличаться от других.

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

Авторы работы (кстати, кому интересно, вот она) на уровне симуляций показали, что предложенный метод работает как задумано. Возможно, в будущем кто-нибудь займется реализаций их идеи на практике. И тогда, будем надеяться, в интернете станет чуть меньше цензуры.
@nil
карма
23,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (69)

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

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

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

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

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

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

        Есть, конечно, PUSH, но опять-таки не гарантируется что на выходе получим сегмент нужного размера. Да и смысла в этом нет. PUSH сделан для ускорения доставки, чтоб информация поменьше залеживалась в буферах.
    • 0
      а не путаете с датаграммой?
    • 0
      Чем же так TCP отличается UDP? Святым духом, что ли, передаётся?
      • 0
        Без установления соединения и всеми вытекающими отсюда последствиями.
  • +1
    Впринципе интересный способ, но есть смысл его слегка развить. Например записывать в резервные 6 бит некую мета-информацию… или в опциональные байты заголовка…
    в качестве мета-информации можно например взять порядок следования пакетов или частоту их следования относительно обычных ретрансмиссий
    • 0
      Отличные предложения. На самом деле, если Вам интересно, то в статье авторы разбирают многие из техник, которые Вы предложили (и придуманы они уже давно). Всего авторы приводят 3 типа стеганографии при помощи TCP: (i) модификация пакетов и хедеров, (ii) модификация свойств соединения (изменение порядка следования пакетов, варьирование времени между пакетами и т.д.) и (iii) гибридные. Свой метод авторы относят к последней категории.
    • 0
      Такие вещи уже давно используются.
      • 0
        я знаю что используются;) я предложил что можно добавить к данному методу
  • +1
    Вот их сайт — stegano.net/

    там и про стеганографию в WAN есть
  • +1
    Более чем уверен, что хорошие IDS, использующие поиск аномалий в трафике распознают эту стеганографию с полпинка.
  • 0
    Эффективней тогда уж тогда обычной стеганографией пользоваться в образах DVD-фильмов или в авишках, косяк в 1 пикселе на фрейме вряд-ли кто заметит, а даже если и заметит — извиняйте хреново пожалось. Опять же при закрытом алгоритме размещения пикселя в кадре — замучаешься доказывать и расшифровывать.
    И никто не докапается — а почему у тебя потери пакетов выше нормы? ;)
  • 0
    Я так понимаю, посылатся обычный пакет и ретрансмиссия.
    Тогда передача обнаруживается простым сравнением этих пакетов. Не так ли?

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

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

    Н ыпра нчог ыдганду :)
    • 0
      В топике не про шифрование данных, а про сокрытие факта передачи.
      Если вы выйдете в центр города и начнете кричать бессмыслицу вроде «Н ыпра нчог ыдганду», думаете, милиция вас не услышит? ;-)
  • 0
    Помимо того, что пропускная способность этого метода чудовищно низкая (как уже заметили в каментах выше), у этого метода ещё один существенный минус. Передача не защищена от ошибок на уровне TCP, т.к. сам этот метод паразитирует на средстве защиты.
  • 0
    Или я ничего не понял, или одно из двух. Этим методом вы пытаетесь скрыть сам факт передачи данных? Это при том, что в IP пакете явно прописан IP адрес получателя пакета, а в TCP — номер порта получателя. Таким образом, явно видно, что некие данные (не важно какие именно) пересылаются из токи А в точку Б. Ну и где здесь скрытая передача данных?
    • 0
      в том что порт этот может быть портом http. из цепочки пакетов сниффер покажет что пользователь просто ходил по сайту. а на самом же деле между хостами среди пакетов запросов ответов HTTP шел обмен данными другого рода.
      • 0
        Между какими хостами? Между клиентом и сайтом? Да, шел обмен данными, среди которых были конфиденциальные данные. Где здесь сокрытие факта передачи данных, я вас спрашиваю?
        • 0
          Подобный вопрос уже был выше, под ним и ответ. Повторюсь, во-первых можно пытаться скрыть факт передачи тайной информации. Тогда факт наличия соединения не играет роли — мы не пытаемся его скрыть. Во-вторых если все-таки нежелательно чтобы вообще знали о факте хоть какой-нибудь передачи, то как я писал выше, отправитель и получатель «нормальных» данных может вообще и не знать о факте тайной переписки.
  • 0
    > Security through obscurity

    Безопасность по незнанию?)
  • 0
    Не знаю что там используют Специально Обученные Люди, но повторно переданные пакеты подсвечивает другим цветом наиболее известный бесплатный софт для анализа — wireshark. Если у обьекта наблюдения на фоне остального нормального трафика пакеты по конкретному адресу постоянно красные, это тут же наведет аналитика на мысли.
    • 0
      Все верно, вопрос тут в том куда смотреть. Если у вас в секунду более 1000 TCP соединений в каждом из которых по 1000 пакетов, то Wireshark тут не помощник — в ручную перелопатить такой объем данных нереально.
      • 0
        Один человек столько не генерирует. Специально Обученные Люди действуют по решению суда или по секретному приказу начальника ( ну это в теории). В этот момент за кем наблюдать уже известно и трафика не так уж много.
        Не вижу проблемы.
        • 0
          Верно, если знать куда смотреть, то проблемы нету. Весь смысл метода и заключается в том, чтобы скрыть тайную пересылку в куче пакетов и соединений.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.